Почему иммерсивный мастер проходит волновой редактор и не проходит QC

Иммерсивная поставка может открыться в волновом редакторе, показать двенадцать или шестнадцать здоровых на вид дорожек, осмысленно воспроизвестись — и всё равно получить отказ. Причина структурная: в файле BW64 аудио и метаданные — это две отдельные сущности, которые обязаны совпадать в точности, и ничто в самом формате их к этому не принуждает. Рендерер разрешает ссылки. Редактор рисует отсчёты. Разные задачи — и именно поэтому QC для ADM есть проверка целостности ссылок, а не прослушивание. Ниже — что говорят два стандарта, где рвутся ссылки и какая проверка ловит какой отказ.

Три вида аудио, и почему это различение решает всё

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

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

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

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

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

BW64 существует из-за одного 32-битного числа

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

Для стерео 48 kHz / 24-bit поток данных составляет 288,000 байт в секунду, так что 4 GB — это примерно 4 hours 8 minutes. Несущественно. Для объектного мастера на 128 дорожек при 96 kHz / 24-bit поток равен 36,864,000 байт в секунду, и 4 GB — это меньше двух минут: 116.5 seconds.

Иммерсивные мастеры переходят этот предел рутинно, а записывающий WAV инструмент, упёршийся в него, выдаёт либо усечённый файл, либо файл, в котором объявленные размеры молча переполнились. Первым эту проблему решил EBU — форматом RF64 (EBU Tech 3306); ITU развил решение в Рекомендацию ITU-R BS.2088 — BW64.

Приём с маркером: 0xFFFFFFFF и чанк ds64

BS.2088 описывает механизм прямо. «The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file», а исходные 32-битные поля размера становятся флагами перехода: «If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead.»

В этом весь приём, и стоит сказать это прямым текстом: BW64 не расширяет поля размера RIFF. Он заполняет их маркером 0xFFFFFFFF, а настоящие 64-битные размеры кладёт в чанк ds64, который обязан идти в файле первым. Поэтому файл BW64 объёмом менее 4 GB побайтово совместим с WAV-читателем во всём, кроме четырёхсимвольной сигнатуры. Многие инструменты его принимают; некоторые упорно нет.

Чанки, и тот, в котором ровно 40 байт на запись

Согласно BS.2088 от файла BW64 ожидается наличие как минимум ds64, fmt , chna, axml (с bxml и sxml как альтернативными носителями метаданных) и собственно волновых данных.

ds64 обязан быть первым чанком после сигнатуры, потому что читателю нужно знать настоящие размеры прежде, чем он сможет пройти по чему-либо ещё. Он несёт 32-битные младшую и старшую половины размера файла целиком и размера data, плюс таблицу записей ChunkSize64 для любого другого превышающего лимит чанка: чанк axml, описывающий тысячи объектов с отсчётной точностью автоматизации, и сам может приблизиться к 4 GB или превысить их.

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

chna — мост между физическими дорожками и ADM. После ckID, ckSize, 2-байтового numTracks и 2-байтового numUIDs он содержит плоский массив записей audioID фиксированной ширины, каждая ровно по 40 байт:

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

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

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 может встретиться в нескольких записях. Инструменты QC, исходящие из «один UID на дорожку», помечают корректные файлы как сломанные.

axml — это XML-документ в UTF-8, содержащий дерево <audioFormatExtended>. Это и есть ADM, и там живёт практически весь интересный класс отказов. data — это обычный чередующийся PCM; ничто внутри него не знает ни о каких объектах.

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

ADM — это граф, а отказы — это оборванные рёбра

Иерархия ITU-R BS.2076 идёт как audioProgramme → audioContent → audioObject → audioPackFormat → audioChannelFormat → audioBlockFormat, где audioTrackUID — лист и единственный элемент, соответствующий физической дорожке.

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

Четыре отказа, на которые приходится большинство отклонений

Число дорожек в fmt , расходящееся с chna. fmt .nChannels говорит 16; chna.numTracks говорит 14. Файл внутренне противоречив уже начиная с первых двух чанков — обычно это сведение, где число дорожек изменилось после того, как метаданные были составлены, или инструмент, выбросивший дорожки без перезаписи chna. Обнаружение — это разбор двух целых чисел и их сравнение: самая дешёвая проверка в конвейере, ловящая поразительную долю отказов. Заодно убедитесь, что каждый trackIndex лежит в пределах 1 … fmt .nChannels.

audioTrackUID, на который не ссылается ни один объект. UID в chna, на который не ссылается ни один audioObject, означает, что существует аудио, которое ничто не отрендерит; зеркальный случай — audioTrackUIDRef в XML без соответствующей записи в chna — означает, что метаданные ждут дорожку, которой нет. Постройте множество UID из chna и множество из axml и возьмите симметрическую разность; она должна быть пуста. EBU Tech 3392 формулирует намерение прямо: «If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs.»

Тайминг блоков, идущий вспять. 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. Пройдите блоки в порядке документа и проверьте rtime[n] + duration[n] == rtime[n+1]. Отказы бывают трёх видов: дыры, где поведение рендерера не определено и одни удерживают последнюю позицию, а другие приглушают; перекрытия, где блоки конфликтуют; и блоки, нарушающие хронологический порядок, — это автоматизация, прыгающая назад посреди программы.

Бед, описанный в XML, но так и не выведенный на диск. XML объявляет пак DirectSpeakers 7.1.4 — двенадцать каналов, — но выведено было только подмножество 5.1, либо каналы высоты были заглушены при сведении и записаны как цифровая тишина. Граф ссылок цел; аудио — нет. Структурные проверки этого поймать не могут: нужен анализ самого сигнала — измерение того, содержит ли вообще сигнал каждый канал, заявленный паком DirectSpeakers. Цифровая тишина в заявленном канале беда — не автоматически ошибка: законный микс вправе оставить верхний тыловой канал пустым, — но она всегда стоит человеческого решения.

Что опубликовано об иммерсивной громкости, а что нет

Одно число не переживает переход от стерео, и стоит объяснить почему.

BS.1770-5 (November 2023) — действующая редакция; BS.1770-4 отменена, хотя большинство используемых измерителей по-прежнему ссылаются на неё. Её базовый алгоритм взвешивает L, R и C с коэффициентом 1.0, а Ls и Rs — 1.41 (около +1.5 dB), исключает LFE и по области применения ограничен «from one to five channels». BS.1770-5 выходит за эти рамки в приложениях, охватывая продвинутые звуковые системы BS.2051 и объектное аудио, которое перед измерением обязано быть отрендерено. Иммерсивная громкость, стало быть, — свойство не файла, а рендера, и смена целевой раскладки меняет число. Измеряйте соответствующий BS.2127 рендер в названную раскладку BS.2051 измерителем по BS.1770-5 и фиксируйте все три пункта в сопроводительных записях к поставке; BS.2127 определяет эталонный рендерер ADM, а его открытая родня, EBU ADM Renderer (EBU Tech 3388), — практический способ получить воспроизводимую цифру.

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

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

Что проверить перед отправкой

Сначала структурные проверки: они быстрые и обнуляют смысл всего, что ниже по цепочке.

• Первые четыре байта — BW64. Если там читается RIFF, это обычный WAV, и он не может превысить 4 GB.
• ds64 — первый чанк после сигнатуры, его 64-битные размеры совпадают с фактическими размерами файла и data на диске, а у любого превышающего лимит чанка, кроме data, есть запись ChunkSize64 в таблице.
• Найдите axml явно, в том числе после data, — никогда не заключайте «ADM нет» по частичному сканированию.
• Частота дискретизации и разрядность в fmt в точности соответствуют спецификации поставки. Никакой передискретизации после составления ADM — она обесценивает каждый rtime и duration, выраженные в отсчётах.
• fmt .nChannels равно chna.numTracks; каждый trackIndex в диапазоне и нумеруется с 1.
• Каждая запись chna ровно 40 байт с правильно добитыми полями фиксированной ширины, а каждый packRef со значением 0x1000 и выше разрешается в пользовательское определение, присутствующее в axml.
• Каждый audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef и audioTrackUIDRef разрешается. Ноль повисших рёбер в обе стороны и никаких циклических ссылок.
• Многоблочные форматы каналов несут и rtime, и duration в каждом блоке; блоки непрерывны и монотонны; объекты начинаются в 00:00:00.00000.
• Каждый канал заявленного беда содержит то, что должен. Цифровую тишину расследуйте.
• Стартовый таймкод bext согласован по всему комплекту, а стерео- и бинауральные конформы перерендерены с текущего мастера. Конформ, ушедший на 40 ms вперёд относительно иммерсивного родителя, пройдёт проверку наличия файлов и провалит синхронное прослушивание.
• Считайте контрольную сумму каждой единицы поставки, храните манифест и архивируйте ADM XML отдельно от BW64: XML, который можно сравнить построчно, впоследствии стоит дороже двоичного файла, который можно только перечитать разбором.

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

Бесплатный инспектор BW64/ADM от Mazufa по адресу mazufa.com/immersive-master-check разбирает контейнер и метаданные целиком на вашем собственном устройстве и ничего никуда не загружает, что делает его пригодным для материала, которому по договору нельзя покидать помещение. Сама Mazufa бесплатна для релизов, берёт комиссию 0% и работает по приглашениям, с человеческим рассмотрением каждой полной заявки.

Источники

Рекомендации 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.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

Технические документы 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/publications/tech3388
• EBU ADM Guidelines — CHNA chunk — https://adm.ebu.io/reference/excursions/chna_chunk.html
• EBU ADM Guidelines — BW64 and 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
• Эталонная реализация libbw64 — https://github.com/ebu/libbw64

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/