BW64 i ADM: dźwięk immersyjny w praktyce dostawczej

Dokument roboczy dla realizatorów przygotowujących mastery obiektowe i scenowe, oraz dla muzyków, którym ktoś wręczył „deliverable immersyjny" i kazał przejść QC.

Krótka odpowiedź

ADM (Audio Definition Model, Zalecenie ITU‑R BS.2076) to otwarty model metadanych, który opisuje, czym jest każda ścieżka w pliku: kanałem przypisanym do konkretnego głośnika, ruchomym obiektem, czy składową ambisoniczną — oraz w jaki sposób te ścieżki składają się na kompletny program. Model ten jest przenoszony jako dokument XML wewnątrz kontenera BW64 (Zalecenie ITU‑R BS.2088), czyli 64‑bitowego rozszerzenia RIFF/WAVE, które wychodzi poza limit 4 GB klasycznego WAV‑a. Dostawy immersyjne wywracają się na QC dlatego, że dźwięk i metadane to dwie osobne rzeczy, które muszą się zgadzać co do znaku, a format nie wymusza tej zgodności. Liczba kanałów w fmt niezgodna z tablicą chna, audioTrackUID, do którego nie odwołuje się żaden obiekt, blok, którego czas biegnie wstecz, podkład opisany w XML‑u, ale nigdy niewydrukowany na dysk — każdy z tych błędów jest niewidoczny w edytorze fal i zabójczy dla renderera. Kontrola jakości ADM to sprawdzanie spójności referencji, a nie odsłuch.

1. Dlaczego akurat polska muzyka jest dobrym punktem wyjścia

Argument za reprezentacją obiektową i scenową rzadko bywa gdziekolwiek tak mocny jak w repertuarze polskiej szkoły kompozytorskiej. Znaczna część dwudziestowiecznej polskiej twórczości orkiestrowej — nurt, który polska muzykologia nazywa sonoryzmem — traktuje orkiestrę nie jako zbiór linii melodycznych powierzonych sekcjom, lecz jako pole barwowe i przestrzenne, w którym instrumenty są rozdrobnione na osobne, indywidualnie zapisane głosy.

Przykład, który da się zweryfikować w partyturze i w opisie bibliograficznym: Tren – Ofiarom Hiroszimy Krzysztofa Pendereckiego jest napisany na 52 instrumenty smyczkowe, w rozkładzie 24 skrzypiec, 10 altówek, 10 wiolonczel i 8 kontrabasów (Wikipedia, Threnody to the Victims of Hiroshima). Culture.pl opisuje utwór jako dzieło, które zapoczątkowało sonoryzm, kładący nacisk na „tone and sound, and achieved through unconventional articulations, a variety of textures and colours" (culture.pl). Nie ma tu sekcji pierwszych skrzypiec grającej unisono — jest 24 osobnych źródeł, których suma tworzy klaster.

Dla realizatora oznacza to rzecz bardzo konkretną: stereofoniczna para nad orkiestrą redukuje właśnie tę informację, która jest treścią utworu. Jeżeli 52 głosy są rozróżnialne w sali, a w pliku stają się dwoma kanałami, to nie jest to strata „detalu" — to strata materiału kompozytorskiego. To jest właśnie ta sytuacja, w której reprezentacja obiektowa (Objects) albo scenowa (HOA) przestaje być wodotryskiem, a zaczyna być adekwatnym zapisem.

1.1 Gdzie kończy się to, co ADM potrafi

Tu trzeba być uczciwym, bo w rozmowach o „muzyce przestrzennej" ta granica jest notorycznie zacierana.

ADM zapisuje rendering, a nie instrukcję wykonawczą. audioBlockFormat z azymutem, elewacją i odległością mówi rendererowi, skąd ma dobiec dźwięk już zarejestrowany. Nie mówi muzykowi, gdzie ma stanąć, nie jest rozszerzeniem partytury i nie ma statusu tekstu dzieła. Jeżeli kompozytor przewidział rozmieszczenie wykonawców w przestrzeni sali, to informacja ta żyje w partyturze i w wykonaniu; ADM może co najwyżej odtworzyć jej brzmiący skutek dla słuchacza w danym punkcie. Nie należy więc pisać w notatkach dostawczych, że „ADM zawiera rozstawienie zespołu" — zawiera pozycje źródeł w renderze.

Druga uczciwość: konkretne wskazówki rozstawienia są sprawą pojedynczej partytury, nie całego nurtu. Da się zweryfikować, że Tren rozdrabnia smyczki na 52 indywidualne głosy. Twierdzenie, że polski sonoryzm jako całość przewiduje rozstawienie muzyków wokół publiczności, jest uogólnieniem, którego nie należy powtarzać bez sięgnięcia do konkretnej partytury. Sprawdź w partyturze utworu, który nagrywasz, i zacytuj ją — nie nurt.

Warto też pamiętać, że polskie środowisko ma z eksperymentem elektroakustycznym doświadczenie instytucjonalne: Studio Eksperymentalne Polskiego Radia powstało 15 listopada 1957 roku, jego wieloletnim kierownikiem był Józef Patkowski, a studio działało do 2004 roku; pierwszym samodzielnym utworem zrealizowanym w studiu była Etiuda na jedno uderzenie w talerz Włodzimierza Kotońskiego z 1959 roku (Wikipedia, Polish Radio Experimental Studio). Festiwal Warszawska Jesień, założony w 1956 roku przez Tadeusza Bairda i Kazimierza Serockiego, odbywa się corocznie (Wikipedia, Warsaw Autumn). Tradycja pracy z barwą i przestrzenią jest tu więc starsza niż formaty, o których mowa w tym dokumencie.

2. Trzy modele dźwięku w ADM

Dźwięk kanałowy (DirectSpeakers, typeLabel 0001) przypisuje każdą ścieżkę do stałej pozycji głośnika. Stereo jest kanałowe, 5.1 jest kanałowe, podkład („bed") 7.1.4 też. Pozycja jest wpisana w tożsamość kanału: ścieżka 3 jest kanałem centralnym i pozostaje nim w każdym systemie. Zalecenie ITU‑R BS.2051 formalizuje te układy dla zaawansowanych systemów dźwiękowych, opisując je liczbami głośników w warstwach górna + środkowa + dolna: 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.

Dźwięk obiektowy (Objects, typeLabel 0003) niesie sygnał mono (lub pakiet wielokanałowy) plus metadane pozycyjne zmienne w czasie. To renderer decyduje, które realne głośniki i w jakich proporcjach odtworzą obiekt — na podstawie układu faktycznie obecnego w pomieszczeniu. Nic w samej ścieżce nie zakłada głośnika.

Dźwięk scenowy (HOA, typeLabel 0004), w praktyce ambisonia wyższych rzędów, koduje całe pole akustyczne jako zestaw składowych harmonik sferycznych. Żadna składowa nie odpowiada samodzielnie żadnemu kierunkowi; kierunek wyłania się z kombinacji liniowej. ADM definiuje ponadto Matrix (0002) dla sygnałów matrycowanych (MS, Lt/Rt) i Binaural (0005) dla gotowych par słuchawkowych.

Dźwięk kanałowy mówi plikowi, gdzie stoją głośniki; dźwięk obiektowy odmawia zgadywania, a scenowy opisuje pole, nie źródła.

Ta różnica ma konsekwencję dostawczą, nie tylko pojęciową. Materiał kanałowy jest na tyle samoopisowy, że przeżyje jako goły WAV — wystarczy trafić z kolejnością kanałów. Materiał obiektowy i scenowy bez metadanych nie znaczy nic: to stos nierozróżnialnych strumieni mono, a ADM jest jedyną rzeczą, która twierdzi inaczej. Ta asymetria jest całym powodem istnienia BW64 i ADM.

3. Kapela góralska: mały zespół jako realna geometria

Najczystszy polski przypadek obiektowy nie jest wcale orkiestrowy. Jest nim kapela góralska.

Współczesny podstawowy skład instrumentarium w muzyce podhalańskiej stanowią, jak podaje serwis muzykatradycyjna.pl, „skrzypce (prym i sekund) oraz małe basy"; basy podhalańskie są instrumentem trzystrunowym o stroju D–d–A, z dwiema strunami jelitowymi i jedną metalową (muzykatradycyjna.pl). Prym prowadzi melodię, sekund (często więcej niż jeden) akompaniuje, basy dają fundament rytmiczno‑harmoniczny.

Co z tego wynika dla realizacji: kapela nie gra ustawiona w linii twarzą do mikrofonu. Muzykanci stoją blisko siebie, zwróceni ku sobie, bo sekund reaguje na prym w skali dziesiątek milisekund, a basy trzymają puls dla całej grupy. To jest realna geometria o znaczeniu muzycznym, a nie przypadkowe rozstawienie, które można „poprawić" na miksie.

Praktyczne mapowanie:

• prym, każdy sekund i basy — osobne obiekty Objects (typeLabel 0003), po jednym audioTrackUID na ścieżkę;
• pozycje statyczne, czyli po jednym audioBlockFormat na audioChannelFormat, rtime 00:00:00.00000 i duration równe czasowi trwania nadrzędnego audioObject;
• podkład (bed) w DirectSpeakers niosący wnętrze — izbę, karczmę, salę — a nie sygnał instrumentów;
• odległości ustawione zgodnie z faktycznymi, a nie „ładnie rozstrzelone": obiekty rozjechane szerzej, niż zespół stał, brzmią jak czterech solistów, którzy przypadkiem grają ten sam kawałek.

Typowy błąd: separacja mikrofonów w takim składzie jest z natury kiepska, więc każdy obiekt zawiera przesłuch pozostałych. Rozsunięcie obiektów w renderze rozsuwa też przesłuch, co daje rozmytą, podwójną lokalizację. Jeżeli separacja jest niska, trzymaj obiekty blisko ich prawdziwych pozycji — wtedy przesłuch trafia mniej więcej tam, gdzie powinien.

4. Kościół i empora organowa: przypadek „bed + obiekty"

Polskie wnętrze sakralne to najczęstsza realna sytuacja nagraniowa, w której podział na podkład i obiekty narzuca się sam.

Organy niemal nigdy nie stoją na poziomie słuchacza. Stoją na chórze muzycznym (emporze organowej), zwykle nad wejściem, po przeciwnej stronie niż prezbiterium. Dźwięk przychodzi więc z góry i z tyłu — a to jest informacja wysokościowa, którą stereo z definicji gubi, a układ z warstwą górną (BS.2051 System D, 4+5+0, albo System J, 4+7+0) potrafi oddać wprost. Jeżeli w jakiejś sytuacji warstwa górna ma sens muzyczny, a nie efektowny, to właśnie w tej.

Rozsądny podział:

• podkład (DirectSpeakers) — wnętrze: pogłos nawy, gwar, otoczenie; to jest „sala", która nie ma się ruszać;
• obiekty — celebrans i lektor przy ołtarzu, kantor, ewentualnie solista;
• chór na emporze — decyzja projektowa, nie oczywistość: jako pakiet DirectSpeakers z podniesioną warstwą, jeżeli traktujesz go jak zespół zajmujący stałe miejsce, albo jako grupa obiektów, jeżeli chcesz zachować rozróżnialność głosów;
• organy — pakiet, nie pojedynczy obiekt: instrument jest fizycznie rozłożony na szafie o kilku metrach szerokości, a piszczałki różnych sekcji mówią z różnych miejsc. Ściśnięcie tego do jednego punktu jest słyszalne i brzmi nienaturalnie mało.

4.1 Ceglany gotyk Pomorza jako problem

Wielkie ceglane kościoły gotyckie północnej Polski — typ budowli, którego najbardziej znanym przedstawicielem jest bazylika Mariacka w Gdańsku — są dla rejestracji immersyjnej problemem osobnej klasy. Cegła, kamienna posadzka, tynkowane sklepienia i ogromna kubatura przy niemal zerowej ilości materiałów pochłaniających dają bardzo długi pogłos i pole dźwiękowe, które szybko przestaje mieć wyraźny kierunek.

Nie podaję tu wartości czasu pogłosu, bo nie znalazłem opublikowanego, wiarygodnego pomiaru RT dla konkretnego obiektu, który mógłbym zacytować; wartości krążące w internecie nie mają źródła, do którego dałoby się odesłać. Jeżeli potrzebujesz liczby, zmierz ją sam i zapisz warunki pomiaru w notatkach dostawczych.

Konsekwencje praktyczne są jednak niezależne od dokładnej liczby:

1. Lokalizacja obiektu zaczyna walczyć z polem pogłosowym. Obiekt o ostro określonej pozycji brzmi w takim wnętrzu jak wklejony, bo słuchacz odbiera sprzeczne przesłanki: precyzyjny kierunek dźwięku bezpośredniego i całkowicie rozmyte otoczenie.
2. Podkład musi być nagrany, nie wyprodukowany. Sztuczny pogłos dodany do suchych obiektów w takiej skali brzmi mało; realne opóźnienia i rozproszenie takiego wnętrza są trudne do podrobienia.
3. Rozstaw mikrofonów podkładu rośnie. Odległość krytyczna jest tu duża i mikrofony podkładu muszą stać wyraźnie dalej niż w sali koncertowej, żeby pole rozproszone było naprawdę rozproszone, a nie skorelowane.
4. Wysoki diffuseness na obiektach jest tu narzędziem, nie ozdobą. ADM przewiduje ten parametr właśnie po to, żeby obiekt mógł być mniej punktowy — i w takim wnętrzu to bywa jedyny sposób, by obiekt i podkład brzmiały jak jedno miejsce.

5. Procesje i tradycje plenerowe: źródło, które naprawdę się porusza

Polska ma nietypowo bogaty zestaw sytuacji, w których źródło dźwięku przemieszcza się względem słuchacza: procesja Bożego Ciała przechodząca między ołtarzami, kolędnicy z gwiazdą i szopką chodzący od domu do domu, orszak Trzech Króli, korowody dożynkowe, obchody odpustowe. To są przypadki obiektowe w najbardziej dosłownym sensie — nie „obiekt, któremu dorysowano automatykę", tylko obiekt, który w rzeczywistości przejechał obok mikrofonu.

Trzy rzeczy, które trzeba tu zrobić dobrze:

Czas musi być ciągły. Ruch zapisuje się jako sekwencja audioBlockFormat. BS.2076 jest tu jednoznaczne: gdy w jednym audioChannelFormat jest więcej niż jeden audioBlockFormat, „both rtime and duration shall be present". EBU Tech 3392 zaostrza to do reguły przylegania: „rtime + duration of an audioBlockFormat should match the rtime of the following block". Automatyka wyeksportowana z DAW‑a co ramkę potrafi wygenerować dziesiątki tysięcy bloków — i jedno zaokrąglenie w złą stronę robi z tego plik z dziurami.

Gęstość bloków to decyzja, nie ustawienie domyślne. Procesja idąca krokiem pieszym przesuwa się o kilkadziesiąt centymetrów na sekundę. Interpolacja pozycji przy dwóch–pięciu blokach na sekundę jest w zupełności wystarczająca, a plik jest o rzędy wielkości mniejszy i o rzędy wielkości łatwiejszy do zwalidowania.

Otwarta przestrzeń nie wybacza. Na dworze nie ma pogłosu, który maskowałby błędy trajektorii. Skok pozycji o kilkanaście stopni między blokami, niesłyszalny w nawie kościoła, na rynku jest słyszalny jako kliknięcie przestrzenne.

6. BW64: po co istnieje, z policzoną arytmetyką

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.

Policzmy, kiedy to boli. Strumień PCM ma przepływność:

bajty/s = częstotliwość próbkowania × liczba kanałów × (bity na próbkę ÷ 8)

• Stereo, 48 kHz, 24 bity: 48 000 × 2 × 3 = 288 000 B/s. 4 294 967 296 ÷ 288 000 ≈ 14 913 s, czyli 4 godziny 8 minut 33 sekundy. Limit nie istnieje.
• 7.1.4 plus 16 obiektów = 28 ścieżek, 48 kHz, 24 bity: 48 000 × 28 × 3 = 4 032 000 B/s. 4 294 967 296 ÷ 4 032 000 ≈ 1 065 s, czyli 17 minut 45 sekund. Limit zaczyna być realny — to jest krótsza EP‑ka.
• To samo w 96 kHz: 8 064 000 B/s, czyli ≈ 533 s = 8 minut 53 sekundy. Jeden dłuższy utwór.
• 128 ścieżek, 96 kHz, 24 bity: 36 864 000 B/s, czyli ≈ 116,5 s — niecałe dwie minuty.

EBU rozwiązało to najpierw formatem RF64 (EBU Tech 3306). ITU podjęło tę pracę jako Zalecenie ITU‑R BS.2088, Long-form file format for the international exchange of audio programme materials with metadata — czyli BW64. Mechanizm jest opisany wprost: „The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file", a stare pola 32‑bitowe 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."

BW64 nie poszerza pól rozmiaru RIFF‑a. Wypełnia je wartownikiem 0xFFFFFFFF i umieszcza prawdziwe rozmiary 64‑bitowe w chunku ds64, który musi stać jako pierwszy.

BW64 to trzecie pokolenie jednej linii: RIFF/WAVE dał kontener chunkowy, Broadcast Wave (BWF, EBU Tech 3285) dołożył chunk bext z originatorem, referencją timecode'u i historią kodowania, a BW64 zachowuje to wszystko, dokłada adresowanie 64‑bitowe i chunki niosące ADM. Plik BW64 poniżej 4 GB jest bajtowo zgodny z czytnikiem WAV we wszystkim poza czteroznakową sygnaturą; wiele narzędzi go przyjmie, część uparcie nie.

7. Układ chunków, konkretnie

Zgodnie z BS.2088 plik BW64 zawiera co najmniej <ds64-ck>, <fmt-ck>, <chna-ck>, <axml-ck> (z <bxml-ck> i <sxml-ck> jako alternatywnymi nośnikami metadanych) oraz <wave-data>.

7.1 ds64 — tablica rozmiarów 64‑bitowych

Musi być pierwszym chunkiem po sygnaturze, bo czytnik musi znać prawdziwe rozmiary, zanim cokolwiek przejdzie. Pola są 32‑bitowymi połówkami wielkości 64‑bitowych:

table[] jest ważniejsze, niż wygląda. Chunk axml opisujący tysiące obiektów z automatyką o rozdzielczości próbki sam potrafi zbliżyć się do 4 GB — i tablica jest jedyną drogą, żeby chunk inny niż data zadeklarował rozmiar 64‑bitowy.

7.2 fmt — opis esencji

Standardowy chunk formatu WAVE: format próbki, częstotliwość, liczba kanałów, bity na próbkę, block align. To jedyne autorytatywne stwierdzenie, ile przeplecionych kanałów naprawdę leży w data. Wszystko dalej jest metadanymi o tych kanałach, a metadane potrafią kłamać.

7.3 chna — tablica przydziału kanałów i te 40 bajtów

chna jest mostem między fizycznymi ścieżkami a ADM‑em. Nagłówek:

• ckID — 4 bajty, 'chna'
• ckSize — 4 bajty
• numTracks — 2 bajty, liczba ścieżek w pliku
• numUIDs — 2 bajty, liczba następujących wpisów audioTrackUID

Dalej płaska tablica wpisów audioID o stałej szerokości. Każdy wpis ma dokładnie 40 bajtów:

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

Policzmy cały chunk dla realistycznego mastera: podkład 7.1.4 (12 kanałów) plus 16 obiektów to 28 ścieżek i 28 wpisów UID.

• ładunek po nagłówku chunku: numTracks 2 + numUIDs 2 + 28 × 40 = 4 + 1120 = 1124 bajty, i tyle powinno stać w ckSize;
• cały chunk z ckID i ckSize: 8 + 1124 = 1132 bajty.

Sprawdź też długości wzorcowych identyfikatorów: ATU_00000001 to dokładnie 12 znaków, AT_00031001_01 — 14, AP_00031001 — 11. Szerokości pól nie są sugestią. To są pola ASCII o stałej długości, a zapisujący, który wyprodukuje UID o 13 znakach, nie stworzył pliku „trochę nietypowego", tylko uszkodzoną tablicę.

Zwróć też uwagę na konwencję identyfikatorów: wartości 0x0FFF i niższe odsyłają do common definitions ADM — standardowych, predefiniowanych formatów kanałów i pakietów — a 0x1000 i wyższe oznaczają definicje własne, które muszą być obecne w axml. packRef o wartości AP_00010003 to 5.1 z definicji wspólnych i nie potrzebuje XML‑a; AP_00031001 to własny pakiet obiektowy i bez XML‑a jest referencją wiszącą.

audioTrackUID to numer seryjny tożsamości jednej fizycznej ścieżki — i istnieje właśnie po to, by ścieżka mogła w trakcie programu legalnie zmienić to, co niesie.

Dlatego numUIDs może przekraczać numTracks. Wytyczne EBU mówią, ż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." Ten sam trackIndex pojawi się więc w kilku wpisach. Walidatory zakładające jeden UID na ścieżkę oznaczają poprawne pliki jako zepsute.

7.4 axml — samo ADM

Dokument XML w UTF‑8 zawierający drzewo <audioFormatExtended>. To jest ADM. Jest tekstem, da się go przejrzeć i to w nim mieszkają praktycznie wszystkie ciekawe awarie.

7.5 data — przeplecione PCM

Zwykłe przeplecione próbki, dokładnie jak w WAV. Nic w data nie wie nic o obiektach.

7.6 Kolejność i pułapka, w którą wpadają wszyscy

ds64 zawsze pierwszy. fmt przed data. Natomiast axml może legalnie stać za data i często tam stoi, bo — jak zauważa BS.2088 — w trakcie 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 brak ADM‑u w całości. Ten jeden fakt odpowiada za zaskakująco dużą część zgłoszeń „mój plik nie ma metadanych".

7.7 bext i po co go wypełniać

bext z BWF przenosi originatora, datę, historię kodowania i referencję timecode'u. W dostawie immersyjnej ta ostatnia jest kluczowa: konform stereo i binauralny muszą mieć ten sam start, a jedynym miejscem, gdzie to zapisujesz w sposób maszynowo sprawdzalny, jest właśnie bext.

8. Polskie znaki diakrytyczne: legalne w axml, nigdy w chna

To jest dla polskich realizatorów najbardziej praktyczny fragment całego dokumentu, bo dotyczy pierwszej rzeczy, którą człowiek robi po otwarciu sesji: nazywa ścieżki po polsku.

W axml polskie znaki są w pełni legalne. Chunk niesie XML w UTF‑8, więc audioObjectName, audioContentName, audioProgrammeName i pozostałe pola nazw mogą bez żadnych zastrzeżeń zawierać ą, ć, ę, ł, ń, ó, ś, ź, ż. Nie ma powodu pisać „Chor" zamiast „Chór" ani „Zlobek" zamiast „Żłobek".

W chna polskie znaki nie mogą pojawić się nigdy. Pola UID, trackRef i packRef to pola binarne o stałej szerokości, wypełnione znakami ASCII według wzorców ATU_########, AT_########_## i AP_########. Nie ma w nich miejsca na nazwę i nie ma miejsca na diakrytykę.

Powód jest arytmetyczny i warto go przeliczyć, bo intuicja „jeden znak to jeden bajt" jest tu fatalna.

Wszystkie polskie litery diakrytyczne mają w Unicode punkty kodowe poniżej U+0800, więc w UTF‑8 zajmują po 2 bajty:

Stąd rozjazd między liczbą znaków a liczbą bajtów. Nazwa obiektu Prym – kapela góralska ma 22 znaki, ale 25 bajtów: ó dokłada 1 bajt, a półpauza „–" (U+2013) leży powyżej U+0800 i zajmuje 3 bajty zamiast 1, czyli dokłada 2. To jest zupełnie w porządku — w axml.

Teraz awaria. Załóżmy narzędzie, które generuje identyfikatory z nazw ścieżek i wpisuje do pola UID ciąg ATU_0000001Ł. Ma on 12 znaków — a więc przechodzi naiwną kontrolę długości — ale 13 bajtów, bo Ł to U+0141. Skutek:

• ten jeden wpis ma 41 bajtów zamiast 40;
• przy 28 wpisach ładunek chunku wynosi 4 + 27 × 40 + 41 = 4 + 1080 + 41 = 1125 bajtów zamiast poprawnych 1124;
• parser, który — całkiem słusznie — czyta wpisy skokiem co 40 bajtów, od tego miejsca ląduje o bajt za daleko w każdym kolejnym wpisie. trackIndex czytany jest z ostatniego bajtu poprzedniego pola i pierwszego bajtu następnego, więc numery ścieżek wychodzą absurdalne, a referencje — nierozwiązywalne;
• ładunek staje się nieparzysty, więc rozjeżdża się także wyrównanie kolejnego chunku.

Nie jest to błąd, który słychać. Nie jest to błąd, który widać w edytorze fal. Jest to błąd, po którym renderer albo odrzuci plik, albo — gorzej — zrenderuje część obiektów w losowych miejscach.

Reguła robocza: nazwy po polsku, identyfikatory po ASCII. W praktyce najlepiej wymusić to przez walidację: dla każdego wpisu chna sprawdź, że długość w bajtach pól wynosi dokładnie 12, 14 i 11, a nie długość w znakach, i że każdy bajt mieści się w zakresie 0x20–0x7E. Osobno sprawdź, że cały axml dekoduje się jako poprawny UTF‑8 — narzędzia zapisujące w CP1250 albo ISO‑8859‑2 (kodowaniach wciąż spotykanych w starszych polskich łańcuchach produkcyjnych) wyprodukują XML, który nie zdekoduje się jako UTF‑8 i który parser odrzuci w całości, razem z metadanymi wszystkich obiektów.

9. Model obiektowy ADM: graf referencji

BS.2076 dzieli model na dwie części. Część formatu „describes the technical nature of the audio so it can be decoded or rendered correctly" i może powstać, zanim istnieje jakikolwiek dźwięk. Część treści opisuje „the language of dialogue, the loudness, etc." i domyka się dopiero, gdy sygnały istnieją. Wiedza, do której połowy należy dany element, mówi ci, na jakim etapie produkcji powstał błąd.

Hierarchia od góry:

• audioProgramme — jedna kompletna prezentacja dostawcza; odsyła do jednego lub wielu audioContent.
• audioContent — składnik o znaczeniu redakcyjnym: stem dialogowy, stem muzyczny, wersja językowa; odsyła do audioObject.
• audioObject — spoina intencji redakcyjnej i formatu technicznego. Niesie czas startu i czas trwania, odsyła do zera lub wielu audioPackFormat, zera lub wielu zagnieżdżonych audioObject i zera lub wielu audioTrackUID. Tu treść spotyka esencję.
• audioPackFormat — grupa kanałów należących do siebie: podkład 7.1.4, para stereo, komplet HOA danego rzędu. Może zagnieżdżać inne pakiety.
• audioChannelFormat — zachowanie jednego kanału w czasie; zawiera jeden lub więcej audioBlockFormat.
• audioBlockFormat — atom. Dla Objects: pozycja (azimuth/elevation/distance albo kartezjańskie X/Y/Z), gain, rozmiar, diffuseness, plus rtime i duration.
• audioTrackUID — liść i jedyny element odpowiadający fizycznej ścieżce; niesie opcjonalne atrybuty sampleRate i bitDepth.

audioStreamFormat i audioTrackFormat leżą między formatem kanału a UID ścieżki. BS.2076‑3 zauważa, że dla PCM są w praktyce zbędne — „the audioStreamFormat and the audioTrackFormat should be omitted" — ale czytniki „should be aware that existing ADM files (based on Recommendation ITU‑R BS.2076‑2 and earlier) for PCM audio may contain" je. Obie postacie są legalne; walidator upierający się przy jednej myli się co do drugiej.

ADM jest grafem referencji, a nie zagnieżdżonym dokumentem — i każda poważna awaria dostawcza to zerwana krawędź w tym grafie.

Co się naprawdę dzieje, gdy referencja wisi. Nie ma jednego zachowania i to jest sedno problemu. Renderer rozwiązujący audioPackFormatIDRef wskazujący pakiet nieobecny w XML‑u może przerwać parsowanie i odrzucić plik; może pominąć ten obiekt i zrenderować resztę, dając miks po cichu pozbawiony całego stemu; albo może spaść do definicji wspólnych, trafić na identyfikator z zakresu własnego 0x1000+ bez dopasowania i podstawić ciszę. We wszystkich trzech przypadkach „plik się otworzył". Tylko jeden z nich wychwyci odsłuch — i to wyłącznie wtedy, gdy akurat wiesz, co powinno tam być. Ucho nie usłyszy nieobecności, o której nie zostało uprzedzone.

10. Typowe odrzuty QC i sposób wykrycia każdego

Niezgodność liczby kanałów fmt ↔ chna. fmt.nChannels mówi 16, chna.numTracks mówi 14. Plik jest wewnętrznie sprzeczny już na dwóch pierwszych chunkach. Wykrycie: sparsuj oba i porównaj liczby całkowite. Sprawdź też, że każdy trackIndex mieści się w 1 … fmt.nChannels.

Osierocone UID ścieżek. UID obecny w chna, do którego nie odwołuje się żaden audioObject, albo audioTrackUIDRef w XML‑u bez odpowiadającego wpisu w chna. Pierwsze oznacza dźwięk, którego nic nie zrenderuje; drugie — metadane oczekujące ścieżki, której nie ma. Wykrycie: zbuduj zbiór UID‑ów z chna i z axml i policz różnicę symetryczną; ma być pusta. EBU Tech 3392 formułuje intencję wprost: „If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs."

Wiszące referencje w zakresie własnym. Każdy packRef i trackRef o wartości 0x1000 lub wyższej musi mieć odpowiednik w axml. Wykrycie: wyodrębnij część liczbową, porównaj z progiem, rozwiąż w XML‑u.

Bloki z brakującym lub niemonotonicznym czasem. Wykrycie: dla każdego audioChannelFormat przejdź bloki w kolejności dokumentu i sprawdź, że rtime[n] + duration[n] == rtime[n+1]. Awarie układają się w trzy kształty: dziury (zachowanie renderera niezdefiniowane — jedne trzymają ostatnią pozycję, inne wyciszają), nakładki (bloki walczące ze sobą) i bloki poza porządkiem chronologicznym.

Niezgodna częstotliwość próbkowania lub rozdzielczość. Gdy atrybuty sampleRate/bitDepth w audioTrackUID przeczą fmt , masz dwa twierdzenia o tej samej esencji. Stanowisko EBU Tech 3392 jest takie, że „Should be ignored if available from the audio essence" — ale nie każdy renderer się do tego stosuje. Osobno: konwersja częstotliwości wykonana po autoringu ADM unieważnia każdy rtime i duration wyrażony w próbkach.

Metadane opisujące podkład, którego nie ma w pliku. XML deklaruje pakiet DirectSpeakers 7.1.4 — dwanaście kanałów — a wydrukowano tylko podzbiór 5.1, albo kanały wysokościowe były wyciszone przy bounce'ie i trafiły na dysk jako cyfrowa cisza. Graf referencji jest spójny; dźwięku nie ma. Wykrycie: kontrola strukturalna tego nie złapie. Trzeba analizy esencji: dla każdego kanału deklarowanego przez pakiet DirectSpeakers zmierz, czy ścieżka w ogóle zawiera sygnał. Cyfrowa cisza na zadeklarowanym kanale podkładu nie jest automatycznie błędem — legalny miks może zostawić pusty kanał tylny górny — ale zawsze zasługuje na ludzką decyzję.

Niezgodność typeLabel między kanałem a pakietem. audioChannelFormat z typeLabel 0003 wewnątrz pakietu 0001 to plik, który mówi jednocześnie „to jest obiekt" i „to jest kanał głośnikowy".

Rozjazd konformów. Konform stereo lub binauralny zrenderowany z wcześniejszej wersji, przesunięty o kilka ramek albo z innym timecode'em startu. Wykrycie: porównaj czasy trwania co do próbki, porównaj timecode startu z bext, skoreluj konform z renderem mastera. Każdy konform, którego nie da się wyprowadzić z bieżącego mastera, traktuj jako podejrzany i zrenderuj ponownie, zamiast sprawdzać go raz jeszcze.

Kontener może być bez zarzutu, XML idealnie poprawny składniowo, a dostawa i tak zła; jedynym testem na pusty kanał podkładu jest zajrzenie w próbki.

Darmowy inspektor BW64/ADM działający w przeglądarce na stronie mazufa.com parsuje kontener i metadane wyłącznie na twoim urządzeniu i niczego nie wysyła, co czyni go użytecznym dla materiału, który z umowy nie może opuścić budynku.

11. Rendering: BS.2127 na układy BS.2051

Materiał obiektowy nie ma brzmienia, dopóki go nie zrenderujesz. Zalecenie ITU‑R BS.2127 definiuje referencyjny renderer ADM, a jego otwartoźródłowy odpowiednik, EBU ADM Renderer (EBU Tech 3388), jest praktyczną drogą do wyniku powtarzalnego.

Trzy rzeczy warte zapamiętania:

1. Ten sam plik daje różne miksy na różnych układach. Obiekt umieszczony między głośnikami zostanie rozłożony inaczej w Systemie B (0+5+0) niż w Systemie D (4+5+0) czy J (4+7+0). Nie jest to wada — to jest cel.
2. Rendering jest deterministyczny. Ten sam plik, ten sam renderer, ten sam układ docelowy → identyczny wynik, co do próbki. To pozwala renderować referencyjnie i porównywać nulle.
3. Binaural nie jest zamiennikiem pomieszczenia — ale nie jest też nic niewart. Renderowanie binauralne zgodne z BS.2127 mówi ci, czy obiekt jest z tyłu, czy z przodu, czy trajektoria jest ciągła i czy jakiś obiekt nie stoi zupełnie nie tam, gdzie miał. Nie powie ci wiarygodnie, jak brzmi warstwa górna ani jaka jest równowaga tonalna. To jest narzędzie weryfikacji struktury przestrzennej, nie narzędzie decyzji miksowych — i przy braku sali odsłuchowej jest to lepsze niż nic.

12. Głośność materiału immersyjnego według BS.1770‑5

Która edycja obowiązuje. BS.1770 ma sześć edycji: ‑0 (2006), ‑1 (2007), ‑2 (2011), ‑3 (2012), ‑4 (2015) i ‑5 (listopad 2023). Obowiązuje BS.1770‑5. BS.1770‑4 z października 2015 jest wycofane, choć to właśnie na nie powołuje się większość wdrożonych mierników. W notatkach dostawczych zawsze nazywaj bieżącą edycję ‑5.

Co zalecenie specyfikuje. BS.1770 definiuje ważenie K: filtr półkowy górnoprzepustowy typu „head", modelujący sztywną kulę, a po nim filtr górnoprzepustowy RLB. Wzmocnienie krzywej ważenia K przy 1 kHz wynosi +0,698 dB (liniowo 1,0836). Pomiar wykorzystuje bloki bramkujące 400 ms z 75 % nakładania, bramkę bezwzględną odrzucającą bloki poniżej −70 LUFS oraz bramkę względną liczoną ze średniej bloków, które przeszły bramkę bezwzględną, przesuniętą o −10 LU. To ostatnie jest źródłem częstego błędu implementacyjnego: bramka względna nie jest liczona ze średniej niebramkowanej.

Wagi kanałów w algorytmie bazowym wynoszą 1,0 (0 dB) dla L, R i C oraz 1,41 (≈ +1,5 dB) dla Ls i Rs, z pominięciem LFE. Algorytm bazowy jest zakresowo określony jako „from one to five channels". BS.1770‑5 wychodzi poza to w aneksach, obejmując zaawansowane systemy dźwiękowe z BS.2051 — dowolnie rozmieszczone głośniki i kanały wysokościowe — oraz dźwięk obiektowy, który musi zostać zrenderowany, zanim da się go zmierzyć.

Głośność immersyjna nie jest cechą pliku. Jest cechą renderu — a zmiana układu docelowego zmienia liczbę.

To jest zasadnicza różnica wobec stereo. Master stereo ma jedną wartość głośności. Master obiektowy ma ich tyle, ile ma celów renderowania, i jedynym uczciwym sposobem podania liczby jest podanie razem z nią układu, na którym mierzono, i renderera, którym renderowano.

Powiązane dokumenty EBU. EBU Tech 3341 definiuje zachowania mierników: momentary 400 ms, short‑term 3 s. EBU Tech 3342 definiuje Loudness Range (LRA), która używa bramki względnej −20 LU, a nie −10 LU — użycie −10 dla LRA to częsty błąd implementacyjny. EBU R 128 ustala programowy cel nadawczy −23 LUFS; jest to praktyka normalizacji nadawczej, nie specyfikacja dla streamingu muzycznego.

Peak prawdziwy. True peak mierzy się na sygnale nadpróbkowanym — minimum 4× według BS.1770, przy czym 8× jest lepsze. Peak próbkowy to nie to samo co peak prawdziwy; szczyty międzypróbkowe potrafią przekroczyć najwyższą wartość próbki.

Co jest opublikowane dla muzyki. Dla kanałowego stereo Spotify publikuje zintegrowany cel −14 LUFS i sufit true peak −1 dBTP, zaostrzany do −2 dBTP dla masterów głośniejszych niż −14 LUFS (support.spotify.com). AES TD1008 zaleca −16 LUFS dla muzyki; figurujące w tym samym dokumencie −18 LUFS dotyczy treści mówionej (wiadomości, talk, słuchowisko), a podawanie −18 jako celu dla muzyki jest częstym i poważnym błędem.

Warto też pamiętać, że normalizacja w górę jest realna, ale warunkowa: Spotify stwierdza, że „Positive gain is applied to softer masters so the loudness level is -14 dB LUFS", ale też że „We consider the headroom of the track, and leave 1 dB headroom for lossy encodings to preserve audio quality." Cichy master o wysokich szczytach może więc nie zostać podniesiony do końca. Ani „ciche mastery nie są podnoszone", ani „ciche mastery zawsze są podnoszone do celu" nie jest prawdą. Wniosek praktyczny pozostaje ten sam: nadmierne limitowanie kupuje płaskość, a nie głośność.

Czego opublikowane nie jest. Żaden serwis streamingowy nie publikuje zintegrowanego celu głośności dla dostawy immersyjnej. Liczby krążą po forach i po materiałach szkoleniowych producentów sprzętu; część jest prawdopodobna, część zapewne trafna. Żadna nie jest opublikowaną specyfikacją i ten dokument żadnej nie powtórzy jako takiej.

Osobny blok, wyraźnie oznaczony — szeroko powtarzane, ale nieopublikowane przez serwis: dla stereo krążą wartości Apple Music ≈ −16, YouTube Music ≈ −14, Amazon Music ≈ −14, TIDAL ≈ −14, Deezer ≈ −15 LUFS. Apple Music, YouTube Music, Amazon Music, TIDAL i Deezer nie publikują celu normalizacji. Nie licz z tych liczb żadnej korekty wzmocnienia i nie traktuj ich jak specyfikacji.

Jeżeli potrzebujesz dziś obronialnej liczby dla materiału immersyjnego: zmierz render zgodny z BS.2127 na nazwany układ BS.2051 miernikiem BS.1770‑5 i zapisz w notatkach dostawczych wszystkie trzy rzeczy.

O systemach zamkniętych. Dolby Atmos jest zastrzeżoną, licencjonowaną technologią Dolby Laboratories, a Sony 360 Reality Audio to zastrzeżony system zbudowany na MPEG‑H. Ich wymagania dostawcze ustalają właściciele i zmieniają się niezależnie od harmonogramów ITU i EBU. Nic w tym dokumencie nie stanowi stwierdzenia wymagań żadnej z tych firm i nie deklaruje się tu żadnego powiązania, certyfikacji ani rekomendacji. Tam, gdzie licencjodawca publikuje wymaganie, czytaj i cytuj jego własną, bieżącą dokumentację.

13. Uczciwa pozycja: prawdopodobnie nie odsłuchujesz immersyjnie

Trzeba to powiedzieć wprost, bo jest to główna różnica między treścią tego dokumentu a marketingiem sprzętu.

Monitoring immersyjny istnieje w Polsce w kilku ośrodkach nadawczych i postprodukcyjnych — tam, gdzie budżet i program pracy to uzasadniają. W studiach muzycznych jest rzadkością. Znakomita większość polskich realizatorów, którzy dostaną zlecenie na materiał immersyjny, będzie pracować bez pełnego układu z warstwą górną, w pomieszczeniu, które nawet gdyby ten układ miało, nie spełniałoby wymagań na jego ustawienie.

Z tego wynika, gdzie naprawdę leży twoja wartość dodana, a gdzie jej nie ma:

Czego nie zrobisz bez sali odsłuchowej: nie ocenisz wiarygodnie równowagi warstwy górnej, nie podejmiesz odpowiedzialnie decyzji o obwiedni przestrzennej miksu i nie stwierdzisz, że „tak brzmi dobrze na 7.1.4".

Co możesz zrobić i co ma realną wartość:

• poprawna dostawa — właściwy kontener, właściwe chunki, właściwa kolejność;
• poprawne metadane — graf ADM bez wiszących krawędzi, chna bajtowo zgodne, nazwy w UTF‑8, identyfikatory w ASCII;
• weryfikacja pliku, którego nie da się porządnie odsłuchać — a to jest umiejętność sama w sobie: sprawdzenie strukturalne, analiza esencji na pustych kanałach, kontrola ciągłości bloków, pomiar głośności na nazwanym renderze;
• binaural jako narzędzie kontroli struktury, nie decyzji miksowych;
• czysta dokumentacja — układ, renderer, edycja BS.1770, sumy kontrolne, archiwum XML‑a osobno od BW64.

To nie jest pocieszenie. Odrzuty dostaw immersyjnych w przytłaczającej większości nie wynikają z tego, że ktoś źle wybalansował kanał tylny górny. Wynikają z tego, że plik jest wewnętrznie niespójny — a to jest problem, który da się rozwiązać w całości bez ani jednego głośnika sufitowego.

14. Lista kontrolna dostawy

Po kolei. Kontrole strukturalne najpierw, bo są tanie i unieważniają wszystko poniżej.

Kontener

1. Pierwsze cztery bajty to BW64. Jeśli RIFF, to zwykły WAV i nie przekroczy 4 GB.
2. ds64 jest pierwszym chunkiem po sygnaturze, a jego rozmiary 64‑bitowe zgadzają się z faktycznymi rozmiarami pliku i data.
3. Każdy przerośnięty chunk inny niż data ma wpis ChunkSize64 w tablicy ds64.
4. Odszukaj axml jawnie, także za data. Nie wnioskuj „brak ADM" ze skanu częściowego.

Esencja

1. fmt — częstotliwość i rozdzielczość dokładnie takie, jak w specyfikacji dostawy. Żadnego SRC po autoringu ADM.
2. fmt.nChannels = chna.numTracks.
3. Każdy trackIndex w zakresie, liczony od 1.

Spójność chna

1. Każdy wpis ma dokładnie 40 bajtów; pola 12, 14 i 11 bajtów mierzone w bajtach, nie w znakach; wszystkie bajty w 0x20–0x7E.
2. Każdy packRef ≥ 0x1000 rozwiązuje się do definicji własnej obecnej w axml.
3. Powtórzone trackIndex są zamierzone (ścieżka legalnie zmienia definicję), a nie zduplikowane.

Kodowanie

1. axml dekoduje się jako poprawny UTF‑8 w całości. Żadnego CP1250 ani ISO‑8859‑2.
2. Polskie diakrytyki występują wyłącznie w polach nazw, nigdy w identyfikatorach.

Graf ADM

1. Każdy audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef i audioTrackUIDRef rozwiązuje się. Zero wiszących krawędzi.
2. Brak osieroconych audioTrackUID w obie strony.
3. Brak cykli i samoodwołań.
4. typeLabel każdego audioChannelFormat zgadza się z nadrzędnym audioPackFormat.

Czas

1. Formaty kanałów wielo‑blokowe mają rtime i duration na każdym bloku.
2. Bloki przylegają i są monotoniczne; suma czasów trwania odpowiada czasowi nadrzędnego audioObject.
3. Obiekty zaczynają się od 00:00:00.00000.

Treść

1. Każdy kanał zadeklarowanego podkładu zawiera to, co powinien; cyfrową ciszę zbadaj.
2. Liczba obiektów i konfiguracja podkładu zgodne ze specyfikacją.
3. Timecode startu w bext poprawny i identyczny we wszystkich plikach zestawu.

Rendery i konformy

1. Konformy stereo i binauralne zrenderowane z bieżącego mastera, nie przeniesione z poprzedniej wersji.
2. Czasy trwania i timecode'y startu zgodne z masterem co do próbki.
3. Głośność zmierzona na nazwanym renderze, nazwanym układzie, nazwanym miernikiem — i wszystkie trzy zapisane w notatkach.

Odtwarzalność

1. Suma kontrolna każdego pliku dostawczego i zachowany manifest.
2. Sesja i XML ADM zarchiwizowane osobno od BW64. XML, który da się zdiffować, jest później wart więcej niż binarium, które da się tylko ponownie sparsować.

Dostawa immersyjna nie jest skończona wtedy, gdy dobrze brzmi. Jest skończona wtedy, gdy maszyna, która nigdy jej nie słyszała, potrafi udowodnić, że jej referencje się rozwiązują.

15. Zakończenie

BW64 i ADM są standardami otwartymi, opublikowanymi i możliwymi do przeczytania za darmo. W tym zakątku branży to rzadkość i warto z niej korzystać: możesz sam przeczytać BS.2088 i BS.2076, sparsować chunk chna w czterdziestu wierszach kodu i sprawdzić, co eksporter faktycznie zapisał, a nie co twierdziło jego okienko dialogowe. Dla polskiego realizatora bez sali odsłuchowej jest to najkrótsza droga od „mam nadzieję, że przejdzie" do „wiem, że przejdzie".

Repertuar, od którego zacząłem — orkiestra rozdrobniona na 52 głosy, kapela zwrócona ku sobie, organy nad głowami słuchaczy, procesja idąca ulicą — jest wyjątkowo mocnym argumentem za reprezentacją, która nie udaje, że wszystko przyszło z dwóch punktów przed słuchaczem. Ale przełożenie tego argumentu na plik, który przejdzie QC, jest pracą inżynierską, nie artystyczną, i sprowadza się do dwóch rzeczy: bajty w chna mają się zgadzać, a każda krawędź w grafie ADM ma prowadzić dokądś.

Dystrybucja w Mazufa jest bezpłatna — bez opłaty za upload, bez abonamentu, bez opłaty za wydawnictwo — a jedynym potrąceniem jest 5 % otrzymanych tantiem; każde kompletne zgłoszenie przechodzi ocenę przez człowieka.

Ź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.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
• Strona zalecenia ITU‑R BS.2127 — https://www.itu.int/rec/R-REC-BS.2127

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, 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
• 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 (mierniki), EBU Tech 3342 (Loudness Range) — https://tech.ebu.ch
• EBU ADM Guidelines — chunk CHNA — https://adm.ebu.io/reference/excursions/chna_chunk.html
• EBU ADM Guidelines — BW64 i 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
• Dokumentacja EBU ADM Renderer (EAR), obsługa BW64 — https://ear.readthedocs.io/en/latest/BW64.html
• Implementacja referencyjna libbw64 — https://github.com/ebu/libbw64
• Implementacja referencyjna 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/

Dokumentacja serwisów

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

Kontekst muzyczny (weryfikacja przykładów polskich)

• culture.pl, Threnody to the Victims of Hiroshima – Krzysztof Penderecki — https://culture.pl/en/work/threnody-to-the-victims-of-hiroshima-krzysztof-penderecki
• Wikipedia, Threnody to the Victims of Hiroshima (obsada: 24 skrzypiec, 10 altówek, 10 wiolonczel, 8 kontrabasów) — https://en.wikipedia.org/wiki/Threnody_to_the_Victims_of_Hiroshima
• Wikipedia, Polish Radio Experimental Studio (założone 15 listopada 1957, działało do 2004) — https://en.wikipedia.org/wiki/Polish_Radio_Experimental_Studio
• Wikipedia, Warsaw Autumn (założony 1956 przez T. Bairda i K. Serockiego) — https://en.wikipedia.org/wiki/Warsaw_Autumn
• muzykatradycyjna.pl, Tradycyjne instrumenty i składy kapel góralskich — https://muzykatradycyjna.pl/do-czytania/tradycyjne-instrumenty-i-sklady-kapel-goralskich-wybrane-regiony/

Unicode

• Standard Unicode, tablice punktów kodowych Latin Extended‑A (U+0100–U+017F) — https://www.unicode.org/charts/PDF/U0100.pdf

Ostatni przegląd: wrzesień 2026. Zalecenia bywają nowelizowane — przed cytowaniem numeru klauzuli sprawdź bieżącą edycję na stronach ITU i EBU.