Warum ein immersives Master im Wave-Editor durchgeht und an der QC scheitert

Eine immersive Lieferung kann sich in einem Wave-Editor öffnen, zwölf oder sechzehn gesund aussehende Spuren zeigen, vernünftig abspielen — und trotzdem abgelehnt werden. Der Grund ist struktureller Natur: In einer BW64-Datei sind Audio und Metadaten zwei getrennte Dinge, die exakt übereinstimmen müssen, und nichts im Format erzwingt das. Ein Renderer löst Referenzen auf. Ein Editor zeichnet Samples. Verschiedene Aufgaben — weshalb ADM-QC eine Prüfung der Referenzintegrität ist und kein Hinhören. Hier steht, was die beiden Standards sagen, wo die Referenzen brechen und welche Prüfung welchen Fehler abfängt.

Drei Arten von Audio, und warum die Unterscheidung alles entscheidet

Jedes Problem bei immersiven Lieferungen beginnt mit der Verwirrung darüber, welches von drei Dingen eine Spur eigentlich ist.

Kanalbasiertes Audio ordnet jede Spur einer festen Lautsprecherposition zu. Stereo ist kanalbasiert, 5.1 ebenso, ein 7.1.4-Bed ebenso. Die Position steckt fest in der Kanalidentität: Spur 3 ist der Centerlautsprecher, und sie ist der Centerlautsprecher auf jedem System, das sie abspielt. ITU-R BS.2051 formalisiert das für fortgeschrittene Tonsysteme und beschreibt Layouts als Anzahl der Ebenen Upper + Middle + Bottom — System A ist 0+2+0 (Stereo), System B ist 0+5+0 (5.1), System D ist 4+5+0, System J ist 4+7+0, System H ist 9+10+3, die 22.2-Konfiguration. Im ADM ist das die typeDefinition DirectSpeakers, typeLabel 0001.

Objektbasiertes Audio trägt ein Mono-Signal (oder einen Mehrkanal-Pack) plus Positionsmetadaten, die sich über die Zeit ändern. Der Renderer entscheidet anhand des im Raum vorhandenen Layouts, welche realen Lautsprecher es wiedergeben. Nichts an der Spur setzt einen Lautsprecher voraus. Das ist typeDefinition Objects, typeLabel 0003.

Szenenbasiertes Audio, in der Praxis Higher-Order Ambisonics, kodiert das gesamte Schallfeld als kugelflächenharmonische Komponenten. Keine Komponente entspricht für sich genommen einer Richtung; die Richtung entsteht erst aus der Linearkombination. Das ist HOA, typeLabel 0004. ADM definiert außerdem Matrix (0002) für matrizierte Signale wie Mid-Side oder Lt/Rt sowie Binaural (0005).

Die Unterscheidung ist keine Taxonomie. Eine kanalbasierte Lieferung beschreibt sich selbst gerade genug, um als nacktes WAV zu überleben — bring die Kanalreihenfolge in Ordnung, und sie spielt. Eine objekt- oder szenenbasierte Lieferung ist ohne ihre Metadaten bedeutungslos: Das Audio ist ein Haufen ununterscheidbarer Monoströme, und das ADM ist das Einzige, was etwas anderes behauptet. Diese Asymmetrie ist der Grund, warum es BW64 und ADM gibt.

BW64 existiert wegen einer 32-Bit-Zahl

Klassisches WAV ist eine RIFF-Datei. RIFF stellt jedem Chunk seit 1991 ein 32-Bit-Größenfeld voran. Zweiunddreißig Bit adressieren 4,294,967,296 Bytes — 4 GB — und das ist die harte Obergrenze sowohl für die gesamte Datei als auch für den data-Chunk darin.

Für Stereo mit 48 kHz / 24 Bit beträgt die Datenrate 288,000 Bytes pro Sekunde, 4 GB sind also etwa 4 Stunden 8 Minuten. Irrelevant. Für ein objektbasiertes Master mit 128 Spuren bei 96 kHz / 24 Bit liegt die Rate bei 36,864,000 Bytes pro Sekunde, und 4 GB sind unter zwei Minuten — 116.5 Sekunden.

Immersive Master überschreiten diese Grenze routinemäßig, und ein WAV-Writer, der dagegenstößt, erzeugt entweder eine abgeschnittene Datei oder eine, deren deklarierte Größen stillschweigend übergelaufen sind. Die EBU hat das zuerst mit RF64 (EBU Tech 3306) adressiert; die ITU hat es als Recommendation ITU-R BS.2088 weitergeführt — BW64.

Der Sentinel-Trick: 0xFFFFFFFF und ein ds64-Chunk

BS.2088 ist beim Mechanismus ausdrücklich. „The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file“, und die ursprünglichen 32-Bit-Größenfelder werden zu Escape-Flags: „If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead.“

Das ist der ganze Trick, und es lohnt sich, ihn klar auszusprechen: BW64 verbreitert die RIFF-Größenfelder nicht. Es füllt sie mit 0xFFFFFFFF als Sentinel und legt die echten 64-Bit-Größen in einen ds64-Chunk, der als Erster in der Datei stehen muss. Eine BW64-Datei unter 4 GB ist damit in jeder Hinsicht byteweise kompatibel mit einem WAV-Reader, außer bei der Vier-Zeichen-Signatur. Viele Werkzeuge akzeptieren sie; manche stur nicht.

Die Chunks, und der eine mit exakt 40 Bytes pro Eintrag

Nach BS.2088 wird von einer BW64-Datei erwartet, dass sie mindestens ds64, fmt , chna, axml (mit bxml und sxml als alternativen Metadatenträgern) und die Wave-Daten enthält.

ds64 muss der erste Chunk nach der Signatur sein, denn ein Reader muss die echten Größen kennen, bevor er irgendetwas anderes durchlaufen kann. Er trägt 32-Bit-Hälften (low/high) für die Gesamtdateigröße und die data-Größe sowie eine Tabelle von ChunkSize64-Einträgen für jeden anderen übergroßen Chunk — ein axml-Chunk, der Tausende von Objekten mit sample-genauer Automation beschreibt, kann selbst an 4 GB heranreichen oder sie überschreiten.

fmt ist der Standard-WAVE-Formatchunk — Sampleformat, Samplerate, Kanalanzahl, Bits pro Sample, Block-Align. Er ist die einzige verbindliche Aussage darüber, wie viele verschachtelte Kanäle in data liegen. Alles danach sind Metadaten über diese Kanäle, und Metadaten können lügen.

chna ist die Brücke zwischen physischen Spuren und dem ADM. Nach ckID, ckSize, einem 2-Byte-numTracks und einem 2-Byte-numUIDs enthält er ein flaches Array von audioID-Einträgen fester Breite, jeder exakt 40 Bytes:

2 + 12 + 14 + 11 + 1 = 40. Die Breiten sind keine Empfehlung: Es ist ASCII mit fester Breite, und ein Writer, der eine 13-Zeichen-UID ausgibt, hat eine korrupte Tabelle erzeugt, keine leicht ungewöhnliche.

Auch die ID-Konvention ist wichtig. Werte von 0x0FFF und darunter verweisen auf die ADM Common Definitions — die standardisierten, vordefinierten Kanal- und Packformate — während 0x1000 und darüber benutzerdefinierte Definitionen anzeigen, die in axml vorhanden sein müssen. AP_00010003 ist 5.1 nach Common Definition und braucht kein XML; AP_00031001 ist ein benutzerdefinierter Objekt-Pack und braucht XML, sonst hängt die Referenz in der Luft.

numUIDs darf außerdem legitim größer sein als numTracks: Die EBU-Richtlinie hält fest, dass dort, wo „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“, ein trackIndex in mehreren Einträgen auftauchen darf. QC-Werkzeuge, die eine UID pro Spur voraussetzen, melden korrekte Dateien als kaputt.

axml ist ein UTF-8-XML-Dokument, das den <audioFormatExtended>-Baum enthält. Das ist das ADM, und dort wohnen praktisch alle interessanten Fehler. data ist schlichtes verschachteltes PCM; nichts darin weiß irgendetwas über Objekte.

Zur Reihenfolge: ds64 immer zuerst; fmt vor data. Aber axml darf legitim nach data stehen und tut es oft, denn — wie BS.2088 anmerkt — während der Aufnahme „the XML metadata will likely be of an unknown length.“ Eine Datei mit axml am Ende ist nicht fehlerhaft, aber ein Reader, der nur das erste Megabyte scannt, meldet überhaupt kein ADM. Das erklärt einen überraschend großen Anteil der Meldungen „meine Datei hat keine Metadaten“.

ADM ist ein Graph, und Fehler sind gebrochene Kanten

Die Hierarchie von ITU-R BS.2076 verläuft audioProgramme → audioContent → audioObject → audioPackFormat → audioChannelFormat → audioBlockFormat, mit audioTrackUID als Blatt und als einzigem Element, das einer physischen Spur entspricht.

Das ist ein Referenzgraph und kein verschachteltes Dokument, und jeder ernste Lieferfehler ist eine gebrochene Kante darin. Gefährlich an einer ins Leere zeigenden Referenz ist, dass es kein einheitliches Verhalten gibt, wenn eine bricht. Ein Renderer, der einen audioPackFormatIDRef auflöst, der einen im XML fehlenden Pack benennt, kann den Parse abbrechen und die Datei ablehnen; er kann dieses Objekt überspringen und alles andere rendern, was eine Mischung ergibt, der still ein Stem fehlt; oder er kann auf die Common Definitions zurückfallen, dort eine ID im benutzerdefinierten Bereich ab 0x1000 ohne Entsprechung finden und Stille einsetzen. Alle drei Ausgänge sind „die Datei hat sich geöffnet“. Nur einer wird durch Hinhören entdeckt, und auch das nur, wenn du weißt, was dort hätte sein sollen.

Die vier Fehler, auf die die meisten Ablehnungen entfallen

Eine fmt -Spurzahl, die chna widerspricht. fmt .nChannels sagt 16; chna.numTracks sagt 14. Die Datei ist schon ab den ersten beiden Chunks in sich widersprüchlich — meist ein Bounce, bei dem sich die Spurzahl nach dem Erstellen der Metadaten geändert hat, oder ein Werkzeug, das Spuren entfernt hat, ohne chna neu zu schreiben. Die Erkennung besteht darin, zwei Ganzzahlen zu parsen und zu vergleichen: die billigste Prüfung der ganzen Kette, und sie fängt einen erstaunlichen Anteil der Fehler ab. Prüfe gleichzeitig, dass jeder trackIndex innerhalb von 1 … fmt .nChannels liegt.

Eine audioTrackUID, auf die kein Objekt verweist. Eine UID in chna, auf die kein audioObject verweist, bedeutet: Es existiert Audio, das nichts rendern wird; der Spiegelfall, ein audioTrackUIDRef im XML ohne passenden chna-Eintrag, bedeutet: Die Metadaten erwarten eine Spur, die es nicht gibt. Bilde die Menge der UIDs aus chna und die aus axml und nimm die symmetrische Differenz; sie sollte leer sein. EBU Tech 3392 formuliert die Absicht direkt: „If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs.“

Blocktiming, das rückwärts läuft. BS.2076 ist unmissverständlich: „When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present.“ EBU Tech 3392 verschärft das zur Lückenlosigkeit — „rtime + duration of an audioBlockFormat should match the rtime of the following block“ — wobei der erste Block eines Objekts bei 00:00:00.00000 beginnt, kein Block kürzer als ein Sample ist und die Dauern sich zum übergeordneten audioObject summieren. Laufe die Blöcke in Dokumentreihenfolge durch und prüfe rtime[n] + duration[n] == rtime[n+1]. Fehler treten in drei Formen auf: Lücken, bei denen das Rendererverhalten undefiniert ist und manche die letzte Position halten, während andere stummschalten; Überlappungen, bei denen Blöcke sich streiten; und Blöcke außerhalb der chronologischen Reihenfolge, also Automation, die mitten im Programm rückwärts springt.

Ein Bed, das im XML beschrieben, aber nie auf die Platte geschrieben wurde. Das XML deklariert einen 7.1.4-DirectSpeakers-Pack — zwölf Kanäle —, aber nur die 5.1-Teilmenge wurde geschrieben, oder die Höhenkanäle waren beim Bounce stumm und wurden als digitale Stille geschrieben. Der Referenzgraph ist intakt; das Audio nicht. Strukturprüfungen können das nicht abfangen: Du brauchst eine Essenzanalyse, die misst, ob jeder von einem DirectSpeakers-Pack beanspruchte Kanal überhaupt Signal enthält. Digitale Stille auf einem deklarierten Bed-Kanal ist nicht automatisch ein Fehler — eine legitime Mischung darf einen hinteren Höhenkanal leer lassen —, aber sie ist immer eine menschliche Entscheidung wert.

Was zu immersiver Lautheit veröffentlicht ist, und was nicht

Eine Zahl übersteht den Sprung von Stereo nicht, und es lohnt sich zu sagen, warum.

BS.1770-5 (November 2023) ist die aktuelle Ausgabe; BS.1770-4 ist überholt, auch wenn die meisten eingesetzten Messgeräte sie noch nennen. Der Kernalgorithmus gewichtet L, R und C mit 1.0 sowie Ls und Rs mit 1.41 (etwa +1.5 dB), schließt LFE aus und ist auf „from one to five channels“ begrenzt. BS.1770-5 geht in seinen Anhängen darüber hinaus und deckt die fortgeschrittenen Tonsysteme nach BS.2051 sowie objektbasiertes Audio ab — das gerendert werden muss, bevor es gemessen werden kann. Immersive Lautheit ist deshalb keine Eigenschaft der Datei, sondern eines Renderings, und ein anderes Ziel-Layout ändert die Zahl. Miss ein BS.2127-konformes Rendering auf ein benanntes BS.2051-Layout mit einem BS.1770-5-Messgerät und halte alle drei Angaben in deinen Lieferunterlagen fest; BS.2127 definiert den Referenz-ADM-Renderer, und sein quelloffenes Geschwister, der EBU ADM Renderer (EBU Tech 3388), ist der praktische Weg zu einer reproduzierbaren Zahl.

Kein Musikstreamingdienst veröffentlicht einen integrierten Lautheitszielwert für immersive Lieferungen. In Foren und Schulungsmaterial von Anbietern kursieren Zahlen; keine davon ist eine veröffentlichte Spezifikation, und dieser Artikel wird keine so wiedergeben, als wäre sie eine. Veröffentlicht ist, was für kanalbasiertes Stereo gilt — Spotifys integrierter Zielwert von −14 LUFS mit einer True-Peak-Grenze von −1 dBTP, verschärft auf −2 dBTP oberhalb von −14 LUFS, und AES TD1008 mit −16 LUFS für Musik (die Angabe −18 LUFS gilt dort für sprachdominierte Inhalte, und −18 als Musikzielwert anzugeben, ist ein häufiger und schwerwiegender Fehler).

Dolby Atmos ist eine proprietäre, lizenzierte Technologie der Dolby Laboratories, und Sony 360 Reality Audio ist ein proprietäres System auf Basis von MPEG-H. Ihre Anforderungen werden von ihren Eigentümern gesetzt, ändern sich ohne Rücksicht auf die Zeitpläne von ITU oder EBU und werden hier nicht wiedergegeben; es wird keine Verbindung oder Billigung behauptet. Lies die jeweils aktuelle Dokumentation des Lizenzgebers selbst.

Was du prüfst, bevor du lieferst

Strukturprüfungen zuerst; sie sind schnell und machen alles Nachgelagerte hinfällig.

• Die ersten vier Bytes sind BW64. Steht dort RIFF, ist es ein einfaches WAV und kann 4 GB nicht überschreiten.
• ds64 ist der erste Chunk nach der Signatur, seine 64-Bit-Größen stimmen mit der Datei- und der data-Größe auf der Platte überein, und jeder übergroße Chunk außer data hat einen ChunkSize64-Eintrag in der Tabelle.
• Suche axml ausdrücklich, auch nach data — schließe niemals aus einem Teilscan auf „kein ADM“.
• Samplerate und Bittiefe in fmt entsprechen exakt der Lieferspezifikation. Keine Samplerate-Konvertierung nach dem Erstellen des ADM — sie macht jede in Samples ausgedrückte rtime und duration ungültig.
• fmt .nChannels ist gleich chna.numTracks; jeder trackIndex liegt im gültigen Bereich und ist 1-basiert.
• Jeder chna-Eintrag hat exakt 40 Bytes mit korrekt aufgefüllten Feldern fester Breite, und jeder packRef ab 0x1000 löst sich auf eine in axml vorhandene benutzerdefinierte Definition auf.
• Jeder audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef und audioTrackUIDRef löst sich auf. Null hängende Kanten, in beide Richtungen, ohne zirkuläre Referenzen.
• Kanalformate mit mehreren Blöcken tragen auf jedem Block sowohl rtime als auch duration; die Blöcke sind lückenlos und monoton; Objekte beginnen bei 00:00:00.00000.
• Jeder Kanal eines deklarierten Beds enthält, was er enthalten soll. Digitale Stille untersuchen.
• Der bext-Starttimecode ist über den gesamten Satz hinweg konsistent, und Stereo- und Binaural-Conforms werden aus dem aktuellen Master neu gerendert. Ein Conform, das gegenüber seinem immersiven Elternteil 40 ms zu früh liegt, besteht eine Dateivorhandenheitsprüfung und scheitert am synchronen Hören.
• Bilde für jede Lieferdatei eine Prüfsumme, behalte das Manifest und archiviere das ADM-XML getrennt von der BW64 — XML, das du diffen kannst, ist später mehr wert als eine Binärdatei, die du nur neu parsen kannst.

BW64 und ADM sind offene, veröffentlichte, frei lesbare Standards, und das sollte man nutzen: Du kannst BS.2088 und BS.2076 selbst lesen, einen chna-Chunk mit vierzig Zeilen Code parsen und überprüfen, was der Exporter eines Anbieters tatsächlich geschrieben hat, statt dem zu glauben, was sein Dialogfenster behauptet hat. Fast alle unnötigen Ablehnungen immersiver Lieferungen sind Fehler der Referenzintegrität, die ein Validator in unter einer Sekunde findet.

Mazufas kostenloser BW64/ADM-Inspektor unter mazufa.com/immersive-master-check parst Container und Metadaten vollständig auf deinem eigenen Gerät und lädt nichts hoch, was ihn auf Material einsetzbar macht, das vertraglich das Haus nicht verlassen darf. Mazufa selbst ist kostenlos zum Veröffentlichen, nimmt 0% Kommission und ist nur auf Einladung zugänglich, mit menschlicher Prüfung jeder vollständigen Bewerbung.

Quellen

ITU-R-Empfehlungen

• 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-Fachdokumente

• EBU Tech 3306, RF64: An extended file format for audio data — https://tech.ebu.ch/docs/tech/tech3306.pdf
• EBU Tech 3285 (und Ergänzungen), 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-Referenzimplementierung — 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/

Dienstdokumentation

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