Dlaczego master immersyjny przechodzi w edytorze fali, a nie przechodzi QC

Plik immersyjny potrafi otworzyć się w edytorze fali, pokazać dwanaście albo szesnaście zdrowo wyglądających ścieżek, odtworzyć się sensownie — i mimo to zostać odrzucony. Powód jest strukturalny: w pliku BW64 audio i metadane to dwie osobne rzeczy, które muszą się dokładnie zgadzać, a nic w samym formacie tego nie wymusza. Renderer rozwiązuje odwołania. Edytor rysuje próbki. Różne zadania — i właśnie dlatego QC materiału ADM polega na sprawdzaniu spójności odwołań, a nie na słuchaniu. Oto co mówią oba standardy, gdzie pękają odwołania i który test wyłapuje którą usterkę.

Trzy rodzaje audio i dlaczego to rozróżnienie decyduje o wszystkim

Każdy problem z dostawą immersyjną zaczyna się od pomylenia tego, którą z trzech rzeczy jest dana ścieżka.

Dźwięk kanałowy przypisuje każdą ścieżkę do stałej pozycji głośnika. Stereo jest kanałowe, 5.1 też, tak samo bed 7.1.4. Pozycja jest wpisana w tożsamość kanału: ścieżka 3 to głośnik centralny i pozostaje głośnikiem centralnym w każdym systemie, który ją odtwarza. ITU-R BS.2051 formalizuje to dla zaawansowanych systemów dźwiękowych, opisując układy jako liczby warstw Upper + Middle + Bottom — System A to 0+2+0 (stereo), System B to 0+5+0 (5.1), System D to 4+5+0, System J to 4+7+0, a System H to 9+10+3, czyli konfiguracja 22.2. W ADM jest to typeDefinition DirectSpeakers, typeLabel 0001.

Dźwięk obiektowy niesie sygnał mono (albo wielokanałowy pack) plus metadane pozycyjne zmienne w czasie. To renderer decyduje, które realne głośniki go odtworzą, na podstawie układu obecnego w pomieszczeniu. Nic w takiej ścieżce nie zakłada istnienia konkretnego głośnika. To typeDefinition Objects, typeLabel 0003.

Dźwięk scenowy, w praktyce ambisonia wyższego rzędu, koduje całe pole akustyczne jako składowe harmonik sferycznych. Żadna składowa sama z siebie nie odpowiada kierunkowi; kierunek wyłania się z kombinacji liniowej. To HOA, typeLabel 0004. ADM definiuje też Matrix (0002) dla sygnałów matrycowanych, takich jak Mid-Side czy Lt/Rt, oraz Binaural (0005).

To rozróżnienie nie jest taksonomią. Dostawa kanałowa opisuje się sama na tyle, że przetrwa jako goły WAV — wystarczy poprawna kolejność kanałów i to zagra. Dostawa obiektowa albo scenowa bez metadanych nie znaczy nic: audio to stos nieodróżnialnych strumieni mono, a ADM jest jedyną rzeczą, która twierdzi inaczej. Ta asymetria jest powodem istnienia BW64 i ADM.

BW64 istnieje z powodu pewnej 32-bitowej liczby

Klasyczny WAV to plik RIFF. RIFF, z 1991 roku, poprzedza każdy chunk 32-bitowym polem rozmiaru. Trzydzieści dwa bity adresują 4,294,967,296 bajtów — 4 GB — i to jest twardy sufit zarówno dla całego pliku, jak i dla chunku data w środku.

Dla stereo 48 kHz / 24-bit przepływność wynosi 288,000 bajtów na sekundę, więc 4 GB to około 4 godziny 8 minut. Bez znaczenia. Dla 128-ścieżkowego mastera obiektowego przy 96 kHz / 24-bit przepływność to 36,864,000 bajtów na sekundę, a 4 GB to niecałe dwie minuty — 116.5 sekundy.

Mastery immersyjne przekraczają ten limit rutynowo, a writer WAV, który go dobije, produkuje albo plik ucięty, albo taki, w którym deklarowane rozmiary po cichu się przewinęły. EBU odpowiedziało na to najpierw formatem RF64 (EBU Tech 3306); ITU poprowadziło to dalej jako Zalecenie ITU-R BS.2088 — BW64.

Sztuczka ze strażnikiem: 0xFFFFFFFF i chunk ds64

BS.2088 opisuje mechanizm wprost. „The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file", a pierwotne 32-bitowe pola rozmiaru stają się flagami ucieczki: „If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead."

To cała sztuczka i warto powiedzieć to wprost: BW64 nie poszerza pól rozmiaru RIFF. Wypełnia je wartością 0xFFFFFFFF jako strażnikiem i umieszcza prawdziwe 64-bitowe rozmiary w chunku ds64, który musi stać w pliku jako pierwszy. Dzięki temu plik BW64 poniżej 4 GB jest bajt w bajt zgodny z czytnikiem WAV pod każdym względem poza czteroznakową sygnaturą. Wiele narzędzi go przyjmuje; niektóre uparcie nie.

Chunki i ten, który ma dokładnie 40 bajtów na wpis

Zgodnie z BS.2088 plik BW64 powinien zawierać co najmniej ds64, fmt , chna, axml (z bxml i sxml jako alternatywnymi nośnikami metadanych) oraz dane fali.

ds64 musi być pierwszym chunkiem po sygnaturze, bo czytnik musi znać prawdziwe rozmiary, zanim ruszy dalej. Niesie 32-bitowe połówki niską i wysoką dla rozmiaru całego pliku i rozmiaru data, plus tablicę wpisów ChunkSize64 dla każdego innego przerośniętego chunku — axml opisujący tysiące obiektów z automatyką z dokładnością do próbki sam może zbliżyć się do 4 GB albo je przekroczyć.

fmt to standardowy chunk formatu WAVE — format próbki, częstotliwość próbkowania, liczba kanałów, bity na próbkę, block align. Jest jedynym wiążącym stwierdzeniem, ile przeplecionych kanałów znajduje się w data. Wszystko dalej to metadane o tych kanałach, a metadane potrafią kłamać.

chna to most między fizycznymi ścieżkami a ADM. Po ckID, ckSize, 2-bajtowym numTracks i 2-bajtowym numUIDs mieści płaską tablicę wpisów audioID o stałej szerokości, każdy dokładnie po 40 bajtów:

2 + 12 + 14 + 11 + 1 = 40. Te szerokości nie są sugestią: to ASCII o stałej szerokości, a writer, który wypuści 13-znakowy UID, wyprodukował tablicę uszkodzoną, a nie lekko nietypową.

Znaczenie ma też konwencja identyfikatorów. Wartości 0x0FFF i niższe odsyłają do wspólnych definicji ADM — standardowych, predefiniowanych formatów kanałów i packów — natomiast 0x1000 i wyższe oznaczają definicje własne, które muszą być obecne w axml. AP_00010003 to 5.1 z definicji wspólnej i nie potrzebuje XML-a; AP_00031001 to własny pack obiektowy i XML-a potrzebuje, inaczej zawiśnie w próżni.

numUIDs może też legalnie przewyższać numTracks: wytyczne EBU zauważają, że tam, gdzie „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", jeden trackIndex może wystąpić w kilku wpisach. Narzędzia QC zakładające jeden UID na ścieżkę oznaczają poprawne pliki jako zepsute.

axml to dokument XML w UTF-8 zawierający drzewo <audioFormatExtended>. To jest ADM i w nim mieszkają praktycznie wszystkie ciekawe usterki. data to zwykły przepleciony PCM; nic w nim nie wie nic o obiektach.

Kolejność: ds64 zawsze pierwszy; fmt przed data. Ale axml może legalnie leżeć za data i często tak leży, ponieważ — jak zauważa BS.2088 — podczas nagrywania „the XML metadata will likely be of an unknown length." Plik z axml na końcu nie jest wadliwy, ale czytnik skanujący tylko pierwszy megabajt zgłosi całkowity brak ADM. To odpowiada za zaskakująco dużą część zgłoszeń „mój plik nie ma metadanych".

ADM to graf, a usterki to zerwane krawędzie

Hierarchia z ITU-R BS.2076 biegnie audioProgramme → audioContent → audioObject → audioPackFormat → audioChannelFormat → audioBlockFormat, z audioTrackUID jako liściem i jedynym elementem odpowiadającym fizycznej ścieżce.

To graf odwołań, a nie zagnieżdżony dokument, i każda poważna usterka dostawy jest w nim zerwaną krawędzią. Wiszące odwołanie jest groźne dlatego, że nie ma jednego zachowania na wypadek zerwania. Renderer rozwiązujący audioPackFormatIDRef wskazujący na pack nieobecny w XML może przerwać parsowanie i odrzucić plik; może pominąć ten obiekt i wyrenderować całą resztę, produkując miks po cichu pozbawiony jednej ścieżki; albo może cofnąć się do wspólnych definicji, znaleźć identyfikator z własnego zakresu 0x1000 i wyżej bez dopasowania i podstawić ciszę. Wszystkie trzy wyniki to „plik się otworzył". Tylko jeden wyłapie słuchanie i tylko wtedy, gdy wiesz, co powinno tam być.

Cztery usterki odpowiadające za większość odrzuceń

Liczba ścieżek w fmt niezgodna z chna. fmt .nChannels mówi 16; chna.numTracks mówi 14. Plik jest wewnętrznie sprzeczny już od dwóch pierwszych chunków — zwykle to bounce, który zmienił liczbę ścieżek po napisaniu metadanych, albo narzędzie, które usunęło ścieżki bez przepisania chna. Wykrycie polega na sparsowaniu dwóch liczb całkowitych i porównaniu ich: najtańszy test w całym łańcuchu, a wyłapuje zdumiewającą część usterek. Sprawdź przy okazji, czy każdy trackIndex mieści się w 1 … fmt .nChannels.

audioTrackUID, do którego nie odwołuje się żaden obiekt. UID w chna, do którego nie odwołuje się żaden audioObject, oznacza, że istnieje audio, którego nic nie wyrenderuje; przypadek odwrotny, audioTrackUIDRef w XML bez odpowiadającego wpisu w chna, oznacza, że metadane oczekują ścieżki, której nie ma. Zbuduj zbiór UID-ów z chna i zbiór z axml, po czym weź różnicę symetryczną; powinna być pusta. EBU Tech 3392 stwierdza to wprost: „If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs."

Czasy bloków biegnące wstecz. BS.2076 nie zostawia wątpliwości: „When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present." EBU Tech 3392 zacieśnia to do ciągłości — „rtime + duration of an audioBlockFormat should match the rtime of the following block" — przy czym pierwszy blok obiektu zaczyna się o 00:00:00.00000, żaden blok nie jest krótszy niż jedna próbka, a czasy trwania sumują się do nadrzędnego audioObject. Przejdź bloki w kolejności dokumentu i sprawdź rtime[n] + duration[n] == rtime[n+1]. Usterki przybierają trzy postaci: dziury, przy których zachowanie renderera jest niezdefiniowane i jedne utrzymują ostatnią pozycję, a inne wyciszają; nakładki, przy których bloki się biją; oraz bloki poza kolejnością chronologiczną, czyli automatyka skacząca wstecz w środku programu.

Bed opisany w XML, którego nigdy nie zapisano na dysk. XML deklaruje pack DirectSpeakers 7.1.4 — dwanaście kanałów — ale zapisano tylko podzbiór 5.1 albo kanały wysokościowe były wyciszone przy bounce i wylądowały jako cyfrowa cisza. Graf odwołań jest nienaruszony; audio nie. Testy strukturalne tego nie złapią: potrzebna jest analiza samej treści, sprawdzająca, czy każdy kanał deklarowany przez pack DirectSpeakers w ogóle zawiera sygnał. Cyfrowa cisza na deklarowanym kanale bedu nie jest automatycznie błędem — uprawniony miks może zostawić kanał tylny górny pusty — ale zawsze zasługuje na decyzję człowieka.

Co opublikowano o głośności immersyjnej, a czego nie

Jedna liczba nie przetrwa przeprowadzki ze stereo i warto powiedzieć dlaczego.

BS.1770-5 (November 2023) to obowiązujące wydanie; BS.1770-4 jest zastąpione, choć większość wdrożonych mierników wciąż je przywołuje. Jego rdzenny algorytm waży L, R i C przez 1.0 oraz Ls i Rs przez 1.41 (około +1.5 dB), wyklucza LFE i ma zakres „from one to five channels". BS.1770-5 wychodzi poza to w aneksach, obejmując zaawansowane systemy dźwiękowe z BS.2051 oraz dźwięk obiektowy — który przed pomiarem musi zostać wyrenderowany. Głośność immersyjna nie jest więc właściwością pliku, tylko renderu, a zmiana docelowego układu zmienia liczbę. Zmierz render zgodny z BS.2127 do nazwanego układu BS.2051 miernikiem BS.1770-5 i zapisz wszystkie trzy rzeczy w notatce dostawczej; BS.2127 definiuje referencyjny renderer ADM, a jego otwartoźródłowy brat, EBU ADM Renderer (EBU Tech 3388), to praktyczna droga do powtarzalnej liczby.

Żaden muzyczny serwis streamingowy nie publikuje celu głośności integrated dla dostawy immersyjnej. Liczby krążą po forach i w materiałach szkoleniowych producentów; żadna nie jest opublikowaną specyfikacją i ten artykuł nie powtórzy żadnej z nich tak, jakby nią była. Opublikowane jest to, co dotyczy kanałowego stereo — cel integrated Spotify na −14 LUFS z sufitem true peak na −1 dBTP, zaostrzonym do −2 dBTP powyżej −14 LUFS, oraz −16 LUFS dla muzyki z AES TD1008 (jego liczba −18 LUFS dotyczy materiału opartego na mowie, a podawanie −18 jako celu dla muzyki to częsty i poważny błąd).

Dolby Atmos to zastrzeżona, licencjonowana technologia Dolby Laboratories, a Sony 360 Reality Audio to system zastrzeżony zbudowany na MPEG-H. Ich wymagania ustalają ich właściciele, zmieniają się bez oglądania na harmonogramy ITU czy EBU i nie są tu podane; nie twierdzimy, że łączą nas z nimi jakiekolwiek związki ani że mamy ich poparcie. Czytaj bieżącą dokumentację samego licencjodawcy.

Co sprawdzić, zanim to wyślesz

Najpierw testy strukturalne; są szybkie i unieważniają wszystko, co dalej.

• Pierwsze cztery bajty to BW64. Jeśli czytasz RIFF, to zwykły WAV i nie może przekroczyć 4 GB.
• ds64 jest pierwszym chunkiem po sygnaturze, jego 64-bitowe rozmiary zgadzają się z rozmiarem pliku i data na dysku, a każdy przerośnięty chunk inny niż data ma wpis ChunkSize64 w tablicy.
• Znajdź axml jawnie, także za data — nigdy nie wyciągaj wniosku „brak ADM" z częściowego skanu.
• Częstotliwość próbkowania i rozdzielczość bitowa w fmt dokładnie odpowiadają specyfikacji dostawy. Żadnej konwersji częstotliwości próbkowania po napisaniu ADM — unieważnia każdy rtime i duration wyrażony w próbkach.
• fmt .nChannels równa się chna.numTracks; każdy trackIndex mieści się w zakresie i jest liczony od 1.
• Każdy wpis chna ma dokładnie 40 bajtów z poprawnie dopełnionymi polami o stałej szerokości, a każdy packRef na poziomie 0x1000 lub wyżej rozwiązuje się do definicji własnej obecnej w axml.
• Każdy audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef i audioTrackUIDRef się rozwiązuje. Zero wiszących krawędzi w którąkolwiek stronę, bez odwołań cyklicznych.
• Wielkoblokowe formaty kanałów niosą rtime i duration na każdym bloku; bloki są ciągłe i monotoniczne; obiekty zaczynają się o 00:00:00.00000.
• Każdy kanał deklarowanego bedu zawiera to, co powinien. Cyfrową ciszę zbadaj.
• Timecode startowy w bext jest spójny w całym zestawie, a wersje stereo i binauralne są przerenderowane z bieżącego mastera. Wersja spóźniona o 40 ms względem swojego immersyjnego rodzica przejdzie test obecności pliku i polegnie przy zsynchronizowanym odsłuchu.
• Policz sumę kontrolną każdego elementu dostawy, zachowaj manifest i zarchiwizuj ADM XML osobno od BW64 — XML, który da się porównać diffem, jest później wart więcej niż binarium, które da się tylko ponownie sparsować.

BW64 i ADM to standardy otwarte, opublikowane i dostępne do czytania za darmo, co warto wykorzystać: możesz sam przeczytać BS.2088 i BS.2076, sparsować chunk chna czterdziestoma linijkami kodu i zweryfikować, co eksporter danego producenta naprawdę zapisał, zamiast wierzyć w to, co twierdziło jego okienko dialogowe. Prawie wszystkie niepotrzebne odrzucenia materiału immersyjnego to błędy spójności odwołań, które walidator wyłapuje w mniej niż sekundę.

Darmowy inspektor BW64/ADM od Mazufy pod adresem mazufa.com/immersive-master-check parsuje kontener i metadane w całości na twoim urządzeniu i niczego nie wysyła, co czyni go użytecznym przy materiale, który kontraktowo nie może opuścić budynku. Sama Mazufa jest darmowa w wydawaniu, bierze 0% prowizji i działa wyłącznie z zaproszenia, z ludzką weryfikacją każdego kompletnego zgłoszenia.

Źródła

Zalecenia 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

Dokumenty techniczne EBU

• EBU Tech 3306, RF64: An extended file format for audio data — https://tech.ebu.ch/docs/tech/tech3306.pdf
• EBU Tech 3285 (wraz z suplementami), 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
• implementacja referencyjna 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/

Dokumentacja serwisów

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