BW64 и ADM: техническая справка по иммерсивному звуку

Рабочий справочник для звукорежиссёра, который готовит объектный или сцен-ориентированный мастер, и для музыканта, которому выдали «атмос-деливери» и сказали, что он должен пройти техприёмку.

Короткий ответ

ADM (Audio Definition Model, модель определения звука) — открытая модель метаданных, Рекомендация ITU-R BS.2076. Она описывает, чем является каждая дорожка в файле: каналом конкретного громкоговорителя, движущимся объектом или компонентой амбисоники, — и как эти дорожки собираются в программу. Сами метаданные — это XML, лежащий внутри контейнера BW64 (Рекомендация ITU-R BS.2088), 64-битного расширения RIFF/WAVE, которое снимает потолок в 4 ГБ, унаследованный от классического WAV. Иммерсивные поставки заворачивают на техприёмке не потому, что они плохо звучат, а потому, что звук и метаданные — две отдельные сущности, которые обязаны совпадать, и в формате нет ничего, что заставило бы их совпасть. Число каналов в fmt , не сходящееся с таблицей chna; audioTrackUID, на который никто не ссылается; блок с временем, идущим назад; подложка, описанная в XML, но не выведенная на диск, — всё это невидимо в редакторе волны и смертельно для рендерера. Проверка ADM — это проверка целостности ссылок, а не прослушивание.

1. Почему разговор о высоте лучше всего начинать в каменном храме

Прежде чем говорить о контейнере, нужно договориться о модели. Почти всякая проблема иммерсивной поставки начинается с путаницы в том, чем именно является дорожка.

Проще всего это объясняется не на списке форматов, а на записи, которую в России делали и делают постоянно, — православное богослужение в каменном храме.

Встаньте в середине храма. Хор поёт с клироса, то есть сбоку и обычно выше уровня головы. Диакон произносит ектению, и произносит её не с одного места: он выходит на амвон, поворачивается, идёт вдоль солеи. Возглас священника приходит из алтаря, из-за иконостаса, то есть спереди, но приглушённо и с другой окраской, потому что между вами и источником стоит преграда. Ответ хора приходит сбоку. А над всем этим — купол, и отражения от него приходят сверху с задержкой, которая слышна ушами, а не измеряется прибором: это единственная часть звуковой картины, которую невозможно ни имитировать реверберацией, ни свести в горизонтальную раскладку.

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

Отсюда — три модели ADM, каждая на своём месте.

Канальный звук (channel-based). Каждая дорожка назначена на фиксированную позицию громкоговорителя. Стерео — канальный звук. 5.1 — тоже. «Подложка» 7.1.4 — тоже. Позиция вшита в саму идентичность канала: дорожка 3 — это центр, и она остаётся центром на любой системе. ITU-R BS.2051 формализует это для перспективных систем звука, описывая раскладки как число громкоговорителей в трёх слоях — верхний + средний + нижний: система A — 0+2+0 (стерео), B — 0+5+0 (5.1), D — 4+5+0, J — 4+7+0, H — 9+10+3 (та самая 22.2). В ADM это typeDefinition DirectSpeakers, typeLabel 0001.

Объектный звук (object-based). Дорожка несёт моносигнал (или пакет каналов) плюс метаданные позиции, которые меняются во времени. Куда именно это выведется, решает рендерер, исходя из раскладки, реально имеющейся в помещении. Дорожка ничего не предполагает о громкоговорителях. typeDefinition Objects, typeLabel 0003.

Сцен-ориентированный звук (scene-based). На практике — амбисоника высоких порядков (HOA). Кодируется всё звуковое поле целиком, набором сферических гармоник. Ни одна компонента сама по себе не соответствует направлению; направление возникает из линейной комбинации. typeDefinition HOA, typeLabel 0004. ADM определяет ещё Matrix (0002) — для матрицированных сигналов вроде MS или Lt/Rt — и Binaural (0005) для готовой наушниковой пары.

Сколько каналов стоит амбисоника. Порядок HOA и число компонент связаны жёстко: для порядка N компонент ровно (N+1)². Первый порядок — 4 канала, второй — 9, третий — 16, четвёртый — 25. Это не абстракция, а прямая строка в бюджете файла и в бюджете смены: третий порядок в 48 кГц / 24 бит даёт 2 304 000 байт/с, и предел RIFF наступает через 1864 секунды — 31 минуту 4 секунды. Четвёртый порядок — через 19 минут 53 секунды. Всенощное бдение при этом идёт три часа и пишется без остановок. Иными словами, выбор порядка амбисоники — это одновременно выбор пространственного разрешения и выбор того, обязателен ли вам BW64; и ответ на второй вопрос при любом порядке выше первого — «да».

Компромисс порядка стоит проговорить отдельно, потому что в храме он ощутим. Первый порядок даёт устойчивый объём и совершенно размытые источники: хор на клиросе перестаёт быть точкой и становится «где-то слева». Третий порядок уже локализует диакона настолько, что слышно его поворот. Разница между ними — двенадцать дополнительных каналов и вчетверо более быстрый расход дискового бюджета.

Канальный звук сообщает файлу, где стоят громкоговорители; объектный отказывается гадать; сцен-ориентированный описывает не источники, а поле.

Храм — случай, где сцен-ориентированный подход выигрывает по существу, а не по моде. Вам не нужно перечислять источники: их слишком много, они гулкие, половина из них — отражения, и главный «источник» — сам объём. Микрофон высокого порядка, поставленный в середине храма, записывает поле, и это поле потом можно развернуть в любую раскладку BS.2051, включая ту, которой не было на площадке.

И тут же — практический вывод, ради которого всё это и написано. Канальная поставка достаточно самоописательна, чтобы выжить в виде голого WAV: правильный порядок каналов — и оно играет. Объектная и сцен-ориентированная поставка без метаданных бессмысленна: аудио превращается в стопку неразличимых моно-потоков, и единственное, что говорит обратное, — это ADM. Именно эта асимметрия и есть причина существования BW64 и ADM, и она же — причина, по которой иммерсивная техприёмка сложнее стереофонической.

2. Колокольный звон, хор и оркестр: когда объект, когда подложка

Три коротких случая, которые вместе покрывают почти все решения на этапе планирования записи.

Колокольня — набор источников на реальной высоте. Звонница — это не «эффект сверху». Это несколько колоколов, физически висящих на десяти-двадцати метрах над слушателем, каждый со своим спектром и своим ритмическим рисунком, причём звонарь работает ими как одним инструментом: благовест, трезвон, перезвон. В горизонтальной раскладке этот материал воспроизвести нечем — не потому, что «не хватает эффекта», а потому, что направление прихода прямого звука лежит выше плоскости громкоговорителей. Это второй после купола случай, где верхний слой не украшение, а носитель информации.

Крестный ход — учебниковый объект с изменяющейся во времени позицией. Ход обходит храм: он выходит из западных дверей, идёт вдоль стены, скрывается за апсидой, появляется с другой стороны и возвращается. Слушатель, стоящий у входа, слышит источник, который непрерывно меняет азимут, проходит полный круг, теряет прямой звук за углом здания и получает его обратно. Это ровно то, для чего в ADM существует последовательность audioBlockFormat с rtime и duration: не «панорама туда-сюда», а траектория, у которой есть физический прообраз и которую можно проверить на правдоподобие. Заодно это отличный тестовый материал: если рендерер криво обходит зоны между громкоговорителями, крестный ход это покажет мгновенно, потому что ухо знает, как должен двигаться поющий хор, и слышит рывок.

Большой симфонический оркестр — случай канальной подложки. Рассадка фиксирована и известна заранее: первые скрипки слева, вторые правее, альты и виолончели, контрабасы, деревянные духовые в глубине, медь и ударные за ними. Ничего не движется. Пытаться описать сто музыкантов ста объектами — значит выдумать сто траекторий, каждая из которых на самом деле константа, и получить файл, который тяжелее, хрупче и не звучит лучше. Правильное решение — снять зал главной системой, положить это в канальную подложку 5.1.4 или 7.1.4 и добавить объектами только то, что действительно требует отдельного обращения: солиста, орган (у которого своя высота), хор на балконе.

Малый ансамбль — противоположный случай. Четыре музыканта: домра, балалайка, баян, ударные — или струнный квартет, или фольклорный состав. Каждый исполнитель — действительно дискретный источник, снятый близким микрофоном, с собственной позицией, которую есть смысл задать точно и, при желании, менять. Здесь объектная модель не вычурность, а самое простое описание реальности: четыре объекта, четыре позиции, никаких вымышленных каналов. И, что важнее, такой мастер переносим: он одинаково осмысленно развернётся и в 4+5+0, и в 4+7+0, и в бинаурал, потому что нигде не зашита раскладка.

Правило, которое почти никогда не подводит: если источник не двигается и его позиция известна заранее — это подложка. Если источник двигается или его позиция важна с точностью, которой нет у сетки громкоговорителей, — это объект.

3. BW64: что это и зачем именно понадобилось

Классический WAV — это файл RIFF. RIFF, спецификация 1991 года, снабжает каждый чанк 32-битным полем размера. Тридцать два бита адресуют 4 294 967 296 байт — 4 ГиБ, ровно 4096 МиБ, — и это жёсткий потолок и для файла целиком, и для чанка data внутри него. Максимальное значение, которое можно записать в такое поле, — 0xFFFFFFFF, то есть 4 294 967 295.

Посчитаем, что это значит на практике. Скорость потока = число каналов × число байт на отсчёт × частота дискретизации.

Арифметика проверяется в одну строку: 28 дорожек × 3 байта × 48 000 = 4 032 000 байт/с, и 4 294 967 296 ÷ 4 032 000 = 1065,2 с. Для 22.2 на 96 кГц: 24 × 3 × 96 000 = 6 912 000 байт/с, и 4 294 967 296 ÷ 6 912 000 = 621,4 с.

Теперь посмотрите на эти цифры глазами человека, записывающего литургию. Полная литургия идёт от полутора до двух с половиной часов и пишется одним куском — остановить службу нельзя, склеивать дубли нечего. Всенощное бдение длиннее. Симфонический концерт с антрактом — два часа. Даже в скромной раскладке 7.1.4 с несколькими объектами вы упираетесь в потолок RIFF на восемнадцатой минуте. Это не пограничный случай, который встречается у кого-то другого: это гарантированное превышение в первом же серьёзном проекте. А писатель WAV, наткнувшийся на предел, выдаёт либо обрезанный файл, либо файл, в котором объявленные размеры молча переполнились, — и второе хуже, потому что оно открывается.

Первой проблему решила EBU форматом RF64 (EBU Tech 3306). ITU затем развил эту работу в Рекомендацию ITU-R BS.2088, Long-form file format for the international exchange of audio programme materials with metadata, — то есть BW64. Механизм в BS.2088 описан прямо:

«The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file» — ITU-R BS.2088

и далее:

«If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead.» — ITU-R BS.2088

Весь фокус в этом, и его стоит проговорить открытым текстом:

BW64 не расширяет 32-битные поля размера. Он заполняет их значением 0xFFFFFFFF как признаком «смотри в другом месте» и кладёт настоящие 64-битные размеры в чанк ds64, который обязан стоять первым.

BW64 удобно понимать как третье поколение одной линии. RIFF/WAVE дал чанковый контейнер. Broadcast Wave (BWF, EBU Tech 3285) добавил чанк bext — источник, привязку к таймкоду, историю кодирования, — превратив WAV в формат вещательного обмена. BW64 сохраняет всё это, добавляет 64-битную адресацию и добавляет чанки, несущие ADM. Файл BW64 размером меньше 4 ГиБ побайтно совместим с обычным WAV-ридером во всём, кроме четырёх символов сигнатуры; многие программы это переживают, а некоторые упрямо нет — и это отдельная причина проверять, что именно записал экспортёр.

4. Раскладка чанков, подробно

Файл BW64 по BS.2088 должен содержать как минимум <ds64-ck>, <fmt-ck>, <chna-ck>, <axml-ck> (с <bxml-ck> и <sxml-ck> как альтернативными носителями метаданных) и <wave-data>.

4.1. ds64 — таблица 64-битных размеров

Обязан идти первым чанком после сигнатуры BW64, потому что читателю нужно узнать настоящие размеры прежде, чем он сможет обойти файл. Поля — 32-битные половины 64-битных величин:

Минимальное тело: 8 + 8 + 8 + 4 = 28 байт, вместе с заголовком ckID+ckSize — 36 байт. Каждая запись table[] — это идентификатор чанка (4 байта) плюс младшая и старшая половины размера (4 + 4), то есть 12 байт на запись.

table[] важнее, чем кажется. Чанк axml, описывающий тысячи объектов с посемпловой автоматизацией, сам может подойти к 4 ГиБ и превысить их; таблица — единственный способ для любого чанка, кроме data, объявить 64-битный размер.

4.2. fmt — описание сущности

Обычный WAVE-чанк формата: формат отсчётов, частота дискретизации, число каналов, разрядность, выравнивание блока. Это единственное авторитетное утверждение о том, сколько чередующихся каналов на самом деле лежит в data. Всё остальное — метаданные о каналах, а метаданные могут врать.

4.3. chna — таблица распределения каналов

chna — мост между физическими дорожками и ADM. Начинается с:

• ckID — 4 байта, 'chna'
• ckSize — 4 байта
• numTracks — 2 байта, число дорожек в файле
• numUIDs — 2 байта, число следующих записей audioTrackUID

Итого заголовок — 12 байт. Дальше идёт плоский массив записей audioID фиксированной ширины. Каждая запись занимает ровно 40 байт:

2 + 12 + 14 + 11 + 1 = 40. Проверьте сами — это ровно та арифметика, которую чаще всего переписывают друг у друга с ошибкой. Ширины полей не рекомендательные: это ASCII фиксированной длины, и писатель, выдавший UID из 13 символов, произвёл не «слегка необычную», а испорченную таблицу, в которой поехало всё, что стоит после.

Отсюда сразу считается размер чанка. Для мастера 7.1.4 плюс 16 объектов — 28 дорожек, 28 UID: 12 + 28 × 40 = 1132 байта. Для 22.2 в 24 каналах: 12 + 24 × 40 = 972 байта. Величины крошечные, и именно поэтому chna дёшево разобрать и сравнить с fmt — это самая быстрая проверка во всём тракте.

Отдельно — соглашение об идентификаторах: значения 0x0FFF и ниже отсылают к общим определениям ADM (common definitions), то есть к стандартным, заранее описанным форматам каналов и пакетов; значения 0x1000 и выше означают пользовательские определения, которые обязаны присутствовать в axml. packRef, равный AP_00010003, — это 5.1 по общему определению, и XML для него не нужен; AP_00031001 — пользовательский объектный пакет, и без XML эта ссылка повисает.

audioTrackUID — это заводской номер, который файл присваивает идентичности одной физической дорожки. Он существует именно затем, чтобы дорожка имела право посреди программы поменять то, что она несёт.

Из-за этого numUIDs вполне законно может быть больше numTracks. В руководстве EBU это сказано прямо: там, где «the audio elements of a track may be [defined] differently in the course of a file … there will be a different UID for each definition». Один и тот же trackIndex может, следовательно, встретиться в нескольких записях. Проверяльщики, наивно считающие, что UID на дорожку ровно один, помечают корректные файлы как сломанные.

Живой пример как раз из нашей темы: дорожка, на которой в первой части записи лежит стационарный объект «хор на клиросе», а после — движущийся объект «крестный ход», честно получает два разных UID при одном trackIndex. Это не ошибка сведения, это ровно тот случай, ради которого механизм и придуман.

4.4. axml — сам ADM

XML-документ в UTF-8, содержащий дерево <audioFormatExtended>. Это и есть ADM. Он текстовый, его можно прочитать глазами и продиффить, и именно в нём живут практически все интересные отказы.

4.5. data — чередующийся PCM

Обычные чередующиеся отсчёты, ровно как в WAV. Ничто внутри data не знает ни о каких объектах.

4.6. Порядок чанков

ds64 — всегда первым. fmt — раньше data. А вот axml вполне законно может стоять после data и часто там и стоит, потому что, как замечает BS.2088, во время записи «the XML metadata will likely be of an unknown length» — длина XML заранее неизвестна. Файл с axml в хвосте не испорчен; но читатель, сканирующий только первый мегабайт, доложит, что ADM в файле вообще нет. На этот единственный факт приходится удивительно большая доля жалоб «мой файл потерял метаданные».

4.7. bext и то, ради чего его стоит заполнять

Чанк bext пришёл из BWF (EBU Tech 3285) и в BW64 сохранён без изменений: имя источника, дата и время, опорный таймкод (TimeReference в отсчётах от полуночи), UMID, история кодирования. В стереофоническом мире его игнорируют. В иммерсивном игнорировать его нельзя, потому что поставка — это не файл, а комплект: иммерсивный мастер, стереоконформ, бинауральный конформ, иногда отдельные стемы. Единственное, что связывает их в одно целое во времени, — совпадающий опорный таймкод.

Классический сценарий отказа выглядит так: мастер записан с TimeReference, отсчитанным от начала записи службы, а конформ выведен из другой сессии с нулём в начале региона. Оба файла корректны, оба открываются, длительности совпадают — и они не совмещаются. Проверять это надо чтением поля, а не на слух.

История кодирования (CodingHistory) — свободный текст, и это единственное место в контейнере, куда осмысленно записать то, что нигде больше не хранится: чем сделан рендер, в какую раскладку, какой редакцией BS.1770 измерялась громкость. Формат этого не требует; через год вы будете благодарны.

5. Объектная модель ADM

ITU-R BS.2076 делит модель на две половины. Форматная часть «describes the technical nature of the audio so it can be decoded or rendered correctly» и может быть написана до того, как появится хоть один отсчёт звука. Содержательная часть описывает «the language of dialogue, the loudness, etc.» и может быть завершена только тогда, когда сигналы уже есть. Понимание того, к какой половине относится элемент, сразу говорит, на каком этапе производства родилась конкретная ошибка.

Иерархия сверху вниз:

• audioProgramme — одна законченная презентация поставки. Ссылается на один или несколько audioContent.
• audioContent — компонента программы с редакторским смыслом: стем диалога, стем музыки, языковая версия. Ссылается на один или несколько audioObject.
• audioObject — стык редакторского замысла и технического формата. Несёт время начала и длительность, ссылается на ноль и более audioPackFormat, ноль и более вложенных audioObject и ноль и более audioTrackUID. Здесь содержание встречается с сущностью.
• audioPackFormat — группа каналов, принадлежащих друг другу: подложка 7.1.4, стереопара, набор HOA заданного порядка. Ссылается на audioChannelFormat и может вкладывать другие пакеты.
• audioChannelFormat — поведение одного канала во времени. Содержит один или несколько audioBlockFormat.
• audioBlockFormat — атом. Для Objects — позиция (azimuth/elevation/distance либо декартовы X/Y/Z), усиление, размер, диффузность, плюс rtime и duration. Неподвижный объект — один блок; движущийся — последовательность.
• audioTrackUID — лист дерева и единственный элемент, соответствующий физической дорожке. Несёт необязательные атрибуты sampleRate и bitDepth и ссылается на audioTrackFormat и audioPackFormat.

audioStreamFormat и audioTrackFormat стоят между форматом канала и UID дорожки и описывают кодирование потока. BS.2076-3 отмечает, что для PCM они по сути избыточны — «the audioStreamFormat and the audioTrackFormat should be omitted», — но читатель «should be aware that existing ADM files (based on Recommendation ITU-R BS.2076-2 and earlier) for PCM audio may contain» их. Обе формы законны. Валидатор, требующий ровно одну из них, ошибается насчёт другой.

ADM — это граф ссылок, а не вложенный документ, и всякий серьёзный отказ поставки есть разорванное ребро в этом графе.

Что происходит, когда ссылка повисает. Единого поведения нет — в этом и беда. Рендерер, разрешающий audioPackFormatIDRef на пакет, отсутствующий в XML, может прервать разбор и отклонить файл; может пропустить этот объект и отрендерить всё остальное, тихо выдав микс без одного стема; может уйти в общие определения, не найти там идентификатор из пользовательского диапазона 0x1000+ и подставить тишину. Все три исхода выглядят одинаково: «файл открылся». Только один из них ловится на слух, и то лишь если вы точно знаете, что там должно было быть.

Возьмите храмовую запись. Ектения — отдельный объект, и её содержание вы, скорее всего, знаете наизусть. А отражение от купола, положенное отдельным объектом с большим size и высокой диффузностью, — не знаете: если оно пропало, вы услышите «чуть суше», а не «нет объекта». Ровно поэтому проверка ADM обязана быть машинной: человеческое ухо не слышит отсутствия того, о чём его не предупредили.

6. Типовые отказы и как поймать каждый

Ниже — отказы в том порядке, в каком их дёшево проверять. Первые три ловятся за миллисекунды и обесценивают всё остальное.

6.1. Расхождение числа каналов между fmt и chna

fmt.nChannels говорит 16, chna.numTracks говорит 14. Файл внутренне противоречив уже на втором чанке. Обычная причина — бонс, изменивший число дорожек после того, как метаданные были написаны, либо конвертер, выбросивший дорожки и не переписавший chna.

Как ловить: разобрать оба чанка и сравнить два целых числа. Это самая дешёвая проверка во всём тракте, и на неё приходится поразительная доля отказов. Заодно убедитесь, что каждый trackIndex в chna лежит в диапазоне 1 … fmt.nChannels.

6.2. Осиротевшие UID дорожек

UID, присутствующий в chna, на который не ссылается ни один audioObject, — или audioTrackUIDRef в XML, которому не соответствует запись в chna. Первое означает, что в файле лежит звук, который никто не отрендерит; второе — что метаданные ждут дорожку, которой нет.

Как ловить: построить множество UID из chna и множество из axml и взять симметрическую разность — она обязана быть пуста.

Практический сценарий: в сессии литургии объект «диакон» был выключен на этапе сведения, дорожку убрали из бонса, но axml остался прежним. Граф ссылается на дорожку, которой в data нет. Часть рендереров подставит тишину и не скажет ни слова.

6.3. Повисшие ссылки в пользовательском диапазоне

packRef со значением 0x1000 и выше обязан разрешаться в определение, физически присутствующее в axml. Если экспортёр записал AP_00031001, а XML описывает только AP_00031002, ссылка повисла. Хуже всего то, что часть рендереров в этой ситуации молча уходит в общие определения, не находит там ничего и подставляет тишину.

Как ловить: собрать все идентификаторы, объявленные в axml, и проверить каждую ссылку из chna и из самого XML на принадлежность этому множеству.

6.4. Блоки с отсутствующим или немонотонным временем

Разбор — в разделе 7. Напомню только критерий обнаружения: для каждого audioChannelFormat пройти блоки в порядке документа и утверждать rtime[n] + duration[n] == rtime[n+1], а также что первый блок начинается в нуле и что сумма длительностей равна длительности родительского audioObject.

6.5. Несовпадение частоты дискретизации и разрядности

audioTrackUID может нести атрибуты sampleRate и bitDepth. Когда они противоречат fmt , у вас два разных утверждения об одной и той же сущности. Позиция EBU Tech 3392 — такие атрибуты «Should be ignored if available from the audio essence», то есть при наличии данных в самом звуке их следует игнорировать. Но не всякий рендерер следует этой рекомендации, и файл, в котором в одном месте написано 48 000, а в другом 96 000, будет по-разному истолкован разными программами.

Как ловить: сравнить fmt с каждым атрибутом sampleRate/bitDepth в XML и помечать любое расхождение, даже формально терпимое.

6.6. Метаданные описывают подложку, которой в файле нет

XML объявляет пакет DirectSpeakers 7.1.4 — двенадцать каналов, — а на диск выведено только подмножество 5.1, либо каналы высоты были заглушены на бонсе и записались цифровой тишиной. Граф ссылок при этом абсолютно цел. Звука нет.

Как ловить: структурные проверки бессильны, нужен анализ сущности: для каждого канала, заявленного пакетом DirectSpeakers, измерить, есть ли в дорожке сигнал вообще. Цифровая тишина в объявленном канале подложки не автоматически ошибка — законное сведение вполне может оставить верхний тыловой пустым, — но всегда требует человеческого решения.

Именно здесь храмовая запись даёт бесплатный критерий здравого смысла: если верхний слой пуст, купол не записался, и это ошибка с вероятностью, близкой к единице. Материал, у которого верх обязан быть заполнен, — лучший тестовый материал, какой можно придумать.

6.7. Несовпадение typeLabel между каналом и пакетом

audioChannelFormat с typeLabel 0003 (Objects), лежащий внутри audioPackFormat с typeLabel 0001 (DirectSpeakers), — противоречие, которое разные рендереры разрешают по-разному. Обычно это след ручной правки XML или склейки двух сессий.

Как ловить: сравнить typeLabel каждого канала с typeLabel родительского пакета; они обязаны совпадать.

6.8. Расхождение конформов

Разобрано в разделе 8: отсутствие видно, расхождение — нет. Считайте подозрительным любой конформ, который нельзя вывести из текущего мастера, и перерендеривайте вместо перепроверки.

Из восьми отказов выше слухом ловятся два. Остальные шесть — это чтение файла, и именно поэтому иммерсивную приёмку нельзя делать ушами.

7. Время: крестный ход как последовательность блоков

Движущийся объект в ADM — это цепочка audioBlockFormat, и требования к ней строгие.

BS.2076 не оставляет двусмысленности: «When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present». EBU Tech 3392 ужесточает это до правила непрерывности — «rtime + duration of an audioBlockFormat should match the rtime of the following block», — причём первый блок объекта начинается в 00:00:00.00000, ни один блок не короче одного отсчёта, а сумма длительностей совпадает с длительностью родительского audioObject.

Проверка простая: для каждого audioChannelFormat пройдите блоки в порядке документа и убедитесь, что rtime[n] + duration[n] == rtime[n+1]. Отказы сбиваются в три формы:

• разрывы — поведение рендерера не определено: один удержит последнюю позицию, другой замолчит;
• перекрытия — блоки спорят друг с другом;
• блоки не в хронологическом порядке — автоматизация, прыгающая назад посреди программы.

На крестном ходе всё это слышно и объяснимо. Разрыв в цепочке — процессия «зависает» у северной стены и потом телепортируется. Перекрытие — источник раздваивается на повороте. Обратный скачок — ход на секунду идёт против часовой стрелки, чего в реальности не бывает. Это, кстати, хороший приём приёмки: описывайте траекторию так, чтобы её неправдоподобие было слышно. Объект, который в жизни обходит здание за две минуты равномерно, не может в метаданных пройти четверть круга за один блок и остановиться.

Отдельно про частоту дискретизации: конвертация частоты, выполненная после авторинга ADM, обесценивает каждый rtime и duration, выраженные в отсчётах. SRC делают до, а не после.

8. Рендеринг: BS.2127 и раскладки BS.2051

Объектный файл сам по себе не звучит. Чтобы он зазвучал, его нужно отрендерить в конкретную раскладку громкоговорителей.

Эталонный рендерер ADM определён Рекомендацией ITU-R BS.2127, а его открытая реализация — EBU ADM Renderer (EAR, EBU Tech 3388). Целевые раскладки — те самые системы BS.2051: 0+2+0, 0+5+0, 4+5+0, 4+7+0, 9+10+3 и остальные. Одно и то же ADM-содержимое, поданное в BS.2127 с разными целями, даёт разные наборы каналов — и это не сбой, а смысл конструкции.

Практический вывод для храмовой записи. Верхний слой в 4+5+0 состоит из четырёх позиций; в 9+10+3 — из девяти. Купол, снятый амбисоникой высокого порядка или описанный объектами с ненулевым elevation, разложится в обе раскладки, но разложится по-разному, и звучать это будет тоже по-разному. Поэтому единственно осмысленная формулировка в сопроводительных документах — не «мастер иммерсивный», а «отрендерено рендерером X, соответствующим BS.2127, в раскладку BS.2051 <номер системы>». Три названные вещи — рендерер, раскладка, версия — делают результат воспроизводимым; их отсутствие превращает любые цифры ниже в анекдот.

Ещё одно, о чём стоит сказать честно: рендер в 0+2+0 (стерео) и в бинаурал — не «побочный продукт», а отдельная поставка, которую надо перерендеривать из текущего мастера. Самая частая ошибка тут не отсутствие конформа — отсутствие видно сразу, — а расхождение: конформ сделан из более ранней версии, сдвинут на несколько кадров или имеет другой стартовый таймкод. Стереофайл, опережающий свой иммерсивный оригинал на 40 мс, пройдёт проверку «файл на месте» и провалит синхронное прослушивание.

8.1. Почему бинаурал — не замена комнате, но и не пустышка

Бинауральный рендер — это Binaural (typeLabel 0005) на выходе или, чаще, результат работы BS.2127-совместимого рендерера с бинауральным целевым профилем. Он свёртывает поле с передаточными функциями головы, и в наушниках вы получаете подобие пространства.

Границы этого «подобия» надо знать точно, иначе вы будете принимать решения не по тем данным.

Бинаурал достоверно отвечает на вопросы: движется ли объект и в какую сторону; есть ли вообще сигнал в верхнем слое; не перепутаны ли фронт и тыл; не разъезжается ли крестный ход по времени. Это ровно те четыре вопроса, которые чаще всего и заваливают поставку.

Бинаурал не отвечает на вопросы: как распределена энергия между конкретными верхними громкоговорителями; сколько именно баса окажется в LFE; как поведёт себя тембр хора при переходе из 4+5+0 в 4+7+0. Индивидуальная разница передаточных функций головы велика, и подъём высоты в наушниках у разных слушателей ощущается по-разному — вплоть до того, что купол у одного «сверху», а у другого «сзади».

Вывод простой: бинаурал — это инструмент верификации, а не мониторинга. Он годится, чтобы доказать, что файл не сломан. Он не годится, чтобы принять художественное решение о балансе верхнего слоя.

9. Громкость иммерсивного материала

Здесь особенно важно отделить опубликованное от циркулирующего.

9.1. Что специфицирует ITU-R BS.1770

Действующая редакция — BS.1770-5 (ноябрь 2023). BS.1770-4 (октябрь 2015) отменена и заменена, хотя именно на неё до сих пор ссылается большинство установленных измерителей. Называть текущей следует пятую редакцию.

Механика:

• K-взвешивание — каскад из двух звеньев: высокочастотный шелф («головной» фильтр, моделирующий влияние головы как жёсткой сферы), затем ФВЧ RLB. Усиление кривой на 1 кГц — +0,698 дБ, линейный множитель 1,0836.
• Измерение ведётся блоками по 400 мс с перекрытием 75 %.
• Абсолютный гейт: блоки ниже −70 LKFS отбрасываются.
• Относительный гейт: считается от среднего по блокам, пережившим абсолютный гейт, и затем смещается на −10 LU. Это не среднее по всем блокам. Различие принципиально и его регулярно реализуют неверно.
• Loudness Range (LRA), EBU Tech 3342, использует относительный гейт −20 LU, а не −10 LU. Применение −10 к LRA — ходовая ошибка реализации.
• Кратковременная громкость — окно 3 с (EBU Tech 3341), мгновенная — 400 мс.
• Истинный пик измеряется на передискретизованном сигнале: минимум 4× по BS.1770, 8× лучше. Пиковое значение отсчёта — не то же самое, что истинный пик; межотсчётные пики могут превышать наибольший отсчёт.

Веса каналов в базовом алгоритме: 1,0 (0 дБ) для L, R и C и 1,41 (≈ +1,5 дБ) для Ls и Rs, LFE исключён. Базовый алгоритм описан для «from one to five channels». BS.1770-5 выходит за эти рамки в приложениях, охватывая перспективные системы BS.2051 — произвольно расположенные громкоговорители и каналы высоты — и объектный звук, который прежде измерения обязан быть отрендерен.

Иммерсивная громкость — не свойство файла. Это свойство рендера, и смена целевой раскладки меняет число.

В этом и состоит содержательное отличие от стерео. У стереомастера одно значение громкости. У объектного мастера их столько, сколько у него целей рендеринга, и честный способ назвать цифру — назвать вместе с ней раскладку, на которой она измерена, и рендерер, которым сделан рендер.

9.2. Что опубликовано для музыки

Для канального стереофонического материала Spotify публикует интегральную цель −14 LUFS и потолок истинного пика −1 dBTP, ужесточаемый до −2 dBTP для мастеров громче −14 LUFS. AES TD1008 рекомендует для музыки −16 LUFS; фигурирующая в том же документе цифра −18 LUFS относится к материалу, ведомому речью (новости, разговорные программы, драма), и назвать −18 музыкальной целью — частая и серьёзная ошибка. EBU R 128 задаёт вещательную программную цель −23 LUFS — это практика нормализации в вещании, а не спецификация музыкального стриминга.

9.3. Что не опубликовано

Ни один музыкальный стриминговый сервис не публикует интегральной цели громкости для иммерсивной поставки. Цифры широко ходят по форумам и по обучающим материалам вендоров; часть из них правдоподобна, часть, вероятно, верна. Ни одна не является опубликованной спецификацией, и здесь ни одна из них не будет повторена так, будто она ею является.

Отдельным блоком — то же самое про стерео: Apple Music, YouTube Music, Amazon Music, TIDAL и Deezer не публикуют цели нормализации. Ходовые значения (Apple ≈ −16, YouTube Music ≈ −14, Amazon ≈ −14, TIDAL ≈ −14, Deezer ≈ −15) — это широко сообщаемые, но не опубликованные сервисом данные. Их нельзя брать за спецификацию и тем более нельзя вычислять из них величину усиления.

Вещание и кино документированы лучше музыки просто потому, что вещатели публикуют свои требования. Если вам сегодня нужна защитимая цифра иммерсивной громкости, измерьте рендер, выполненный по BS.2127, в названную раскладку BS.2051, измерителем по BS.1770-5 — и запишите все три названия в сопроводительный документ.

9.4. О проприетарных системах

Dolby Atmos — проприетарная лицензируемая технология Dolby Laboratories, Sony 360 Reality Audio — проприетарная система, построенная на MPEG-H. Их требования к поставке устанавливают правообладатели этих систем, и меняются они безотносительно к графикам ITU и EBU. Ничто в этом документе не является изложением требований этих компаний, никакая аффилиация, сертификация или одобрение не заявляются и не подразумеваются. Там, где лицензиар публикует требование, читайте актуальную документацию самого лицензиара и ссылайтесь на неё.

10. Честная позиция: иммерсивного мониторинга у вас, скорее всего, нет

Это надо сказать прямо, потому что молчание об этом делает всю тему нечестной.

В российских музыкальных студиях иммерсивный мониторинг — редкость. За пределами нескольких пост-продакшн площадок, работающих с кино и вещанием, полноценной комнаты 7.1.4 с калиброванными позициями и разумной акустикой практически нет. Музыкальная студия среднего размера имеет отличный стереомониторинг, иногда 5.1, оставшуюся от эпохи DVD-Audio, и на этом всё. Записать литургию в амбисонику высокого порядка технически по силам многим; послушать результат так, как его услышит конечный слушатель, — почти никому.

Из этого не следует, что иммерсивной работой не надо заниматься. Из этого следует, куда именно смещается ценность вашей работы:

1. Корректная поставка. Контейнер правильный, размеры сходятся, чанки на местах, ничего не обрезано на 4 ГиБ.
2. Корректные метаданные. Граф ссылок замкнут, времена непрерывны, типы совпадают, идентификаторы не повисли.
3. Проверка файла, который вы не можете как следует прослушать. Это не компромисс и не полумера — это ровно та часть работы, которая машинно проверяема и потому объективна.

Практический набор приёмов для студии без иммерсивной комнаты:

• Разбирайте файл, а не слушайте его. Сравните fmt.nChannels с chna.numTracks. Проверьте, что каждый trackIndex лежит в диапазоне от 1 до числа каналов. Постройте множество UID из chna и множество из axml и возьмите симметрическую разность — она обязана быть пуста. EBU Tech 3392 формулирует намерение прямо: «If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs».
• Ищите цифровую тишину в каналах объявленной подложки. Структурные проверки этого не поймают: граф цел, а звука нет. Для каждого канала, заявленного пакетом DirectSpeakers, измерьте, есть ли в дорожке сигнал вообще. Пустой верхний тыловой канал не обязательно ошибка — но всегда повод для человеческого решения. В храмовой записи, где верх несёт купол, пустой верхний канал — почти наверняка ошибка вывода.
• Слушайте бинаурал, зная его границы. Бинауральный рендер по BS.2127 даст вам ответ на вопрос «объект вообще двигается и в ту ли сторону», и не даст ответа на вопрос «правильно ли распределена энергия по верхнему слою». Первое — уже много: крестный ход, идущий не в ту сторону, слышно в наушниках мгновенно.
• Сохраняйте XML отдельно. ADM-XML, лежащий рядом с BW64 в системе контроля версий, диффится. Бинарник, который можно только заново разобрать, — нет. Через полгода, когда придёт правка, разница между двумя текстовыми файлами стоит дороже любого протокола прослушивания.

Бесплатный браузерный инспектор BW64/ADM на mazufa.com разбирает контейнер и метаданные целиком на вашем устройстве и ничего никуда не загружает, что делает его пригодным для материала, который по договору не может покидать студию.

11. Чек-лист поставки

Идите по порядку. Структурные проверки первыми — они быстрые и обесценивают всё, что ниже.

Контейнер

1. Первые четыре байта — BW64. Если там RIFF, это обычный WAV, и он не может превысить 4 ГиБ.
2. ds64 — первый чанк после сигнатуры, и его 64-битные размеры совпадают с фактическими размерами файла и data на диске.
3. Любой переросший чанк, кроме data, имеет запись ChunkSize64 в таблице ds64.
4. axml найден явно, в том числе если он лежит после data. Не делайте вывод «ADM нет» по частичному сканированию.

Сущность

1. Частота дискретизации и разрядность в fmt точно соответствуют спецификации поставки. Никакого SRC после авторинга ADM.
2. fmt.nChannels равно chna.numTracks.
3. Каждый trackIndex в chna в диапазоне и нумерован с 1.

Целостность chna

1. Каждая запись — ровно 40 байт, поля фиксированной ширины корректно добиты.
2. Каждый packRef со значением 0x1000 и выше разрешается в пользовательское определение, присутствующее в axml.
3. Повторяющиеся trackIndex — намеренные (дорожка законно меняет определение), а не дубли.

Граф ADM

1. Каждый audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef и audioTrackUIDRef разрешается. Ноль повисших рёбер.
2. Нет осиротевших audioTrackUID ни в одну, ни в другую сторону.
3. Нет циклических и самоссылающихся элементов.
4. typeLabel каждого audioChannelFormat совпадает с типом родительского audioPackFormat.

Время

1. У многоблочных форматов канала на каждом блоке есть и rtime, и duration.
2. Блоки непрерывны и монотонны; сумма длительностей равна длительности родительского audioObject.
3. Объекты начинаются в 00:00:00.00000.

Содержание

1. Каждый канал объявленной подложки содержит то, что должен; цифровая тишина расследуется.
2. Число объектов и конфигурация подложки соответствуют спецификации поставки.
3. Стартовый таймкод в bext верен и одинаков во всех файлах комплекта.

Рендеры и конформы

1. Стерео- и бинауральный конформы перерендерены из текущего мастера, а не перенесены из прошлой версии.
2. Длительности и стартовые таймкоды совпадают с мастером с точностью до отсчёта.
3. Громкость измерена на названном рендере в названную раскладку названным рендерером, и все три названия записаны.

Воспроизводимость

1. Контрольная сумма по каждому файлу поставки, манифест сохранён.
2. Сессия и ADM-XML заархивированы отдельно от BW64.

Иммерсивная поставка закончена не тогда, когда она хорошо звучит, а тогда, когда машина, никогда её не слышавшая, может доказать, что все ссылки в ней разрешаются.

12. Итог

• Высота — это не эффект. Купол каменного храма, колокольня, хор на клиросе выше уровня головы — это источники и отражения, физически расположенные над слушателем. Верхний слой BS.2051 несёт информацию, а не украшение, и православная богослужебная запись — самое чистое доказательство этого тезиса, какое можно найти.
• Модель выбирается по физике источника. Неподвижный оркестр с известной рассадкой — канальная подложка. Четверо музыкантов малого ансамбля — четыре объекта. Крестный ход — объект с изменяющейся во времени позицией. Объём храма целиком — сцен-ориентированный звук.
• BW64 существует ради арифметики. 28 каналов на 48 кГц / 24 бит упираются в потолок RIFF через 17 минут 45 секунд, а литургия идёт два часа. ds64 — единственный механизм, который это решает, и он обязан стоять первым.
• Запись chna — ровно 40 байт: 2 + 12 + 14 + 11 + 1. Ширины фиксированы; лишний символ портит всю таблицу, а не одну запись.
• ADM — граф ссылок. Отказ поставки — это разорванное ребро, и оно почти никогда не слышно.
• Громкость принадлежит рендеру, а не файлу. Называйте раскладку, рендерер и редакцию BS.1770 — сейчас это -5.
• Иммерсивного мониторинга у большинства из нас нет. Значит, ценность — в корректной поставке, корректных метаданных и в машинной проверке того, что толком нельзя прослушать.

BW64 и ADM — открытые, опубликованные, свободно читаемые стандарты. В этом углу индустрии это редкость, и ею стоит пользоваться: BS.2088 и BS.2076 можно прочитать самому, разобрать чанк chna сорока строками кода и проверить, что экспортёр действительно записал, а не что он написал в своём диалоговом окне.

Mazufa распространяет релизы бесплатно (без платы за загрузку, без подписки, без платы за релиз), удерживает 5% от полученных роялти и рассматривает каждую полную заявку вручную.

Источники

Рекомендации ITU-R

• ITU-R BS.2088-2 (11/2025), Long-form file format for the international exchange of audio programme materials with metadata (BW64) — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2088-2-202511-I!!PDF-E.pdf
• ITU-R BS.2076-3 (02/2025), Audio Definition Model — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2076-3-202502-I!!PDF-E.pdf
• ITU-R BS.2076-2 (10/2019), Audio definition model — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2076-2-201910-S!!TOC-HTM-E.htm
• ITU-R BS.1770-5 (11/2023), Algorithms to measure audio programme loudness and true-peak audio level — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-5-202311-I!!PDF-E.pdf
• ITU-R BS.2051-2 (07/2018), Advanced sound system for programme production — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2051-2-201807-S!!PDF-E.pdf
• ITU-R BS.2127-1 (11/2023), Audio Definition Model renderer for advanced sound systems — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2127-1-202311-I!!PDF-E.pdf
• Страница Рекомендации BS.2127 — https://www.itu.int/rec/R-REC-BS.2127

Технические документы EBU

• EBU Tech 3306, RF64: An extended file format for audio data — https://tech.ebu.ch/docs/tech/tech3306.pdf
• EBU Tech 3285 (и дополнения), Specification of the Broadcast Wave Format — https://tech.ebu.ch/files/live/sites/tech/files/shared/tech/tech3285s7.pdf
• EBU Tech 3392, ADM Broadcast Production Profile — https://tech.ebu.ch/files/live/sites/tech/files/shared/tech/tech3392.pdf
• EBU Tech 3388, ADM Renderer for use in Next Generation Audio broadcasting — https://tech.ebu.ch/docs/tech/tech3388.pdf и https://tech.ebu.ch/publications/tech3388
• EBU Tech 3343, Practical guidelines for production and implementation in accordance with EBU R 128 — https://tech.ebu.ch/files/live/sites/tech/files/shared/tech/tech3343v2_0.pdf
• EBU R 128, EBU Tech 3341 (измерители), EBU Tech 3342 (Loudness Range) — https://tech.ebu.ch
• EBU ADM Guidelines — чанк CHNA — https://adm.ebu.io/reference/excursions/chna_chunk.html
• EBU ADM Guidelines — BW64 и ADM — https://adm.ebu.io/reference/excursions/bw64_and_adm.html
• EBU ADM Guidelines — audioTrackUID — https://adm.ebu.io/reference/adm_elements/audio_track_uid.html
• Документация EBU ADM Renderer (EAR), ввод-вывод BW64 — https://ear.readthedocs.io/en/latest/BW64.html
• libbw64, эталонная реализация — https://github.com/ebu/libbw64
• libadm, эталонная реализация — https://github.com/ebu/libadm

AES

• AES TD1008, Recommendations for loudness of internet audio streaming and on-demand distribution — https://www.aes.org/community/technical-council/technical-document-aestd1008/

Документация сервисов

• Spotify, Loudness normalization — https://support.spotify.com/us/artists/article/loudness-normalization/

О границах опубликованного. Ни один музыкальный стриминговый сервис не публикует цели интегральной громкости для иммерсивной поставки; ходовые цифры здесь не воспроизводятся. Цели нормализации Apple Music, YouTube Music, Amazon Music, TIDAL и Deezer также не публикуются самими сервисами — приведённые в разделе 9.3 значения помечены как широко сообщаемые, но не опубликованные. Требования проприетарных иммерсивных систем устанавливают их правообладатели и здесь не излагаются.

Последняя сверка — сентябрь 2026 года. Стандарты пересматриваются; прежде чем цитировать номер пункта, проверьте текущую редакцию на страницах ITU и EBU выше.