BW64 en ADM: technische referentie voor het aanleveren van immersieve audio

Voor technici die object- en scènegebaseerde masters klaarmaken, en voor musici die een "immersieve levering" in handen gedrukt kregen met de mededeling dat hij door de QC moet.

Het korte antwoord

Het Audio Definition Model (ADM, Aanbeveling ITU-R BS.2076) is een open metadatamodel dat van elke audiotrack in een bestand vastlegt wat die track is — een luidsprekerkanaal, een bewegend object of een ambisonische component — en hoe die tracks samen één programma vormen. Dat model wordt als XML meegedragen in een BW64-container (Aanbeveling ITU-R BS.2088), een 64-bits uitbreiding van RIFF/WAVE die de 4 GB-grens van de klassieke WAV doorbreekt. Immersieve leveringen zakken zo vaak voor de controle omdat audio en metadata twee losse dingen zijn die tot op de byte met elkaar moeten kloppen, terwijl niets in het formaat dat afdwingt. Een kanaalaantal in fmt dat niet overeenkomt met de chna-tabel, een audioTrackUID waar geen enkel object naar verwijst, een blokformaat waarvan de tijdlijn achteruitloopt, een bed dat in de XML beschreven staat maar nooit naar schijf is weggeschreven — geen enkele golfvormeditor laat dat zien, en elk ervan is dodelijk voor een renderer. ADM-controle is het narekenen van verwijzingen, niet luisteren.

1. Een Nederlands ijkpunt: de beiaard

Begin niet bij het formaat maar bij een instrument dat de vraag zelf stelt. De beiaard is het meest overtuigende immersieve geval dat er in de Lage Landen bestaat, en waarschijnlijk het meest overtuigende dat er überhaupt bestaat.

Een beiaard is volgens de World Carillon Federation "a musical instrument composed of tuned bronze bells which are played from a baton keyboard", met als norm minstens 23 klokken; instrumenten van vóór 1940 met 15 tot 22 klokken krijgen een aparte aanduiding (carillon.org). De beiaardier bespeelt een stokkenklavier met de vuisten en een pedaal met de voeten. België schreef de beiaardcultuur in 2014 als eerste land in op UNESCO's Register of Good Safeguarding Practices (ich.unesco.org).

Nu de akoestische situatie. De klokken hangen in een klokkenstoel, boven elkaar en naast elkaar, in een toren. Ter grootte-orde: de Utrechtse Domtoren is 112,32 m hoog en de beiaard telt sinds de restauratie van 1972 vijftig klokken, waarvan er vierendertig nog van de gebroeders Hemony zijn (Wikipedia, Dom Tower of Utrecht). De luisteraar staat op het plein, dus onder en buiten het instrument. Het geluid verlaat de toren door de galmgaten en straalt naar beneden en naar buiten, een stedelijke ruimte in met harde gevels aan alle kanten.

Zet dat naast een piano-opname en het verschil is categorisch. Bij de piano is hoogte een artefact van microfoonplaatsing. Bij de beiaard is hoogte de positie van de bron. De grote bassklokken hangen typisch lager en zwaarder in de stoel, de kleine discantklokken hoger en dichter bij de galmgaten; de spreiding van het instrument over de verticale as is geen effect en geen zaalreflectie, maar de constructie van het instrument zelf. Daar komt afstand bij: tientallen meters, met echte luchtdemping in de hoogte en echte vertraging. En daar komt de stad bij — het plein kaatst het terug in een patroon dat per gevel verschilt.

Hoe je dit zou opzetten in ADM. De eerlijke aanpak is gelaagd:

• Een bed (DirectSpeakers, typeLabel 0001) van het plein: het diffuse veld, de gevelreflecties, het stadsrumoer, de wind. Dit is het akoestische decor en het hoort thuis in een 7.1.4- of 9.1.6-bed, want het is nergens in het bijzonder.
• Een objectgroep (Objects, typeLabel 0003) voor de toren: geen object per klok — dat is niet houdbaar en niet nodig — maar een handvol objecten die de klokkenstoel in registers verdeelt: bas, midden, discant, elk op de elevatie en azimut waar dat register daadwerkelijk hangt, elk met een eigen distance en een eigen size, want een luidende bronzen klok van zevenduizend kilo is geen puntbron.
• Eventueel een HOA-laag (0004) als het plein met een ambisonische opstelling is vastgelegd; dat is dan het veld, niet de bron.

De reden dat dit niet in een horizontale opstelling past, is niet esthetisch maar meetkundig. Een 5.1- of 7.1-opstelling heeft alle luidsprekers op oorhoogte. Elke bron die je daarin plaatst, komt uit het horizontale vlak. De beiaard is niet in het horizontale vlak. Een renderer die een object op elevatie +45° naar een 0+5+0-opstelling (BS.2051 systeem B) moet brengen, kan alleen maar wat elke goede renderer doet: hem naar beneden projecteren en de hoogte-informatie weggooien. De klok komt dan uit een luidspreker naast u in plaats van uit een toren boven u, en het verschil tussen een beiaardopname en een opname van klokgeluid is precies dat. In een 4+5+0-opstelling (systeem D) of 4+7+0 (systeem J) blijft het onderscheid bestaan, omdat er een bovenlaag is die de elevatie kan dragen.

De praktische consequentie voor uw metadata: leg de elevatie vast als positie, niet als panning-smaak, documenteer in audioObject-namen welk register waar hing, en zorg dat de stereoconform die u meelevert een bewuste artistieke reductie is en niet een automatische downmix waar niemand naar geluisterd heeft. De downmix is namelijk het enige wat de meeste luisteraars zullen horen.

2. Drie soorten audio, en waarom het onderscheid het formaat bepaalt

Vrijwel elk aanleverprobleem begint met verwarring over welke van drie dingen een track eigenlijk is.

Kanaalgebaseerde audio koppelt elke track aan een vaste luidsprekerpositie. Stereo is kanaalgebaseerd, 5.1 ook, en een 7.1.4-bed ook. De positie zit in de identiteit van het kanaal gebakken: track 3 is het centerkanaal, en dat is hij op elk systeem. ITU-R BS.2051 formaliseert dit voor geavanceerde geluidssystemen en beschrijft opstellingen als Upper + Middle + Bottom: systeem A is 0+2+0 (stereo), systeem B 0+5+0 (5.1), systeem D 4+5+0, systeem J 4+7+0 en systeem H 9+10+3, de 22.2-configuratie. In ADM is dit typeDefinition DirectSpeakers, typeLabel 0001.

Objectgebaseerde audio draagt een monosignaal (of een pack van meerdere kanalen) plus positiemetadata die in de tijd mag veranderen. De renderer bepaalt welke fysieke luidsprekers het weergeven, op grond van de opstelling die er in de ruimte werkelijk staat. Niets aan de track veronderstelt een luidspreker. Dit is typeDefinition Objects, typeLabel 0003.

Scènegebaseerde audio, in de praktijk hogere-orde ambisonics, codeert het hele geluidsveld als een verzameling sferisch-harmonische componenten. Geen enkele component komt op zichzelf overeen met een richting; richting ontstaat pas uit de lineaire combinatie. Dit is HOA, typeLabel 0004. ADM kent daarnaast Matrix (0002) voor gematrixeerde signalen zoals Mid-Side of Lt/Rt, en Binaural (0005) voor koptelefoonklare paren.

Kanaalgebaseerde audio vertelt het bestand waar de luidsprekers staan; objectgebaseerde audio weigert te gokken; scènegebaseerde audio beschrijft het veld in plaats van de bronnen.

Dit is geen indeling om de indeling. Een kanaalgebaseerde levering beschrijft zichzelf voldoende om als kale WAV te overleven: zet de kanaalvolgorde goed en hij speelt. Een object- of scènegebaseerde levering is betekenisloos zonder metadata — de audio is dan een stapel ononderscheiden monostromen, en de ADM is het enige wat iets anders beweert. Die asymmetrie is de hele bestaansreden van BW64 en ADM, en de hele reden dat immersieve controle lastiger is dan stereocontrole.

3. Het orgel op de westgalerij: één instrument, ruimtelijk uit elkaar gelegd

Het tweede Nederlandse geval is het kerkorgel, en het is bijna even overtuigend als de beiaard — maar om een andere reden.

Een groot Noord-Nederlands orgel is geen kast. Het is een verzameling werken die volgens het werkprincipe fysiek uit elkaar zijn gezet, elk met een eigen positie ten opzichte van de speler en de kerk. Het rugpositief hangt aan de galerijbalustrade, letterlijk achter de rug van de organist en het dichtst bij de kerk. Het hoofdwerk staat in de hoofdkas, hoger en verder naar achteren. Het bovenwerk of borstwerk zit daar weer boven of onder in, meestal gezwelder of in elk geval verder weg klinkend. De pedaaltorens staan links en rechts als aparte torens, met de zwaarste pijpen het verst uit elkaar.

Dat is niet decoratief. Het uit elkaar zetten van de werken is het idee: registerwisselingen worden ook plaatswisselingen, en een dialoog tussen rugpositief en hoofdwerk is een dialoog tussen twee punten in de ruimte. Wie zo'n instrument in een stereopaar vangt, houdt de klankkleur over en gooit de architectuur weg. De registratie is dan nog te horen, maar het waarom van de registratie niet meer.

En er is een tweede as. De galerij ligt hoog in het schip. De luisteraar in de banken zit eronder. Ook hier is elevatie geen effect maar de plaats van de bron, en ook hier is er echte afstand — een schip van vijftig, zestig meter, met een nagalmtijd die in de grote Nederlandse kerken makkelijk boven de vier seconden komt en die in de laagste octaven nog langer doorloopt.

Hoe je dit opzet. Anders dan bij de beiaard. Hier is de verleiding om objecten te gebruiken groot, en meestal is dat verkeerd:

• Het orgel klinkt in de zaal, en de zaal is de helft van het instrument. Neem het schip als bed op — een hoofdopstelling die de nagalm en de hoogte draagt.
• Gebruik objecten alleen voor de werken die daadwerkelijk als aparte bron worden waargenomen: rugpositief als één object vooraan-onder, hoofdwerk als één object hoger en verder, pedaaltorens als twee objecten links en rechts buiten. Dat zijn vier tot zes objecten, geen veertig.
• Geef de objecten een realistische size en een diffuseness die klopt. Een orgelwerk is een wand van pijpen van meerdere meters breed; als puntbron gerenderd klinkt het als een sample van een orgel, niet als een orgel.
• Zet er geen beweging op. rtime/duration mogen precies één blok zijn per kanaal. Een orgel beweegt niet, en een automatiecurve die "ruimte suggereert" is de snelste manier om een authentieke opname in een demo te veranderen.

Het contrast met de beiaard is instructief: bij de beiaard is de bron zelf verticaal gespreid en het decor diffuus; bij het orgel is de bron horizontaal én verticaal gespreid over een galerij en is het decor de kerk. Beide gevallen falen op dezelfde manier in een stereopaar, maar om verschillende redenen.

4. De zaal als bed: de Nederlandse en Vlaamse zaaltraditie

Voor klassieke opnames uit de zaaltraditie van deze landen — het Concertgebouw, de Doelen, TivoliVredenburg, het Muziekgebouw aan 't IJ, en aan Vlaamse zijde deSingel, het Concertgebouw Brugge, Flagey — is de bruikbaarste vuistregel de eenvoudigste:

De zaal is het bed. De solisten zijn de objecten. Alles daartussenin is smaak, en smaak hoort in de mix, niet in de metadata.

Een schoenendoosachtige zaal met een lange, gelijkmatige nagalm doet precies wat een bed hoort te doen: hij vult de opstelling met een veld dat nergens in het bijzonder vandaan komt en dat op elke BS.2051-opstelling herkenbaar blijft. Zet dat veld in een DirectSpeakers-pack van 7.1.4 of ruimer, inclusief de bovenlaag, en gebruik de bovenlaag ook echt: een 7.1.4-bed waarvan de vier hoogtekanalen digitale stilte bevatten is geen 7.1.4-bed, en het is een van de vaakst voorkomende stille fouten in dit repertoire (zie §12.6).

De objecten zijn dan wat ze in de zaal ook zijn: de sopraan die naar voren stapt, het kleine ensemble dat vanaf het balkon antwoordt, het slagwerk dat achter het orkest staat. Vier tot twaalf objecten is voor dit repertoire ruim. Wie er zestig maakt, heeft geen immersieve mix gemaakt maar een orkestopname in losse microfoons uit elkaar getrokken, en levert een bestand af dat op elke opstelling anders klinkt zonder dat iemand kan zeggen welke versie de juiste is.

5. De andere pool: Nederlandse elektronica en clubmuziek

Nederlandse en Vlaamse elektronische muziek — house, techno, drum-and-bass, gabber, en de hele productietraditie die daaruit voortkomt — staat aan het tegenovergestelde uiterste, en dat verandert de vraag volledig.

Hier bestaat er geen origineel. Er is geen kerk, geen toren, geen zaal en geen bron die ergens stond. Een synthesizerlaag heeft geen positie; hij krijgt er een. Objectplaatsing is hier dus geen documentatie maar compositie: een keuze op hetzelfde niveau als de keuze van een filterinstelling, en net zo goed of net zo slecht als de maker hem maakt.

Dat is een vrijheid en tegelijk het specifieke risico van dit repertoire: alles object maken omdat het kan. De symptomen zijn herkenbaar:

• Een sessie met tachtig objecten waarvan er zeventig statisch en gecentreerd zijn. Dat zijn geen objecten, dat is een bed dat de lange weg heeft genomen — met alle bijbehorende renderkosten en zonder enige winst.
• Automatiecurves op elementen die daar niets aan hebben. Een kickdrum die rondvliegt, is geen ruimtelijk idee maar een defect. Kick, bas en de kern van de drums horen bij vrijwel elke club-georiënteerde mix in het bed, laag en gecentreerd, precies zoals ze in een zaal uit het systeem komen.
• Reverb-returns als objecten. Een return is een diffuus veld; dat is precies wat een bed is. Als object gerenderd wordt hij een puntbron, en dan verliest de mix haar diepte in plaats van dat ze die wint.
• Hoogte gebruikt als noviteit. In dit repertoire zijn de bovenkanalen op hun sterkst als ze schaars zijn: één element, consequent, met een reden.

De bruikbare discipline is de omgekeerde van de klassieke: begin met een bed dat op zichzelf al een complete mix is, en promoveer alleen die elementen tot object waarvoor u in één zin kunt uitleggen wat de beweging of de plaatsing muzikaal doet. Alles wat die zin niet haalt, hoort in het bed.

6. BW64: wat het is, en de rekensom achter de 4 GB-grens

De klassieke WAV is een RIFF-bestand. RIFF, uit 1991, zet vóór elke chunk een grootteveld van 32 bits. Tweeëndertig bits adresseert 4 294 967 296 bytes — 4 GiB — en dat is de harde bovengrens, zowel voor het bestand als geheel als voor de data-chunk erin.

Reken het uit voor de gevallen hierboven. De datasnelheid is kanalen × bytes-per-sample × bemonsteringsfrequentie:

Bij stereo is de grens irrelevant. Bij een beiaardconcert van drie kwartier op 24 sporen en 96 kHz zit u er ruim vier keer overheen, en bij een grote objectsessie zit u er binnen twee minuten overheen. Een WAV-schrijver die tegen de grens aanloopt, levert óf een afgekapt bestand op, óf een bestand waarvan de opgegeven groottes stilzwijgend zijn omgeklapt.

De EBU heeft dit eerst opgelost met RF64 (EBU Tech 3306). De ITU heeft dat werk overgenomen als Aanbeveling ITU-R BS.2088, Long-form file format for the international exchange of audio programme materials with metadata — BW64. BS.2088 is expliciet over het mechanisme: "The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file", en de oorspronkelijke 32-bits velden worden ontsnappingsvlaggen — "If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead."

BW64 verbreedt de RIFF-groottevelden niet; het vult ze met 0xFFFFFFFF als signaalwaarde en zet de echte 64-bits groottes in een ds64-chunk die vooraan in het bestand moet staan.

Zie BW64 als de derde generatie van één familie. RIFF/WAVE leverde de chunkcontainer. Broadcast Wave (BWF, EBU Tech 3285) voegde de bext-chunk toe — originator, tijdcodereferentie, coding history — en maakte van WAV een omroepuitwisselingsformaat. BW64 behoudt dat alles, voegt 64-bits adressering toe, en voegt de chunks toe die ADM dragen. Een BW64-bestand onder de 4 GiB is byte-compatibel met een WAV-lezer in alles behalve de vier tekens van de bestandssignatuur; veel gereedschap accepteert het, sommig hardnekkig niet.

7. De chunkindeling, concreet

Volgens BS.2088 bevat een BW64-bestand ten minste <ds64-ck>, <fmt-ck>, <chna-ck>, <axml-ck> (met <bxml-ck> en <sxml-ck> als alternatieve metadatadragers) en <wave-data>.

7.1 ds64 — de tabel met 64-bits groottes

Moet de eerste chunk zijn na de BW64-signatuur, want een lezer moet de echte groottes kennen vóór hij door de rest kan lopen. De velden zijn 32-bits helften van 64-bits waarden:

Reken de minimale vorm na: alles na ckSize is 8 + 8 + 8 + 4 = 28 bytes, dus ckSize = 28 en de chunk beslaat op schijf 4 + 4 + 28 = 36 bytes. Elke ChunkSize64-ingang is een 4-byte chunk-ID plus een 8-byte grootte = 12 bytes, dus met n ingangen is ckSize = 28 + 12 n en de chunk op schijf 36 + 12 n bytes.

Die table[] doet er meer toe dan hij lijkt. Een axml-chunk die duizenden objecten met sample-nauwkeurige automatie beschrijft, kan zelf de 4 GiB naderen of overschrijden; de tabel is de enige manier waarop een andere chunk dan data een 64-bits grootte kan opgeven.

7.2 fmt — de beschrijving van de essentie

De standaard WAVE-formaatchunk: sampleformaat, bemonsteringsfrequentie, kanaalaantal, bitdiepte, block align. Dit is de enige gezaghebbende uitspraak over hoeveel geïnterleavede kanalen er werkelijk in data staan. Alles daarna is metadata over die kanalen, en metadata kan liegen.

7.3 chna — de kanaaltoewijzingstabel, en de veertig bytes

chna is de brug tussen fysieke tracks en de ADM. De chunk begint met:

• ckID — 4 bytes, 'chna'
• ckSize — 4 bytes
• numTracks — 2 bytes, aantal tracks in het bestand
• numUIDs — 2 bytes, aantal audioTrackUID-ingangen dat volgt

Daarna een vlakke rij audioID-ingangen met vaste breedte. Elke ingang is exact 40 bytes:

2 + 12 + 14 + 11 + 1 = 40. Tel de voorbeeldwaarden zelf na: ATU_00000001 is 4 tekens prefix plus 8 cijfers = 12; AT_00031001_01 is 3 + 8 + 3 = 14; AP_00031001 is 3 + 8 = 11. De veldbreedtes zijn geen advies maar vaste ASCII-breedtes: een schrijver die een UID van 13 tekens wegschrijft, heeft een corrupte tabel gemaakt, geen ietwat afwijkende.

En de chunk als geheel, voor de 7.1.4 + 16 objecten uit §6: 28 tracks en 28 UID's geven ckSize = 2 + 2 + (28 × 40) = 1124 bytes, en op schijf 4 + 4 + 1124 = 1132 bytes — even, dus geen chunkopvulling nodig. Voor de grote sessie van 128 tracks: ckSize = 4 + 5120 = 5124, op schijf 5132 bytes. Een chna-chunk waarvan ckSize min 4 niet deelbaar is door 40, is per definitie stuk; dat is een controle van één regel code.

Let ook op de ID-conventie: waarden tot en met 0x0FFF verwijzen naar de ADM-common definitions — de vooraf gedefinieerde standaardkanaal- en packformaten — terwijl 0x1000 en hoger op eigen definities duiden die in de axml-chunk aanwezig moeten zijn. Een packRef van AP_00010003 is 5.1 volgens de common definitions en heeft geen XML nodig; AP_00031001 is een eigen objectpack en hangt zonder XML in de lucht.

Een track-UID is het serienummer dat het bestand aan de identiteit van één fysieke track geeft, en het bestaat opdat een track halverwege een programma legitiem iets anders kan gaan dragen.

Dat laatste is de reden dat numUIDs groter mag zijn dan numTracks: de EBU-richtlijn merkt op dat waar "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." Eén trackIndex mag dus in meerdere ingangen voorkomen. Controlegereedschap dat uitgaat van één UID per track, markeert correcte bestanden als stuk.

7.4 axml — de ADM zelf

Een XML-document in UTF-8 met de <audioFormatExtended>-boom. Dit is de ADM. Het is tekst, het is inspecteerbaar, en hier zitten vrijwel alle interessante fouten.

7.5 data — de geïnterleavede PCM

Gewone geïnterleavede samples, precies als in WAV. Niets in data weet iets van objecten.

7.6 De volgorde, en de valkuil waar iedereen in loopt

ds64 altijd als eerste. fmt vóór data. Maar axml mag legitiem ná data staan, en staat dat vaak ook, omdat — zoals BS.2088 opmerkt — tijdens opname "the XML metadata will likely be of an unknown length." Een bestand met axml aan het eind is niet defect; een lezer die alleen de eerste megabyte scant, meldt niettemin dat er helemaal geen ADM in zit. Dit ene feit verklaart een verrassend groot deel van alle meldingen "mijn bestand heeft geen metadata".

8. Het ADM-model: een grafe van verwijzingen

ITU-R BS.2076 splitst het model in twee helften. Het format-deel "describes the technical nature of the audio so it can be decoded or rendered correctly" en kan geschreven worden voordat er audio bestaat. Het content-deel beschrijft "the language of dialogue, the loudness, etc." en kan pas af zijn als de signalen er zijn. Weten in welke helft een element hoort, vertelt u in welk productiestadium een fout is ontstaan.

De hiërarchie, van boven naar beneden:

• audioProgramme — één complete presentatie. Verwijst naar een of meer audioContent.
• audioContent — een programmaonderdeel met redactionele betekenis: dialoogstem, muziekstem, een taalversie. Verwijst naar een of meer audioObject.
• audioObject — de las tussen redactionele bedoeling en technisch formaat. Draagt starttijd en duur, en verwijst naar nul of meer audioPackFormat, nul of meer geneste audioObject, en nul of meer audioTrackUID. Hier ontmoet inhoud de essentie.
• audioPackFormat — een groep kanalen die bij elkaar horen: een 7.1.4-bed, een stereopaar, een HOA-set van een bepaalde orde. Verwijst naar audioChannelFormat-elementen en mag andere packs nesten.
• audioChannelFormat — het gedrag van één kanaal in de tijd. Bevat een of meer audioBlockFormat.
• audioBlockFormat — het atoom. Voor Objects: een positie (azimuth/elevation/distance of cartesisch X/Y/Z), gain, size, diffuseness, plus rtime en duration. Een statisch object is één blok; een bewegend object is een reeks.
• audioTrackUID — het blad, en het enige element dat met een fysieke track correspondeert. Draagt optioneel sampleRate en bitDepth en verwijst naar een audioTrackFormat en een audioPackFormat.

audioStreamFormat en audioTrackFormat zitten tussen kanaalformaat en track-UID en beschrijven de streamcodering. BS.2076-3 merkt op dat ze voor PCM in feite overbodig zijn — "the audioStreamFormat and the audioTrackFormat should be omitted" — maar dat lezers zich ervan bewust moeten zijn dat "existing ADM files (based on Recommendation ITU-R BS.2076-2 and earlier) for PCM audio may contain" ze. Beide vormen zijn geldig. Een validator die op één van de twee staat, heeft het over de andere mis.

ADM is een grafe van verwijzingen, geen genest document, en elke serieuze aanleverfout is een gebroken tak in die grafe.

Wat er gebeurt als een verwijzing in de lucht hangt. Er is geen vast gedrag, en dat is het probleem. Een renderer die een audioPackFormatIDRef tegenkomt die naar een pack wijst dat niet in de XML staat, kan de parse afbreken en het bestand weigeren; kan dat ene object overslaan en de rest wél weergeven, waarmee er stilletjes een stem uit de mix verdwijnt; of kan terugvallen op de common definitions, daar een ID uit het 0x1000-bereik niet vinden, en stilte invullen. Alle drie de uitkomsten heten "het bestand ging open". Maar één ervan valt op door te luisteren, en dan alleen als u toevallig weet wat er had moeten staan. Daarom moet ADM-controle geautomatiseerd zijn: een menselijk oor hoort geen afwezigheid waarvan het niet wist dat ze er zou zijn.

9. Rendering: BS.2127 naar BS.2051-opstellingen

Een objectgebaseerd bestand klinkt niet. Het klinkt pas na rendering, en de renderer maakt keuzes.

ITU-R BS.2127 definieert de referentie-ADM-renderer voor geavanceerde geluidssystemen. De open-source tegenhanger, de EBU ADM Renderer (EAR, EBU Tech 3388), is de praktische manier om een reproduceerbaar resultaat te krijgen: dezelfde invoer geeft dezelfde uitvoer, en u kunt de code lezen. Voor iedereen die een immersief bestand moet verantwoorden zonder een gecertificeerde monitorruimte is dat het belangrijkste gereedschap dat er bestaat.

Wat de renderer doet, hangt af van de doelopstelling uit BS.2051. Hetzelfde object op elevatie +30° gaat:

• naar 0+2+0 (systeem A, stereo): geplet in het horizontale vlak, hoogte verdwijnt volledig;
• naar 0+5+0 (systeem B): idem, met meer omhulling maar nog steeds geen bovenlaag;
• naar 4+5+0 (systeem D) of 4+7+0 (systeem J): verdeeld tussen midden- en bovenlaag, hoogte blijft behouden;
• naar 9+10+3 (systeem H, 22.2): fijner opgelost, met een onderlaag die de meeste producties niet gebruiken.

Twee praktische gevolgen. Ten eerste: er is geen "de mix". Er is een mix per doelopstelling, en de verschillen zijn muzikaal, niet marginaal — bij de beiaard uit §1 is het verschil tussen systeem B en systeem D letterlijk het verschil tussen een klok naast u en een toren boven u. Ten tweede: alles wat u meet — luidheid, true peak, correlatie — meet u aan een render, niet aan het bestand. Noteer daarom altijd drie dingen samen: de opstelling, de renderer en de versie ervan.

10. Luidheid van immersief materiaal onder BS.1770-5

Hier is het essentieel om te scheiden wat gepubliceerd is van wat circuleert.

10.1 Wat de Aanbeveling vastlegt

BS.1770 kent zes edities: -0 (2006), -1 (2007), -2 (2011), -3 (2012), -4 (2015) en -5 (november 2023). BS.1770-5 is de vigerende editie; BS.1770-4 (oktober 2015) is ingetrokken, ook al is het de editie waar de meeste ingezette meters nog naar verwijzen. Noem in documentatie altijd -5.

De mechanica:

• K-weging: een filter in twee trappen — eerst een high-shelf ("head"-filter, dat een stijve bol modelleert), dan een hoogdoorlaat (RLB).
• De versterking van de K-wegingscurve bij 1 kHz is +0,698 dB (lineair 1,0836).
• Meting in blokken van 400 ms met 75 % overlap.
• Absolute poort: blokken onder −70 LUFS worden weggegooid.
• Relatieve poort: berekend uit het gemiddelde van de blokken die de absolute poort hebben overleefd, en vervolgens −10 LU verschoven. Het is niet het ongepoorte gemiddelde. Dat onderscheid wordt vaak fout geïmplementeerd en het maakt uit.
• Loudness Range (LRA), EBU Tech 3342, gebruikt een relatieve poort van −20 LU, níet −10 LU. −10 gebruiken voor LRA is een klassieke implementatiefout.
• Short-term: venster van 3 s (EBU Tech 3341). Momentary: 400 ms.
• True peak wordt gemeten op een oversampled signaal (minimaal 4× volgens BS.1770; 8× is beter). Samplepiek is niet gelijk aan true peak: intersample-pieken kunnen hoger uitkomen dan de hoogste sample.

De kanaalweging in het kernalgoritme is 1,0 (0 dB) voor L, R en C en 1,41 (≈ +1,5 dB) voor Ls en Rs, met LFE uitgesloten. Het basisalgoritme is gedefinieerd voor "from one to five channels". BS.1770-5 gaat in de bijlagen verder en behandelt de geavanceerde geluidssystemen van BS.2051 — willekeurig geplaatste luidsprekers en hoogtekanalen — en objectgebaseerde audio, die eerst gerenderd moet worden voordat er iets te meten valt.

Immersieve luidheid is geen eigenschap van het bestand; het is een eigenschap van een render, en een andere doelopstelling geeft een ander getal.

Dat is het wezenlijke verschil met stereo. Een stereomaster heeft één luidheidswaarde. Een objectgebaseerde master heeft er zoveel als hij doelopstellingen heeft, en de enige eerlijke manier om een getal op te schrijven is er de opstelling en de renderer bij te noemen.

10.2 Wat er voor muziek wél gepubliceerd is

Voor kanaalgebaseerde stereomuziek publiceert Spotify een geïntegreerd doel van −14 LUFS en een true-peak-plafond van −1 dBTP, aangescherpt tot −2 dBTP als de master luider is dan −14 LUFS. AES TD1008 adviseert −16 LUFS voor muziek; het getal −18 LUFS in datzelfde document geldt voor spraakgedreven materiaal (nieuws, talk, hoorspel), en −18 als muziekdoel noemen is een veelgemaakte en serieuze fout. EBU R 128 zet het omroepdoel op −23 LUFS, maar R 128 is een omroepnormalisatiepraktijk, geen specificatie voor muziekstreaming.

Diensten normaliseren bij weergave: een master die luider is dan het doel wordt met het verschil omlaag gedraaid. Opwaartse normalisatie bestaat, maar is voorwaardelijk. Spotify schrijft zowel "Positive gain is applied to softer masters so the loudness level is -14 dB LUFS" als "We consider the headroom of the track, and leave 1 dB headroom for lossy encodings to preserve audio quality." Een stille master met hoge pieken wordt dus niet noodzakelijk helemaal opgetrokken. "Stille masters worden niet opgedraaid" is onjuist; "stille masters worden altijd naar het doel opgetrokken" is óók onjuist. De verdedigbare conclusie blijft: overmatig limiteren koopt vlakheid, geen luidheid.

10.3 Wat er níet gepubliceerd is

Geen enkele muziekstreamingdienst publiceert een geïntegreerd luidheidsdoel voor immersieve levering. Er circuleren getallen in forums en in trainingsmateriaal van leveranciers; sommige zijn plausibel en sommige zullen kloppen. Geen daarvan is een gepubliceerde specificatie, en dit document herhaalt er geen als ware het dat wel.

Ook voor stereo geldt dat Apple Music, YouTube Music, Amazon Music, TIDAL en Deezer géén normalisatiedoel publiceren. De veelgenoemde waarden (Apple ≈ −16, YouTube Music ≈ −14, Amazon ≈ −14, TIDAL ≈ −14, Deezer ≈ −15) zijn breed gerapporteerd maar niet door de dienst gepubliceerd en mogen nooit worden behandeld als een specificatie waaruit u een versterkingsverandering berekent.

Heeft u vandaag een verdedigbaar immersief luidheidsgetal nodig, dan is er één werkwijze: meet een BS.2127-conforme render naar een met naam genoemde BS.2051-opstelling met een BS.1770-5-meter, en zet alle drie in uw aanleverdocumentatie.

10.4 Over propriëtaire systemen

Dolby Atmos is propriëtaire, gelicentieerde technologie van Dolby Laboratories; Sony 360 Reality Audio is een propriëtair systeem op basis van MPEG-H. Hun aanleververeisten worden door de eigenaren bepaald en wijzigen los van de tijdlijnen van ITU en EBU. Niets in dit document is een uitspraak over de eisen van die bedrijven, en er wordt geen enkele band, certificering of goedkeuring geclaimd of gesuggereerd. Publiceert een licentiegever een eis, lees dan diens eigen actuele documentatie en citeer die.

11. De eerlijke positie: u luistert waarschijnlijk niet immersief mee

Dit hoort in een Nederlandstalige referentie thuis, want het gaat om de dagelijkse werkelijkheid van de meeste lezers.

Buiten de buitenopnamewagens van de omroep en een handvol postproductiehuizen is een gekalibreerde immersieve regiekamer in Nederland en Vlaanderen zeldzaam. De typische situatie is een goed stereopaar, misschien 5.1, en een koptelefoon. Dat is geen schande en het is geen beletsel om immersief aan te leveren — maar het verandert wél waar uw waarde ligt.

Uw waarde ligt dan niet in "mooi mixen in de hoogte", want dat kunt u niet controleren. Uw waarde ligt in drie dingen:

1. Correcte aanlevering. Het juiste formaat, de juiste bemonsteringsfrequentie en bitdiepte, de juiste bestandssignatuur, de juiste conforms, de juiste tijdcode.
2. Correcte metadata. Een ADM-grafe zonder losse takken, tijdlijnen die aaneensluiten, packs die bestaan, UID's die kloppen. Dit is volledig verifieerbaar zonder te luisteren, en dit is waar de meeste afkeuringen op vallen.
3. Verifiëren van een bestand dat u niet fatsoenlijk kunt beluisteren. Parse de container. Vergelijk fmt met chna. Render met de EAR naar de opstellingen die u wél hebt en luister daarnaar. Meet de luidheid van die render. Kijk naar de samples van elk bedkanaal en constateer zelf of er signaal in staat.

Wie zich daaraan houdt, levert een bestand af dat op apparatuur die hij nooit heeft gehoord correct wordt weergegeven — en dat is precies wat een open, gedocumenteerd formaat als BW64/ADM u in staat stelt te doen.

Een gratis, in de browser draaiende BW64/ADM-inspecteur op mazufa.com leest container én metadata volledig op uw eigen apparaat en uploadt niets, wat hem bruikbaar maakt voor materiaal dat contractueel het pand niet uit mag.

12. Veelvoorkomende QC-fouten en hoe je ze opspoort

12.1 Kanaalaantal in fmt klopt niet met chna

fmt.nChannels zegt 16, chna.numTracks zegt 14. Het bestand spreekt zichzelf al bij de eerste twee chunks tegen. Meestal veroorzaakt door een bounce waarin het aantal sporen veranderde nadat de metadata was geschreven, of door gereedschap dat sporen weghaalde zonder chna te herschrijven.

Opsporen: lees beide chunks en vergelijk twee gehele getallen. Dit is de goedkoopste controle in de hele keten en hij vangt een verrassend groot deel van de fouten. Controleer meteen dat elke trackIndex in chna binnen 1 … fmt.nChannels valt.

12.2 Verweesde track-UID's

Een UID in chna waar geen enkel audioObject naar verwijst, of een audioTrackUIDRef in de XML zonder bijbehorende chna-ingang. Het eerste betekent audio die niemand zal renderen; het tweede metadata die een spoor verwacht dat er niet is.

Opsporen: bouw de verzameling UID's uit chna en die uit axml en neem het symmetrisch verschil. Dat hoort leeg te zijn. EBU Tech 3392 maakt de bedoeling expliciet: "If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs."

12.3 Blokformaten met ontbrekende of niet-monotone tijden

BS.2076 is ondubbelzinnig: "When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present." EBU Tech 3392 scherpt dat aan tot een aaneensluitingsregel — "rtime + duration of an audioBlockFormat should match the rtime of the following block" — met het eerste blok van een object op 00:00:00.00000, geen blok korter dan één sample, en een som van de duren die gelijk is aan die van het bovenliggende audioObject.

Opsporen: loop per audioChannelFormat de blokken in documentvolgorde af en toets rtime[n] + duration[n] == rtime[n+1]. De fouten vallen in drie vormen uiteen: gaten (renderergedrag ongedefinieerd — sommige houden de laatste positie vast, andere dempen), overlappingen (blokken die elkaar tegenspreken) en blokken in de verkeerde chronologische volgorde (automatie die halverwege terugspringt).

12.4 Verkeerde bemonsteringsfrequentie of bitdiepte

audioTrackUID mag sampleRate en bitDepth dragen. Spreken die fmt tegen, dan heeft u twee beweringen over dezelfde essentie. EBU Tech 3392 stelt dat ze "Should be ignored if available from the audio essence", maar niet elke renderer volgt dat advies, en een bestand dat op de ene plek 48 000 en op de andere 96 000 zegt, wordt door verschillende gereedschappen verschillend uitgelegd. Controleer daarnaast of de frequentie is wat de aanleverspecificatie vraagt: samplerateconversie ná het schrijven van de ADM maakt elke rtime en duration die in samples is uitgedrukt ongeldig.

Opsporen: vergelijk fmt met elk sampleRate/bitDepth-attribuut in de XML en meld elk verschil, ook al is het formeel toelaatbaar.

12.5 Ontbrekende of verschoven stereo- of binaurale conform

De meeste immersieve leveringen vragen een stereoconform en vaak ook een binaurale, náást de immersieve master. De terugkerende fout is niet afwezigheid — dat valt op — maar verloop: de conform is uit een oudere versie gerenderd, staat een paar frames verschoven, of heeft een andere starttijdcode. Een stereobestand dat 40 ms voorloopt op zijn immersieve ouder, komt door een aanwezigheidscontrole en zakt bij het eerste synchrone beluisteren.

Opsporen: vergelijk duren tot op de sample, vergelijk de starttijdcode uit bext, en kruiscorreleer de conform met een render van de master. Behandel elke conform die niet aantoonbaar uit de huidige master is afgeleid als verdacht en render hem opnieuw in plaats van hem opnieuw te controleren.

12.6 Metadata die een bed beschrijft dat niet in het bestand staat

De XML declareert een 7.1.4-DirectSpeakers-pack — twaalf kanalen — maar er is alleen de 5.1-subset weggeschreven, of de hoogtekanalen stonden bij de bounce gedempt en zijn als digitale stilte weggeschreven. De verwijzingsgrafe is heel; de audio niet. Bij zaalopnames uit §4 is dit veruit de meest voorkomende inhoudelijke fout.

Opsporen: structurele controles vinden dit niet. Hiervoor is essentie-analyse nodig: meet voor elk kanaal dat een DirectSpeakers-pack claimt of er überhaupt signaal in staat. Digitale stilte op een gedeclareerd bedkanaal is niet automatisch fout — een legitieme mix mag een achterste hoogtekanaal leeg laten — maar het verdient altijd een menselijke beslissing.

De container kan volmaakt geldig zijn, de XML volmaakt welgevormd, en de levering toch verkeerd; de enige controle op een leeg bedkanaal is naar de samples kijken.

13. Aanleveringschecklist

Werk deze op volgorde af. Structurele controles eerst — ze zijn snel en ze maken alles daarna zinloos als ze falen.

Container

1. De eerste vier bytes zijn BW64. Staat er RIFF, dan is het een gewone WAV en kan hij de 4 GiB niet overschrijden.
2. ds64 is de eerste chunk na de signatuur, en zijn 64-bits waarden komen overeen met de werkelijke bestands- en data-groottes op schijf.
3. Elke te grote chunk die niet data is, heeft een ChunkSize64-ingang in de ds64-tabel.
4. Zoek axml expliciet op, ook ná data. Concludeer nooit "geen ADM" uit een gedeeltelijke scan.

Essentie

1. Bemonsteringsfrequentie en bitdiepte in fmt komen exact overeen met de specificatie. Geen SRC ná het schrijven van de ADM.
2. fmt.nChannels is gelijk aan chna.numTracks.
3. Elke trackIndex in chna valt binnen bereik en is 1-gebaseerd.

chna-integriteit

1. Elke ingang is exact 40 bytes met correct opgevulde vaste velden; ckSize − 4 is deelbaar door 40.
2. Elke packRef van 0x1000 of hoger verwijst naar een eigen definitie die in axml staat.
3. Herhaalde trackIndex-waarden zijn bedoeld (een spoor dat legitiem van definitie wisselt), geen duplicaten.

ADM-grafe

1. Elke audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef en audioTrackUIDRef lost op. Nul losse takken.
2. Geen verweesde audioTrackUID in beide richtingen.
3. Geen circulaire of naar zichzelf verwijzende elementen.
4. Het typeLabel van elk audioChannelFormat komt overeen met dat van het bovenliggende audioPackFormat.

Tijd

1. Kanaalformaten met meerdere blokken dragen op elk blok zowel rtime als duration.
2. Blokken sluiten aaneen en lopen monotoon; de duren tellen op tot de duur van het bovenliggende audioObject.
3. Objecten beginnen op 00:00:00.00000.

Inhoud

1. Elk kanaal van een gedeclareerd bed bevat wat het hoort te bevatten; onderzoek digitale stilte.
2. Objectaantal en bedconfiguratie komen overeen met de specificatie.
3. De starttijdcode in bext klopt en is consistent over alle bestanden van de levering.

Renders en conforms

1. Stereo- en binaurale conforms zijn opnieuw gerenderd uit de huidige master, niet meegesleept.
2. Duren en starttijdcodes komen tot op de sample overeen met de master.
3. Luidheid gemeten op een met naam genoemde render naar een met naam genoemde opstelling met een met naam genoemde renderer, en alle drie vastgelegd in de aanleverdocumentatie.

Reproduceerbaarheid

1. Bereken een checksum over elk aangeleverd bestand en bewaar het manifest.
2. Archiveer de sessie en de ADM-XML apart van de BW64. XML die u kunt diffen is later meer waard dan een binair bestand dat u alleen opnieuw kunt parsen.

Een immersieve levering is niet af als hij goed klinkt; hij is af als een machine die hem nooit gehoord heeft kan bewijzen dat zijn verwijzingen oplossen.

14. Tot slot

BW64 en ADM zijn open, gepubliceerde, vrij leesbare standaarden. Dat is ongewoon in deze hoek van de branche en het is de moeite waard om er gebruik van te maken: u kunt BS.2088 en BS.2076 zelf lezen, een chna-chunk met veertig regels code ontleden, en nagaan wat de exporter van een leverancier werkelijk heeft weggeschreven in plaats van wat zijn dialoogvenster beweerde.

En de twee gevallen waarmee dit document begon, zijn precies de reden dat het de moeite waard is. Een beiaard en een kerkorgel zijn instrumenten waarvan de ruimtelijke opbouw geen effect is maar het instrument zelf. Een formaat dat die opbouw kan vastleggen, legt iets vast wat stereo al vier generaties opnametechniek lang weggooit. Dat is geen marketingargument voor immersieve audio; het is gewoon wat hier technisch waar is.

De distributie van Mazufa is gratis — geen uploadkosten, geen abonnement, geen kosten per release — met een inhouding van 5 % op ontvangen royalty's, en elke complete aanvraag wordt door een mens beoordeeld.

Bronnen

ITU-R-aanbevelingen

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

EBU-documenten

• EBU Tech 3306, RF64: An extended file format for audio data — https://tech.ebu.ch/docs/tech/tech3306.pdf
• EBU Tech 3285 (en supplementen), 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 en 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 (meters), EBU Tech 3342 (Loudness Range) — https://tech.ebu.ch
• EBU ADM Guidelines — CHNA-chunk — https://adm.ebu.io/reference/excursions/chna_chunk.html
• EBU ADM Guidelines — BW64 en 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), BW64-I/O — https://ear.readthedocs.io/en/latest/BW64.html
• libbw64 referentie-implementatie — https://github.com/ebu/libbw64
• libadm referentie-implementatie — 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/

Documentatie van diensten

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

Beiaard

• World Carillon Federation, Discover (definitie, norm van 23 klokken, stokkenklavier) — https://carillon.org/en/discover-en/
• UNESCO, Safeguarding the carillon culture (Register of Good Safeguarding Practices, 2014, België) — https://ich.unesco.org/en/BSP/safeguarding-the-carillon-culture-preservation-transmission-exchange-and-awareness-raising-01017
• Dom Tower of Utrecht (torenhoogte 112,32 m; beiaard van 50 klokken sinds 1972) — https://en.wikipedia.org/wiki/Dom_Tower_of_Utrecht

Laatst nagezien in september 2026. Standaarden worden herzien; controleer altijd de ITU- en EBU-pagina's hierboven op de actuele editie voordat u een clausulenummer citeert.