Чому immersive-майстер проходить хвильовий редактор і не проходить QC

Immersive-файл може відкритися у хвильовому редакторі, показати дванадцять чи шістнадцять на вигляд здорових доріжок, розумно програтися — і все одно бути відхиленим. Причина структурна: у файлі BW64 аудіо й метадані є двома окремими речами, які мусять точно збігатися, і ніщо у самому форматі їх до цього не змушує. Рендерер розв’язує посилання. Редактор малює відліки. Різна робота — саме тому QC для ADM є перевіркою цілісності посилань, а не прослуховуванням. Ось що кажуть два стандарти, де саме ламаються посилання і яка перевірка ловить яку поломку.

Три види аудіо, і чому ця різниця вирішує все

Кожна проблема з immersive-здачею починається з плутанини щодо того, чим із трьох речей є доріжка.

Канальне аудіо приписує кожну доріжку до фіксованої позиції гучномовця. Стерео є канальним, як і 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.

Об’єктне аудіо несе моносигнал (або багатоканальний pack) плюс позиційні метадані, що змінюються в часі. Рендерер вирішує, які реальні гучномовці його відтворять, виходячи з наявної в приміщенні розкладки. Ніщо в доріжці не передбачає гучномовця. Це typeDefinition Objects, typeLabel 0003.

Сценове аудіо, на практиці Higher-Order Ambisonics, кодує все звукове поле як компоненти сферичних гармонік. Жодна компонента сама по собі не відповідає напрямку; напрямок постає з лінійної комбінації. Це 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 години 8 хвилин. Байдуже. Для об’єктного майстра на 128 доріжок при 96 kHz / 24-bit швидкість становить 36,864,000 байтів на секунду, і 4 GB — це менш ніж дві хвилини, 116.5 секунди.

Immersive-майстри переходять цю межу постійно, а 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 — формат відліку, частота дискретизації, кількість каналів, бітів на відлік, block align. Це єдине авторитетне твердження про те, скільки перемежованих каналів є в data. Усе далі за течією є метаданими про ці канали, а метадані можуть брехати.

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

2 + 12 + 14 + 11 + 1 = 40. Ширини не є рекомендаційними: це ASCII фіксованої ширини, і райтер, що видає UID із 13 символів, зробив пошкоджену таблицю, а не трохи незвичну.

Домовленість про ідентифікатори теж важить. Значення 0x0FFF і нижче посилаються на спільні визначення ADM — стандартні, наперед задані формати каналів і pack — тоді як 0x1000 і вище позначають власні визначення, які мусять бути присутні в axml. AP_00010003 є 5.1 за спільним визначенням і не потребує XML; AP_00031001 є власним об’єктним pack і потребує 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 pack, може перервати розбір і відхилити файл; може пропустити цей об’єкт і відрендерити все інше, видавши мікс, у якому тихо бракує стема; або може відкотитися до спільних визначень, знайти ідентифікатор із власного діапазону від 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 оголошує pack DirectSpeakers 7.1.4 — дванадцять каналів — але записано лише підмножину 5.1, або канали висоти були заглушені на баунсі й записалися як цифрова тиша. Граф посилань цілий; аудіо — ні. Структурні перевірки цього спіймати не можуть: потрібен аналіз самої сутності, вимірювання того, чи взагалі містить сигнал кожен канал, заявлений pack-ом DirectSpeakers. Цифрова тиша в оголошеному каналі беду не є автоматично помилкою — законний мікс може лишити верхній тиловий канал порожнім, — але вона завжди варта людського рішення.

Що опубліковано про immersive-гучність, а що ні

Одне число не переживає переходу зі стерео, і варто сказати чому.

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 та об’єктне аудіо — яке спершу треба відрендерити, щоб виміряти. Immersive-гучність, отже, є властивістю не файлу, а рендеру, і зміна цільової розкладки змінює число. Виміряйте BS.2127-сумісний рендер у названу розкладку BS.2051 вимірювачем за BS.1770-5 і запишіть усі три в нотатки до здачі; BS.2127 визначає еталонний ADM-рендерер, а його відкритий побратим EBU ADM Renderer (EBU Tech 3388) є практичним способом отримати відтворюване число.

Жоден музичний стримінговий сервіс не публікує цільової інтегрованої гучності для immersive-здачі. Цифри ходять форумами та навчальними матеріалами виробників; жодна з них не є опублікованою специфікацією, і ця стаття не повторюватиме жодну так, ніби вона нею є. Опублікованим є те, що стосується канального стерео, — інтегрована ціль 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 раніше за свого immersive-батька проходить перевірку наявності файлу і не проходить синхронного прослуховування.
• Порахуйте контрольну суму для кожного файлу здачі, збережіть маніфест і архівуйте ADM XML окремо від BW64 — XML, який можна порівняти діфом, згодом вартий більше за бінарник, який можна лише розібрати заново.

BW64 і ADM є відкритими, опублікованими, вільно доступними стандартами, і цим варто скористатися: ви можете самі прочитати BS.2088 і BS.2076, розібрати чанк chna сорока рядками коду й перевірити, що насправді записав експортер виробника, а не що заявило його вікно. Майже всі зайві immersive-відхилення є помилками цілісності посилань, які валідатор ловить менш ніж за секунду.

Безкоштовний інспектор 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 reference implementation — 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/