BW64 e ADM: consegnare l'opera lirica come audio a oggetti su un bed di canali

Riferimento tecnico per chi prepara master immersivi in Italia — teatro, chiesa, studio — e per chi si è visto recapitare un «deliverable immersivo» con l'ordine di farlo passare al QC.

La risposta breve

L'Audio Definition Model (ADM), Raccomandazione ITU-R BS.2076, è un modello di metadati aperto che descrive che cosa è ogni traccia di un file audio: un canale di altoparlante, un oggetto in movimento o una componente ambisonica, e come queste tracce si compongono in un programma. Viaggia come XML dentro un contenitore BW64, Raccomandazione ITU-R BS.2088, che è un'estensione a 64 bit di RIFF/WAVE nata per superare il tetto dei 4 GB del WAV classico. Le consegne immersive vengono respinte quasi sempre per lo stesso motivo: audio e metadati sono due cose distinte che devono coincidere esattamente, e il formato non obbliga nessuno a farle coincidere. Un conteggio di canali in fmt che non concorda con la tabella chna, un audioTrackUID che nessun oggetto referenzia, una sequenza di blocchi la cui temporizzazione torna indietro, un bed dichiarato nell'XML e mai stampato su disco: nulla di tutto ciò è visibile in un editor di forme d'onda, e ognuna di queste cose è fatale per un renderer. Il QC di ADM non è ascolto: è verifica di integrità referenziale.

1. Il teatro d'opera è il caso «oggetti più bed» più forte che esista

Prima del contenitore, la geometria. E qui l'Italia ha un vantaggio argomentativo che nessun'altra tradizione registrata possiede: il teatro d'opera è, letteralmente, un dispositivo per distribuire sorgenti sonore su piani spaziali diversi e farle muovere.

Si consideri che cosa succede in una serata qualsiasi in un teatro all'italiana.

L'orchestra sta in buca, cioè sotto il livello della platea e davanti al palcoscenico. Nella conformazione a golfo mistico è anche parzialmente coperta. Rispetto a un ascoltatore in platea l'orchestra è quindi una sorgente estesa, bassa e frontale: la sua elevazione è negativa, la sua estensione laterale è ampia, e la sua immagine non è puntiforme.

I cantanti stanno sul palcoscenico, cioè sopra il livello della buca e dietro di essa. Le voci arrivano da una quota più alta dell'orchestra e da una profondità maggiore. Se in un mix si posiziona la voce alla stessa quota degli archi, si è già distrutto il rapporto spaziale che il pubblico in sala sente come normale.

I cantanti si muovono. Un tenore che avanza al proscenio durante una cabaletta percorre otto o dieci metri di palcoscenico in pochi secondi, cambiando distanza, azimut ed elevazione apparente rispetto a chi ascolta. Non è un effetto: è la messa in scena.

Il coro può essere fuori scena. Il Miserere del Trovatore ha il coro interno, l'organo e Leonora in scena contemporaneamente: tre distanze diverse, di cui una espressamente «da dentro». Cavalleria rusticana apre con la Siciliana cantata da dietro il sipario. Questa non è una scelta di regia: è scritto in partitura.

La banda può suonare da dietro le scene o sul palco. Verdi scrive banda interna e banda sul palco in modo sistematico — la festa in casa di Rigoletto, le trombe in Aida, le marce di Traviata. Una banda che suona dietro un fondale dipinto è una sorgente con distanza vera, filtrata dal materiale scenico, in un punto che non coincide con nessun altro.

Contiamoli: quattro piani spaziali distinti — buca, palcoscenico, fuori scena, retroscena — più sorgenti in movimento, tutti simultaneamente, in un'unica presa. Non esiste, nel repertorio registrato, una giustificazione più forte dell'audio a oggetti con un bed di canali. Il pop la giustifica con l'effetto; l'opera la giustifica con la fedeltà.

1.1 Come lo si scrive davvero

Ecco un'assegnazione di lavoro difendibile per un'opera ripresa dal vivo. Non è l'unica possibile, ma ogni scelta è motivata da una proprietà del renderer, non dal gusto.

La sala come bed. L'acustica del teatro — riverbero, pubblico, il respiro dell'ambiente — è un campo diffuso, non una sorgente localizzabile. Va in un audioPackFormat di tipo DirectSpeakers (typeLabel 0001), tipicamente 7.1.4, cioè il Sistema D (4+5+0) o J (4+7+0) della BS.2051. Motivo tecnico: un campo diffuso non ha una posizione da automatizzare, e forzarlo a oggetto significa chiedere al renderer di panpottare qualcosa che per definizione non ha direzione. In alternativa, o in aggiunta, la sala può essere ripresa in ambisonica di ordine superiore e consegnata come pack HOA (typeLabel 0004).

La buca: bed o piccolo gruppo di oggetti. Qui c'è una decisione vera. Se la ripresa d'orchestra è a coppie principali più spot e il montaggio è già bilanciato, la buca è un secondo bed — un pack DirectSpeakers a 5.1 o 7.1 il cui rendering finisce nel piano medio-basso frontale. Se invece si vuole che la posizione delle sezioni resti governabile a valle — legni al centro, ottoni a destra, arpa a sinistra — la buca diventa da quattro a otto oggetti statici, uno per famiglia, con elevazione negativa e distanza maggiore di zero. La scelta ha una conseguenza concreta: un bed è immutabile in fase di rendering, gli oggetti no. Se il committente può chiedere «alza i violoncelli e spostali un po'», servono oggetti.

Ogni interprete principale come oggetto in movimento. Un audioObject per ruolo, ciascuno con un audioPackFormat di tipo Objects (typeLabel 0003) e una sequenza reale di audioBlockFormat con automazione di posizione. «Reale» significa: derivata da come il cantante si è effettivamente mosso in quella recita, non un panning inventato in post. Se si dispone di un sistema di tracking, la traiettoria è già lì; se non si dispone, la si ricostruisce dal video di sala con le scene come riferimento. Un oggetto statico su un personaggio che si muove è una bugia che si sente.

Il coro come pack, non come oggetti individuali. Sessanta coristi non sono sessanta oggetti. Sono uno o due pack — coro in scena, coro interno — perché ciò che conta è l'estensione e la posizione del blocco, non la localizzazione del singolo. Il coro interno merita però un audioObject proprio, con distanza e occlusione proprie: è a tutti gli effetti una sorgente in un'altra stanza.

La banda interna come oggetto con distanza vera. Un oggetto singolo (o un pack di due-tre oggetti se la banda è larga), con distance maggiore di quella di qualsiasi cantante e una posizione fuori dal perimetro della scena. È il punto in cui il modello a oggetti paga di più, perché la banda entra e esce: il suo audioObject ha uno start e una duration che non coprono l'intero atto, e questo è esattamente il caso d'uso per cui gli attributi esistono.

2. Tre tipi di audio, e perché la distinzione decide il formato

Riformuliamo quanto sopra nei termini della Raccomandazione.

Audio a canali (channel-based). Ogni traccia è assegnata a una posizione fissa di altoparlante. Lo stereo è channel-based; lo sono il 5.1 e il bed 7.1.4. La posizione è incorporata nell'identità del canale: la traccia 3 è il centrale, ed è il centrale su qualunque impianto la riproduca. La BS.2051 formalizza questo per i sistemi avanzati, definendo i layout come conteggi di strati Upper + Middle + Bottom: il Sistema A è 0+2+0 (stereo), il B 0+5+0 (5.1), il D 4+5+0, il J 4+7+0 e l'H 9+10+3, cioè il 22.2. In ADM è la typeDefinition DirectSpeakers, typeLabel 0001. La sala del teatro sta qui.

Audio a oggetti (object-based). Un segnale mono (o un pack multicanale) più metadati di posizione che cambiano nel tempo. È il renderer a decidere quali altoparlanti reali lo riproducono, e come, in base al layout effettivamente presente in sala. Nulla nella traccia presuppone un altoparlante. È la typeDefinition Objects, typeLabel 0003. Il soprano che attraversa il palcoscenico sta qui, e non può stare altrove.

Audio a scena (scene-based). In pratica ambisonica di ordine superiore: l'intero campo sonoro codificato come insieme di componenti armoniche sferiche. Nessuna componente corrisponde da sola a una direzione; la direzione emerge dalla combinazione lineare. È HOA, typeLabel 0004. Il riverbero della sala può stare qui. ADM definisce inoltre Matrix (0002) per segnali matriciati come Mid-Side o Lt/Rt e Binaural (0005) per coppie già pronte per cuffia.

L'audio a canali dice al file dove sono gli altoparlanti; l'audio a oggetti si rifiuta di indovinarlo; l'audio a scena descrive il campo invece delle sorgenti.

Non è tassonomia fine a sé stessa. Un deliverable a canali è abbastanza autodescrittivo da sopravvivere come WAV nudo: basta azzeccare l'ordine dei canali e suona. Un deliverable a oggetti o a scena è privo di significato senza i suoi metadati: l'audio è un mucchio di flussi mono indifferenziati, e l'ADM è l'unica cosa che dica il contrario. Un'opera consegnata come ventotto tracce senza XML non è un'opera imperfetta: è rumore ordinato in modo arbitrario. Questa asimmetria è l'intera ragione d'essere di BW64 e ADM, ed è l'intera ragione per cui il QC immersivo è più difficile del QC stereo.

3. BW64: che cos'è, e perché serve proprio all'opera

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 quello è il tetto rigido sia del file nel suo complesso sia del chunk data al suo interno.

Facciamo l'aritmetica, perché in Italia questo numero ha una conseguenza immediata.

Per lo stereo a 48 kHz / 24 bit la portata è 2 × 3 × 48 000 = 288 000 byte al secondo. Il limite di 4 GB cade a 4 294 967 296 ÷ 288 000 ≈ 14 913 secondi, cioè 4 ore e 8 minuti. Irrilevante.

Per un semplice bed 7.1.4 — dodici canali — a 48 kHz / 24 bit la portata è 12 × 3 × 48 000 = 1 728 000 byte al secondo. Il limite cade a 4 294 967 296 ÷ 1 728 000 ≈ 2 485,5 secondi, cioè 41 minuti e 25 secondi. Si legga di nuovo: quarantun minuti. Il primo atto di Otello dura di più. Il secondo atto di Tosca dura di più. Con il solo bed, senza un singolo oggetto, un atto d'opera non ci sta in un WAV.

Alziamo a un master realistico: bed 7.1.4 più sedici oggetti = ventotto tracce, a 96 kHz / 24 bit. Portata 28 × 3 × 96 000 = 8 064 000 byte al secondo. Il limite di 4 GB cade a 532,6 secondi: otto minuti e cinquantatré secondi. Un'opera intera di tre ore e mezza in questa configurazione occupa 12 600 × 8 064 000 = 101 606 400 000 byte, cioè circa 101,6 GB — 23,7 volte il limite RIFF.

L'EBU affrontò per prima il problema con RF64 (EBU Tech 3306). L'ITU ne ha poi portato avanti il lavoro come Raccomandazione ITU-R BS.2088, Long-form file format for the international exchange of audio programme materials with metadata, cioè BW64. La BS.2088 è esplicita sul meccanismo: «The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file» — l'identificatore BW64 sostituisce RIFF nei primi quattro byte — e i vecchi campi a 32 bit diventano bandiere 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 conviene dirlo senza giri di parole:

BW64 non allarga i campi di dimensione di RIFF: li riempie con 0xFFFFFFFF come sentinella e mette le dimensioni vere a 64 bit in un chunk ds64 che deve stare per primo nel file.

BW64 si capisce meglio come terza generazione di una sola linea genealogica. RIFF/WAVE ha dato il contenitore a chunk. Broadcast Wave (BWF, EBU Tech 3285) ha aggiunto il chunk bext — originator, riferimento di timecode, coding history — trasformando il WAV in un formato di scambio broadcast. BW64 conserva tutto questo, aggiunge l'indirizzamento a 64 bit e aggiunge i chunk che trasportano l'ADM. 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.

4. Il layout dei chunk, in concreto

Un file BW64, secondo la BS.2088, contiene almeno <ds64-ck>, <fmt-ck>, <chna-ck>, <axml-ck> (con <bxml-ck> e <sxml-ck> come vettori alternativi di metadati) e <wave-data>.

4.1 ds64 — la tabella delle dimensioni a 64 bit

Deve essere il primo chunk dopo la firma BW64, perché un lettore deve conoscere le dimensioni vere prima di poter percorrere qualunque altra cosa. I suoi campi sono metà a 32 bit di quantità a 64 bit:

Il nucleo fisso è quindi di 4 + 4 + 8 + 8 + 8 + 4 = 36 byte, più la tabella.

La table[] conta più di quanto sembri. Un chunk axml che descriva migliaia di oggetti con automazione campione-accurata può a sua volta avvicinarsi ai 4 GB o superarli; la tabella è il modo in cui un chunk diverso da data dichiara una dimensione a 64 bit. Per un'opera con automazione fitta su dodici ruoli questo non è teorico.

4.2 fmt — la descrizione dell'essenza

Chunk WAVE standard: formato campione, frequenza di campionamento, numero di canali, bit per campione, block align. È l'unica affermazione autorevole su quanti canali interleaved ci siano davvero in data. Tutto il resto è metadato a proposito di quei canali, e i metadati possono mentire.

4.3 chna — la tabella di allocazione dei canali

chna è il ponte fra le tracce fisiche e l'ADM. Si apre con:

• ckID — 4 byte, 'chna'
• ckSize — 4 byte
• numTracks — 2 byte, tracce nel file
• numUIDs — 2 byte, voci audioTrackUID che seguono

Poi un array piatto di voci audioID a larghezza fissa. Ogni voce è esattamente 40 byte:

2 + 12 + 14 + 11 + 1 = 40. Si controllino i conteggi di caratteri: ATU_00000001 sono quattro caratteri di prefisso più otto cifre esadecimali = 12; AT_00031001_01 sono tre più otto più tre = 14; AP_00031001 sono tre più otto = 11. Le larghezze non sono indicative: sono ASCII a larghezza fissa, e un writer che emette un UID di tredici caratteri non ha prodotto una tabella leggermente anomala, ha prodotto una tabella corrotta — perché ogni voce successiva risulterà disallineata di un byte e il parser leggerà spazzatura da lì in poi.

Facciamo il conto per il nostro master d'opera a ventotto tracce, ipotizzando un audioTrackUID per traccia: 4 + 4 + 2 + 2 + (28 × 40) = 1 132 byte di chunk totale, con il campo ckSize che vale 2 + 2 + 1 120 = 1 124. Con centoventotto tracce: 4 + 4 + 2 + 2 + (128 × 40) = 5 132 byte, ckSize = 5 124. Se il vostro chna non è di 8 byte più ckSize, e se ckSize meno 4 non è divisibile per 40, avete già trovato l'errore senza aprire l'XML.

Si noti anche la convenzione degli identificatori: i valori fino a 0x0FFF rimandano alle definizioni comuni dell'ADM — i formati di canale e di pack predefiniti — mentre da 0x1000 in su indicano definizioni personalizzate che devono essere presenti nel chunk axml. Un packRef AP_00010003 è 5.1 per definizione comune e non ha bisogno di XML; AP_00031001 è un pack di oggetti personalizzato e senza XML resta appeso nel vuoto.

Un track UID è il numero di matricola che il file assegna all'identità di una traccia fisica, ed esiste proprio perché una traccia può legittimamente cambiare ciò che trasporta a metà programma.

Quest'ultimo punto spiega perché numUIDs può superare numTracks. La guida EBU annota che, quando «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» — gli elementi audio di una traccia possono essere definiti diversamente nel corso del file, e allora ci sarà un UID diverso per ogni definizione. Un trackIndex può quindi comparire in più voci. In teatro è la norma, non l'eccezione: lo stesso microfono di scena che nel primo atto serve il basso serve nel terzo atto il baritono, e sono due definizioni diverse della stessa traccia fisica. Gli strumenti di QC che assumono un UID per traccia bocciano file corretti.

4.4 axml — l'ADM vero e proprio

Un documento XML in UTF-8 che contiene l'albero <audioFormatExtended>. È testo, è ispezionabile, ed è dove vive praticamente ogni guasto interessante. Corollario per un catalogo italiano: i nomi degli elementi (audioProgrammeName, audioObjectName) sono testo libero UTF-8, quindi non c'è alcuna ragione tecnica per scrivere Citta invece di Città o E invece di È. Vale però l'abitudine di verificare la codifica reale del file e non la dichiarazione in testata: un XML dichiarato UTF-8 ma scritto in Latin-1 da una catena di strumenti anziana trasforma «à» in mojibake, e alcuni parser abbandonano la lettura dell'intero documento su quel solo carattere. Nei file italiani il rivelatore più affidabile è la «è» accentata in un audioProgrammeName; il secondo è l'apostrofo tipografico «’» (U+2019) che qualcuno inserisce copiando da un word processor.

4.5 data — il PCM interleaved

Campioni interleaved semplici, esattamente come in WAV. Niente in data sa alcunché di oggetti.

4.6 Ordine

ds64 sempre per primo. fmt prima di data. 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», i metadati XML avranno probabilmente lunghezza ignota. Un file con axml in coda non è malformato; un lettore che scandisce solo il primo megabyte riferirà però che l'ADM non c'è affatto. Questo singolo fatto spiega una quota sorprendente delle segnalazioni «il mio file non ha metadati» — e spiega perché sia sensato, prima di allarmarsi, cercare la stringa axml in tutto il file e non solo in testa.

5. Il modello a oggetti ADM, e il cantante che cammina

La BS.2076 divide il modello in due metà. La parte di formato «describes the technical nature of the audio so it can be decoded or rendered correctly» e può essere scritta prima che l'audio esista. La parte di contenuto descrive «the language of dialogue, the loudness, etc.» e può essere completata solo quando i segnali esistono. Capire a quale metà appartiene un elemento dice a quale stadio della produzione è entrato un dato errore.

La gerarchia, dall'alto:

• audioProgramme — una presentazione completa. Referenzia uno o più audioContent. Per noi: l'opera.
• audioContent — una componente con senso editoriale: uno stem, una versione linguistica. Per noi: «Orchestra», «Voci», «Coro», «Ambiente sala».
• audioObject — la giunzione fra intento editoriale e formato tecnico. Porta tempo di inizio e durata, e referenzia zero o più audioPackFormat, zero o più audioObject annidati e zero o più audioTrackUID. È qui che il contenuto incontra l'essenza. Per noi: «Violetta», «Banda interna», «Coro fuori scena».
• audioPackFormat — un gruppo di canali che stanno insieme: un bed 7.1.4, una coppia stereo, un insieme HOA di ordine dato. Referenzia audioChannelFormat e può annidare altri pack.
• audioChannelFormat — il comportamento di un canale nel tempo. Contiene uno o più audioBlockFormat.
• audioBlockFormat — l'atomo. Per gli Objects: posizione (azimuth/elevation/distance oppure cartesiane X/Y/Z), guadagno, dimensione, diffusione, più rtime e duration. Un oggetto fermo è un blocco solo; un oggetto in movimento è una sequenza.
• audioTrackUID — la foglia, e l'unico elemento che corrisponde a una traccia fisica. Porta attributi opzionali sampleRate e bitDepth e referenzia un audioTrackFormat e un audioPackFormat.

audioStreamFormat e audioTrackFormat stanno fra channel format e track UID e descrivono la codifica del flusso. La BS.2076-3 osserva che per il PCM sono di fatto ridondanti — «the audioStreamFormat and the audioTrackFormat should be omitted» — ma avverte che i lettori «should be aware that existing ADM files (based on Recommendation ITU-R BS.2076-2 and earlier) for PCM audio may contain» quegli elementi. Entrambe le forme sono legali. Un validatore che ne pretenda una sola sbaglia sull'altra.

L'ADM è un grafo di riferimenti, non un documento annidato, e ogni guasto serio di consegna è un arco spezzato in quel grafo.

5.1 Il cantante che avanza al proscenio

Ecco il punto in cui il modello smette di essere astratto. Un soprano che avanza durante un'aria è il caso da manuale di una sequenza di audioBlockFormat variabile nel tempo.

Supponiamo un movimento di otto secondi dal fondo del palcoscenico al proscenio, descritto con blocchi da 100 ms: ottanta blocchi, ciascuno con il proprio rtime, la propria duration e la propria terna di posizione. La distance scende, l'elevazione apparente cala leggermente man mano che la sorgente si abbassa nel campo visivo dell'ascoltatore, l'azimut si stringe verso il centro. Il primo blocco parte a 00:00:00.00000 relativo all'oggetto, non al file.

Quel «relativo all'oggetto» è la trappola numero uno. La guida EBU è netta: «The start (rtime) of the audioBlockFormat is relative to the start of the audioObject», mentre «The start attribute corresponds to the start time of the object relative to the start of the file» (EBU ADM Guidelines — Timing). Due sistemi di riferimento diversi che convivono nello stesso documento. Un writer che scriva gli rtime dei blocchi in tempo assoluto di file produce, per una banda interna che entra al minuto dodici e mezzo, blocchi con rtime di 00:12:30.00000 dentro un oggetto la cui duration è di novanta secondi. Il renderer non ha modo di sapere che è un errore: o blocca tutto sul primo blocco, o non rende nulla. In entrambi i casi il file «si apre».

La trappola numero due è la contiguità. Se un blocco della sequenza ha duration sbagliata — 1 secondo invece di 100 ms perché qualcuno ha scritto 00:00:01.00000 invece di 00:00:00.10000 — tutto ciò che segue slitta di 900 ms rispetto alla musica, oppure si apre un buco. E qui l'errore è udibile in un modo molto specifico: la voce si teletrasporta. Il renderer, arrivato alla fine di un blocco senza un blocco successivo contiguo, o tiene l'ultima posizione o salta a quella nuova, e in entrambi i casi un movimento continuo di otto secondi diventa uno scatto. In un'aria, con un'orchestra sotto e una sala intorno, questo non suona come un difetto di metadato: suona come un difetto di missaggio, e chi ascolta darà la colpa al fonico. È il motivo per cui vale la pena verificare la contiguità dei blocchi con uno script prima di consegnare, e non dopo la contestazione.

La trappola numero tre riguarda la conversione di frequenza di campionamento. Se gli rtime sono stati calcolati sui campioni di un progetto a 96 kHz e il master viene poi convertito a 48 kHz dopo l'authoring ADM, ogni tempo espresso in campioni diventa falso di un fattore due. Regola operativa: nessun SRC dopo l'authoring, mai.

6. Cori spezzati: musica composta per uno spazio tridimensionale, secoli prima dello standard

C'è una seconda tradizione italiana che il modello ADM descrive con precisione quasi imbarazzante, ed è più antica dell'opera.

Nella prassi policorale veneta e poi italiana in generale, due o più cori si rispondono da posizioni fisicamente separate dell'edificio — le cantorie, i pulpiti, le tribune d'organo — cioè da punti che stanno sopra l'ascoltatore e su lati opposti. Il repertorio nasce da lì: i Salmi spezzati di Adrian Willaert sono del 1550, e le Sacrae Symphoniae di Giovanni Gabrieli sono del 1597, con la Sonata pian' e forte in cui i due cori strumentali sono distinti anche timbricamente (Britannica). Nel Sud e nelle isole la stessa idea sopravvive nella pratica dei cori battenti, con formazioni che si rispondono da posizioni opposte.

Il punto tecnico è semplice e forte: questa musica è stata composta per una distribuzione spaziale che il formato stereo non è in grado di rappresentare, e lo era quattro secoli prima che lo standard esistesse. Ridurre un mottetto a doppio coro a un'immagine stereo non è una scelta conservativa: è la cancellazione della sua idea costitutiva.

Come si scrive in ADM:

• ogni coro un audioObject distinto, con un audioPackFormat di oggetti (o un piccolo pack a tre-quattro oggetti se il coro è largo e si vuole preservarne l'estensione), con elevazione positiva reale — le cantorie stanno in alto — e azimut opposti;
• l'organo — o gli organi, dove ce ne sono due — come oggetto proprio, alla sua quota e alla sua distanza;
• l'edificio come bed o come pack HOA, perché in una basilica il riverbero non è un effetto ma metà del materiale sonoro;
• se i cori sono più di due, si valuti l'annidamento: audioPackFormat può contenere altri pack, e un «Coro I» con quattro sotto-oggetti è più governabile di quattro oggetti fratelli senza gerarchia.

C'è una precisazione onesta da fare, e va fatta. La ricostruzione romantica del coro spezzato — due cori fissi che si fronteggiano sempre dalle due cantorie di San Marco — è contestata dalla musicologia: il saggio di David Bryant The 'cori spezzati' of St Mark's: myth and reality in Early Music History discute proprio quanto la prassi documentata corrisponda all'immagine tramandata (Cambridge Core). Per chi fa audio la conseguenza è pratica: la disposizione va decisa e documentata per la singola esecuzione — nell'audioProgrammeName e nei nomi degli oggetti — invece di essere ereditata da un'idea generica di «prassi veneziana». Un file ADM che dichiara dove stavano i cori quella sera è un documento; uno che li mette a ±90° perché così si fa non lo è.

Un dettaglio acustico che diventa una scelta di metadato: fra due cantorie separate da una ventina di metri ci sono circa 58 ms di propagazione in aria (a 343 m/s, 20 m ÷ 343 ≈ 0,058 s). Quel ritardo è l'effetto policorale. Se lo si allinea in fase «per pulizia», si distrugge esattamente ciò che l'oggetto dovrebbe codificare. Se si allinea, lo si faccia consapevolmente e lo si annoti nelle note di consegna.

7. Banda e processioni: la sorgente che attraversa la strada

L'altra tradizione italiana che l'audio a oggetti descrive e lo stereo no è quella processionale. Un complesso bandistico che percorre una via durante una festa patronale, una marcia funebre della Settimana Santa meridionale, una banda da giro che attraversa una piazza: la sorgente si sposta attraverso il pubblico, non davanti a esso.

Tre requisiti tecnici, in ordine di frequenza con cui vengono sbagliati.

Primo: l'automazione della posizione deve essere una vera sequenza di blocchi, non un panning finale. Una banda che si avvicina per novanta secondi e si allontana per altri novanta è una traiettoria di tre minuti che passa dietro e a fianco dell'ascoltatore. Con blocchi da 250 ms sono 720 blocchi; con blocchi da 100 ms sono 1 800. Non è un numero spaventoso, ma è un numero che rende concreto il rischio di dimensione dell'axml di cui parla la table[] del ds64.

Secondo: la scelta della cadenza dei blocchi è una decisione, non un default. Blocchi troppo lunghi su una sorgente veloce producono un movimento a scatti anche se ogni singolo blocco è corretto, perché l'interpolazione fra due posizioni distanti è una retta e la traiettoria vera non lo è. Blocchi troppo corti gonfiano l'XML senza guadagno percettivo. Una regola pratica ragionevole: la cadenza va scelta in modo che lo spostamento angolare fra due blocchi consecutivi resti sotto la soglia di localizzazione utile per quel contenuto, e va dichiarata nelle note di consegna insieme al renderer, perché renderer diversi interpolano diversamente.

Terzo: le processioni non hanno un start a zero. La banda entra nel campo di ripresa e ne esce. Il suo audioObject ha start e duration propri, e i blocchi dentro di esso ripartono da 00:00:00.00000 relativo. Ripetiamo il concetto della sezione 5 perché è il singolo errore più caro: chi confonde i due riferimenti temporali produce file che passano ogni controllo strutturale e rendono in silenzio.

8. I guasti tipici del QC, e come si rilevano

8.1 Conteggio canali discordante fra fmt e chna

fmt.nChannels dice 28; chna.numTracks dice 26. Il file è internamente incoerente dai primi due chunk. Di solito è colpa di un bounce che ha cambiato numero di tracce dopo che i metadati erano stati scritti, o di uno strumento conformante che ha eliminato tracce senza riscrivere chna.

Rilevamento: si leggono i due chunk e si confrontano due interi. È il controllo più economico dell'intera pipeline e intercetta una quota sorprendente dei guasti. Si verifichi anche che ogni trackIndex in chna stia fra 1 e fmt.nChannels.

8.2 Track UID orfani

Un UID presente in chna che nessun audioObject referenzia, o un audioTrackUIDRef nell'XML senza voce corrispondente in chna. Il primo caso significa audio che nessuno renderizzerà — la banda interna registrata e mai dichiarata. Il secondo significa metadati che si aspettano una traccia che non c'è.

Rilevamento: si costruisce l'insieme degli UID da chna e quello da axml e se ne prende la differenza simmetrica. Deve essere vuota. L'EBU Tech 3392 esplicita l'intenzione: «If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs.»

8.3 Blocchi con temporizzazione mancante o non monotona

La BS.2076 è inequivocabile: «When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present». L'EBU Tech 3392 stringe la regola alla contiguità — «rtime + duration of an audioBlockFormat should match the rtime of the following block» — con il primo blocco di un oggetto che parte a 00:00:00.00000, nessun blocco più corto di un campione, e la somma delle durate pari alla durata dell'audioObject genitore.

Rilevamento: per ogni audioChannelFormat si percorrono i blocchi nell'ordine del documento verificando che rtime[n] + duration[n] == rtime[n+1]. I guasti si raggruppano in tre forme: buchi (comportamento del renderer indefinito: alcuni tengono l'ultima posizione, altri silenziano), sovrapposizioni (blocchi che si contendono lo stesso istante) e blocchi fuori ordine cronologico, cioè automazione che torna indietro a metà programma. Sul soprano che avanza, tutte e tre suonano come un teletrasporto.

8.4 Frequenza di campionamento o profondità di bit discordanti

audioTrackUID può portare gli attributi sampleRate e bitDepth. Quando contraddicono fmt , si hanno due affermazioni sulla stessa essenza. La posizione dell'EBU Tech 3392 è che questi attributi «Should be ignored if available from the audio essence» — ma non tutti i renderer seguono quell'indicazione, e un file che dice 48 000 in un posto e 96 000 in un altro sarà interpretato in modo diverso da strumenti diversi.

Rilevamento: si confronta fmt con ogni attributo sampleRate/bitDepth nell'XML e si segnala ogni discordanza, anche se nominalmente tollerabile.

8.5 Conform stereo o binaurale mancante, o fuori sincrono

Quasi ogni consegna immersiva richiede un conform stereo — e spesso binaurale — accanto al master immersivo. Il guasto ricorrente non è l'assenza, che è evidente, ma la deriva: il conform è stato reso da una versione precedente, è spostato di qualche frame, o ha un timecode di partenza diverso. Un file stereo in anticipo di 40 ms rispetto al suo genitore immersivo supera il controllo di presenza e fallisce il primo ascolto sincronizzato.

Rilevamento: si confrontano le durate campione per campione, si confronta il timecode di partenza da bext, e si cross-correla il conform con un render nullo del master. Ogni conform che non sia derivabile dal master corrente va considerato sospetto e rifatto, non ricontrollato.

8.6 Metadati che descrivono un bed che nel file non c'è

L'XML dichiara un pack DirectSpeakers 7.1.4 — dodici canali — ma è stato stampato solo il sottoinsieme 5.1, oppure i canali di altezza erano in mute al bounce e sono finiti su disco come nero digitale. Il grafo dei riferimenti è integro; l'audio no.

Rilevamento: i controlli strutturali non intercettano questo caso. Serve analisi dell'essenza: per ogni canale rivendicato da un pack DirectSpeakers, misurare se la traccia contiene segnale. Il nero digitale su un canale di bed dichiarato non è automaticamente un errore — un mix legittimo può lasciare vuoto un canale posteriore alto — ma merita sempre una decisione umana.

Il contenitore può essere perfettamente valido, l'XML perfettamente ben formato, e il deliverable comunque sbagliato; l'unico controllo per un canale di bed vuoto è guardare i campioni.

Un ispettore BW64/ADM gratuito basato su browser è disponibile su mazufa.com: analizza il contenitore e i metadati interamente sul dispositivo di chi lo usa e non carica nulla, il che lo rende utilizzabile su materiale che per contratto non può uscire dall'edificio — condizione ordinaria per una registrazione teatrale.

9. Loudness immersivo: che cosa è specificato davvero

Qui conviene separare con cura ciò che è pubblicato da ciò che circola.

Che cosa specifica la ITU-R BS.1770. Attenzione all'edizione: la BS.1770-5, di novembre 2023, è quella in vigore; la BS.1770-4 (ottobre 2015) è superata, benché resti l'edizione citata dalla maggior parte dei misuratori installati. Quando si scrive una nota di consegna, si nomini la -5.

La BS.1770 definisce la ponderazione K: un filtro a due stadi, prima uno shelving alto (il filtro «head», che modella una testa sferica rigida) e poi un passa-alto RLB. Il guadagno della curva a 1 kHz è +0,698 dB (lineare 1,0836). La misura usa blocchi di gating da 400 ms con sovrapposizione del 75 %, un gate assoluto che scarta i blocchi sotto −70 LUFS, e un gate relativo calcolato dalla media dei blocchi sopravvissuti al gate assoluto, poi spostato di −10 LU. Quel gate relativo si calcola sui blocchi sopravvissuti, non sulla media non gated: è una distinzione che le implementazioni sbagliano abbastanza spesso da meritare di essere ripetuta.

La ponderazione dei canali nell'algoritmo di base è 1,0 (0 dB) per L, R e C e 1,41 (≈ +1,5 dB) per Ls e Rs, con l'LFE escluso. L'algoritmo base è definito «from one to five channels». La BS.1770-5 estende oltre questo limite nei suoi allegati, coprendo i sistemi avanzati della BS.2051 — altoparlanti in posizioni arbitrarie e canali di altezza — e l'audio a oggetti, che deve essere renderizzato prima di poter essere misurato.

Il loudness immersivo non è una proprietà del file: è una proprietà di un render, e cambiando il layout di destinazione cambia il numero.

È questa la differenza sostanziale rispetto allo stereo. Un master stereo ha un valore di loudness. Un master a oggetti ne ha tanti quanti sono i suoi bersagli di rendering, e l'unico modo onesto di dichiarare una cifra è nominare il layout su cui è stata misurata e il renderer usato. La ITU-R BS.2127 definisce il renderer ADM di riferimento, e il suo fratello open source, l'EBU ADM Renderer (EBU Tech 3388), è il modo pratico per ottenere un numero riproducibile.

Conseguenza concreta per l'opera: la stessa serata renderizzata sul Sistema B (0+5+0) e sul Sistema J (4+7+0) produce due distribuzioni di energia diverse. Nel primo caso tutto ciò che sta sopra il piano dell'ascoltatore — la sala, le cantorie, le voci in quota — viene riversato nel piano orizzontale; nel secondo no. Nessuno dei due è «il file»: sono due render. Chi consegna un solo numero senza dire su che cosa è stato misurato non ha consegnato un'informazione.

Documenti EBU correlati. L'EBU Tech 3341 definisce il comportamento dei misuratori: momentary a 400 ms, short-term a 3 s. L'EBU Tech 3342 definisce il Loudness Range (LRA), che usa un gate relativo di −20 LU — non −10 LU; usare −10 per l'LRA è un bug di implementazione comune. La EBU R 128 fissa il target broadcast di programma a −23 LUFS: è una prassi di normalizzazione broadcast, non una specifica per lo streaming musicale.

True peak. Si misura su segnale sovracampionato (almeno 4× secondo la BS.1770, meglio 8×). Il picco di campione non è il true peak: i picchi inter-campione possono superare il valore del campione più alto. Su materiale d'opera, con transitori d'ottone e attacchi di coro, la differenza è tutt'altro che accademica.

Che cosa è pubblicato per la musica. Per la musica stereo a canali, Spotify pubblica un target integrato di −14 LUFS e un tetto di true peak di −1 dBTP, che si stringe a −2 dBTP per i master più forti di −14 LUFS (Spotify). L'AES TD1008 raccomanda −16 LUFS per la musica; la cifra di −18 LUFS contenuta nello stesso documento riguarda i contenuti parlati (notiziari, talk, radiodramma), e presentare −18 come target musicale è un errore frequente e serio.

Che cosa non è pubblicato. Nessun servizio di streaming musicale pubblica un target di loudness integrato per la consegna immersiva. Circolano numeri nei forum e nei materiali di formazione dei produttori di software; alcuni sono plausibili e alcuni sono probabilmente giusti. Nessuno di essi è una specifica pubblicata, e questo documento non ne ripeterà nessuno come se lo fosse.

Va aggiunta la stessa cautela per lo stereo: Apple Music, YouTube Music, Amazon Music, TIDAL e Deezer non pubblicano alcun target di normalizzazione. Le cifre che circolano per questi servizi (Apple ≈ −16, YouTube Music ≈ −14, Amazon ≈ −14, TIDAL ≈ −14, Deezer ≈ −15) sono ampiamente riportate ma non pubblicate dal servizio, e non vanno mai usate per calcolare una variazione di guadagno.

Un ultimo punto, perché in ambito classico è ricorrente. I servizi normalizzano in riproduzione: un master più forte del target viene abbassato della differenza. La normalizzazione verso l'alto esiste ma è condizionata: Spotify dichiara che «Positive gain is applied to softer masters so the loudness level is -14 dB LUFS» e insieme che «We consider the headroom of the track, and leave 1 dB headroom for lossy encodings to preserve audio quality». Quindi un master silenzioso con picchi alti può non essere alzato fino al target. Non si scriva «i master silenziosi non vengono alzati» (è falso) né «i master silenziosi vengono sempre portati al target» (è altrettanto falso). La conseguenza per un master d'opera, che ha un LRA naturalmente ampio, è che comprimere per «arrivare al numero» non compra volume: compra appiattimento.

Sui sistemi proprietari. Dolby Atmos è una tecnologia proprietaria e su licenza di Dolby Laboratories, e Sony 360 Reality Audio è un sistema proprietario costruito su MPEG-H. I loro requisiti di consegna sono stabiliti dai rispettivi titolari e cambiano senza riferimento ai calendari di ITU o EBU. Nulla in questo documento costituisce una dichiarazione dei requisiti di quelle aziende, e non si rivendica né si sottintende alcuna affiliazione, certificazione o approvazione. Dove un licenziante pubblica un requisito, si legga e si citi la documentazione corrente del licenziante.

10. La posizione onesta sulla realtà italiana

Va detto chiaramente, perché il resto del documento perde senso senza: fuori da poche strutture di post-produzione, il monitoraggio immersivo negli studi musicali italiani è raro. La maggior parte di chi legge queste righe non ha una regia con dodici altoparlanti calibrati, e non l'avrà a breve. Molti lavorano in stereo con un controllo binaurale in cuffia.

Questo non rende inutile il resto. Sposta però il valore da un punto a un altro, e vale la pena essere espliciti su dove.

Ciò che non si può fare senza sala immersiva: giudicare l'equilibrio spaziale finale, decidere quanta energia mandare ai canali di altezza, verificare se un oggetto in movimento «funziona» percettivamente. Queste sono decisioni di ascolto e richiedono ascolto.

Ciò che si può fare integralmente senza sala immersiva, ed è ciò che fa respingere le consegne:

• verificare che la firma del file sia BW64 e non RIFF;
• verificare che ds64 sia primo e che le sue dimensioni a 64 bit coincidano con quelle reali su disco;
• verificare che fmt.nChannels sia uguale a chna.numTracks;
• verificare che ckSize di chna meno 4 sia divisibile per 40, e che ogni voce sia allineata;
• verificare che ogni riferimento nel grafo ADM risolva, in entrambe le direzioni;
• verificare che ogni sequenza di blocchi sia contigua e monotona;
• verificare che i canali dichiarati contengano davvero segnale;
• verificare che i conform stereo e binaurale siano derivati dal master corrente.

Nessuno di questi controlli richiede un altoparlante. Tutti si fanno leggendo il file. In una realtà dove l'ascolto immersivo è raro, il contributo tecnico serio consiste esattamente in questo: consegna corretta, metadati corretti, e verifica di un file che non si è in condizione di ascoltare come si dovrebbe. Chi sa fare questo lavoro rende un servizio reale anche se lavora in una stanza con due monitor.

E c'è un corollario culturale che vale la pena non perdere. L'Italia produce ogni anno una quantità enorme di registrazioni di teatro, di musica sacra in edifici storici e di feste con banda: materiale la cui geometria è il contenuto. È esattamente il repertorio per cui l'audio a oggetti è stato pensato, e a differenza del pop non ha bisogno di essere convinto che serva.

11. Checklist di consegna

Da percorrere in quest'ordine. Prima i controlli strutturali: sono rapidi e invalidano tutto ciò che sta a valle.

Contenitore

1. I primi quattro byte sono BW64. Se sono RIFF, il file è un WAV normale e non può superare i 4 GB.
2. ds64 è il primo chunk dopo la firma, e le sue dimensioni a 64 bit corrispondono a quelle reali del file e del chunk data su disco.
3. Ogni chunk non-data fuori misura ha una voce ChunkSize64 nella tabella di ds64.
4. axml è stato cercato in tutto il file, anche dopo data. Non si conclude «nessun ADM» da una scansione parziale.

Essenza

1. Frequenza di campionamento e profondità di bit in fmt corrispondono esattamente alla specifica di consegna. Nessun SRC dopo l'authoring ADM.
2. fmt.nChannels è uguale a chna.numTracks.
3. Ogni trackIndex in chna è nell'intervallo valido e in base 1.

Integrità di chna

1. Ogni voce è esattamente di 40 byte, con i campi a larghezza fissa correttamente riempiti; ckSize − 4 è divisibile per 40.
2. Ogni packRef da 0x1000 in su risolve a una definizione personalizzata presente in axml.
3. I trackIndex ripetuti sono intenzionali (una traccia che cambia legittimamente definizione fra un atto e l'altro), non duplicazioni per errore.

Grafo ADM

1. Ogni audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef e audioTrackUIDRef risolve. Zero archi appesi.
2. Nessun audioTrackUID orfano in nessuna delle due direzioni.
3. Nessun elemento circolare o auto-referenziante.
4. Il typeLabel di ogni audioChannelFormat è coerente con quello dell'audioPackFormat genitore.

Temporizzazione

1. Gli audioChannelFormat multi-blocco portano rtime e duration su ogni blocco.
2. I blocchi sono contigui e monotoni; le durate sommano alla durata dell'audioObject genitore.
3. Ogni oggetto comincia a 00:00:00.00000 relativo all'oggetto, non al file. Verificare esplicitamente gli oggetti a ingresso ritardato: banda interna, coro fuori scena, comprimari che entrano a metà atto.

Contenuto

1. Ogni canale di un bed dichiarato contiene ciò che deve contenere; indagare il nero digitale.
2. Numero di oggetti e configurazione del bed corrispondono alla specifica di consegna.
3. Il timecode di partenza in bext è corretto e coerente su tutti i deliverable dell'insieme.

Render e conform

1. I conform stereo e binaurale sono stati rifatti dal master corrente, non trascinati da una versione precedente.
2. Durate e timecode di partenza coincidono con il master campione per campione.
3. Il loudness è stato misurato su un render nominato, verso un layout BS.2051 nominato, con un renderer nominato e un misuratore BS.1770-5, e tutti e tre sono scritti nelle note di consegna.

Riproducibilità

1. Checksum di ogni deliverable, con il manifest conservato.
2. Sessione e XML ADM archiviati separatamente dal BW64: un XML che si può diffare vale, a distanza di anni, più di un binario che si può solo ri-analizzare.

Un deliverable immersivo non è finito quando suona bene: è finito quando una macchina che non l'ha mai sentito può dimostrare che i suoi riferimenti risolvono.

12. Nota conclusiva

BW64 e ADM sono standard aperti, pubblicati e liberamente leggibili. Nel nostro settore è un'anomalia e conviene sfruttarla: si può leggere la BS.2088 e la BS.2076 di persona, percorrere un chunk chna con quaranta righe di codice, e verificare che cosa un esportatore commerciale abbia davvero scritto invece di fidarsi di quel che dichiarava la sua finestra di dialogo. L'audio immersivo è l'area in cui si concentra ancora la quota maggiore di respingimenti evitabili, e quasi tutti sono errori di integrità referenziale che un validatore intercetta in meno di un secondo.

Per chi in Italia registra opera, musica sacra o banda, questo è il pezzo di lavoro che si può fare fino in fondo anche senza la parte costosa: la sala d'ascolto forse non c'è, ma la parte che fa bocciare la consegna è esattamente la parte che si può controllare da soli, con un parser e un pomeriggio.

La distribuzione con Mazufa è gratuita — nessun costo di caricamento, nessun abbonamento, nessuna tariffa per pubblicazione — e l'unica trattenuta è il 5 % delle royalty ricevute; ogni candidatura completa riceve una revisione umana.

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.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 della Raccomandazione BS.2127 — https://www.itu.int/rec/R-REC-BS.2127
• Report ITU-R BS.2388, Usage Guidelines for the Audio Definition Model — https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BS.2388-3-2018-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, 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 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 (misuratori), EBU Tech 3342 (Loudness Range) — https://tech.ebu.ch
• EBU ADM Guidelines — Timing (rtime relativo all'audioObject) — https://adm.ebu.io/tutorial/timing.html
• EBU ADM Guidelines — chunk CHNA — 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
• EBU ADM Renderer (EAR), I/O BW64 — https://ear.readthedocs.io/en/latest/BW64.html
• libbw64, implementazione di riferimento — https://github.com/ebu/libbw64
• libadm, implementazione di riferimento — 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/

Documentazione dei servizi

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

Contesto musicologico

• David Bryant, The 'cori spezzati' of St Mark's: myth and reality, Early Music History — https://www.cambridge.org/core/journals/early-music-history/article/abs/cori-spezzati-of-st-marks-myth-and-reality/A7A9F78946DE4A5F423F9D160747C2C5
• Singing the Republic: Polychoral Culture at San Marco in Venice (1550–1615) — https://digital.library.unt.edu/ark:/67531/metadc33220/m2/1/high_res_d/dissertation.pdf
• Encyclopædia Britannica, Giovanni Gabrieli (Sacrae Symphoniae, 1597) — https://www.britannica.com/biography/Giovanni-Gabrieli

Ultima revisione: settembre 2026. Gli standard vengono rivisti; prima di citare il numero di una clausola si controlli sempre l'edizione corrente sulle pagine ITU ed EBU indicate sopra.