Кратко

  • RFC 2422 включил порядок байтовой упаковки в контракт audio/32KADPCM: более раннее кодовое слово занимает младший полубайт, следующее — старший.
  • При нечётном числе кодовых слов стандарт предпочитает дополнить выборку тишиной; иначе отбрасывается последнее слово. Это снимает неоднозначность интерпретации, но ничего не доказывает о доставке или прослушивании сообщения.

Кодек уже выполнил свою математическую работу. Рекомендация ITU-T G.726 описывала адаптивную дифференциальную импульсно-кодовую модуляцию и преобразование между 64-кбит/с PCM по закону A или μ с частотой 8000 отсчётов в секунду и каналами с меньшей скоростью, включая 32 кбит/с. При скорости 32 кбит/с на каждый отсчёт приходятся четыре бита. Этого достаточно, чтобы понять, как формируется кодовое слово, но недостаточно, чтобы определить, какая половина восьмибитного байта содержит более раннее слово.

Эту разницу легко не заметить в описании кодека, однако она способна сорвать обмен. Две реализации могут согласовать последовательность четырёхбитных значений и при этом помещать каждую пару в противоположные половины байта. В каждой локальной схеме октеты допустимы; читатель, использующий другую схему, восстановит иную последовательность. Для этого не требуется ни повреждённый файл, ни сорванная почтовая транзакция. Неоднозначность возникает уровнем ниже: одного MIME-подтипа недостаточно, чтобы понять, какую локальную договорённость имел в виду отправитель.

RFC 1911 уже включал Audio/32KADPCM в число обязательных общих аудиоформатов экспериментального Voice Profile for Internet Mail. Он определял место кодирования в ограниченном профиле обмена сообщениями, но не устанавливал порядок четырёх битов. RFC 2422, опубликованный в сентябре 1998 года в категории Standards Track и прямо уточняющий прежнюю регистрацию, закрыл этот пробел. Он зарегистрировал audio/32KADPCM для данных G.726 и сделал одну схему сериализации частью смысла подтипа.

Отображение задано точно. В каждом октете первое кодовое слово A занимает биты 0–3: его младший бит A0 помещается в младший бит октета. Следующее слово B занимает биты 4–7, причём B3 находится у старшего края. Каждая последующая пара упаковывается так же. Это не разворот всего аудиопотока и не изменение адаптивного предиктора G.726. Речь идёт только о порядке двух полубайтов внутри одного байта.

Такая точность одновременно распределяет работу. RFC 2422 отмечает, что существующие кодеки G.726 могут использовать разный порядок кодовых слов. Поскольку этот MIME-тип допускает только little-endian-схему, кодек с противоположным порядком обязан переставить слова до записи данных в этот тип либо после их чтения. Одного общего названия недостаточно для совместимости. Стандарт делает точку преобразования на границе видимой и проверяемой, вместо того чтобы оставлять каждой паре реализаций частные переговоры.

Неполная последняя пара показывает ещё одну границу. RFC предпочитает продлевать речевую выборку тишиной, чтобы получить чётное число кодовых слов. Если число всё же нечётное, последнее слово отбрасывается. Это не эстетическое пожелание о тихом окончании: оно объясняет анализатору, что означает свободная половина байта. Без такого правила контейнер завершался бы на границе байта, а последовательность кодека — между полубайтами; читателям пришлось бы самим решать, считать ли последнюю половину значимой.

У подтипа нет обязательных или необязательных параметров. Его тело содержит двоичные аудиоданные G.726 без аудиозаголовка; MIME-кодирование передачи может быть двоичным или, как правило, Base64. Это разные решения. Base64 меняет способ передачи октетов через почтовую систему, но после декодирования не меняет, в каком полубайте находятся A и B. Смешивать транспортное кодирование с порядком кодовых слов — значит путать оболочку байтов с их смыслом.

Так RFC 2422 рассказывает короткую, но важную историю стандартизации. Описать преобразование не всегда достаточно, чтобы определить совместимый объект. Как только результат пересекает границу, частью контракта становятся также порядок, дополнение и ответственность. Документ не показывает, насколько широко правило было реализовано, какой-либо ошибочный кодек или факт прослушивания сообщения адресатом. Зато он ясно указывает, где реализация должна принять решение и где MIME-подтип перестаёт оставлять его локальным.