Waarom een immersive master door een waveform-editor komt en op QC stukloopt

Een immersive levering kan openen in een waveform-editor, twaalf of zestien gezond ogende tracks tonen, verstandig afspelen — en toch worden afgekeurd. De reden is structureel: in een BW64-bestand zijn de audio en de metadata twee losse dingen die exact moeten overeenkomen, en niets in het formaat dwingt dat af. Een renderer lost verwijzingen op. Een editor tekent samples. Verschillende taken — en daarom is ADM-QC het controleren van referentie-integriteit, niet luisteren. Hier staat wat de twee standaarden zeggen, waar de verwijzingen breken, en welke controle welk mankement vangt.

Drie soorten audio, en waarom dat onderscheid alles bepaalt

Elk probleem bij een immersive levering begint met verwarring over welke van drie dingen een track is.

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

Objectgebaseerde audio draagt een mono- (of meerkanaals pack-)signaal mee plus positiemetadata die in de tijd verandert. De renderer bepaalt welke echte luidsprekers het weergeven, op basis van de opstelling die in de ruimte aanwezig is. Niets aan de track veronderstelt een luidspreker. Dit is typeDefinition Objects, typeLabel 0003.

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

Het onderscheid is geen taxonomie. 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 zonder haar metadata betekenisloos: de audio is een stapel ongedifferentieerde monostromen, en de ADM is het enige dat iets anders beweert. Die asymmetrie is de reden dat BW64 en ADM bestaan.

BW64 bestaat vanwege een 32-bits getal

Klassieke WAV is een RIFF-bestand. RIFF, uit 1991, zet voor elke chunk een 32-bits groottveld. Tweeëndertig bits adresseert 4,294,967,296 bytes — 4 GB — en dat is het harde plafond voor zowel het hele bestand als de data-chunk erin.

Voor stereo op 48 kHz / 24-bit is de datastroom 288,000 bytes per seconde, dus 4 GB is ongeveer 4 hours 8 minutes. Niet relevant. Voor een objectgebaseerde master van 128 tracks op 96 kHz / 24-bit is de stroom 36,864,000 bytes per seconde, en is 4 GB minder dan twee minuten — 116.5 seconden.

Immersive masters gaan daar routineus overheen, en een WAV-schrijver die tegen die grens aanloopt, levert ofwel een afgekapt bestand op, ofwel een bestand waarvan de opgegeven groottes stilletjes zijn omgeslagen. De EBU pakte dit als eerste aan met RF64 (EBU Tech 3306); de ITU bracht het verder als Recommendation ITU-R BS.2088 — BW64.

De sentineltruc: 0xFFFFFFFF en een ds64-chunk

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 grootteveldjes worden escape-vlaggen: "If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead."

Dat is de hele truc, en het is de moeite waard om hem onomwonden te stellen: BW64 verbreedt de RIFF-grootteveldjes niet. Het vult ze met 0xFFFFFFFF als sentinel en zet de echte 64-bits groottes in een ds64-chunk, die vooraan in het bestand moet staan. Een BW64-bestand kleiner dan 4 GB is dus byte-compatibel met een WAV-lezer in alle opzichten behalve de vier tekens van de signature. Veel tools accepteren het; sommige hardnekkig niet.

De chunks, en die ene van precies 40 bytes per regel

Volgens BS.2088 wordt van een BW64-bestand verwacht dat het ten minste ds64, fmt , chna, axml (met bxml en sxml als alternatieve metadatadragers) en de wave-data bevat.

ds64 moet de eerste chunk na de signature zijn, omdat een lezer de echte groottes moet kennen voordat hij ergens anders doorheen kan lopen. Hij bevat 32-bits lage/hoge helften voor de bestandsgrootte en de data-grootte, plus een tabel met ChunkSize64-regels voor elke andere te grote chunk — een axml-chunk die duizenden objecten met sample-nauwkeurige automatisering beschrijft, kan zelf 4 GB naderen of overschrijden.

fmt is de standaard WAVE-formaatchunk — sampleformaat, samplefrequentie, aantal kanalen, bits per sample, block align. Het is de enige gezaghebbende vaststelling van hoeveel geïnterleavede kanalen er in data zitten. Alles stroomafwaarts is metadata over die kanalen, en metadata kan liegen.

chna is de brug tussen fysieke tracks en de ADM. Na ckID, ckSize, een 2-byte numTracks en een 2-byte numUIDs bevat hij een platte array van audioID-regels met vaste breedte, elk precies 40 bytes:

2 + 12 + 14 + 11 + 1 = 40. De breedtes zijn geen advies: het is ASCII met vaste breedte, en een schrijver die een UID van 13 tekens uitspuwt, heeft een corrupte tabel geproduceerd, geen licht afwijkende.

De ID-conventie doet er ook toe. Waarden van 0x0FFF en lager verwijzen naar de common definitions van ADM — de standaard, vooraf gedefinieerde kanaal- en packformaten — terwijl 0x1000 en hoger duiden op eigen definities die in axml aanwezig moeten zijn. AP_00010003 is 5.1 volgens common definition en heeft geen XML nodig; AP_00031001 is een eigen objectpack en heeft XML nodig, anders bungelt de verwijzing.

numUIDs mag ook legitiem groter zijn dan numTracks: de EBU-richtlijnen merken 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", zodat één trackIndex in meerdere regels kan voorkomen. QC-tools die uitgaan van één UID per track markeren correcte bestanden als kapot.

axml is een UTF-8 XML-document met daarin de <audioFormatExtended>-boom. Dat is de ADM, en daar zitten vrijwel alle interessante mankementen. data is gewone geïnterleavede PCM; niets daarin weet iets van objecten.

Volgorde: ds64 altijd eerst; fmt vóór data. Maar axml mag legitiem na data staan, en dat gebeurt vaak, want — zoals BS.2088 opmerkt — tijdens opname is "the XML metadata will likely be of an unknown length." Een bestand met axml achteraan is niet misvormd, maar een lezer die alleen de eerste megabyte doorzoekt, meldt dat er helemaal geen ADM is. Dat verklaart een verrassend deel van de meldingen "mijn bestand heeft geen metadata".

ADM is een graaf, en mankementen zijn gebroken verbindingen

De hiërarchie van ITU-R BS.2076 loopt audioProgramme → audioContent → audioObject → audioPackFormat → audioChannelFormat → audioBlockFormat, met audioTrackUID als blad en als enige element dat overeenkomt met een fysieke track.

Dat is een graaf van verwijzingen, geen genest document, en elk serieus leveringsmankement is daarin een gebroken verbinding. Wat een bungelende verwijzing gevaarlijk maakt, is dat er geen enkel vast gedrag bestaat wanneer er een breekt. Een renderer die een audioPackFormatIDRef oplost die verwijst naar een pack dat in de XML ontbreekt, kan het parsen afbreken en het bestand afkeuren; kan dat object overslaan en de rest wél renderen, wat een mix oplevert waarin stilletjes een stem ontbreekt; of kan terugvallen op de common definitions, daar een ID in het eigen bereik vanaf 0x1000 vinden zonder match, en stilte invullen. Alle drie de uitkomsten zijn "het bestand ging open". Slechts één ervan vang je met luisteren, en alleen als je weet wat er had moeten staan.

De vier mankementen die de meeste afkeuringen verklaren

Een fmt -trackaantal dat niet strookt met chna. fmt .nChannels zegt 16; chna.numTracks zegt 14. Het bestand is al vanaf de eerste twee chunks intern inconsistent — meestal een bounce waarbij het aantal tracks veranderde nadat de metadata was gemaakt, of een tool dat tracks liet vallen zonder chna te herschrijven. De detectie is twee gehele getallen parsen en vergelijken: de goedkoopste controle in de pijplijn, en hij vangt een opvallend groot deel van de mankementen. Controleer meteen ook dat elke trackIndex binnen 1 … fmt .nChannels valt.

Een audioTrackUID waarnaar geen enkel object verwijst. Een UID in chna waar geen enkel audioObject naar verwijst, betekent dat er audio bestaat die niets zal renderen; het spiegelgeval, een audioTrackUIDRef in de XML zonder bijbehorende chna-regel, betekent dat metadata een track verwacht die er niet is. Bouw de verzameling UID's uit chna en die uit axml en neem het symmetrisch verschil; dat hoort leeg te zijn. EBU Tech 3392 stelt de bedoeling ronduit: "If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs."

Bloktiming die achteruit loopt. 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 aaneengeslotenheid — "rtime + duration of an audioBlockFormat should match the rtime of the following block" — met het eerste blok van een object beginnend op 00:00:00.00000, geen blok korter dan één sample, en duren die optellen tot het bovenliggende audioObject. Loop de blokken in documentvolgorde door en stel vast dat rtime[n] + duration[n] == rtime[n+1]. Mankementen komen in drie vormen voor: gaten, waar renderergedrag ongedefinieerd is en sommige de laatste positie vasthouden terwijl andere dempen; overlappingen, waar blokken met elkaar vechten; en blokken die niet chronologisch staan, wat neerkomt op automatisering die midden in het programma terugspringt.

Een bed dat in XML beschreven staat maar nooit naar schijf is weggeschreven. De XML declareert een 7.1.4-DirectSpeakers-pack — twaalf kanalen — maar alleen de 5.1-subset is weggeschreven, of de hoogtekanalen stonden bij het bouncen op mute en zijn als digital black weggeschreven. De referentiegraaf is intact; de audio niet. Structurele controles vangen dit niet: je hebt essence-analyse nodig, waarbij je meet of elk kanaal dat een DirectSpeakers-pack claimt überhaupt signaal bevat. Digital black op een gedeclareerd bedkanaal is niet automatisch een fout — een legitieme mix mag een top-rear-kanaal leeg laten — maar het verdient altijd een menselijke beslissing.

Wat er over immersive luidheid gepubliceerd is, en wat niet

Eén getal overleeft de stap weg van stereo niet, en het is de moeite waard te zeggen waarom.

BS.1770-5 (November 2023) is de huidige editie; BS.1770-4 is vervallen, ook al noemen de meeste in gebruik zijnde meters die nog. Het kernalgoritme weegt L, R en C met 1.0 en Ls en Rs met 1.41 (ongeveer +1.5 dB), sluit LFE uit, en heeft als bereik "from one to five channels". BS.1770-5 gaat daar in de bijlagen overheen en behandelt de geavanceerde geluidssystemen van BS.2051 en objectgebaseerde audio — die eerst gerenderd moet worden voordat ze gemeten kan worden. Immersive luidheid is daarom geen eigenschap van het bestand maar van een render, en een andere doelopstelling geeft een ander getal. Meet een BS.2127-conforme render naar een met naam genoemde BS.2051-opstelling met een BS.1770-5-meter en leg alle drie vast in je leveringsnotities; BS.2127 definieert de referentie-ADM-renderer, en zijn opensource-tegenhanger, de EBU ADM Renderer (EBU Tech 3388), is de praktische manier om aan een reproduceerbaar cijfer te komen.

Geen enkele muziekstreamingdienst publiceert een integrated-luidheidsdoel voor immersive levering. Er circuleren cijfers op fora en in trainingsmateriaal van leveranciers; geen daarvan is een gepubliceerde specificatie, en dit artikel gaat er geen herhalen alsof dat wel zo is. Wat wél gepubliceerd is, geldt voor kanaalgebaseerde stereo — Spotify's integrated-doel van −14 LUFS met een true-peak-plafond van −1 dBTP, aangescherpt tot −2 dBTP boven −14 LUFS, en de −16 LUFS van AES TD1008 voor muziek (het cijfer van −18 LUFS geldt voor spraakgedreven materiaal, en −18 als muziekdoel noemen is een veelvoorkomende en ernstige fout).

Dolby Atmos is een propriëtaire, gelicentieerde technologie van Dolby Laboratories, en Sony 360 Reality Audio is een propriëtair systeem gebouwd op MPEG-H. Hun eisen worden door hun eigenaren vastgesteld, veranderen los van de tijdlijnen van ITU of EBU, en staan hier niet vermeld; er wordt geen enkele band of goedkeuring geclaimd. Lees de eigen, actuele documentatie van de licentiegever.

Wat je controleert voordat je het opstuurt

Eerst de structurele controles; die zijn snel en ze maken al het overige ongeldig.

• De eerste vier bytes zijn BW64. Staat er RIFF, dan is het een gewone WAV en kan hij niet groter zijn dan 4 GB.
• ds64 is de eerste chunk na de signature, zijn 64-bits groottes komen overeen met de bestands- en data-groottes op schijf, en elke te grote niet-data-chunk heeft een ChunkSize64-regel in de tabel.
• Zoek axml expliciet op, ook ná data — concludeer nooit "geen ADM" op basis van een gedeeltelijke scan.
• Samplefrequentie en bitdiepte in fmt komen exact overeen met de leveringsspecificatie. Geen samplerateconversie ná het maken van de ADM — dat maakt elke rtime en duration die in samples is uitgedrukt ongeldig.
• fmt .nChannels is gelijk aan chna.numTracks; elke trackIndex valt binnen het bereik en is 1-gebaseerd.
• Elke chna-regel is precies 40 bytes met correct opgevulde velden van vaste breedte, en elke packRef vanaf 0x1000 verwijst naar een eigen definitie die in axml aanwezig is.
• Elke audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef en audioTrackUIDRef lost op. Nul bungelende verbindingen, in beide richtingen, zonder circulaire verwijzingen.
• Kanaalformaten met meerdere blokken dragen op elk blok zowel rtime als duration; blokken zijn aaneengesloten en monotoon; objecten beginnen op 00:00:00.00000.
• Elk kanaal van een gedeclareerd bed bevat wat het hoort te bevatten. Onderzoek digital black.
• De starttimecode in bext is consistent over de hele set, en stereo- en binaurale conforms zijn opnieuw gerenderd vanuit de huidige master. Een conform die 40 ms voorloopt op zijn immersive ouder komt door een controle op bestandsaanwezigheid en valt door de mand bij synchroon luisteren.
• Maak van elke levering een checksum, bewaar het manifest, en archiveer de ADM-XML apart van de BW64 — XML die je kunt diffen is later meer waard dan een binair bestand dat je alleen opnieuw kunt parsen.

BW64 en ADM zijn open, gepubliceerde, vrij leesbare standaarden, en daar valt gebruik van te maken: je kunt BS.2088 en BS.2076 zelf lezen, een chna-chunk parsen met veertig regels code, en nagaan wat de exporteur van een leverancier werkelijk heeft geschreven in plaats van wat zijn dialoogvenster beweerde. Vrijwel alle onnodige immersive afkeuringen zijn fouten in referentie-integriteit die een validator binnen een seconde vangt.

Mazufa's gratis BW64/ADM-inspector op mazufa.com/immersive-master-check parseert de container en de metadata volledig op je eigen apparaat en uploadt niets, waardoor hij bruikbaar is op materiaal dat contractueel het pand niet uit mag. Mazufa zelf is gratis om op te releasen, neemt 0% commissie, en werkt op uitnodiging met menselijke beoordeling van elke volledige aanvraag.

Bronnen

ITU-R Recommendations

• 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

EBU Technical documents

• 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/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
• libbw64, referentie-implementatie — 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/

Documentatie van diensten

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