Perché un master immersivo passa l'editor di forme d'onda e non supera il QC

Una consegna immersiva può aprirsi in un editor di forme d'onda, mostrare dodici o sedici tracce dall'aspetto sano, riprodursi in modo sensato ed essere comunque respinta. La ragione è strutturale: in un file BW64 l'audio e i metadati sono due cose distinte che devono coincidere esattamente, e nel formato non c'è nulla che le costringa a farlo. Un renderer risolve riferimenti. Un editor disegna campioni. Lavori diversi — ed è per questo che il QC dell'ADM è una verifica di integrità dei riferimenti, non un ascolto. Ecco che cosa dicono i due standard, dove i riferimenti si rompono e quale controllo intercetta quale guasto.

Tre tipi di audio, e perché la distinzione decide tutto

Ogni problema di consegna immersiva nasce dalla confusione su quale delle tre cose sia una traccia.

L'audio channel-based assegna ogni traccia a una posizione fissa di altoparlante. Lo stereo è channel-based, così come il 5.1 e un bed 7.1.4. La posizione è incorporata nell'identità del canale: la traccia 3 è il diffusore centrale, ed è il diffusore centrale su ogni sistema che la riproduce. La ITU-R BS.2051 formalizza questo per i sistemi audio avanzati, descrivendo i layout come conteggi di strati Upper + Middle + Bottom — il System A è 0+2+0 (stereo), il System B è 0+5+0 (5.1), il System D è 4+5+0, il System J è 4+7+0, il System H è 9+10+3, cioè la configurazione 22.2. Nell'ADM è la typeDefinition DirectSpeakers, typeLabel 0001.

L'audio object-based trasporta un segnale mono (o un pack multicanale) più metadati posizionali che variano nel tempo. È il renderer a decidere quali altoparlanti reali lo riproducono, in base al layout presente nella stanza. Nulla, nella traccia, presuppone un diffusore. È la typeDefinition Objects, typeLabel 0003.

L'audio scene-based, in pratica l'Higher-Order Ambisonics, codifica l'intero campo sonoro come componenti armoniche sferiche. Nessuna componente corrisponde da sola a una direzione; la direzione emerge dalla combinazione lineare. È HOA, typeLabel 0004. L'ADM definisce anche Matrix (0002) per segnali matrixati come Mid-Side o Lt/Rt, e Binaural (0005).

La distinzione non è tassonomia. Una consegna channel-based si autodescrive abbastanza da sopravvivere come semplice WAV — basta azzeccare l'ordine dei canali e suona. Una consegna object-based o scene-based è priva di senso senza i suoi metadati: l'audio è un mucchio di flussi mono indifferenziati, e l'ADM è l'unica cosa che dica il contrario. È questa asimmetria la ragione per cui BW64 e ADM esistono.

BW64 esiste a causa di un numero a 32 bit

Il WAV classico è un file RIFF. RIFF, dal 1991, antepone a ogni chunk un campo di dimensione a 32 bit. Trentadue bit indirizzano 4,294,967,296 byte — 4 GB — e questo è il tetto rigido sia per l'intero file sia per il chunk data al suo interno.

Per uno stereo a 48 kHz / 24 bit il data rate è di 288,000 byte al secondo, quindi 4 GB corrispondono a circa 4 ore e 8 minuti. Irrilevante. Per un master object-based a 128 tracce a 96 kHz / 24 bit il rate è di 36,864,000 byte al secondo, e 4 GB sono meno di due minuti — 116.5 secondi.

I master immersivi superano quel limite di routine, e uno scrittore WAV che lo raggiunge produce o un file troncato o uno le cui dimensioni dichiarate sono andate silenziosamente in overflow. L'EBU ha affrontato per prima la questione con RF64 (EBU Tech 3306); l'ITU l'ha portata avanti come Raccomandazione ITU-R BS.2088 — BW64.

Il trucco della sentinella: 0xFFFFFFFF e un chunk ds64

La BS.2088 è esplicita sul meccanismo. «The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file», e i campi di dimensione originali a 32 bit diventano flag di escape: «If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead.»

Il trucco è tutto qui, e vale la pena dirlo chiaramente: BW64 non allarga i campi di dimensione RIFF. Li riempie con 0xFFFFFFFF come sentinella e mette le vere dimensioni a 64 bit in un chunk ds64 che deve stare per primo nel file. Perciò un file BW64 sotto i 4 GB è compatibile byte per byte con un lettore WAV sotto ogni aspetto tranne la firma di quattro caratteri. Molti strumenti lo accettano; alcuni si ostinano a non farlo.

I chunk, e quello che è esattamente di 40 byte per voce

Secondo la BS.2088 ci si aspetta che un file BW64 contenga almeno ds64, fmt , chna, axml (con bxml e sxml come vettori di metadati alternativi) e i dati audio.

ds64 deve essere il primo chunk dopo la firma, perché un lettore deve conoscere le dimensioni reali prima di poter percorrere qualsiasi altra cosa. Contiene le metà basse/alte a 32 bit per la dimensione dell'intero file e per quella di data, più una tabella di voci ChunkSize64 per qualsiasi altro chunk sovradimensionato — un chunk axml che descriva migliaia di oggetti con automazione campione-accurata può a sua volta avvicinarsi ai 4 GB o superarli.

fmt è il chunk di formato WAVE standard — formato dei campioni, frequenza di campionamento, numero di canali, bit per campione, block align. È l'unica dichiarazione autorevole di quanti canali interlacciati ci siano in data. Tutto ciò che sta a valle sono metadati su quei canali, e i metadati possono mentire.

chna è il ponte tra le tracce fisiche e l'ADM. Dopo ckID, ckSize, un numTracks di 2 byte e un numUIDs di 2 byte, contiene un array piatto di voci audioID a larghezza fissa, ciascuna di esattamente 40 byte:

2 + 12 + 14 + 11 + 1 = 40. Le larghezze non sono indicative: sono ASCII a larghezza fissa, e uno scrittore che emette un UID di 13 caratteri ha prodotto una tabella corrotta, non una leggermente insolita.

Conta anche la convenzione sugli ID. I valori pari a 0x0FFF e inferiori rimandano alle common definitions dell'ADM — i formati di canale e di pack standard, predefiniti — mentre da 0x1000 in su indicano definizioni personalizzate che devono essere presenti in axml. AP_00010003 è il 5.1 per common definition e non richiede XML; AP_00031001 è un pack di oggetti personalizzato e richiede XML, altrimenti resta un riferimento pendente.

Anche numUIDs può legittimamente superare numTracks: le linee guida dell'EBU osservano che laddove «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», per cui uno stesso trackIndex può comparire in più voci. Gli strumenti di QC che presumono un UID per traccia segnalano come guasti dei file corretti.

axml è un documento XML in UTF-8 che contiene l'albero <audioFormatExtended>. Quello è l'ADM, ed è lì che vive praticamente ogni guasto interessante. data è semplice PCM interlacciato; nulla al suo interno sa alcunché degli oggetti.

Ordinamento: ds64 per primo, sempre; fmt prima di data. Ma axml può legittimamente stare dopo data, e spesso ci sta perché — come osserva la BS.2088 — durante la registrazione «the XML metadata will likely be of an unknown length.» Un file con axml in coda non è malformato, ma un lettore che scansiona solo il primo megabyte riporterà l'assenza totale di ADM. È questo a spiegare una quota sorprendente delle segnalazioni «il mio file non ha metadati».

L'ADM è un grafo, e i guasti sono archi spezzati

La gerarchia della ITU-R BS.2076 va da audioProgramme → audioContent → audioObject → audioPackFormat → audioChannelFormat → audioBlockFormat, con audioTrackUID come foglia e unico elemento che corrisponda a una traccia fisica.

Quello è un grafo di riferimenti, non un documento annidato, e ogni guasto serio di consegna è un arco spezzato al suo interno. Ciò che rende pericoloso un riferimento pendente è che, quando se ne rompe uno, non esiste un comportamento univoco. Un renderer che risolva un audioPackFormatIDRef il quale nomini un pack assente dall'XML può interrompere il parsing e rifiutare il file; può saltare quell'oggetto e renderizzare tutto il resto, producendo un mix a cui manca silenziosamente uno stem; oppure può ripiegare sulle common definitions, trovare un ID nell'intervallo personalizzato da 0x1000 in su senza corrispondenza e sostituirvi il silenzio. Tutti e tre gli esiti sono «il file si è aperto». Solo uno viene colto dall'ascolto, e solo se sai che cosa avrebbe dovuto esserci.

I quattro guasti che spiegano la maggior parte dei rifiuti

Un conteggio di tracce in fmt che non concorda con chna. fmt .nChannels dice 16; chna.numTracks dice 14. Il file è internamente incoerente già dai primi due chunk — di solito un bounce che ha cambiato il numero di tracce dopo la scrittura dei metadati, o uno strumento che ha eliminato tracce senza riscrivere chna. Rilevarlo significa leggere due interi e confrontarli: il controllo più economico della pipeline, e intercetta una quota sorprendente di guasti. Verifica nello stesso momento che ogni trackIndex ricada entro 1 … fmt .nChannels.

Un audioTrackUID non referenziato da alcun oggetto. Un UID in chna che nessun audioObject referenzia significa che esiste audio che nulla renderizzerà; il caso speculare, un audioTrackUIDRef nell'XML senza una voce corrispondente in chna, significa che i metadati si aspettano una traccia che non c'è. Costruisci l'insieme degli UID da chna e quello da axml e prendi la differenza simmetrica; deve essere vuota. La EBU Tech 3392 enuncia direttamente l'intento: «If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs.»

Timing dei blocchi che scorre all'indietro. La BS.2076 è inequivocabile: «When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present.» La EBU Tech 3392 stringe la cosa fino alla contiguità — «rtime + duration of an audioBlockFormat should match the rtime of the following block» — con il primo blocco di un oggetto che inizia a 00:00:00.00000, nessun blocco più corto di un campione e durate la cui somma corrisponda all'audioObject genitore. Percorri i blocchi nell'ordine del documento e verifica che rtime[n] + duration[n] == rtime[n+1]. I guasti si presentano in tre forme: lacune, dove il comportamento del renderer è indefinito e alcuni mantengono l'ultima posizione mentre altri silenziano; sovrapposizioni, dove i blocchi si contendono il campo; e blocchi fuori ordine cronologico, che sono automazioni che saltano indietro a metà programma.

Un bed descritto nell'XML che non è mai stato scritto su disco. L'XML dichiara un pack DirectSpeakers 7.1.4 — dodici canali — ma è stato scritto solo il sottoinsieme 5.1, oppure i canali di altezza erano in mute al bounce e sono stati scritti come nero digitale. Il grafo dei riferimenti è integro; l'audio no. I controlli strutturali non possono coglierlo: serve un'analisi dell'essence, che misuri se ogni canale rivendicato da un pack DirectSpeakers contenga del segnale. Il nero digitale su un canale di bed dichiarato non è automaticamente un errore — un mix legittimo può lasciare vuoto un canale posteriore superiore — ma merita sempre una decisione umana.

Che cosa è pubblicato sul volume immersivo, e che cosa no

Un numero non sopravvive al passaggio dallo stereo, e vale la pena spiegare perché.

La BS.1770-5 (novembre 2023) è l'edizione in vigore; la BS.1770-4 è superata, anche se la maggior parte dei misuratori in uso continua a citarla. Il suo algoritmo di base pondera L, R e C a 1.0 e Ls e Rs a 1.41 (circa +1.5 dB), esclude l'LFE ed è delimitato «from one to five channels». La BS.1770-5 va oltre nei suoi allegati, coprendo i sistemi audio avanzati della BS.2051 e l'audio object-based — che deve essere renderizzato prima di poter essere misurato. Il volume immersivo non è dunque una proprietà del file ma di un render, e cambiare il layout di destinazione cambia il numero. Misura un render conforme alla BS.2127 verso un layout BS.2051 esplicitamente nominato con un misuratore BS.1770-5 e annota tutti e tre i dati nelle tue note di consegna; la BS.2127 definisce il renderer ADM di riferimento, e il suo fratello open source, l'EBU ADM Renderer (EBU Tech 3388), è la via pratica per ottenere una cifra riproducibile.

Nessun servizio di streaming musicale pubblica un target di volume integrato per la consegna immersiva. Delle cifre circolano nei forum e nel materiale formativo dei fornitori; nessuna è una specifica pubblicata e questo articolo non ne ripeterà nessuna come se lo fosse. Ciò che è pubblicato riguarda lo stereo channel-based — il target integrato di Spotify di −14 LUFS con un tetto di true peak di −1 dBTP, che si stringe a −2 dBTP sopra i −14 LUFS, e i −16 LUFS della AES TD1008 per la musica (la sua cifra di −18 LUFS si applica ai contenuti a prevalenza parlata, e indicare −18 come target per la musica è un errore frequente e grave).

Dolby Atmos è una tecnologia proprietaria e su licenza dei Dolby Laboratories, e Sony 360 Reality Audio è un sistema proprietario costruito su MPEG-H. I loro requisiti sono stabiliti dai rispettivi proprietari, cambiano senza riferimento alle tempistiche di ITU o EBU e non sono riportati qui; non si rivendica alcuna affiliazione né alcun avallo. Consulta la documentazione attuale del licenziante stesso.

Che cosa controllare prima di inviarlo

Prima i controlli strutturali; sono rapidi e invalidano tutto ciò che sta a valle.

• I primi quattro byte sono BW64. Se leggi RIFF, è un semplice WAV e non può superare i 4 GB.
• ds64 è il primo chunk dopo la firma, le sue dimensioni a 64 bit coincidono con le dimensioni del file e di data su disco, e ogni chunk sovradimensionato diverso da data ha una voce ChunkSize64 nella tabella.
• Individua axml esplicitamente, anche dopo data — non concludere mai «niente ADM» a partire da una scansione parziale.
• La frequenza di campionamento e la profondità di bit in fmt corrispondono esattamente alla specifica di consegna. Nessuna conversione di frequenza di campionamento dopo la scrittura dell'ADM — invalida ogni rtime e duration espressi in campioni.
• fmt .nChannels è uguale a chna.numTracks; ogni trackIndex è nell'intervallo e a base 1.
• Ogni voce di chna è esattamente di 40 byte con campi a larghezza fissa correttamente riempiti, e ogni packRef da 0x1000 in su si risolve in una definizione personalizzata presente in axml.
• Ogni audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef e audioTrackUIDRef si risolve. Zero archi pendenti, in entrambe le direzioni, senza riferimenti circolari.
• I formati di canale multiblocco riportano sia rtime sia duration su ogni blocco; i blocchi sono contigui e monotoni; gli oggetti iniziano a 00:00:00.00000.
• Ogni canale di un bed dichiarato contiene ciò che deve contenere. Indaga sul nero digitale.
• Il timecode di inizio in bext è coerente su tutto il set, e i conform stereo e binaurali sono ri-renderizzati dal master corrente. Un conform in anticipo di 40 ms rispetto al suo genitore immersivo supera un controllo di presenza dei file e non supera un ascolto sincronizzato.
• Calcola il checksum di ogni consegnabile, conserva il manifest e archivia l'XML dell'ADM separatamente dal BW64 — un XML di cui puoi fare il diff vale di più, in seguito, di un binario che puoi solo rifare il parsing.

BW64 e ADM sono standard aperti, pubblicati e liberamente consultabili, ed è una cosa che conviene sfruttare: puoi leggerti da solo la BS.2088 e la BS.2076, fare il parsing di un chunk chna con quaranta righe di codice e verificare che cosa abbia davvero scritto l'esportatore di un fornitore anziché quello che dichiarava la sua finestra di dialogo. Quasi tutti i rifiuti immersivi non necessari sono errori di integrità dei riferimenti che un validatore intercetta in meno di un secondo.

L'ispettore BW64/ADM gratuito di Mazufa, all'indirizzo mazufa.com/immersive-master-check, analizza il contenitore e i metadati interamente sul tuo dispositivo e non carica nulla, il che lo rende utilizzabile su materiale che contrattualmente non può uscire dall'edificio. Mazufa stessa è gratuita su cui pubblicare, prende 0% di commissione ed è su invito, con revisione umana di ogni candidatura completa.

Fonti

Raccomandazioni 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

Documenti tecnici EBU

• EBU Tech 3306, RF64: An extended file format for audio data — https://tech.ebu.ch/docs/tech/tech3306.pdf
• EBU Tech 3285 (e supplementi), 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
• Implementazione di riferimento 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/

Documentazione dei servizi

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