RFC 3190：有効な音声標本が DV エラーになる境界

要約

DV では 12 ビットの 800h、16 ビットの 8000h、20 ビットの 80000h が、磁気テープから有効な音声を読めなかったことを示した。波形の底ではなく、標本の不在を伝える番兵だった。

RFC 3190 の RTP 表現には欠番がない。DAT12、L20、L24 の全数値が音声であり、L16 も同じである。他の音源が本当に負のフルスケールを生成することは許される。

したがってビット列の保存だけでは意味を保存できない。DV から出るときは欠けた音に代用品を選び、DV に入るときは本物の音が故障扱いされないようにする必要があった。

DV から RTP へ渡す送信者にはエラー隠蔽が推奨された。単発と連続欠損で処理を変えられるよう、方式は実装に委ねられた。番兵を音としてそのまま送ることも可能だったが、好ましくない出力になり得る。

補間や反復は期限のある再生には有用である。しかしテープが返さなかった標本を回復するわけではない。置換後の RTP パケットが証明するのは、変換器が選んだ修復値である。

ネットワーク記録が完全でも、上流の読み取り失敗は消えているかもしれない。滑らかな音声ほど故障を発見しにくい。元の番兵を別に保存しなければ、後の調査は録音と生成値を区別できない。

RTP の負のフルスケールをそのまま DV に渡すと、装置がエラーと解釈する。RFC は 800h を 801h に、8000h を 8001h に移すよう勧告した。

20 ビットでは 80000h から 8000Fh までを 80010h に移す。16 ビット装置が下位四ビットを捨てて再生すると、十六個の値が同じ 16 ビット番兵になるためである。

これは意図的な数値変更だった。厳密性を少し失い、意味の誤判定を防いだ。24 ビットの変換がないのは、参照された DV 仕様にその符号化がないからである。

DAT の長時間モードは 16 ビット線形標本を 12 ビット非線形値にした。L16 に展開して送れば容易だが、帯域を 33 パーセント余計に使う。DAT12 は圧縮された表現を維持した。

-2048 から 2047 の二の補数値を上位ビットから連続して詰め、奇数標本なら最後のオクテットの下位四ビットを使わない。L20 にも同じ半オクテットがあり、L24 はオクテット境界に揃う。

正しい長さは数値を取り出せることを示すだけである。隠蔽がなかったことや、聴感が忠実であることは示さない。完全なパーサーは補修値も完全に再現する。

RTP は同じ時刻の各チャネル標本を並べてから次の時刻へ進む。DV のネイティブブロックは別の順序である。抽出した音声を DAT12、L20、L24、L16 で送る実装は標本を並べ替えなければならない。ネイティブな音声・映像ブロックを保つなら DV ペイロードを使う。

一から三チャネルは AIFF-C 順を暗黙に用いた。四チャネル以上は channel-order で許可された DV 配置を示し、チャネル数と一致させる。記号を区切りなしで連結したのは、任意の順序を作らせないためだった。

五チャネルは選択肢が一つでも明示が必要で、小規模構成では後方互換のため属性を付けてはならない。また同時再生する成分は一つの流にできるが、別言語のような独立番組は別セッションに分けるべきだとされた。

アナログのプリエンファシスは量子化前に行われる。RFC は emphasis=50-15 を帯域外で伝え、処理がない場合は属性を含めてはならないとした。

古い実装が SDP を受理しながら属性を無視することはあり得る。パケットも標本も正しいまま、受信音が明るすぎたり送信音が鈍くなったりする。交渉成功は再現成功ではない。

ペイロード名、レート、チャネル数、順序、プリエンファシスは別々の主張である。全部が相手に届き、正しく適用されて初めて意図した音に近づく。

RFC 3190 は audio/DAT12、audio/L20、audio/L24 を登録し、テープ機器と RTP の間に明示的な橋を置いた。橋は差異を消さず、どこで処理するかを示した。

エラー隠蔽、標本移動、チャネル再配置、無視され得る属性は、どれも運用上は合理的である。同時に、新しい表現を作る行為でもある。

8000h の意味はビットの内部にはなかった。契約が音にし、別の契約が欠損にした。修復後の音を事実の全てにしないためには、変換記録を波形の外に残す必要がある。