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. Автентичний спів: коло, звернене всередину

Почнімо не з контейнера, а з випадку, який в українському матеріалі трапляється постійно і який жоден інший формат, крім об'єктного, не описує чесно.

Автентичний багатоголосий спів виконують у колі, обличчям усередину. Це не сценічна побудова й не режисерська вигадка — так співають, бо голоси строяться один по одному: співачка чує сусідку не через зал, а прямо, через два метри повітря, і підлаштовує терцію в реальному часі. Коло — це робочий інструмент ансамблю, а не мізансцена.

Звідси випливає річ, яку варто проговорити повільно, бо вона визначає весь подальший технічний вибір.

Прямий звук кожного співака йде всередину кола, а не назовні. Голос має виражену спрямованість на верхніх формантах; той, хто стоїть у центрі, чує всіх виконавців в осі, з відстані півтора-два метри, рівномірно розподіленими по всіх 360° азимуту, приблизно на рівні власних вух. Той, хто стоїть зовні, чує зовсім іншу картину: найближчі до нього співаки повернуті спиною, тобто приходять поза віссю і глухіше; далекі співаки повернуті до нього обличчям і звучать яскравіше, але їхній прямий звук частково затінений тілами ближніх; увесь ансамбль стискається у сектор шириною 60–90°, а не розгортається навколо.

Це не одна сцена, повернута на 180°. Це дві різні звукові події, породжені одним виконанням. Ніяким поворотом матриці одну не можна отримати з іншої, тому що змінюється не лише азимут джерел, а й їхня спрямованість, взаємне затінення й співвідношення прямого звуку до відбитого.

Саме тут об'єктна модель перестає бути модою і стає єдиним чесним описом. Канальна підкладка фіксує позиції гучномовців — а отже, фіксує й точку слухача. Об'єктний запис фіксує джерела, а точку слухача лишає рішенням етапу зведення.

Як авторувати обидві версії

Матеріал знімається один раз і однаково:

• По одному моно-мікрофону на співака. Петличка або гарнітура, щоб мікрофон рухався разом із головою і не змінював вісь, коли виконавиця повертається до сусідки. Кардіоїда на стійці за 30 см теж працює, але дає більше перехресного проникнення, а в колі діаметром чотири метри перехресне проникнення — це не завада, а частина сигналу.
• Амбісонічний масив у центрі кола — поле «зсередини».
• Другий масив зовні, за два-три метри від найближчої співачки, на рівні вух — поле «ззовні».

Далі — два audioProgramme у межах однієї моделі ADM.

Програма «всередині кола». Вісім співаків — вісім audioObject з typeDefinition="Objects". Азимути розподілені рівномірно: 0°, 45°, 90°, 135°, 180°, 225°, 270°, 315°. Елевація близька до нуля — голови на рівні вух, і цю очевидність варто задати явно, бо дефолт рендерера вас не питатиме. distance — мале й однакове для всіх, бо коло симетричне. Амбісонічний масив центру йде окремим audioPackFormat типу HOA і працює як «шов»: він несе приміщення й ті відбиття, яких немає в петличках.

Програма «зовні кола». Ті самі вісім сигналів, але азимути стиснуті у сектор — наприклад від −40° до +40°, — а distance різні: ближні співаки ближче, дальні далі. І, що важливіше за геометрію: у цій програмі до ближніх об'єктів має бути застосований інший тембр, бо в реальності ви чуєте їхню спину. Це не позиційна метадана — це обробка сигналу, і вона мусить бути надрукована в доріжку або зроблена окремим міксом. ADM описує, де джерело, а не куди воно повернуте. Спрямованість джерела в моделі не виражається, і робити вигляд, що distance це компенсує, — самообман.

Практична пастка з audioTrackUID

Тут виникає технічна деталь, через яку такий файл найчастіше не проходить валідатор.

audioTrackUID — єдиний елемент моделі, що відповідає фізичній доріжці, — несе посилання і на audioTrackFormat, і на audioPackFormat. Отже, один UID прив'язаний до одного пакета. Якщо ви хочете, щоб та сама фізична доріжка брала участь у двох програмах із різними позиціями, вам потрібні два UID на одну доріжку, тобто два записи в chna з однаковим trackIndex.

Формат це дозволяє: numUIDs у chna цілком законно може перевищувати numTracks. Опублікована EBU підстава для цього, щоправда, інша — зміна визначення доріжки в часі: у настановах 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». Використання того самого механізму для двох альтернативних програм є логічним наслідком означень полів, але прямо в цій ролі воно не задокументоване. Тому чесна рекомендація така: якщо поставка йде на невідомий валідатор — віддавайте два окремі файли BW64, кожен з однією програмою. Якщо ланцюжок відомий і перевірений — один файл із двома програмами компактніший і виключає розсинхрон між версіями.

Різниця у витратах видима одразу. Вісім об'єктів плюс амбісоніка першого порядку (4 канали) — 12 доріжок. Одна програма: 12 UID, тіло чанка chna = 4 + 40 × 12 = 484 байти, увесь чанк із заголовком — 492 байти. Дві програми: 24 UID на тих самих 12 доріжках, тіло = 4 + 40 × 24 = 964 байти, чанк — 972 байти. Плата за другу точку слухача — 480 байтів метаданих і жодного зайвого семпла.

Автентичний спів — це рідкісний випадок, коли питання «де стоїть слухач?» не має правильної відповіді, і саме тому відповідь має лишитися у метаданих, а не в мікшері.

2. Три моделі 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. Це не абстракція, а рядок у бюджеті файлу, до якого ми повернемося в розділі 6.

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

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

3. Трембіта: джерело на справжній відстані

Другий український випадок, який ставить формат у незручне становище, — трембіта.

Трембіту грають надворі, у горах, і грають так, щоб її почули за кілометри. Це не студійна ситуація й навіть не концертна: слухач і джерело розділені долиною. Наслідків для запису три, і всі три технічні.

Перший: реверберація тут — це ландшафт, а не приміщення. Хвіст, який ви чуєте, утворюють схили, ліс, скельні виходи й сама форма долини. Він не має ані рівномірного спадання, ані щільної дифузної частини — це серія дискретних, розділених у часі відбиттів із різних напрямків, кожне зі своїм тембром, бо ліс поглинає верх, а голий схил — ні. Жоден алгоритмічний ревербератор із параметром «розмір приміщення» цього не відтворює, і жоден diffuseness в audioBlockFormat цього не описує. Хвіст трембіти треба записати, а не синтезувати — другим набором мікрофонів, з боку слухача, як окремий об'єкт або окремий амбісонічний пакет із власною позицією.

Другий: джерело справді далеко, і затримка чутна. Швидкість звуку в повітрі — приблизно 343 м/с за 20 °C. Через долину шириною 1,2 км прямий звук іде 1200 ÷ 343 ≈ 3,5 секунди. Якщо ви пишете двома точками — біля трембітаря і біля слухача, — ці доріжки розходяться на три з половиною секунди, і жоден «автоматичний вирівнювач фази» вам тут не друг: розходження і є змістом матеріалу. Якщо його прибрати, зникне те єдине, заради чого запис робили.

Третій, і найважливіший для ADM: distance не робить того, чого від нього чекають. У моделі позиція об'єкта в сферичних координатах — це azimuth, elevation і distance, причому distance нормалізований, а не виражений у метрах. Він каже рендереру, що джерело ближче або далі за опорну відстань, — і на цьому гарантії закінчуються. BS.2127 не синтезує ані поглинання повітря, ані затримку поширення, ані реверберацію ландшафту. Спад високих частот на кілометрі шляху, розмиття атаки, той характерний «пласкіший» тембр далекого джерела — усе це має бути надруковане в семпли. distance у такому файлі виконує рівно одну корисну функцію: він документує намір, щоб через рік хтось інший, відкривши XML, зрозумів, що об'єкт задумано далеким, і не «підправив» його ближче.

Практично трембіта авторується так: два об'єкти на одне джерело. Об'єкт «прямий» — вузько локалізований, distance близький до максимуму, у сигналі вже є ландшафтний тембр. Об'єкт «відлуння» — з великою width/height (розміром), меншою локалізованістю та власними, іншими азимутами, бо відбиття приходять не звідти, звідки прямий звук. Складати їх в один об'єкт із високим diffuseness — спокуса, якої варто уникнути: diffuseness розмиває, але не переносить у інший напрямок.

І ще одне, суто організаційне. Матеріал такого роду пишеться двома окремими комплектами, часто на два різні рекордери, і зводити їх доводиться постфактум. Єдине, що рятує в цій ситуації, — спільний часовий код і чесно заповнений bext на обох комплектах. Без цього трисекундне розходження, яке є змістом запису, неможливо відрізнити від трисекундного розходження, яке є помилкою запуску, і ви витратите зміну на з'ясування того, що мало бути записано на етапі знімання.

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

4. Бандура: капела як підкладка, кобзар як об'єкт

Третій випадок — про те, коли об'єкт не потрібен, і це так само важливо.

Капела бандуристів — великий склад, від десятків виконавців, розсаджений рядами на сцені. Розсадка фіксована, відома заздалегідь і не змінюється протягом програми. Ніхто не рухається. Партії розподілені по групах, а не по окремих інструментах, і слухач сприймає групу як одне протяжне джерело, а не як суму точок.

Спроба описати таку капелу шістдесятьма об'єктами — класична помилка. Ви вигадаєте шістдесят траєкторій, кожна з яких насправді константа; отримаєте файл, важчий за потрібне, крихкіший на посиланнях і не кращий на слух; і додатково змусите рендерер розв'язувати шістдесят задач панорамування там, де вистачило б однієї матриці. Правильне рішення — канальна підкладка: зняти сцену основною системою, покласти це в 5.1.4 або 7.1.4 DirectSpeakers, а об'єктами додати лише те, що справді потребує окремого поводження.

Соло кобзаря — рівно протилежний випадок. Один виконавець, один інструмент, який одночасно є акомпанементом і голосом, причому голос і струни звучать із двох різних точок одного тіла й по-різному спрямовані. Це дискретне джерело з позицією, яку є сенс задати точно. Це об'єкт — і, що важливо, об'єкт переносний: такий мастер однаково осмислено розгорнеться і в 4+5+0, і в 4+7+0, і в бінаурал, бо ніде не зашита розкладка.

Комбінація, яка покриває майже всі реальні сесії: підкладка для капели плюс два-три об'єкти — соліст, ведучий, окремий інструмент. Кількість каналів при цьому виходить така: 7.1.4 — це 12 каналів підкладки, плюс, скажімо, 8 об'єктів, разом 20 доріжок. Запам'ятайте це число, воно знадобиться в наступному розділі.

Окремо варто сказати про те, чого підкладка не пробачає: порядок каналів. Канальний пакет DirectSpeakers осмислений лише тоді, коли фізична доріжка справді відповідає заявленому гучномовцю. Переставлені місцями тилові канали або переплутані ліва й права висота — це помилка, яку граф посилань не ловить узагалі, бо граф цілий, і яку на слух у неповній кімнаті теж не почути. Єдиний надійний захист — записати порядок каналів у супровідні нотатки на етапі бавнсу й звірити його з chna окремою перевіркою, а не покладатися на пам'ять про те, як був налаштований експорт.

Правило, яке майже ніколи не підводить: якщо джерело не рухається і його позиція відома заздалегідь — це підкладка. Якщо джерело рухається або його позиція важлива з точністю, якої немає в сітці гучномовців, — це об'єкт.

5. Колядування і щедрування: рухоме джерело в сухій відкритій акустиці

Четвертий випадок — той, що найкраще ламає інтуїцію, вибудувану на студійній роботі.

Гурт колядників іде селом від хати до хати, уночі, надворі, узимку. З погляду запису це рухоме джерело — але рухоме джерело в акустиці, яка не схожа на жодне приміщення й на жоден концертний майданчик.

Реверберації майже немає. Сніг поглинає, відбивати нема від чого — між хатами простір відкритий, найближча вертикальна поверхня це паркан або стіна за десять метрів. Ви отримуєте практично сухий прямий звук плюс поодинокі, добре розділені відбиття від стіни хати, до якої гурт підходить. Це рідкісна ситуація, коли об'єктна модель працює саме так, як обіцяно на папері: майже весь сигнал прямий, майже вся просторова інформація в позиції, і рендерер справді може відтворити картину, бо йому не треба вгадувати приміщення, якого немає.

Рух реальний і повільний. Гурт наближається, зупиняється під вікном, співає, повертається, іде далі. Це не панорама «туди-сюди» — це траєкторія з фізичним прообразом, у якої є ділянки постійної швидкості, зупинки та поворот. В ADM це послідовність audioBlockFormat із rtime і duration, і це найкращий тестовий матеріал, який можна собі побажати: якщо рендерер криво проходить зони між гучномовцями, вухо це почує миттєво, бо воно знає, як має рухатися гурт людей, і чує ривок.

Практична деталь, яку легко проґавити: elevation не нуль. Слухач у хаті, гурт надворі; якщо мікрофон стоїть у кімнаті, а гурт співає під вікном, джерело часто нижче або вище рівня вух і завжди за перепоною. Задавати елевацію нулем «бо всі стоять на землі» — типова помилка авторування, яка робить сцену пласкою саме там, де вертикаль несе інформацію.

І бюджет файлу. Скромний виїзний комплект — 12 доріжок, 48 кГц, 24 біти. Швидкість потоку: 12 × 3 × 48 000 = 1 728 000 байтів/с. Межа RIFF у 4 294 967 296 байтів настає через 4 294 967 296 ÷ 1 728 000 ≈ 2485,5 с — 41 хвилина 25 секунд. Ніч колядування — це чотири-шість годин безперервного запису. Тобто питання «чи потрібен мені BW64» тут навіть не постає.

6. BW64: що це і навіщо саме знадобилося

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

Порахуймо, кого це стосується.

Останній рядок вартий окремої уваги. Сім із половиною хвилин. Один дубль автентичної пісні з розспівуванням перед ним — і ви за межею. Записувач 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» — тобто перші чотири байти файлу містять BW64 замість RIFF, — а старі 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 найкраще розуміти як третє покоління однієї лінії. RIFF/WAVE дав чанковий контейнер. Broadcast Wave (BWF, EBU Tech 3285) додав чанк bext — автор, часовий код, історія кодування, — перетворивши WAV на формат мовного обміну. BW64 зберігає все це, додає 64-бітну адресацію і додає чанки, що несуть ADM. Файл BW64 розміром до 4 ГБ побайтово сумісний із читачем WAV в усьому, крім чотирисимвольного підпису файлу; багато інструментів його приймають, а деякі вперто ні.

7. Розкладка чанків, детально

За BS.2088 файл BW64 має містити щонайменше <ds64-ck>, <fmt-ck>, <chna-ck>, <axml-ck> (з <bxml-ck> і <sxml-ck> як альтернативними носіями метаданих) та <wave-data>.

7.1. ds64 — таблиця 64-бітних розмірів

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

Арифметика мінімального ds64: тіло — 8 + 8 + 8 + 4 = 28 байтів, разом із заголовком ckID + ckSize — 36 байтів. Тридцять шість байтів — це вся ціна виходу за 4 ГБ.

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

7.2. fmt — опис сутності

Стандартний чанк формату WAVE: формат семплів, частота дискретизації, кількість каналів, розрядність, вирівнювання блоку. Це єдине авторитетне твердження про те, скільки чергованих каналів реально лежить у data. Усе інше — метадані про ці канали, а метадані можуть брехати.

7.3. chna — таблиця розподілу каналів

chna — міст між фізичними доріжками й ADM. Починається так:

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

Далі — плаский масив записів audioID фіксованої ширини. Кожен запис — рівно 40 байтів:

2 + 12 + 14 + 11 + 1 = 40.

Звідси розмір усього чанка: 8 байтів заголовка + 4 байти (numTracks + numUIDs) + 40 × N. Для нашої капели з підкладкою 7.1.4 і вісьмома об'єктами — 20 доріжок, 20 UID: тіло = 4 + 40 × 20 = 804 байти, чанк цілком — 812 байтів. Для кола з двома програмами (12 доріжок, 24 UID) — 964 і 972 байти відповідно.

Ширини полів не є рекомендаційними. Це ASCII фіксованої ширини, і записувач, який видав UID на 13 символів, створив пошкоджену таблицю, а не трохи незвичайну.

Зверніть увагу і на конвенцію ідентифікаторів: значення 0x0FFF і нижче посилаються на загальні визначення ADM — стандартні, наперед визначені формати каналів і пакетів, — а 0x1000 і вище означають користувацькі визначення, які зобов'язані бути присутні в чанку axml. packRef зі значенням AP_00010003 — це 5.1 за загальним визначенням, і XML йому не потрібен; AP_00031001 — користувацький об'єктний пакет, і без XML це повисле посилання.

UID доріжки — це серійний номер ідентичності однієї фізичної доріжки, і він існує саме для того, щоб доріжка могла законно змінити те, що вона несе, посеред програми.

Через це numUIDs і може перевищувати numTracks, а один trackIndex — з'явитися в кількох записах. Інструменти техприймання, які припускають «один UID на доріжку», позначають коректні файли як зламані.

7.4. axml — сам ADM

XML-документ у UTF-8, що містить дерево <audioFormatExtended>. Це і є ADM. Він текстовий, його можна прочитати очима, і саме в ньому живуть практично всі цікаві відмови.

7.5. data — чергований PCM

Звичайні черговані семпли, точно як у WAV. Ніщо в data не знає нічого про об'єкти.

7.6. Порядок чанків

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

7.7. bext, і навіщо його заповнювати

bext несе часовий код початку, автора та історію кодування. У багатодобовій польовій сесії — а колядування чи гуцульський виїзд це саме вона — bext часто єдине, що дозволяє через півроку відповісти на питання, який дубль був першим. Заповнюйте його на етапі запису, а не зведення.

8. Кирилиця в ADM: де вона законна, а де руйнує файл

Це той розділ, який в українській практиці треба читати уважніше за решту.

8.1. У axml кирилиця повністю законна

axml — це XML у UTF-8. Атрибут audioProgrammeName="Щедрівка, гурт іде селом" або audioObjectName="Трембіта — прямий звук" абсолютно коректний. Українська абетка вміщається в діапазон Кирилиці Unicode, і кожна літера — два байти в UTF-8. Літери, специфічні для української, — і (U+0456), ї (U+0457), є (U+0454), ґ (U+0491) — лежать у тому самому двобайтовому діапазоні й не є винятком.

Один виняток усе-таки є, і він український: апостроф. Типографський апостроф ’ — це U+2019, і в UTF-8 він займає три байти, а не два і не один. ASCII-апостроф ' (U+0027) — один байт. Слово об'єкт, набране з U+2019, важить 13 байтів: п'ять кириличних літер × 2 = 10, плюс 3 на апостроф. Те саме слово з ASCII-апострофом — 11 байтів. У axml це не має значення. У полі фіксованої ширини — має вирішальне.

8.2. У chna кирилиці не може бути ніколи

Поля UID, trackRef і packRef — це ASCII фіксованої ширини, і їхні розміри задані в байтах, а не в символах. Порахуймо точно.

Канонічні значення заповнюють свої поля рівно:

• ATU_00000001 — 12 символів, 12 байтів, поле UID = 12. Збіг точний.
• AT_00031001_01 — 14 символів, 14 байтів, поле trackRef = 14. Точний.
• AP_00031001 — 11 символів, 11 байтів, поле packRef = 11. Точний.

У кожному з трьох полів не лишається жодного вільного байта. Тепер найнебезпечніший сценарій: гомогліфи. Кириличні А, В, Е, І, К, М, Н, О, Р, С, Т, Х візуально не відрізняються від латинських A, B, E, I, K, M, H, O, P, C, T, X. При роботі з українською розкладкою — а звукорежисер перемикає розкладку десятки разів на годину — набрати ідентифікатор із кириличною літерою всередині надзвичайно легко, і на екрані це виглядатиме бездоганно.

Арифметика наслідків:

Кожна підмінена літера додає рівно один байт. Далі можливі рівно два сценарії, і обидва погані.

Записувач обрізає до ширини поля. Тоді в файл потрапляють 12 байтів із 14, причому обрізання відбувається посеред двобайтової послідовності: у полі опиняється перший байт кириличної Т без другого. Це вже не просто хибний ідентифікатор — це недійсний UTF-8, і парсер, який спробує декодувати поле як текст, або кине виняток, або підставить символ заміни.

Записувач не обрізає, а пише всі 14 байтів. Тоді зсувається весь масив. Запис перестає бути сорокабайтовим; наступний trackIndex читається зі зміщення 40, де тепер лежить не він, а хвіст попереднього UID. Файл із двадцятьма записами розсипається повністю, і повідомлення про помилку вкаже на доріжку 20, а не на доріжку 1, де насправді проблема.

Варто додати, що обидва сценарії однаково легко виникають і при копіюванні ідентифікатора з документа, набраного в текстовому редакторі з автозаміною, і при ручному правленні XML у редакторі, який показує кирилицю й латиницю одним і тим самим шрифтом без жодної позначки.

Практичне правило. Ідентифікатори ADM — ATU_, AT_, AP_, AC_, AO_, APR_ — генеруйте програмно й ніколи не набирайте руками. Якщо їх усе ж доводиться правити, поставте на конвеєр односкладову перевірку: кожен chna-запис має бути завдовжки 40 байтів, а кожне з трьох текстових полів — задовольняти регулярний вираз лише з [A-Z0-9_]. Кирилична літера у полі UID — не питання смаку, а пошкоджений файл.

Українським назвам місце в axml, і тільки в axml. У chna немає ні мови, ні кодування — там є байти фіксованої ширини.

8.3. Як це ловити автоматично

Перевірка коштує кілька рядків і має стояти в конвеєрі перед усім іншим. Логіка така: прочитати ckSize чанка chna, відняти чотири байти на numTracks і numUIDs, поділити залишок на 40 і переконатися, що ділення точне й частка дорівнює numUIDs. Якщо залишок не нульовий — у таблиці є запис нештатної довжини, і майже завжди причина в тому, що в текстове поле потрапив багатобайтовий символ. Далі — по кожному запису окремо: вирізати три текстові поля за фіксованими зміщеннями (2, 14 і 28 байтів від початку запису), декодувати їх суворо як ASCII без заміни помилкових байтів і перевірити регулярним виразом. Суворий режим декодування тут принциповий: режим із заміною перетворить кириличну літеру на знак заміни й тихо приховає саме ту помилку, яку ви шукаєте.

Ту саму перевірку варто застосувати й до назв файлів у комплекті поставки, і до рядків, які ви вводите в системи, що чекають на латиницю. Гомогліф у назві файлу не ламає BW64, але ламає зіставлення маніфесту з диском — а це вже наступний етап того самого техприймання.

9. Об'єктна модель 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+ без відповідника і підставити тишу. Усі три результати — це «файл відкрився». Лише один із них ловиться на слух, і то лише якщо ви знаєте, що там мало бути. Саме тому перевірку ADM неможливо робити вухами: вухо не чує відсутності, про яку його не попередили.

10. Типові відмови і як зловити кожну

10.1. Розбіжність кількості каналів між fmt і chna

fmt.nChannels каже 20, chna.numTracks каже 18. Файл суперечливий уже на другому чанку. Зазвичай це наслідок бавнсу, що змінив кількість доріжок після авторування метаданих. Виявлення: розібрати обидва чанки й порівняти цілі числа. Найдешевша перевірка в усьому конвеєрі, і вона ловить дивовижно велику частку відмов. Додатково перевірити, що кожен trackIndex у chna лежить у межах 1 … fmt.nChannels.

10.2. Осиротілі UID доріжок

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».

10.3. Повислі посилання в користувацькому діапазоні

packRef зі значенням 0x1000 і вище, для якого в axml немає визначення. Це найпідступніша відмова, бо файл відкривається. Виявлення: зібрати всі посилання з chna та axml, відібрати ті, що ≥ 0x1000, і переконатися, що кожне має визначення в XML.

10.4. Блоки з відсутнім або немонотонним часом

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]. Відмови групуються у три форми: розриви (поведінка рендерера не визначена — хтось утримує останню позицію, хтось глушить), перекриття (блоки конфліктують) і блоки поза хронологічним порядком (автоматизація, що стрибає назад).

10.5. Розбіжність частоти дискретизації та розрядності

audioTrackUID може нести sampleRate і bitDepth. Коли вони суперечать fmt , ви маєте два твердження про одну сутність. Позиція EBU Tech 3392 — такі атрибути «Should be ignored if available from the audio essence», — але не кожен рендерер цієї настанови дотримується. Окремо переконайтеся, що частота саме та, якої вимагає специфікація поставки: перетворення частоти після авторування ADM знецінює кожен rtime і duration, виражений у семплах.

10.6. Метадані описують підкладку, якої у файлі немає

XML оголошує пакет DirectSpeakers 7.1.4 — дванадцять каналів, — але надруковано лише підмножину 5.1, або канали висоти були заглушені на бавнсі й вивелися цифровою тишею. Граф посилань цілий; аудіо — ні. Виявлення: структурні перевірки цього не ловлять. Потрібен аналіз сутності: для кожного каналу, заявленого пакетом DirectSpeakers, виміряти, чи є в доріжці сигнал узагалі. Цифрова тиша на заявленому каналі підкладки не є автоматично помилкою — легітимний мікс цілком може лишити верхній тиловий канал порожнім, — але завжди потребує людського рішення.

10.7. Розбіжність typeLabel між каналом і пакетом

audioChannelFormat із typeLabel="0003" (Objects) усередині audioPackFormat із typeLabel="0001" (DirectSpeakers). Класичний результат ручного правлення XML. Виявлення: обійти дерево й порівняти typeLabel дитини з батьківським.

10.8. Розходження конформів

Більшість імерсивних поставок вимагає стерео- (і часто бінаурального) конформу поряд з імерсивним мастером. Типова відмова — не відсутність, а дрейф: конформ відрендерено з попередньої версії, зсунуто на кілька кадрів або з іншим стартовим часовим кодом. Стереофайл на 40 мс раніший за свого імерсивного батька пройде перевірку наявності файлу й провалить синхронне прослуховування. Виявлення: порівняти тривалості посемплово, порівняти стартовий часовий код із bext, звірити конформ із нуль-рендером мастера. Будь-який конформ, який не виводиться напряму з поточного мастера, вважайте підозрілим і перерендеріть, а не переперевіряйте.

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

11. Рендеринг: BS.2127 у розкладки BS.2051

Об'єктний файл сам по собі не звучить. Щоб він зазвучав, потрібен рендерер, який візьме позиції з audioBlockFormat і перетворить їх на підсилення для конкретних гучномовців конкретної розкладки.

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

Ключова властивість, яку варто засвоїти: рендер не міститься у файлі. Файл містить джерела й наміри; рендер — це результат застосування алгоритму до розкладки. Один і той самий BW64, відрендерений у 4+5+0 і в 4+7+0, дасть два різні сигнали, і в них буде різна виміряна гучність. Це не помилка — це визначення.

Для наших випадків із цього випливають цілком практичні речі. Програма «всередині кола» розгортається в 4+7+0 добре, бо в цій розкладці достатньо тилових позицій, щоб вісім рівномірно розподілених азимутів не злипалися попарно. У 0+5+0 та сама програма стискається: тилових напрямків мало, і два сусідні голоси починають ділити одну пару гучномовців. Це аргумент не проти 5.1, а за те, щоб перевіряти рендер у всіх цільових розкладках, а не тільки в найбагатшій.

Другий практичний наслідок стосується колядницької траєкторії. Рух, який у 4+7+0 читається як плавний прохід повз слухача, у 0+5+0 може перетворитися на серію стрибків між гучномовцями — не тому, що метадані погані, а тому, що між напрямками надто великі проміжки. Якщо матеріал будується навколо руху, перевірте його рендер у найбіднішій із цільових розкладок: саме там ламається те, що в найбагатшій звучить бездоганно.

Бінаурал — окрема тема, і про нього варто сказати чесно. Бінауральний рендер не є замінником кімнати: узагальнена HRTF не збігається з вашою анатомією, і локалізація спереду в багатьох слухачів «схлопується» до голови. Але для перевірки траєкторії — руху гурту колядників, повороту, зупинки під вікном — бінаурал цілком достатній, бо помилки в метаданих часу й азимуту чутні в навушниках так само, як у кімнаті. Використовуйте його як контрольний інструмент, а не як художнє мірило.

12. Гучність імерсивного матеріалу

Тут важливо розділяти те, що опубліковано, і те, що ходить по форумах.

12.1. Яка редакція чинна

ITU-R BS.1770 має шість редакцій: -0 (2006), -1 (2007), -2 (2011), -3 (2012), -4 (2015) і -5 (листопад 2023). Чинною є BS.1770-5. Редакція BS.1770-4 (жовтень 2015) — скасована, хоча саме на неї досі посилається більшість розгорнутих вимірювачів. Якщо ваш вимірювач пише в звіті «BS.1770-4», це не робить його результат неправильним, але в документації поставки називайте чинну редакцію.

12.2. Що специфікує BS.1770-5

• K-зважування — двоступеневий фільтр: спершу високочастотна полиця («головний» фільтр, що моделює жорстку сферу), потім фільтр високих частот RLB.
• Підсилення кривої K-зважування на 1 кГц — +0,698 дБ (лінійно 1,0836).
• Вимірювання блоками по 400 мс із перекриттям 75 %.
• Абсолютний ґейт: відкидаються блоки, тихіші за −70 LUFS.
• Відносний ґейт: обчислюється із середнього по блоках, які пережили абсолютний ґейт, і зміщується на −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 — довільно розташовані гучномовці й канали висоти — та об'єктний звук, який необхідно відрендерити, перш ніж його можна виміряти.

Гучність імерсивного матеріалу не є властивістю файлу; вона є властивістю рендера, і зміна цільової розкладки змінює число.

У цьому й полягає змістова відмінність від стерео. Стереомастер має одне значення гучності. Об'єктний мастер має їх стільки, скільки в нього цілей рендеру, і чесний спосіб назвати цифру — назвати разом із нею розкладку, на якій міряли, і рендерер, яким рендерили.

12.3. Що опубліковано для музики

Для канального стерео Spotify публікує інтегровану ціль −14 LUFS і стелю справжнього піку −1 dBTP, що затягується до −2 dBTP для мастерів, гучніших за −14 LUFS. Spotify також прямо зазначає: «Positive gain is applied to softer masters so the loudness level is -14 dB LUFS», але разом із тим — «We consider the headroom of the track, and leave 1 dB headroom for lossy encodings to preserve audio quality». Тобто тихий мастер із високими піками може бути піднятий не до кінця. Формулювання «тихі мастери не підіймають» помилкове; формулювання «тихі мастери завжди підіймають до цілі» помилкове так само.

AES TD1008 рекомендує −16 LUFS для музики. Фігура −18 LUFS із того самого документа стосується мовленнєвого контенту — новин, розмовних програм, драми; називати −18 музичною ціллю — поширена й серйозна помилка.

EBU R 128 задає мовну програмну ціль −23 LUFS. Це практика мовлення, а не специфікація музичного стримінгу.

12.4. Що не опубліковано

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

Так само 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 і запишіть у супровідні нотатки всі три назви.

12.5. Про пропрієтарні системи

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

13. Чесна позиція: імерсивного моніторингу у вас, найімовірніше, немає

Це треба сказати прямо, бо решта документа без цього виглядає відірваною від реальності.

В українських музичних студіях імерсивний моніторинг — рідкість. Кімнат із коректно налаштованою 4+7+0 або 4+5+0, із виміряними затримками, вирівняними рівнями й акустикою, придатною для оцінки верхнього шару, дуже небагато, і більшість із них не музичні, а постпродакшн для кіно й реклами. Ситуація, у якій опиняється більшість читачів цього тексту: матеріал знято, поставку вимагають імерсивну, а прослухати її як слід ніде.

З цього не випливає, що робити нічого не можна. З цього випливає, де саме лежить ваша додана вартість, і вона лежить не там, де здається.

Чого ви не можете зробити без кімнати: ухвалювати художні рішення про верхній шар. Тонкий баланс висоти, глибина, «скільки саме купола» — це рішення, які без коректної кімнати ухвалювати чесно неможливо, і навушники їх не замінюють.

Що ви можете зробити повністю, і зробити краще за багатьох:

1. Правильно вибрати модель. Коло — об'єкти. Капела — підкладка. Кобзар — об'єкт. Ці рішення ухвалюються на етапі планування запису, вухами в реальному просторі, і кімната для них не потрібна.
2. Правильно записати. Мікрофонний план, дисципліна доріжок, bext, часовий код, дублі. Це половина справи, і вона робиться в полі.
3. Правильно оформити метадані. Кожна перевірка з розділів 8 і 10 — арифметична або текстова. Жодна не потребує гучномовців.
4. Перевірити файл, який ви не можете належно прослухати. Це і є ключове вміння. Розібрати chna, звірити його з fmt , побудувати граф посилань, перевірити суміжність блоків, виміряти наявність сигналу в кожному заявленому каналі підкладки — усе це робиться програмно, детерміновано й повторювано.
5. Виміряти гучність на рендері й задокументувати розкладку та рендерер.
6. Перевірити траєкторії у бінауралі — не як художнє рішення, а як контроль метаданих.

Файл, який ви не можете належно прослухати, все одно можна довести до стану, коли машина підтверджує його коректність. Це не менша робота за зведення — просто інша.

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

Проходьте по порядку. Структурні перевірки першими — вони швидкі й знецінюють усе подальше.

Контейнер

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

Сутність

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

Цілісність chna

1. Кожен запис — рівно 40 байтів; тіло чанка дорівнює 4 + 40 × numUIDs.
2. Усі три текстові поля кожного запису містять лише [A-Z0-9_]. Жодного байта поза ASCII.
3. Кожен packRef зі значенням 0x1000 і вище розв'язується у користувацьке визначення, присутнє в axml.
4. Повторювані 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. axml — валідний UTF-8; українські назви в атрибутах імен присутні там, де вони мають бути.
2. Апострофи в назвах узгоджені (U+2019 або U+0027 — але один і той самий у всьому комплекті, разом із назвою релізу й списком треків).

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

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

Відтворюваність

1. Контрольна сума для кожного файлу поставки, маніфест збережено.
2. Сесію і XML ADM архівуйте окремо від BW64: XML, який можна порівняти утилітою diff, згодом вартий більше, ніж бінарник, який можна лише перерозібрати.

Імерсивна поставка не завершена, коли вона добре звучить; вона завершена, коли машина, яка ніколи її не чула, може довести, що її посилання розв'язуються.

15. Підсумок

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/

Unicode

• Unicode Standard, блок Cyrillic (U+0400–U+04FF) — https://www.unicode.org/charts/PDF/U0400.pdf
• Unicode Standard, блок General Punctuation (U+2000–U+206F, апостроф U+2019) — https://www.unicode.org/charts/PDF/U2000.pdf

Довідково

• Швидкість звуку в повітрі за 20 °C (≈343 м/с) — загальновідома фізична величина; розрахунок затримки в розділі 3 виконано з неї арифметично.

Востаннє переглянуто у вересні 2026 року. Стандарти переглядають; перш ніж цитувати номер пункту, завжди звіряйтеся з чинною редакцією на сторінках ITU та EBU.