BW64 și ADM: referință tehnică pentru livrarea de audio imersiv

Document de lucru pentru inginerii care pregătesc masterele bazate pe obiecte și pentru muzicienii cărora li s-a cerut un „livrabil imersiv" și li s-a spus să treacă de QC.

Răspunsul scurt

ADM (Audio Definition Model, Recomandarea ITU-R BS.2076) este un model deschis de metadate care descrie ce este fiecare pistă dintr-un fișier — un canal fix de difuzor, un obiect care se mișcă în timp sau o componentă ambisonică — și cum se combină pistele într-un program. ADM se transportă ca XML în interiorul unui container BW64 (Recomandarea ITU-R BS.2088), o extensie pe 64 de biți a RIFF/WAVE care iese din plafonul de 4 GB al fișierului WAV clasic. Livrările imersive pică QC-ul pentru că audio-ul și metadatele sunt două lucruri separate care trebuie să coincidă exact, iar formatul de fișier nu obligă pe nimeni să le țină sincronizate. Un număr de canale în fmt care nu se potrivește cu tabela chna, un audioTrackUID la care nu trimite niciun obiect, un bloc a cărui cronologie merge înapoi, un pat descris în XML care nu a fost niciodată tipărit pe disc — fiecare dintre acestea este invizibil într-un editor de formă de undă și fatal pentru un renderer. Verificarea ADM este verificare de integritate referențială, nu ascultare.

1. Taraful: cazul românesc care rupe stereofonia

Aproape orice discuție despre audio pe obiecte începe cu un exemplu de film — un elicopter care traversează sala. Este un exemplu prost pentru muzicieni, pentru că sugerează că obiectele sunt un efect. În muzica românească există un caz mult mai bun, și este cazul cel mai obișnuit din lume: taraful la o nuntă sau la un eveniment de sat.

Ce fac lăutarii, spațial vorbind, nu seamănă cu nicio altă configurație de concert. Ei nu cântă de pe scenă către public. Se ridică de la masă, se duc la un nuntaș anume, îi cântă în ureche — la propriu, vioara la treizeci de centimetri de capul omului — apoi trec la masa următoare, se întorc, se despart, se regrupează lângă miri. Un taraf de șase oameni se mișcă independent, în șase traiectorii diferite, timp de opt ore.

Rezultatul, în termeni de format, este dublu și amândouă părțile contează:

1. Sursa este în mișcare continuă. Nu „panoramată" — chiar în mișcare, cu o traiectorie care are un corespondent fizic verificabil. Exact asta descrie o secvență de elemente audioBlockFormat cu rtime și duration, într-un audioChannelFormat de tip Objects.
2. Sursa este deliberat aproape. Un lăutar care cântă la treizeci de centimetri de ascultător nu este „mai tare" decât unul aflat la trei metri; este altfel: unghiul se schimbă rapid, câmpul reverberant al sălii aproape dispare din raportul direct/reverberat, iar sunetul își pierde caracterul de sursă punctiformă și devine ceva ce simți lângă tine. Aceasta este informație de distanță, iar în ADM parametrul distance din blocul de poziție polară există tocmai pentru asta.

Stereofonia nu poate reprezenta niciunul dintre cele două lucruri onest. Un pan pot poate muta vioara între boxe, dar nu îi poate schimba distanța; iar apropierea o poți doar simula, prin nivel și prin uscarea semnalului, ceea ce este o convenție, nu o măsurătoare. Un pat cu canale fixe nu poate nici el: patul presupune că sursa stă unde sunt difuzoarele, iar lăutarul nu stă nicăieri.

Taraful este definiția de manual a unui obiect cu poziție variabilă în timp și cu distanță reală. Dacă cineva vă întreabă de ce ar avea nevoie muzica populară românească de audio pe obiecte, acesta este răspunsul, și nu are nimic de-a face cu efectele.

Practic, o înregistrare de taraf se împarte firesc așa: fiecare instrument primește un lavalier sau un microfon de contact și devine un obiect; sala (petrecerea, zgomotul, aplauzele, chiuiturile) devine un pat cu canale fixe. Șase obiecte plus un pat de 7.1.4 înseamnă optsprezece piste, iar dacă mai adăugați o pereche de microfoane de ambianță și un canal de rezervă ajungeți la douăzeci — o cifră la care vom reveni când calculăm limita de 4 GB.

Ce trebuie făcut cu adevărat pe teren

Poziția obiectului trebuie să vină de undeva. În post-producție de film vine dintr-un sistem de urmărire. La o nuntă nu aveți așa ceva, iar soluțiile realiste sunt trei: automatizare scrisă de mână pe baza unei camere video de referință puse în tavan; poziție statică pe segmente, cu blocuri noi la fiecare deplasare vizibilă (mai puțin elegant, dar perfect valid în ADM și mult mai ușor de verificat); sau, dacă nu aveți nici camera, renunțarea onestă la mișcare și declararea obiectelor ca statice. Un obiect declarat static și tipărit static este corect. Un obiect declarat în mișcare cu o traiectorie inventată este o minciună pe care renderer-ul o va executa fidel.

2. Hora: de ce „unde stă ascultătorul" sunt trei înregistrări diferite

Dacă taraful este cazul mișcării, hora este cazul geometriei circulare, și scoate la iveală întrebarea pe care formatele imersive o pun și pe care stereo nu o pune niciodată: de unde ascultăm?

La o horă, muzicanții stau în centru sau lângă centru, iar dansatorii formează un inel care se rotește în jurul lor. Sunt trei poziții posibile de microfon și fiecare produce o înregistrare cu o structură complet diferită:

• În centru, lângă muzicanți. Instrumentele sunt aproape, în jurul dumneavoastră, iar dansatorii — pașii, strigăturile, fusta care foșnește — trec pe lângă microfon ca un inel de surse care se rotește. Acesta este cazul în care sursele ambientale se mișcă, iar sursele muzicale sunt fixe și apropiate. Ambisonică de ordin înalt în centru, plus obiecte pentru instrumente.
• În inel, printre dansatori. Dumneavoastră sunteți cel care se rotește. Muzicanții rămân la distanță constantă, dar la azimut care se schimbă continuu; restul lumii se rotește în sens invers. Acesta este singurul caz în care tot câmpul este în rotație, și este cel care va scoate imediat la iveală dacă renderer-ul dumneavoastră tratează prost zonele dintre difuzoare.
• În afara inelului, ca privitor. Aici aveți o scenă frontală obișnuită, cu inelul între dumneavoastră și muzicanți. Este cea mai comercială dintre cele trei și cea mai puțin interesantă tehnic.

Formatul nu decide asta în locul dumneavoastră, dar vă obligă să o declarați. Într-un master stereo, întrebarea nici nu se pune — poziția e implicită și mereu aceeași. Într-un livrabil ADM, poziția ascultătorului este o decizie editorială care se materializează în conținutul obiectelor și al patului, iar dacă nu ați luat-o conștient, ați luat-o oricum.

Hora arată de ce audio-ul imersiv este o formă de documentare, nu de spațializare. Alegeți un punct de ascultare care există fizic și îl reproduceți; nu construiți unul care nu a existat.

3. Trei feluri de audio, și de ce distincția decide formatul

Înainte de container, modelul. Fiecare problemă de livrare imersivă pornește de la o confuzie despre ce este de fapt o pistă.

Audio pe canale. Fiecare pistă este atribuită unei poziții fixe de difuzor. Stereo este pe canale. La fel 5.1 și la fel un „pat" 7.1.4. Poziția este înscrisă în identitatea canalului: pista 3 este centrul și este centrul pe orice sistem. Recomandarea ITU-R BS.2051 formalizează asta pentru sistemele avansate, definind dispunerile ca număr de difuzoare pe straturile superior + mijlociu + inferior: sistemul A este 0+2+0 (stereo), B este 0+5+0 (5.1), D este 4+5+0, J este 4+7+0, iar H este 9+10+3, configurația 22.2. În ADM, conținutul pe canale folosește typeDefinition = DirectSpeakers, typeLabel 0001.

Audio pe obiecte. O pistă mono (sau un pachet multicanal) plus metadate de poziție care se schimbă în timp. Renderer-ul decide ce difuzoare reale îl reproduc, în funcție de dispunerea existentă în cameră. Nimic din pistă nu presupune un difuzor. typeDefinition = Objects, typeLabel 0003. Taraful, colindătorii și diaconul care se mișcă intră aici.

Audio pe scenă, în practică ambisonică de ordin înalt, codează întreg câmpul sonor ca un set de componente armonice sferice. Nicio componentă nu corespunde singură unei direcții; direcția apare din combinația liniară. typeDefinition = HOA, typeLabel 0004. ADM mai definește Matrix (0002) pentru semnale matriciale de tip Mid-Side sau Lt/Rt și Binaural (0005) pentru perechi gata de căști.

Distincția nu este taxonomie de dragul taxonomiei. Un livrabil pe canale se descrie suficient de bine pe sine încât să supraviețuiască ca WAV simplu: nimeriți ordinea canalelor și se aude. Un livrabil pe obiecte sau pe scenă este lipsit de sens fără metadatele lui — audio-ul este o grămadă de fluxuri mono nediferențiate, iar ADM-ul este singurul lucru care spune altceva. Această asimetrie este întregul motiv pentru care există BW64 și ADM și întregul motiv pentru care QC-ul imersiv este mai greu decât cel stereo.

4. BW64: ce este și de ce există exact

WAV-ul clasic este un fișier RIFF. RIFF, din 1991, pune înaintea fiecărui chunk un câmp de dimensiune pe 32 de biți. Treizeci și doi de biți adresează 4 294 967 296 de octeți — 4 GiB — și acesta este plafonul dur atât pentru fișier în ansamblu, cât și pentru chunk-ul data dinăuntru.

Aritmetica merită făcută cu cifrele unei nunți, nu ale unui film.

Pentru stereo la 48 kHz / 24 de biți, debitul este 2 × 48 000 × 3 = 288 000 octeți pe secundă, iar 4 GiB înseamnă 4 294 967 296 ÷ 288 000 = 14 913 secunde, adică 4 ore 8 minute și 33 de secunde. Irelevant.

Pentru livrabilul de taraf descris mai sus — douăzeci de piste la 48 kHz / 24 de biți — debitul este 20 × 48 000 × 3 = 2 880 000 octeți pe secundă. Plafonul de 4 GiB se atinge la 4 294 967 296 ÷ 2 880 000 = 1 491,3 secunde, adică 24 de minute și 51 de secunde.

Iar o nuntă românească nu ține douăzeci și patru de minute. Ține de seara până dimineața. Opt ore de înregistrare continuă la acest debit înseamnă 2 880 000 × 28 800 = 82 944 000 000 de octeți ≈ 82,9 GB (77,2 GiB), adică de 19,3 ori peste plafonul RIFF. Dacă ridicați rata de eșantionare la 96 kHz, debitul se dublează la 5 760 000 octeți pe secundă și limita cade la 745,7 secunde — 12 minute și 26 de secunde. La 96 kHz nu apucați să terminați o singură horă lungă.

EBU a rezolvat prima dată problema cu RF64 (EBU Tech 3306). ITU a preluat lucrarea și a publicat-o ca Recomandarea ITU-R BS.2088, Long-form file format for the international exchange of audio programme materials with metadata — BW64. BS.2088 este explicită asupra mecanismului: „The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file", iar vechile câmpuri pe 32 de biți devin steaguri de evadare — „If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead."

BW64 nu lărgește câmpurile de dimensiune din RIFF; le umple cu 0xFFFFFFFF ca valoare-santinelă și pune dimensiunile reale pe 64 de biți într-un chunk ds64 care trebuie să stea primul în fișier.

BW64 se înțelege cel mai bine ca a treia generație a unei singure familii. RIFF/WAVE a dat containerul pe chunk-uri. Broadcast Wave (BWF, EBU Tech 3285) a adăugat chunk-ul bext — originator, referință de timecode, istoric de codare — transformând WAV-ul în format de schimb pentru radiodifuziune. BW64 păstrează tot și adaugă adresarea pe 64 de biți plus chunk-urile care poartă ADM. Un fișier BW64 sub 4 GiB este compatibil octet cu octet cu un cititor de WAV în toate privințele, mai puțin semnătura de patru caractere de la început; multe unelte îl acceptă, unele refuză încăpățânat.

5. Structura chunk-urilor, în detaliu

Conform BS.2088, un fișier BW64 este așteptat să conțină cel puțin <ds64-ck>, <fmt-ck>, <chna-ck>, <axml-ck> (cu <bxml-ck> și <sxml-ck> ca alternative pentru metadate) și <wave-data>.

ds64 — tabela de dimensiuni pe 64 de biți

Trebuie să fie primul chunk după semnătura BW64, pentru că un cititor trebuie să afle dimensiunile reale înainte să poată parcurge orice altceva. Câmpurile sunt jumătăți pe 32 de biți ale unor mărimi pe 64:

Aritmetica: antetul are 8 octeți (ckID + ckSize), iar corpul minim are 8 + 8 + 8 + 4 = 28 de octeți, deci un ds64 fără intrări în tabelă ocupă 36 de octeți în total. Fiecare intrare ChunkSize64 este de 12 octeți (identificator de 4 octeți plus dimensiune pe 64 de biți, adică 8 octeți), deci un ds64 care declară un singur chunk supradimensionat suplimentar are 48 de octeți.

Concret, pentru fișierul de nuntă de 82 944 000 000 de octeți: împărțit la 2³² = 4 294 967 296, dă câtul 19 și restul 1 339 621 376. Așadar dataSizeHigh = 19 (0x00000013) și dataSizeLow = 1 339 621 376 (0x4FD90000). Câmpul ckSize din antetul lui data conține 0xFFFFFFFF, care nu este o dimensiune, ci un semnal că adevărul se află în ds64. Un parser care ia 0xFFFFFFFF drept dimensiune reală va crede că fișierul are 4 GiB și se va opri acolo — este exact eroarea care produce rapoarte de tipul „mi s-a tăiat înregistrarea la ora patru dimineața".

table[] contează mai mult decât pare. Un chunk axml care descrie mii de obiecte cu automatizare la nivel de eșantion poate el însuși să se apropie de 4 GiB sau să depășească; tabela este singurul mecanism prin care un chunk altul decât data își poate declara o dimensiune pe 64 de biți.

fmt — descrierea esenței

Chunk-ul WAVE standard: format de eșantion, rată de eșantionare, număr de canale, biți pe eșantion, aliniere de bloc. Aceasta este singura declarație autoritară despre câte canale întrețesute există efectiv în data. Tot ce urmează sunt metadate despre aceste canale, iar metadatele pot minți.

chna — tabela de alocare a canalelor

chna este puntea dintre pistele fizice și ADM. Începe cu:

• ckID — 4 octeți, 'chna'
• ckSize — 4 octeți
• numTracks — 2 octeți, numărul de piste din fișier
• numUIDs — 2 octeți, numărul de intrări audioTrackUID care urmează

Urmează un tablou plat de intrări audioID cu lățime fixă. Fiecare intrare are exact 40 de octeți:

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

Fiecare lățime se verifică pe exemplu, caracter cu caracter, și toate sunt ASCII:

• ATU_00000001 = prefixul ATU_ (4 caractere) + 8 cifre hexazecimale = 12.
• AT_00031001_01 = AT_ (3) + 8 hexazecimale + _ (1) + 2 hexazecimale = 14.
• AP_00031001 = AP_ (3) + 8 hexazecimale = 11.

Consecința pentru poziționare: antetul lui chna ocupă 4 + 4 + 2 + 2 = 12 octeți, deci intrarea k începe la offsetul 12 + 40 × (k − 1) față de începutul chunk-ului. Prima intrare începe la 12, a doua la 52, a treia la 92, a douăzeci și patra la 932. Pentru livrabilul nostru de taraf cu 20 de piste și, să zicem, 24 de UID-uri (pentru că două instrumente își schimbă definiția în cursul serii), corpul chunk-ului este 2 + 2 + 24 × 40 = 964 de octeți, iar chunk-ul complet cu antet are 972 — număr par, deci nu mai trebuie umplutură la final.

Lățimile nu sunt orientative. Sunt câmpuri ASCII de lățime fixă, iar un scriitor care emite un UID de 13 caractere nu a produs un tabel puțin neobișnuit, ci un tabel corupt: toate intrările următoare se decalează cu un octet și parserul citește gunoi începând de la intrarea a doua.

Rețineți și convenția de identificatori: valorile de 0x0FFF și mai jos trimit la definițiile comune ADM — formatele de canal și de pachet standard, predefinite — în timp ce 0x1000 și peste indică definiții personalizate, care trebuie să existe în chunk-ul axml. Un packRef AP_00010003 este 5.1 prin definiție comună și nu are nevoie de XML; AP_00031001 este un pachet de obiecte personalizat și fără XML rămâne o referință suspendată.

Un audioTrackUID este numărul de serie pe care fișierul îl dă identității unei piste fizice, și există tocmai pentru ca o pistă să poată schimba legitim ce transportă în timpul programului.

Acesta este motivul pentru care numUIDs poate depăși numTracks: ghidul EBU notează că, acolo unde „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." Un trackIndex poate deci apărea în mai multe intrări. La nuntă asta se întâmplă firesc: pista pe care în prima parte a serii se află vioara primă devine, după ora două, pista unui alt lăutar care preia instrumentul. Uneltele de QC care presupun un singur UID pe pistă marchează fișiere corecte drept defecte.

axml — ADM-ul propriu-zis

Un document XML, UTF-8, care conține arborele <audioFormatExtended>. Acesta este ADM-ul. Este text, este inspectabil și acolo trăiesc practic toate defectele interesante.

data — PCM întrețesut

Eșantioane întrețesute simple, exact ca în WAV. Nimic din data nu știe nimic despre obiecte.

Ordinea. ds64 primul, întotdeauna. fmt înainte de data. axml poate sta legitim după data, și adesea stă, pentru că — după cum observă BS.2088 — în timpul înregistrării „the XML metadata will likely be of an unknown length." Un fișier cu axml la coadă nu este malformat; dar un cititor care scanează doar primul megaoctet va raporta că nu există ADM deloc. Acest singur fapt explică o parte surprinzător de mare din reclamațiile „fișierul meu nu are metadate".

6. Diacriticele românești: unde au voie ș și ț și unde nu au

Acesta este punctul în care limba română intră direct în format, și este un punct pe care majoritatea ghidurilor internaționale nu îl tratează.

Formele corecte ale literelor românești cu virguliță sunt ș U+0219 (s cu virgulă dedesubt) și ț U+021B (t cu virgulă dedesubt). În UTF-8, fiecare ocupă doi octeți:

• ș U+0219 → 0xC8 0x99
• ț U+021B → 0xC8 0x9B

Formele greșite, moștenite din epoca fonturilor Windows care nu aveau virgulița, sunt ş U+015F și ţ U+0163 — s și t cu sedilă, litere turcești. Și acestea ocupă doi octeți, dar alți octeți:

• ş U+015F → 0xC5 0x9F
• ţ U+0163 → 0xC5 0xA3

Diferența nu este cosmetică: două șiruri altfel identice, unul cu virguliță și unul cu sedilă, sunt secvențe de octeți diferite, nu se potrivesc la o comparație binară, se sortează diferit și produc duplicate în orice catalog. Celelalte trei diacritice românești sunt tot pe doi octeți: ă U+0103 → 0xC4 0x83, â U+00E2 → 0xC3 0xA2, î U+00EE → 0xC3 0xAE.

În axml, toate acestea sunt perfect valide. Chunk-ul axml este XML în UTF-8, iar câmpurile de nume — audioProgrammeName, audioContentName, audioObjectName, audioChannelFormatName — sunt text liber. Scrieți-le corect, cu diacritice, cu virguliță:

<audioObject audioObjectID="AO_1003" audioObjectName="Vioară primă — lăutar în mișcare">

Aritmetica acestui șir merită făcută, pentru că este exact ce încurcă parserele scrise cu presupunerea că un caracter este un octet. Vioară primă — lăutar în mișcare are 32 de caractere: 26 sunt ASCII (1 octet fiecare), cinci sunt diacritice pe doi octeți (ă de trei ori, î, ș), iar linia de dialog — (U+2014) este un caracter pe trei octeți. Total: 26 × 1 + 5 × 2 + 1 × 3 = 39 de octeți pentru 32 de caractere. Similar, Țambal mare are 11 caractere și 12 octeți.

În chna, niciunul dintre ele nu are ce căuta. Câmpurile UID, trackRef și packRef sunt ASCII de lățime fixă, iar conținutul lor este generat mecanic din prefix plus cifre hexazecimale. Ele nu sunt nume și nu trebuie personalizate niciodată. Dacă un instrument de creație — sau un script scris în grabă — încearcă să pună o denumire umană într-un packRef, de exemplu AP_000ș1001, se întâmplă următoarele, în ordine:

1. Șirul are 11 caractere, deci pare corect unui programator care numără caractere.
2. Dar ocupă 12 octeți, pentru că ș este 0xC8 0x99.
3. Intrarea devine de 41 de octeți în loc de 40.
4. Toate intrările următoare se decalează cu un octet. Intrarea a doua nu mai începe la 52, ci la 53, iar parserul citește trackIndex-ul ei din ultimul octet al intrării precedente.
5. Rezultatul nu este o eroare de parsare curată, ci un tabel plauzibil și complet fals: indici de pistă aberanți, UID-uri care nu se potrivesc cu nimic din axml și un fișier care „se deschide".

Regula practică, formulată pe scurt: diacriticele românești merg în axml; în chna nu intră niciun octet peste 0x7F. Verificați-o mecanic — parcurgeți fiecare intrare chna și confirmați că toți cei 40 de octeți sunt în intervalul ASCII imprimabil (cu excepția octetului de umplutură). Este o verificare de trei rânduri și prinde o categorie întreagă de erori.

Merită adăugat un al treilea nivel de prudență: diacriticele corecte în axml nu vă garantează că vor supraviețui în lanțul din aval. Multe sisteme de catalogare încă normalizează sau elimină diacriticele. Aceasta nu este o problemă a BW64 și nu se rezolvă scriind greșit numele în fișier — se rezolvă scriind corect și verificând ce a ajuns la capăt.

7. Modelul de obiecte ADM

ITU-R BS.2076 împarte modelul în două jumătăți. Partea de format „describes the technical nature of the audio so it can be decoded or rendered correctly" și poate fi scrisă înainte să existe vreun sunet. Partea de conținut descrie „the language of dialogue, the loudness, etc." și se poate completa doar după ce semnalele există. Să știți cărei jumătăți îi aparține un element vă spune în ce etapă de producție a apărut o eroare dată.

Ierarhia, de sus în jos:

• audioProgramme — o prezentare completă, livrabilă. Trimite la unul sau mai multe audioContent.
• audioContent — o componentă cu sens editorial: stem-ul de voce, stem-ul de instrumente, o versiune lingvistică. Trimite la unul sau mai multe audioObject.
• audioObject — îmbinarea dintre intenție editorială și format tehnic. Poartă timp de start și durată și trimite la zero sau mai multe audioPackFormat, zero sau mai multe audioObject imbricate și zero sau mai multe audioTrackUID. Aici se întâlnește conținutul cu esența.
• audioPackFormat — un grup de canale care merg împreună: un pat 7.1.4, o pereche stereo, un set HOA de un anumit ordin. Trimite la elemente audioChannelFormat și poate imbrica alte pachete.
• audioChannelFormat — comportamentul unui canal în timp. Conține unul sau mai multe audioBlockFormat.
• audioBlockFormat — atomul. Pentru Objects: o poziție (azimuth / elevation / distance, sau cartezian X / Y / Z), câștig, dimensiune (size), difuzie, plus rtime și duration. Un obiect static este un singur bloc; un obiect în mișcare este o secvență.
• audioTrackUID — frunza, și singurul element care corespunde unei piste fizice. Poartă atributele opționale sampleRate și bitDepth și trimite la un audioTrackFormat și un audioPackFormat.

audioStreamFormat și audioTrackFormat stau între formatul de canal și UID-ul de pistă și descriu codarea fluxului. BS.2076-3 notează că pentru PCM sunt practic redundante — „the audioStreamFormat and the audioTrackFormat should be omitted" — dar că cititorii „should be aware that existing ADM files (based on Recommendation ITU-R BS.2076-2 and earlier) for PCM audio may contain" aceste elemente. Ambele forme sunt legale. Un validator care insistă pe una greșește în privința celeilalte.

ADM este un graf de referințe, nu un document imbricat, iar orice eșec serios de livrare este o muchie ruptă în graful acela.

Ce se întâmplă concret când o referință rămâne suspendată. Nu există un comportament unic, și asta este problema. Un renderer care rezolvă un audioPackFormatIDRef ce numește un pachet absent din XML poate: să abandoneze parsarea și să respingă fișierul; să sară peste obiectul respectiv și să redea restul, producând un mix căruia îi lipsește discret un stem; sau să cadă înapoi pe definițiile comune, să găsească un identificator din intervalul personalizat 0x1000+ fără corespondent și să substituie tăcere. În toate trei cazurile „fișierul s-a deschis". Doar unul se prinde ascultând, și numai dacă știți ce ar fi trebuit să fie acolo.

La taraf, exemplul este dureros de concret: obiectul „acordeon" a fost oprit la mixaj, pista a fost scoasă din bounce, dar axml a rămas neschimbat. Graful trimite la o pistă care nu există în data. Dacă acordeonul cânta doar în două hore din opt, nimeni nu observă la ascultare. Urechea nu aude absența unui lucru despre care nu a fost avertizată — de asta verificarea ADM trebuie să fie mecanică.

8. Biserica: cazul pat-plus-obiecte, și de ce cel românesc este în afară

Cazul liturgic este cazul canonic de pat plus obiecte, dar tradiția românească oferă o variantă pe care interiorul de piatră nu o oferă: biserica pictată pe exterior și slujba ținută în curtea bisericii.

Bisericile pictate din nordul Moldovei — Voroneț, Sucevița, Moldovița, Humor, Arbore — au fresca pe fața exterioară a zidului, o particularitate care nu are echivalent la scara aceasta în altă parte. Motivul pentru care asta contează acustic nu ține de pictură, ci de ceea ce implică: aceste biserici au fost gândite pentru o mulțime care stă afară, în incintă, pentru că lăcașul propriu-zis este mic și nu încape decât o mică parte din obște. La hram, la Înviere, la sfințiri, slujba se desfășoară în curte.

Consecința pentru înregistrare este exact inversul cazului de interior, și de aceea merită tratat separat:

• Câmpul reverberant este aerul liber. Nu există o coadă de reverberație a incintei, pentru că nu există incintă. Timpul de reverberație este scurt, iar ceea ce înregistrați este în mare parte sunet direct plus o mână de reflexii identificabile individual. Dacă master-ul dumneavoastră de curte de biserică sună ca un interior de piatră, nu ați înregistrat curtea, ați adăugat reverb.
• Clădirea este un reflector, nu o incintă. Zidul de piatră din spatele altarului improvizat trimite înapoi o reflexie puternică, întârziată și direcțională — vine dintr-un unghi precis, care se poate măsura din geometrie. Zidul de incintă, dacă există, dă o a doua reflexie mai slabă din partea opusă. Acestea sunt evenimente discrete, nu un câmp difuz, și se tratează cel mai bine ca obiecte cu size mare și difuzie moderată, nu ca reverberație amestecată în pat.
• Stratul de înălțime are altă justificare. Într-o biserică boltită, înălțimea vine de la cupolă. În curte, nu vine de nicăieri deasupra — cerul nu reflectă. În schimb, ceea ce este sus sunt clopotele (în turn sau în clopotniță separată, la zece-douăzeci de metri deasupra ascultătorului și lateral) și, uneori, un cor plasat pe un pridvor înălțat. Stratul superior BS.2051 poartă atunci surse reale, identificabile, nu ambianță. Este un test bun: dacă ați declarat un pat 4+5+0 pentru o slujbă în curte și canalele de sus sunt tăcute până când bat clopotele, probabil este corect — dar merită o decizie umană explicită, nu o presupunere.

Împărțirea practică se scrie singură: pat pentru mulțime, vânt, ambianța incintei și fondul general; obiecte pentru preot, pentru diaconul care se deplasează, pentru cor, pentru clopote și pentru reflexia de zid. Ultimul este cel care se pierde cel mai ușor la QC, exact pentru că nimeni nu îl are în minte ca „instrument".

9. Colindătorii: sursa care se mișcă în afara casei

O ultimă situație românească, și una care nu are echivalent în listele de cazuri de utilizare scrise pentru film: colindătorii din noaptea de Ajun.

Ceata pornește de la o casă, merge pe uliță, se oprește la poartă, cântă la fereastră, este poftită înăuntru sau nu, apoi pleacă mai departe. Din punctul de vedere al unui microfon fix pus în casă sau pe prispă, aveți o sursă care:

• apare de la distanță, cu azimutul schimbându-se lent și cu raportul direct/reverberat foarte scăzut;
• se apropie până la câțiva metri, moment în care distanța devine parametrul dominant;
• trece printr-o barieră fizică — gardul, ușa, geamul — care filtrează în frecvență și schimbă timbrul fără să schimbe poziția;
• se îndepărtează, cu un profil de descreștere care este asimetric față de apropiere, pentru că ulița nu este simetrică.

Este material didactic aproape ideal pentru validarea unui renderer, și în același timp este un caz în care tentația de a „ajuta" cu automatizare inventată este mare. Rezistați-i. Traiectoria reală, chiar aproximată în trepte prin blocuri statice succesive, sună corect. O traiectorie netedă și frumoasă, desenată cu mouse-ul, sună ca un efect, pentru că este.

Și încă un detaliu de format: colindătorii se înregistrează afară, iarna, pe baterii, adesea într-o singură priză lungă de câteva ore, pentru că nu poți opri ceata ca să schimbi cardul. La 16 piste / 48 kHz / 24 de biți debitul este 16 × 48 000 × 3 = 2 304 000 octeți pe secundă, iar plafonul RIFF cade la 4 294 967 296 ÷ 2 304 000 = 1 864,1 secunde, adică 31 de minute și 4 secunde. Un reportofon care scrie WAV, nu BW64, vă va tăia noaptea în bucăți de o jumătate de oră — sau, mai rău, va scrie un fișier ale cărui dimensiuni declarate au depășit tăcut, iar acela se deschide și pare bun.

10. Erorile obișnuite de QC și cum se detectează fiecare

10.1 Nepotrivire între fmt și chna

fmt.nChannels spune 20; chna.numTracks spune 18. Fișierul este inconsistent intern încă din primele două chunk-uri. De obicei este cauzat de un bounce care a schimbat numărul de piste după ce metadatele fuseseră scrise.

Detectare: parsați ambele chunk-uri și comparați numere întregi. Este cea mai ieftină verificare din tot lanțul și prinde o proporție surprinzătoare de eșecuri. Verificați și că fiecare trackIndex din chna se află în intervalul 1 … fmt.nChannels.

10.2 UID-uri de pistă orfane

Un UID prezent în chna la care nu trimite niciun audioObject, sau un audioTrackUIDRef în XML fără intrare corespunzătoare în chna. Primul înseamnă audio pe care nu îl va reda nimic; al doilea, metadate care așteaptă o pistă inexistentă.

Detectare: construiți mulțimea UID-urilor din chna și pe cea din axml și luați diferența simetrică. Trebuie să fie vidă. EBU Tech 3392 formulează intenția explicit: „If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs."

10.3 Blocuri cu cronologie lipsă sau nemonotonă

BS.2076 este fără echivoc: „When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present." EBU Tech 3392 strânge regula la contiguitate — „rtime + duration of an audioBlockFormat should match the rtime of the following block" — cu primul bloc al unui obiect începând la 00:00:00.00000, niciun bloc mai scurt de un eșantion și suma duratelor egală cu durata audioObject-ului părinte.

Detectare: pentru fiecare audioChannelFormat, parcurgeți blocurile în ordinea din document și verificați că rtime[n] + duration[n] == rtime[n+1]. Eșecurile se grupează în trei forme: goluri (comportament nedefinit — unele renderere țin ultima poziție, altele taie sunetul), suprapuneri (blocuri care se bat între ele) și blocuri în afara ordinii cronologice. Pe traiectoria unui lăutar care se plimbă prin sală, ultima formă se aude ca un salt și este singura care se prinde la ascultare.

10.4 Rată de eșantionare sau adâncime de biți contradictorie

audioTrackUID poate purta atributele sampleRate și bitDepth. Când contrazic fmt , aveți două afirmații despre aceeași esență. Poziția EBU Tech 3392 este că acestea „Should be ignored if available from the audio essence" — dar nu toate rendererele respectă recomandarea. Separat, confirmați că rata este cea cerută de specificația de livrare: o conversie de rată aplicată după scrierea ADM invalidează fiecare rtime și duration exprimate în eșantioane.

Detectare: comparați fmt cu fiecare atribut sampleRate / bitDepth din XML și semnalați orice dezacord, chiar dacă nominal este tolerabil.

10.5 Conformarea stereo sau binaurală lipsă ori desincronizată

Aproape orice livrare imersivă cere și o conformare stereo (adesea și una binaurală). Eșecul recurent nu este absența — absența se vede — ci derapajul: conformarea a fost randată dintr-o versiune anterioară, este decalată cu câteva cadre sau are alt timecode de start. Un fișier stereo cu 40 ms avans față de părintele imersiv trece verificarea de prezență și pică ascultarea sincronizată.

Detectare: comparați duratele eșantion cu eșantion, comparați timecode-ul de start din bext și corelați conformarea cu o randare nulă a master-ului. Orice conformare care nu se poate deriva din master-ul curent se re-randează, nu se re-verifică.

10.6 Metadate care descriu un pat care nu e în fișier

XML-ul declară un pachet DirectSpeakers 7.1.4 — douăsprezece canale — dar s-a tipărit doar subsetul 5.1, sau canalele de înălțime au fost pe mut la bounce și au ieșit tăcere digitală. Graful de referințe este intact; audio-ul nu este.

Detectare: verificările structurale nu prind asta. Este nevoie de analiză de esență: pentru fiecare canal revendicat de un pachet DirectSpeakers, măsurați dacă pista conține semnal. Tăcerea digitală pe un canal de pat declarat nu este automat o eroare — un mix legitim poate lăsa gol un canal spate-sus — dar merită întotdeauna o decizie umană.

Containerul poate fi perfect valid, XML-ul perfect bine format, iar livrabilul tot greșit; singura verificare pentru un canal de pat gol este să te uiți la eșantioane.

Un inspector BW64/ADM gratuit, care rulează în browser, este disponibil la mazufa.com: parsează containerul și metadatele integral pe dispozitivul dumneavoastră și nu încarcă nimic nicăieri, ceea ce îl face utilizabil pe material care contractual nu are voie să iasă din studio.

11. Sonoritatea materialului imersiv: ce este de fapt specificat

Aici este important să separăm ce este publicat de ce circulă.

Ce specifică ITU-R BS.1770. Recomandarea definește ponderarea K: un filtru de tip shelving înalt („head filter", care modelează un cap sferic rigid), urmat de un filtru trece-sus RLB. Câștigul curbei la 1 kHz este +0,698 dB (liniar 1,0836). Măsurarea folosește blocuri de gating de 400 ms cu suprapunere de 75 %, o poartă absolută care elimină blocurile sub −70 LKFS și o poartă relativă calculată din media blocurilor care au supraviețuit porții absolute, apoi decalată cu −10 LU. Poarta relativă se calculează din blocurile supraviețuitoare, nu din media neselectată — o distincție pe care implementările o greșesc destul de des încât să conteze.

Ponderarea de canal în algoritmul de bază este 1,0 (0 dB) pentru L, R și C și 1,41 (≈ +1,5 dB) pentru Ls și Rs, cu LFE exclus. Algoritmul de bază este definit pentru „from one to five channels". BS.1770-5 extinde dincolo de asta în anexe, acoperind sistemele avansate din BS.2051 — difuzoare poziționate arbitrar și canale de înălțime — și audio-ul pe obiecte, care trebuie randat înainte să poată fi măsurat.

Ediția în vigoare. BS.1770 are șase ediții: -0 (2006), -1 (2007), -2 (2011), -3 (2012), -4 (2015) și -5 (noiembrie 2023). BS.1770-5 este ediția în vigoare; BS.1770-4 (octombrie 2015) este depășită, chiar dacă rămâne ediția pe care o citează majoritatea măsurătoarelor instalate în studiouri. Când notați o cifră în documentele de livrare, numiți ediția — și numiți-o pe cea curentă.

Sonoritatea imersivă nu este o proprietate a fișierului; este o proprietate a unei randări, iar schimbarea dispunerii-țintă schimbă numărul.

Aceasta este diferența de fond față de stereo. Un master stereo are o valoare de loudness. Un master pe obiecte are atâtea câte ținte de randare are, iar singurul mod onest de a declara o cifră este să numiți dispunerea pe care a fost măsurată și renderer-ul folosit. ITU-R BS.2127 definește renderer-ul ADM de referință, iar fratele său cu sursă deschisă, EBU ADM Renderer (EBU Tech 3388), este calea practică spre un număr reproductibil.

Concret pentru cazurile de aici: taraful randat în 0+5+0 și același taraf randat în 4+7+0 dau două valori integrate diferite, pentru că energia obiectelor se distribuie altfel pe difuzoare. Nu este o eroare de măsurare. Este comportamentul așteptat, și de asta formularea din documentele de livrare trebuie să fie „−X LUFS, măsurat cu un instrument conform BS.1770-5, pe o randare BS.2127 către dispunerea BS.2051 sistem J (4+7+0)" — trei lucruri numite, nu unul singur.

Documente EBU conexe. EBU Tech 3341 definește comportamentul instrumentelor (momentan 400 ms, pe termen scurt 3 s). EBU Tech 3342 definește Loudness Range (LRA), care folosește o poartă relativă de −20 LU — nu −10 LU; folosirea lui −10 pentru LRA este un bug de implementare frecvent. EBU R 128 stabilește ținta de program pentru radiodifuziune la −23 LUFS; R 128 este o practică de normalizare în broadcasting, nu o specificație pentru streaming muzical.

True peak. Se măsoară pe semnal supraeșantionat — minimum 4× conform BS.1770, 8× fiind mai bine. Vârful de eșantion nu este vârf real: vârfurile inter-eșantion pot depăși cea mai mare valoare de eșantion din fișier. Pentru material de nuntă, unde există chiuituri și percuție cu tranzienți foarte scurți, diferența nu este academică.

Ce este publicat pentru muzică. Pentru muzică stereo pe canale, Spotify publică o țintă integrată de −14 LUFS și un plafon de true peak de −1 dBTP, care se strânge la −2 dBTP pentru masterele mai tari de −14 LUFS. AES TD1008 recomandă −16 LUFS pentru muzică; cifra de −18 LUFS din același document se referă la conținut dominat de vorbire (știri, talk, dramă), iar afirmarea lui −18 ca țintă pentru muzică este o eroare frecventă și serioasă.

Ce nu este publicat. Niciun serviciu de streaming muzical nu publică o țintă de loudness integrat pentru livrarea imersivă. Cifre circulă pe forumuri și în materialele de instruire ale producătorilor de echipamente; unele sunt plauzibile, unele probabil corecte. Niciuna nu este o specificație publicată, iar acest document nu o va repeta ca și cum ar fi. Apple Music, YouTube Music, Amazon Music, TIDAL și Deezer nu publică o țintă de normalizare nici pentru stereo — cifrele citate frecvent pentru aceste servicii sunt larg raportate, dar nepublicate de serviciu, și nu trebuie tratate niciodată ca o specificație din care să calculați o diferență de câștig.

Despre sistemele proprietare. Dolby Atmos este o tehnologie proprietară, licențiată, a Dolby Laboratories, iar Sony 360 Reality Audio este un sistem proprietar construit peste MPEG-H. Cerințele lor de livrare sunt stabilite de proprietari și se schimbă fără legătură cu calendarele ITU sau EBU. Nimic din acest document nu constituie o declarație despre cerințele acestor companii și nu se pretinde nicio afiliere, certificare sau aprobare. Acolo unde un licențiator publică o cerință, citiți documentația lui curentă și citați-o pe aceea.

12. Poziția onestă: în România, monitorizarea imersivă este rară

Merită spus direct, pentru că ocolirea acestui fapt produce documente care nu ajută pe nimeni.

În studiourile de muzică din România, monitorizarea imersivă este o raritate. Dincolo de câteva spații de post-producție care lucrează pentru film și televiziune, o cameră 7.1.4 completă, cu poziții calibrate și o acustică rezonabilă, practic nu există în circuitul muzical. Un studio bun de dimensiuni medii are monitorizare stereo excelentă, uneori un 5.1 rămas dintr-o epocă anterioară, și cam atât. A înregistra un taraf cu microfoane individuale și un pat ambiental este la îndemâna multora. A asculta rezultatul așa cum îl va auzi ascultătorul final nu este la îndemâna aproape nimănui.

Concluzia care urmează de aici nu este „nu faceți imersiv". Este că valoarea muncii dumneavoastră stă în livrarea corectă, în metadatele corecte și în verificarea unui fișier pe care nu îl puteți audia cum trebuie. Ceea ce este realist și util:

1. Randarea binaurală nu este monitorizare, dar este un punct de control. O randare binaurală făcută cu un renderer conform BS.2127 (de exemplu EAR, cu sursă deschisă) vă lasă să auziți în căști dacă obiectele sunt în direcția corectă, dacă un instrument stă pe partea greșită, dacă stratul de înălțime este gol. Nu ajunge pentru a lua decizii de mix. Ajunge cu vârf și îndesat pentru a nu livra o greșeală grosolană.
2. Verificările structurale nu au nevoie de nicio cameră. Toate erorile din secțiunea 10, cu excepția patului gol, se prind cu un parser și câteva zeci de rânduri de cod, pe orice laptop.
3. Tăcerea digitală se măsoară, nu se ascultă. Este singura verificare de esență care contează cu adevărat și nu cere monitorizare, ci un histogramă de nivel pe fiecare canal declarat.
4. Documentați ce nu ați putut verifica. Dacă nu ați ascultat niciodată master-ul într-o cameră 4+7+0, spuneți asta în notele de livrare, împreună cu renderer-ul, dispunerea și versiunea BS.1770 folosite la măsurătoare. Un livrabil însoțit de o declarație onestă a limitelor este mai ușor de reparat decât unul care pretinde o verificare care nu s-a făcut.

13. Listă de verificare pentru livrare

Parcurgeți-o în ordine. Verificările structurale întâi — sunt rapide și invalidează tot ce urmează.

Container

1. Primii patru octeți sunt BW64. Dacă sunt RIFF, fișierul este WAV simplu și nu poate depăși 4 GiB.
2. ds64 este primul chunk după semnătură, iar dimensiunile lui pe 64 de biți se potrivesc cu dimensiunea reală a fișierului și a chunk-ului data de pe disc.
3. Orice chunk supradimensionat care nu este data are o intrare ChunkSize64 în tabela ds64.
4. axml este localizat explicit, inclusiv după data. Nu concluzionați „nu are ADM" dintr-o scanare parțială.

Esență

1. Rata de eșantionare și adâncimea de biți din fmt corespund exact specificației. Fără conversie de rată după scrierea ADM.
2. fmt.nChannels este egal cu chna.numTracks.
3. Fiecare trackIndex din chna este în interval și numerotat de la 1.

Integritatea chna

1. Fiecare intrare are exact 40 de octeți, cu câmpuri de lățime fixă corect completate.
2. Toți octeții din câmpurile UID, trackRef și packRef sunt ASCII (≤ 0x7F). Niciun ș, ț, ă, â sau î nu are voie aici.
3. Fiecare packRef de la 0x1000 în sus se rezolvă la o definiție personalizată prezentă în axml.
4. Valorile repetate de trackIndex sunt intenționate (o pistă care își schimbă legitim definiția), nu erori de duplicare.

Graful ADM

1. Fiecare audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef și audioTrackUIDRef se rezolvă. Zero muchii suspendate.
2. Niciun audioTrackUID orfan, în niciunul dintre sensuri.
3. Niciun element circular sau autoreferențial.
4. typeLabel de pe fiecare audioChannelFormat corespunde cu audioPackFormat-ul părinte.

Cronologie

1. Formatele de canal cu mai multe blocuri au și rtime, și duration pe fiecare bloc.
2. Blocurile sunt contigue și monotone; suma duratelor egalează durata audioObject-ului părinte.
3. Obiectele încep la 00:00:00.00000.

Conținut și text

1. Fiecare canal al unui pat declarat conține ce trebuie; investigați tăcerea digitală.
2. Numărul de obiecte și configurația patului corespund specificației de livrare.
3. axml este UTF-8 valid, iar diacriticele românești sunt cele corecte: ș U+0219 și ț U+021B, nu ş U+015F și ţ U+0163.
4. Timecode-ul de start din bext este corect și consecvent în tot setul de livrabile.

Randări și conformări

1. Conformările stereo și binaurală sunt re-randate din master-ul curent, nu preluate din versiuni anterioare.
2. Duratele și timecode-urile de start se potrivesc cu master-ul, eșantion cu eșantion.
3. Loudness-ul este măsurat pe o randare numită, către o dispunere numită, cu un renderer numit — și toate trei sunt trecute în notele de livrare, împreună cu ediția BS.1770 folosită.

Reproductibilitate

1. Fiecare livrabil are sumă de control, iar manifestul se păstrează.
2. Sesiunea și XML-ul ADM se arhivează separat de BW64; un XML pe care îl puteți compara cu diff valorează mai mult peste doi ani decât un binar pe care îl puteți doar re-parsa.

Un livrabil imersiv nu este gata când sună bine; este gata când o mașină care nu l-a auzit niciodată poate demonstra că referințele lui se rezolvă.

14. Încheiere

BW64 și ADM sunt standarde deschise, publicate, care se pot citi liber. Este ceva neobișnuit în colțul acesta al industriei și merită folosit: puteți citi BS.2088 și BS.2076 cu ochii dumneavoastră, puteți parsa un chunk chna în patruzeci de rânduri de cod și puteți verifica ce a scris efectiv exportatorul unui producător, în loc de ce a pretins caseta lui de dialog. Audio-ul imersiv este zona unde se produce cea mai mare parte a respingerilor inutile, iar aproape toate sunt erori de integritate referențială pe care un validator le prinde într-o secundă.

Pentru un muzician român care înregistrează un taraf, o horă sau o slujbă în curtea bisericii, asta este o veste bună: partea care cere o cameră de 7.1.4 este partea artistică, iar partea care decide dacă fișierul trece este partea pe care o puteți verifica singuri, pe laptop, cu certitudine matematică.

Distribuția prin Mazufa este gratuită — fără taxă de încărcare, fără abonament, fără cost per lansare; singura deducere este 5 % din redevențele încasate, iar fiecare cerere completă trece printr-o evaluare umană.

Surse

Recomandări 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
• Pagina ITU-R BS.2127 — https://www.itu.int/rec/R-REC-BS.2127

Documente tehnice EBU

• EBU Tech 3306, RF64: An extended file format for audio data — https://tech.ebu.ch/docs/tech/tech3306.pdf
• EBU Tech 3285 (și suplimentele), 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 și 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 (instrumente de măsură), EBU Tech 3342 (Loudness Range) — https://tech.ebu.ch
• EBU ADM Guidelines — chunk-ul 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
• Documentația EBU ADM Renderer (EAR), I/O pentru BW64 — https://ear.readthedocs.io/en/latest/BW64.html
• Implementarea de referință libbw64 — https://github.com/ebu/libbw64
• Implementarea de referință libadm — https://github.com/ebu/libadm

Unicode

• Unicode Character Database — ș U+0219 LATIN SMALL LETTER S WITH COMMA BELOW — https://util.unicode.org/UnicodeJsps/character.jsp?a=0219
• Unicode Character Database — ț U+021B LATIN SMALL LETTER T WITH COMMA BELOW — https://util.unicode.org/UnicodeJsps/character.jsp?a=021B

AES

• AES TD1008, Recommendations for loudness of internet audio streaming and on-demand distribution — https://www.aes.org/community/technical-council/technical-document-aestd1008/

Documentația serviciilor

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

Ultima revizuire: septembrie 2026. Standardele se revizuiesc; verificați întotdeauna paginile ITU și EBU de mai sus pentru ediția curentă înainte de a cita un număr de clauză.