De ce un master imersiv trece de un editor de undă și pică la QC

Un livrabil imersiv se poate deschide într-un editor de undă, poate arăta douăsprezece sau șaisprezece piste cu aspect sănătos, se poate reda rezonabil — și tot poate fi respins. Motivul este structural: într-un fișier BW64, audio și metadatele sunt două lucruri separate care trebuie să coincidă exact, iar formatul în sine nu impune nimic în acest sens. Un renderer rezolvă referințe. Un editor desenează eșantioane. Sarcini diferite — și tocmai de aceea QC-ul de ADM înseamnă verificarea integrității referințelor, nu ascultare. Iată ce spun cele două standarde, unde se rup referințele și ce verificare prinde care defect.

Trei feluri de audio și de ce distincția decide totul

Fiecare problemă de livrare imersivă începe de la confuzia legată de care dintre cele trei lucruri este o pistă.

Audio pe canale atribuie fiecare pistă unei poziții fixe de difuzor. Stereo este pe canale, la fel 5.1, la fel un pat 7.1.4. Poziția este înscrisă în identitatea canalului: pista 3 este difuzorul central și rămâne difuzorul central pe orice sistem care o redă. ITU-R BS.2051 formalizează asta pentru sistemele de sunet avansate, descriind configurațiile prin numărul de straturi Upper + Middle + Bottom — Sistemul A este 0+2+0 (stereo), Sistemul B este 0+5+0 (5.1), Sistemul D este 4+5+0, Sistemul J este 4+7+0, iar Sistemul H este 9+10+3, configurația 22.2. În ADM aceasta este typeDefinition DirectSpeakers, typeLabel 0001.

Audio pe obiecte poartă un semnal mono (sau un pack multicanal) plus metadate de poziție care se schimbă în timp. Rendererul decide ce difuzoare reale îl reproduc, în funcție de configurația prezentă în încăpere. Nimic din pistă nu presupune un difuzor anume. Aceasta este typeDefinition Objects, typeLabel 0003.

Audio pe scenă, în practică Ambisonics de ordin superior, codifică întregul câmp sonor sub formă de componente armonice sferice. Nicio componentă nu corespunde singură unei direcții; direcția apare din combinația liniară. Aceasta este HOA, typeLabel 0004. ADM mai definește Matrix (0002) pentru semnale matriciate precum Mid-Side sau Lt/Rt și Binaural (0005).

Distincția nu este taxonomie. Un livrabil pe canale se autodescrie suficient cât să supraviețuiască ca simplu WAV — nimerește ordinea canalelor și se redă. Un livrabil pe obiecte sau pe scenă nu înseamnă nimic fără metadatele lui: audio este un morman de fluxuri mono nediferențiate, iar ADM-ul este singurul lucru care spune altceva. Asimetria asta este motivul pentru care există BW64 și ADM.

BW64 există din cauza unui număr pe 32 de biți

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 GB — și acesta este plafonul dur atât pentru fișierul întreg, cât și pentru chunk-ul data din el.

Pentru stereo la 48 kHz / 24-bit, debitul de date este de 288,000 de octeți pe secundă, deci 4 GB înseamnă circa 4 ore și 8 minute. Irelevant. Pentru un master pe obiecte cu 128 de piste la 96 kHz / 24-bit, debitul este de 36,864,000 de octeți pe secundă, iar 4 GB înseamnă sub două minute — 116.5 secunde.

Masterele imersive trec de această limită în mod curent, iar un writer de WAV care o atinge produce fie un fișier trunchiat, fie unul ale cărui dimensiuni declarate s-au rotit în tăcere. EBU a rezolvat asta întâi cu RF64 (EBU Tech 3306); ITU a dus-o mai departe ca Recomandarea ITU-R BS.2088 — BW64.

Trucul santinelei: 0xFFFFFFFF și un chunk ds64

BS.2088 este explicită în privința mecanismului. „The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file", iar câmpurile originale de dimensiune 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."

Acesta este tot trucul și merită spus pe șleau: BW64 nu lărgește câmpurile de dimensiune RIFF. Le umple cu 0xFFFFFFFF pe post de santinelă și pune dimensiunile reale pe 64 de biți într-un chunk ds64 care trebuie să stea primul în fișier. Astfel, un fișier BW64 sub 4 GB este compatibil octet cu octet cu un cititor de WAV în toate privințele, mai puțin semnătura de patru caractere. Multe unelte îl acceptă; unele refuză cu încăpățânare.

Chunk-urile și cel care are exact 40 de octeți pe intrare

Conform BS.2088, un fișier BW64 se așteaptă să conțină cel puțin ds64, fmt , chna, axml (cu bxml și sxml ca purtători alternativi de metadate) și datele de undă.

ds64 trebuie să fie primul chunk după semnătură, fiindcă un cititor are nevoie să știe dimensiunile reale înainte să poată parcurge orice altceva. Poartă jumătățile inferioară și superioară pe 32 de biți pentru dimensiunea întregului fișier și pentru cea a data, plus un tabel de intrări ChunkSize64 pentru orice alt chunk supradimensionat — un chunk axml care descrie mii de obiecte cu automatizare la nivel de eșantion poate el însuși să se apropie de 4 GB sau să le depășească.

fmt este chunk-ul standard de format WAVE — formatul eșantionului, frecvența de eșantionare, numărul de canale, biții pe eșantion, block align. Este singura afirmație autoritară despre câte canale întrețesute există în data. Tot ce vine după este metadată despre acele canale, iar metadatele pot minți.

chna este puntea dintre pistele fizice și ADM. După ckID, ckSize, un numTracks pe 2 octeți și un numUIDs pe 2 octeți, conține un tablou plat de intrări audioID de lățime fixă, fiecare de exact 40 de octeți:

2 + 12 + 14 + 11 + 1 = 40. Lățimile nu sunt orientative: sunt ASCII de lățime fixă, iar un writer care emite un UID de 13 caractere a produs un tabel corupt, nu unul ușor neobișnuit.

Contează și convenția identificatorilor. Valorile de 0x0FFF și mai jos trimit la definițiile comune ADM — formatele standard, predefinite, de canal și de pack — în timp ce 0x1000 și mai sus indică definiții proprii, care trebuie să fie prezente în axml. AP_00010003 este 5.1 prin definiție comună și nu are nevoie de XML; AP_00031001 este un pack de obiecte propriu și are nevoie de XML, altfel rămâne suspendat.

numUIDs poate depăși legitim și numTracks: îndrumarul 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 singur trackIndex poate apărea în mai multe intrări. Uneltele de QC care presupun un UID per pistă marchează drept stricate fișiere corecte.

axml este un document XML în UTF-8 care conține arborele <audioFormatExtended>. Acela este ADM-ul și acolo trăiesc practic toate defectele interesante. data este PCM întrețesut simplu; nimic din el nu știe nimic despre obiecte.

Ordinea: ds64 primul, întotdeauna; fmt înaintea lui data. Dar axml poate sta legitim după data și adesea chiar stă, fiindcă — 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 defect, dar un cititor care scanează doar primul megaoctet va raporta că nu există ADM deloc. Asta explică o proporție surprinzătoare din sesizările „fișierul meu nu are metadate".

ADM este un graf, iar defectele sunt muchii rupte

Ierarhia din ITU-R BS.2076 merge audioProgramme → audioContent → audioObject → audioPackFormat → audioChannelFormat → audioBlockFormat, cu audioTrackUID drept frunză și singurul element care corespunde unei piste fizice.

Acesta este un graf de referințe, nu un document imbricat, iar fiecare defect serios de livrare este o muchie ruptă în el. O referință suspendată este periculoasă fiindcă nu există un comportament unic atunci când se rupe. Un renderer care rezolvă un audioPackFormatIDRef ce numește un pack absent din XML poate abandona parsarea și respinge fișierul; poate sări peste obiectul respectiv și reda tot restul, producând un mix căruia îi lipsește discret o componentă; sau poate cădea înapoi pe definițiile comune, poate găsi un ID din intervalul propriu de la 0x1000 în sus fără corespondent și poate substitui liniște. Toate cele trei rezultate înseamnă „fișierul s-a deschis". Doar unul este prins prin ascultare și doar dacă știi ce ar fi trebuit să fie acolo.

Cele patru defecte care explică majoritatea respingerilor

Un număr de piste din fmt care nu se potrivește cu chna. fmt .nChannels spune 16; chna.numTracks spune 14. Fișierul este inconsistent intern încă de la primele două chunk-uri — de obicei un bounce care a schimbat numărul de piste după ce metadatele fuseseră scrise, sau o unealtă care a eliminat piste fără să rescrie chna. Detectarea înseamnă parsarea a două numere întregi și compararea lor: cea mai ieftină verificare din lanț și prinde o proporție uimitoare de defecte. Verifică în același timp că fiecare trackIndex se află în 1 … fmt .nChannels.

Un audioTrackUID la care nu trimite niciun obiect. Un UID din chna la care nu trimite niciun audioObject înseamnă că există audio pe care nimic nu-l va reda; cazul în oglindă, un audioTrackUIDRef în XML fără o intrare corespondentă în chna, înseamnă că metadatele așteaptă o pistă care nu există. Construiește mulțimea de UID-uri din chna și pe cea din axml și ia diferența simetrică; trebuie să fie vidă. EBU Tech 3392 formulează intenția direct: „If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs."

Sincronizarea blocurilor care merge înapoi. 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 asta până la contiguitate — „rtime + duration of an audioBlockFormat should match the rtime of the following block" — cu primul bloc al unui obiect pornind de la 00:00:00.00000, niciun bloc mai scurt de un eșantion, iar duratele însumându-se la audioObject-ul părinte. Parcurge blocurile în ordinea din document și verifică rtime[n] + duration[n] == rtime[n+1]. Defectele vin în trei forme: goluri, unde comportamentul rendererului este nedefinit, unele reținând ultima poziție, altele trecând pe mut; suprapuneri, unde blocurile se bat între ele; și blocuri în afara ordinii cronologice, adică automatizare care sare înapoi în mijlocul programului.

Un pat descris în XML care nu a fost niciodată scris pe disc. XML-ul declară un pack DirectSpeakers 7.1.4 — douăsprezece canale — dar s-a scris doar subsetul 5.1, sau canalele de înălțime au fost pe mut la bounce și s-au scris ca liniște digitală. Graful de referințe este intact; audio nu este. Verificările structurale nu pot prinde asta: îți trebuie analiza conținutului propriu-zis, care măsoară dacă fiecare canal revendicat de un pack DirectSpeakers conține în general semnal. Liniștea digitală pe un canal declarat de pat nu este automat o eroare — un mix legitim poate lăsa gol un canal spate-sus — dar merită întotdeauna o decizie umană.

Ce se publică despre sonoritatea imersivă și ce nu

Un singur număr nu supraviețuiește mutării din stereo și merită spus de ce.

BS.1770-5 (November 2023) este ediția curentă; BS.1770-4 este înlocuită, chiar dacă majoritatea aparatelor de măsură instalate o citează încă. Algoritmul ei de bază ponderează L, R și C cu 1.0 și Ls și Rs cu 1.41 (circa +1.5 dB), exclude LFE și are ca domeniu „from one to five channels". BS.1770-5 depășește asta în anexele ei, acoperind sistemele de sunet avansate din BS.2051 și audio pe obiecte — care trebuie redat înainte să poată fi măsurat. Prin urmare, sonoritatea imersivă nu este o proprietate a fișierului, ci a unei redări, iar schimbarea configurației țintă schimbă cifra. Măsoară o redare conformă cu BS.2127 către o configurație BS.2051 numită, cu un aparat conform BS.1770-5, și consemnează toate trei în notele de livrare; BS.2127 definește rendererul ADM de referință, iar fratele lui cu sursă deschisă, EBU ADM Renderer (EBU Tech 3388), este calea practică spre o cifră reproductibilă.

Niciun serviciu de streaming muzical nu publică o țintă de sonoritate integrată pentru livrarea imersivă. Cifre circulă pe forumuri și în materialele de instruire ale furnizorilor; niciuna nu este o specificație publicată, iar acest articol nu va repeta vreuna ca și cum ar fi. Ce este publicat se referă la stereo pe canale — ținta integrată a Spotify de −14 LUFS cu un plafon de vârf real de −1 dBTP, strâns la −2 dBTP peste −14 LUFS, și cifra de −16 LUFS pentru muzică din AES TD1008 (cifra ei de −18 LUFS se aplică materialului centrat pe vorbire, iar a prezenta −18 drept ținta pentru muzică este o greșeală frecventă și gravă).

Dolby Atmos este o tehnologie proprietară, licențiată, a Dolby Laboratories, iar Sony 360 Reality Audio este un sistem proprietar construit pe MPEG-H. Cerințele lor sunt stabilite de proprietarii lor, se schimbă fără legătură cu calendarele ITU sau EBU și nu sunt enunțate aici; nu se pretinde nicio afiliere și niciun gir. Citește documentația curentă a licențiatorului însuși.

Ce să verifici înainte să-l trimiți

Verificările structurale întâi; sunt rapide și invalidează tot ce vine după ele.

• Primii patru octeți sunt BW64. Dacă se citește RIFF, este un WAV obișnuit și nu poate depăși 4 GB.
• ds64 este primul chunk după semnătură, dimensiunile lui pe 64 de biți se potrivesc cu dimensiunea fișierului și a data de pe disc, iar orice chunk supradimensionat care nu e data are o intrare ChunkSize64 în tabel.
• Localizează axml explicit, inclusiv după data — nu conchide niciodată „fără ADM" pe baza unei scanări parțiale.
• Frecvența de eșantionare și adâncimea de biți din fmt corespund exact specificației de livrare. Nicio conversie de frecvență de eșantionare după scrierea ADM — invalidează fiecare rtime și duration exprimat în eșantioane.
• fmt .nChannels este egal cu chna.numTracks; fiecare trackIndex este în interval și numerotat de la 1.
• Fiecare intrare chna are exact 40 de octeți, cu câmpuri de lățime fixă corect completate, iar fiecare packRef de la 0x1000 în sus se rezolvă la o definiție proprie prezentă în axml.
• Fiecare audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef și audioTrackUIDRef se rezolvă. Zero muchii suspendate, în oricare direcție, fără referințe circulare.
• Formatele de canal cu mai multe blocuri poartă și rtime, și duration pe fiecare bloc; blocurile sunt contigue și monotone; obiectele încep la 00:00:00.00000.
• Fiecare canal al unui pat declarat conține ce ar trebui. Cercetează liniștea digitală.
• Timecode-ul de start din bext este consecvent pe tot setul, iar conformările stereo și binaurale sunt redate din nou din masterul curent. O conformare cu 40 ms mai devreme față de părintele ei imersiv trece de o verificare de prezență a fișierului și pică la o ascultare sincronizată.
• Calculează suma de control pentru fiecare livrabil, păstrează manifestul și arhivează XML-ul ADM separat de BW64 — un XML pe care poți face diff valorează mai mult mai târziu decât un binar pe care nu-l poți decât reparsa.

BW64 și ADM sunt standarde deschise, publicate și liber de citit, iar asta merită folosit: poți citi singur BS.2088 și BS.2076, poți parsa un chunk chna cu patruzeci de linii de cod și poți verifica ce a scris de fapt exportatorul unui furnizor, în loc de ce pretindea caseta lui de dialog. Aproape toate respingerile inutile de material imersiv sunt erori de integritate a referințelor pe care un validator le prinde în mai puțin de o secundă.

Inspectorul gratuit de BW64/ADM al Mazufa, la mazufa.com/immersive-master-check, parsează containerul și metadatele integral pe propriul tău dispozitiv și nu încarcă nimic, ceea ce îl face utilizabil pe material care, contractual, nu poate părăsi clădirea. Mazufa în sine este gratuită pentru lansări, ia 0% comision și funcționează doar pe bază de invitație, cu verificare umană a fiecărei cereri complete.

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

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/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
• implementarea de referință 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/

Documentația serviciilor

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