要約

  • RFC 2422は、audio/32KADPCMの契約にバイト配置を加えた。先に現れる符号語を下位ニブル、次の符号語を上位ニブルに置く。
  • 符号語数が奇数なら、無音を加えて偶数にする方法を推奨し、それでも奇数なら最後の符号語を捨てる。これはバイトの読み方を確定する規則であり、メールの配送や再生を証明するものではない。

コーデックの数学的な仕事はすでに済んでいた。ITU-T勧告G.726は、適応差分パルス符号変調と、毎秒8,000サンプルの64 kbit/s A則またはμ則PCMから、32 kbit/sなどの低い速度への変換を規定していた。32 kbit/sでは、1サンプルを4ビットで表す。これで符号語の生成方法はわかる。しかし、8ビットの1バイトのどちら半分に先の符号語を置くかまでは、それだけでは決まらない。

この違いはコーデックの説明に埋もれるほど小さい一方、相互交換を妨げるには十分だ。二つの実装が同じ4ビット値の列を生成しても、各組をバイトの反対側に格納することがある。どちらのローカル規約でもオクテット自体は有効だが、別の規約で読む側は異なる列を復元する。ファイル破損やメール処理の失敗がなくても起こりうる。曖昧さは一段下にある。MIMEサブタイプだけでは、送信側がどちらのローカル規約を想定したかを受信側は知れない。

RFC 1911は、実験的なVoice Profile for Internet Mailの必須共通音声形式に、すでにAudio/32KADPCMを含めていた。制約のあるメッセージング・プロファイル内での役割は定めたが、4ビットの順序は決めていなかった。1998年9月にStandards Trackとして公開されたRFC 2422は、以前の登録を明示的に精緻化し、この隙間を埋めた。G.726データ用にaudio/32KADPCMを登録し、単一のシリアライズ規約をサブタイプの意味に組み込んだ。

対応関係は明確だ。各オクテットで最初の符号語Aはビット0〜3を使い、最下位ビットA0をオクテットの最下位位置に置く。次の符号語Bはビット4〜7を使い、最上位側にB3を置く。その後の組も同じ配置を繰り返す。音声ストリーム全体を逆順にする規則でも、G.726の適応予測器を変える規則でもない。1バイト内にある二つのニブルの順序を定めている。

この精密さは、作業の分担も明らかにする。RFC 2422は、既存のG.726コーデックで符号語の順序が異なる場合があると記している。このMIMEタイプが認めるのはリトルエンディアン配置だけなので、逆の規約を使うコーデックは、このタイプで保存する前、または読み出した後に符号語を並べ替えなければならない。共通の名前を付けるだけでは相互運用性は得られない。規格は変換箇所を見える形にし、実装ごとの非公開な調整に委ねない。

最後の組が欠ける場合には、もう一つの境界が表れる。RFCは、符号語数が偶数になるよう音声サンプルに無音を加えることを推奨する。それでも奇数なら、最後の符号語を捨てる。これは無音で終える美的判断ではない。残った半バイトをパーサーがどう扱うかを定めている。規則がなければ、コンテナはバイト境界で終わるのにコーデックの列はニブルの途中で終わり、最後の半分を有効とみなすかどうかを各読取側が推測することになる。

このサブタイプには必須・任意いずれのパラメーターもない。本文はオーディオヘッダーを含まないG.726のバイナリー音声データで、MIMEの転送エンコーディングはバイナリー、または通常Base64が使われる。これは別々の判断だ。Base64はメールシステム内でオクテットを運ぶ方法を変えるが、本文を復号した後にAとBがどのニブルにあるかは変えない。転送エンコーディングを符号語順の答えと取り違えると、バイトを包む形式とバイトの意味を混同してしまう。

RFC 2422は、短いながらも規格化の要点を示している。変換方式を定義するだけでは、相互運用できるオブジェクトを定義しきれないことがある。出力が境界を越えるなら、順序、補完、責任も契約の一部となる。この文書は、規則がどれほど実装されたか、どのコーデックが誤っていたか、受信者がメッセージを聞いたかを示してはいない。その代わり、実装が明示的に判断すべき箇所と、MIMEサブタイプが判断をローカルに残さなくなる地点を示している。