BW64 und ADM: technische Referenz für die Auslieferung immersiver Produktionen

Für Tonmeisterinnen und Tonmeister, die objekt- oder szenenbasierte Master aufbauen, und für Musikerinnen und Musiker, denen ein „immersives Deliverable" abverlangt wird, ohne dass jemand erklärt hätte, woraus es eigentlich besteht.

Die kurze Antwort

Das Audio Definition Model (ADM, Empfehlung ITU-R BS.2076) ist ein offenes Metadatenmodell, das beschreibt, was jede einzelne Spur einer Datei ist — ein Lautsprecherkanal, ein bewegtes Objekt oder eine Ambisonics-Komponente — und wie diese Spuren zu einem Programm zusammengesetzt werden. Getragen wird es als XML in einem BW64-Container (Empfehlung ITU-R BS.2088), einer 64-Bit-Erweiterung von RIFF/WAVE, die die 4-GB-Grenze der klassischen WAV-Datei überwindet. Immersive Auslieferungen fallen im QC durch, weil Audio und Metadaten zwei getrennte Dinge sind, die exakt übereinstimmen müssen, und weil das Dateiformat diese Übereinstimmung nirgends erzwingt. Eine Kanalzahl in fmt , die der chna-Tabelle widerspricht; eine audioTrackUID, auf die kein Objekt verweist; eine Blockfolge, deren Zeitachse rückwärts läuft; ein Bed, das im XML steht, aber nie auf die Platte geschrieben wurde — nichts davon sieht man in einem Wellenformeditor, und jedes davon ist für einen Renderer tödlich. ADM-QC ist Referenzprüfung, nicht Abhören.

1. ADM kommt aus dem Rundfunk — und das erklärt fast alles daran

Wer aus der Musikproduktion kommt und dem ADM zum ersten Mal begegnet, hält es für überkonstruiert. Sieben Hierarchieebenen, um zu sagen, dass eine Klarinette links hinten sitzt? Das ist eine berechtigte erste Reaktion, und sie geht an der Herkunft des Modells vorbei.

Das ADM wurde nicht in einem Musikstudio erfunden, sondern in der europäischen Rundfunkforschung. Die erste vollständige Spezifikation ist EBU Tech 3364, Audio Definition Model Metadata Specification, Version 1.0, Genf, Januar 2014. Ihre Begründung im Einleitungsabschnitt ist knapp und deutlich: „Audio for broadcasting and cinema is evolving towards an immersive and interactive experience which requires the use of more flexible audio formats." (EBU Tech 3364 v1.0) Die ITU übernahm diese Arbeit als Empfehlung BS.2076; die EBU hat anschließend entschieden, dass zur Vermeidung doppelter Normung „Recommendation ITU-R BS.2076 should exclusively be used" (Library of Congress, Sustainability of Digital Formats).

Der deutschsprachige Rundfunk steht mitten in dieser Vorgeschichte. Das Institut für Rundfunktechnik (IRT), 1956 gegründet und ab 1957 in Betrieb, war das gemeinsame Forschungsinstitut von ARD, ZDF, Deutschlandradio, ORF und SRG SSR; aus seiner Arbeit ging unter anderem der MUSICAM-Codec hervor, der 1992 als ISO MPEG-1 Layer II normiert wurde. Zum 31. Dezember 2020 kündigten alle Gesellschafter ihre Verträge, im März 2021 endete der Betrieb (Wikipedia: Institut für Rundfunktechnik). Die EBU-Empfehlung R 128 liegt in einer amtlichen deutschen Fassung vor, in der der Kern in einem Satz steht: „dass die Programmlautheit (‚Programme Loudness') auf den Zielwert -23,0 LUFS normalisiert werden soll" (EBU R 128, deutsche Fassung). Und die Ausbildung, die diese Kultur trägt, ist ebenfalls hier entstanden: 1949 gründete Erich Thienhaus in Detmold „das erste deutsche, musikalisch-akustische Institut zur Ausbildung von Tonmeistern" (Erich-Thienhaus-Institut, HfM Detmold). Objektbasierte Übertragung wird heute maßgeblich über MPEG-H 3D Audio realisiert, dessen Entwicklung am Fraunhofer IIS in Erlangen sitzt (Fraunhofer IIS, Audio und Medientechnologien).

Was folgt daraus praktisch? Der Rundfunk hat ein Problem, das die Musikproduktion so nicht kennt: Er muss dieselbe Sendung an Systeme ausliefern, die er nicht kennt, in Sprachfassungen, die er später ergänzt, mit Barrierefreiheits-Spuren, die getrennt gemischt werden. Deshalb trennt das ADM sauber zwischen einer Formatbeschreibung und einer Inhaltsbeschreibung. Tech 3364 formuliert das so:

„The model is divided into two sections, the content part, and the format part. The content part describes what is contained in the audio, so will describe things like the language of any dialogue, the loudness and so on. The format part describes the technical nature of the audio so it can be decoded or rendered correctly." — EBU Tech 3364 v1.0

Der Formatteil lässt sich schreiben, bevor auch nur ein Sample existiert; der Inhaltsteil erst danach. Genau diese Trennung wirkt im Musikkontext zunächst wie Bürokratie — bis zu dem Moment, in dem man dieselbe Aufnahme in einer Fassung mit und einer ohne Ansage, in einer Stereo- und einer 7.1.4-Version, mit stimmigen Zeitbezügen ausliefern soll. Dann ist sie das einzige, was den Vorgang beherrschbar hält. Merksatz für den Anfang: Wenn Ihnen eine ADM-Struktur zu kompliziert vorkommt, haben Sie den Anwendungsfall noch nicht getroffen, für den sie entworfen wurde.

2. Drei Arten von Audio, und warum die Unterscheidung das Format bestimmt

Kanalbasiertes Audio ordnet jede Spur einer festen Lautsprecherposition zu. Stereo ist kanalbasiert, 5.1 ebenso, und ein 7.1.4-„Bed" (im deutschen Sprachgebrauch sagt fast jeder Bed, gelegentlich Bett) auch. Die Position steckt in der Kanalidentität: Spur 3 ist der Center, auf jeder Anlage. ITU-R BS.2051 formalisiert das für fortgeschrittene Systeme und benennt Anordnungen als Zahlentripel Obere + Mittlere + Untere Ebene: System A ist 0+2+0 (Stereo), System B 0+5+0 (5.1), System D 4+5+0, System J 4+7+0, System H 9+10+3 — die 22.2-Konfiguration. Im ADM ist das die typeDefinition DirectSpeakers, typeLabel 0001.

Objektbasiertes Audio trägt ein Monosignal (oder ein mehrkanaliges Pack) plus Positionsmetadaten, die sich über die Zeit ändern dürfen. Welcher reale Lautsprecher das wiedergibt, entscheidet der Renderer anhand der tatsächlich vorhandenen Anordnung. typeDefinition Objects, typeLabel 0003.

Szenenbasiertes Audio, praktisch: Ambisonics höherer Ordnung, codiert das gesamte Schallfeld als Satz sphärisch-harmonischer Komponenten. Keine Komponente entspricht für sich einer Richtung; Richtung entsteht erst aus der Linearkombination. typeDefinition HOA, typeLabel 0004. Daneben kennt das ADM Matrix (0002) für matrizierte Signale wie M/S oder Lt/Rt und Binaural (0005).

Kanalbasiertes Audio sagt der Datei, wo die Lautsprecher stehen; objektbasiertes Audio weigert sich zu raten; szenenbasiertes Audio beschreibt das Feld statt der Quellen.

Der praktische Unterschied ist eine Asymmetrie: Ein kanalbasiertes Deliverable überlebt als nacktes WAV — Kanalreihenfolge stimmt, es klingt. Ein objekt- oder szenenbasiertes Deliverable ist ohne seine Metadaten bedeutungslos: Auf der Platte liegt ein Haufen undifferenzierter Monoströme, und einzig das ADM behauptet etwas anderes. Deshalb existieren BW64 und ADM, und deshalb ist immersives QC schwerer als Stereo-QC.

3. Der Konzertsaal: das Bed ist der Saal, die Objekte sind die Solisten

Der deutschsprachige Raum hat eine Aufnahmetradition, in der der Saal nicht Kulisse, sondern Gegenstand der Aufnahme ist. Wer ein Sinfonieorchester in einem Weinbergsaal aufnimmt — der Große Saal der Elbphilharmonie folgt „dem Prinzip einer ‚Weinberg-Architektur'" mit 2.100 Sitzplätzen, akustisch verantwortet von Yasuhisa Toyota, eröffnet am 11./12. Januar 2017 (Wikipedia: Elbphilharmonie) —, nimmt nicht Instrumente in einem Raum auf, sondern einen Raum, in dem Instrumente spielen.

Für die ADM-Struktur folgt daraus eine sehr klare Arbeitsteilung, und sie ist fast das Gegenteil dessen, was die Popmischung nahelegt:

1. Das Orchester ist keine Objektwolke. Es sitzt fest, die Sitzordnung ist geprobt, sie ändert sich innerhalb eines Satzes nicht. Was es gibt, ist eine stabile Geometrie — und stabile Geometrie ist genau der Fall, für den ein kanalbasiertes Bed erfunden wurde. Ein 7.1.4- oder 9.1.6-Bed aus Hauptmikrofon plus Stützen trägt Klangkörper und Saal in einer einzigen, in sich konsistenten Repräsentation.
2. Objekte sind die Ausnahmen, nicht die Regel. Die Solovioline im Konzert, der Bariton im Oratorium, die Fernorchestergruppe, das Off-Blech auf der Empore: Das sind Quellen, deren Position von der Tuttigeometrie abweicht oder sich ändert, und die im Nachhinein in Pegel und Ort verhandelbar bleiben sollen. Sie werden Objects, alles andere bleibt im Bed.
3. Die Höhenebene ist die Decke des Saals, kein Effekt. Das ist der Punkt, an dem sich klassische und populäre Produktion am deutlichsten trennen. Die oberen vier bis sechs Kanäle tragen in einer Saalaufnahme keine „Elemente", sondern die frühen Deckenreflexionen und den oberen Anteil des Nachhalls. Sie sind der akustische Grund, warum der Saal überhaupt so klingt. Wer sie mit Hall-Returns oder hochgezogenen Stützen füllt, weil sie sonst „leer" wirken, ersetzt die Messung durch eine Behauptung — und hört den Fehler auf einer korrekt aufgebauten 4+7+0-Anordnung sofort, auf Kopfhörern dagegen oft nicht.

Zwei Fallstricke, die in dieser Tradition regelmäßig auftreten:

• Laufzeit ist Information, kein Fehler. Zwischen einer Fernbläsergruppe auf dem Rang und dem Hauptmikrofon liegen leicht über dreißig Meter, also rund hundert Millisekunden Schalllaufzeit. Ein automatischer Phasenabgleich „für Sauberkeit" zerstört die Tiefenstaffelung, die das Objekt gerade codieren soll. Wenn Sie ausrichten, tun Sie es bewusst und dokumentieren Sie es.
• distance im ADM ist keine Entfernung in Metern. Der Parameter eines audioBlockFormat vom Typ Objects ist normiert, nicht metrisch. Er ersetzt niemals das real aufgenommene Verhältnis von Direkt- zu Diffusschall. Diese Arbeit leistet das Bed.

4. Die Orgel auf der Empore: ein Instrument, das räumlich zerlegt ist

Es gibt einen Fall, in dem die saubere Trennung „ein Instrument = ein Objekt" schon im Ansatz scheitert, und er ist im deutschen Sprachraum in jeder größeren Kirche zu besichtigen. Eine Orgel nach dem Werkprinzip ist ein einziges Instrument, das an mehreren Stellen des Raumes gleichzeitig steht.

Die Teilwerke sind räumlich definiert, nicht nur klanglich:

„Das Hauptwerk (HW, manchmal auch nur Werk genannt) ist das zentrale Teilwerk der Orgel mit den wichtigsten Pfeifen für das gewöhnliche Spiel." — „Das Rückpositiv (RP) … befindet sich oft im Rücken des Organisten in einem eigenen Gehäuse, meistens in der Emporenbrüstung." — „Das Oberwerk (OW), auch Kronwerk, befindet sich über dem Hauptwerk und bildet meist (nach dem Pedalwerk) den höchsten Punkt der Orgel." — „Das Brustwerk (BW) liegt direkt vor dem Spieler oberhalb des Spieltisches." — Das Pedalwerk ist „oft … in sogenannten Pedaltürmen untergebracht, die mit ihren langen Prospektpfeifen die Seiten der Orgel begrenzen." — Werk (Orgel))

Und zum Rückpositiv ausdrücklich: „Durch die Platzierung in der Brüstung erklingt es frei in den Kirchenraum. Dadurch ergibt sich für den Zuhörer ein unmittelbarerer Klang als bei den anderen Werken der Orgel." (Rückpositiv) Ein Fernwerk schließlich „befindet sich ‚fern' von den übrigen Werken einer Orgel, d. h. an einer anderen Stelle in einem Kirchenraum bzw. Konzertsaal."

Für die Auslieferung heißt das dreierlei:

Erstens ist der räumliche Kontrast zwischen den Werken kompositorisch gemeint. Ein Dialogsatz, in dem die rechte Hand im Rückpositiv und die linke im Hauptwerk registriert ist, ist eine Aussage über Ort, nicht nur über Farbe. Eine Mischung, die beide Werke auf dieselbe Position rendert, hat die Musik geglättet — technisch fehlerfrei, musikalisch falsch.

Zweitens ist die Höhe hier trivial real. Das Rückpositiv steht auf Brüstungshöhe und strahlt frei ab, das Oberwerk deutlich darüber, das Fernwerk unter Umständen im Chor oder im Gewölbe. Wer diese Werke als Objekte mit realistischer Elevation setzt, dokumentiert eine Tatsache. Der Fehler wäre, das statt eines Bed zu tun: Der Kirchenraum mit seinen fünf, sechs, acht Sekunden Nachhall ist kein Bündel von Punktquellen, sondern ein diffuses Feld. Er gehört in ein DirectSpeakers-Pack, gespeist aus Raummikrofonen in Schiff und Seitenemporen.

Drittens — der Punkt, an dem die meisten Orgelaufnahmen technisch straucheln: Der Wind- und Traktionsanteil, das Anblasgeräusch, die Mechanik sind Teil des Instruments und liegen im Nahfeld der Prospektmikrofone. Wenn Sie diese Mikrofone als Objekte setzen, wandert das Geräusch mit der Position. Auf einer 4+5+0-Anordnung fällt das nicht auf; auf 9+10+3 sitzt es plötzlich exakt dort, wo es hingehört oder eben nicht. Prüfen Sie Nahmikrofon-Objekte immer auf der größten Zielanordnung, nicht auf der kleinsten.

5. Berliner Elektronik: der Gegenpol, und das umgekehrte Risiko

Die Technokultur in Berlin ist seit 2024 im bundesweiten Verzeichnis des Immateriellen Kulturerbes eingetragen; die Deutsche UNESCO-Kommission beschreibt sie als „eine Subkultur rund um den Musikstil Techno, eine Form der elektronischen Tanzmusik" (Deutsche UNESCO-Kommission). Für dieses Dokument ist sie aus einem präzisen Grund interessant: Sie ist der exakte methodische Gegenpol zur Saalaufnahme.

Im Konzertsaal und in der Kirche ist objektbasiertes Authoring eine Dokumentation der Wirklichkeit. Die Positionen existieren vor der Mischung, und die Aufgabe des Ingenieurs ist, sie nicht zu verlieren. In einer Berliner Produktion mit vollsynthetischen Quellen existiert überhaupt keine Position, die man verlieren könnte. Ein Kick aus einem Sampler, eine Fläche aus einem modularen System, ein Sub-Bass, den es als physisches Ereignis nie gegeben hat — für diese Signale ist eine Position eine kompositorische Entscheidung, kein Messwert. Das ist völlig legitim und in vielen Fällen der eigentliche Reiz des Formats.

Nur ist das Risiko hier das genaue Gegenteil, und es ist ein technisches:

• Alles zum Objekt zu machen, weil man es kann. Wenn jede der 64 Spuren ein audioObject mit eigener Automation wird, entsteht eine Datei, die formal gültig und praktisch unbeherrschbar ist. Auf einer kleinen Anordnung faltet der Renderer diese Objekte auf wenige Lautsprecher zusammen; was in 9.1.6 als Bewegung wirkte, wird in 5.1.2 zu Pegel-Modulation. Die Regel, die sich bewährt: Ein Objekt pro Quelle, die sich wirklich bewegt oder wirklich woanders sitzt — alles andere in ein Bed. Ein statisches Pad gehört ins Bed, auch wenn es breit ist.
• Automation ohne Bezug zur Blockstruktur. Eine kontinuierlich modulierte Position wird beim Export in audioBlockFormat-Sequenzen zerlegt. Eine LFO-gesteuerte Kreisbewegung mit hoher Rate erzeugt tausende Blöcke pro Minute; die axml wächst entsprechend (siehe §7.1, warum das ausgerechnet in BW64 relevant wird), und Renderer interpolieren zwischen Blöcken unterschiedlich. Bewegungen, die musikalisch zählen, sollten so grob quantisiert sein, dass sie jeder konforme Renderer gleich wiedergibt.
• Sub-Bass und LFE sind nicht dasselbe. Ein tief modulierter Bass als Objekt wird vom Renderer auf die Hauptlautsprecher verteilt, deren Tieftonfähigkeit unbekannt ist. Der LFE-Kanal ist Teil des Bed und wird nicht gerendert. Wer beides verwechselt, liefert etwas ab, das im eigenen Studio funktioniert und sonst nirgends.

6. BW64: was es ist und die Arithmetik der 4-GB-Grenze

Klassisches WAV ist eine RIFF-Datei. RIFF, 1991, stellt jedem Chunk ein 32-Bit-Größenfeld voran. 32 Bit adressieren 4.294.967.296 Bytes — 4 GiB — und das ist die harte Obergrenze sowohl für die Datei insgesamt als auch für den data-Chunk.

Rechnen wir das für vier realistische Fälle durch (Datenrate = Kanäle × Bytes pro Sample × Abtastrate; 24 Bit = 3 Bytes):

Für Stereo ist die Grenze irrelevant. Für eine Bruckner-Sinfonie von 90 Minuten in der dritten Zeile ergeben sich 5.400 s × 8.064.000 B/s = 43.545.600.000 Bytes, also rund 43,5 GB und damit gut das Zehnfache (10,1×) dessen, was RIFF adressieren kann. Ein WAV-Writer, der an diese Grenze stößt, liefert entweder eine abgeschnittene Datei oder eine, deren Größenfelder still übergelaufen sind — und Letzteres bemerkt man erst beim Empfänger.

Die EBU löste das zuerst mit RF64 (EBU Tech 3306). Die ITU führte diese Arbeit als Empfehlung ITU-R BS.2088 weiter, Long-form file format for the international exchange of audio programme materials with metadata — BW64. Der Mechanismus steht dort ausdrücklich: „The ID ‚BW64' is used instead of ‚RIFF' in the first four bytes of the file", und die alten 32-Bit-Felder werden zu Escape-Markierungen — „If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the ‚ds64' chunk is used instead."

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 zwingend am Anfang steht.

BW64 ist die dritte Generation einer Linie: RIFF/WAVE brachte den Chunk-Container; Broadcast Wave (BWF, EBU Tech 3285) ergänzte den bext-Chunk mit Urheber, Timecode-Referenz und Coding History; BW64 behält beides, ergänzt 64-Bit-Adressierung und die Chunks, die das ADM tragen. Eine BW64-Datei unter 4 GiB ist zu einem WAV-Leser byteweise kompatibel — außer in den vier Signaturbytes. Manche Werkzeuge akzeptieren sie deshalb, andere hartnäckig nicht.

7. Der Chunk-Aufbau, konkret

Eine BW64-Datei enthält nach BS.2088 mindestens <ds64-ck>, <fmt-ck>, <chna-ck>, <axml-ck> (alternativ <bxml-ck> oder <sxml-ck>) sowie <wave-data>.

7.1 ds64 — die Tabelle der 64-Bit-Größen

Muss der erste Chunk nach der BW64-Signatur sein, weil ein Leser die tatsächlichen Größen kennen muss, bevor er irgendetwas anderes ablaufen kann. Die Felder sind 32-Bit-Hälften von 64-Bit-Größen:

Die Tabelle table[] ist wichtiger, als sie aussieht. Eine axml, die tausende Objekte mit sampleweiser Automation beschreibt — der Fall aus §5 —, kann selbst an 4 GiB heranreichen. Nur über diese Tabelle kann ein anderer Chunk als data überhaupt eine 64-Bit-Größe deklarieren.

7.2 fmt — die Beschreibung der Essenz

Der übliche WAVE-Format-Chunk: Sampleformat, Abtastrate, Kanalzahl, Bittiefe, Block Align. Dies ist die einzige verbindliche Aussage darüber, wie viele verschachtelte Kanäle tatsächlich in data liegen. Alles Weitere ist Metadatum über diese Kanäle — und Metadaten können lügen.

7.3 chna — die Kanalzuordnungstabelle und die 40 Bytes

chna ist die Brücke zwischen physischen Spuren und dem ADM. Der Kopf:

• ckID — 4 Bytes, 'chna'
• ckSize — 4 Bytes
• numTracks — 2 Bytes, Anzahl Spuren
• numUIDs — 2 Bytes, Anzahl folgender audioTrackUID-Einträge

Danach ein flaches Array von audioID-Einträgen fester Breite. Jeder Eintrag ist exakt 40 Bytes lang:

Nachgerechnet: 2 + 12 + 14 + 11 + 1 = 40. Die Zeichenketten sind ASCII fester Breite, nicht Richtwerte. ATU_00000001 sind genau 12 Zeichen, AT_00031001_01 genau 14, AP_00031001 genau 11 — ein Writer, der eine 13 Zeichen lange UID schreibt, hat keine ungewöhnliche, sondern eine defekte Tabelle erzeugt.

Der Umfang ist damit exakt vorhersagbar. Für das Beispiel aus §6 — 7.1.4-Bed plus 16 Objekte, also 28 Spuren mit je einer UID — gilt: Kopf 4 + 4 + 2 + 2 = 12 Bytes, Einträge 28 × 40 = 1.120 Bytes, Chunk gesamt 1.132 Bytes. Wenn Ihr Parser bei 28 Spuren nicht auf 1.132 kommt, stimmt eine Feldbreite nicht.

Beachten Sie außerdem die ID-Konvention: Werte bis einschließlich 0x0FFF verweisen auf die Common Definitions des ADM, also die vordefinierten Standard-Kanal- und -Packformate; Werte ab 0x1000 kennzeichnen kundenspezifische Definitionen, die zwingend in der axml stehen müssen. AP_00010003 ist per Common Definition 5.1 und braucht kein XML; AP_00031001 ist ein eigenes Objekt-Pack und hängt ohne XML in der Luft.

Eine Track-UID ist die Seriennummer, unter der die Datei die Identität einer physischen Spur führt — und sie existiert, damit eine Spur mitten im Programm rechtmäßig etwas anderes tragen darf.

Das ist der Grund, weshalb numUIDs größer als numTracks sein darf: Wenn „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" (EBU ADM Guidelines). Ein trackIndex darf also mehrfach auftauchen. QC-Werkzeuge, die stur eine UID je Spur erwarten, melden korrekte Dateien als defekt.

7.4 axml — das ADM selbst

Ein XML-Dokument in UTF-8 mit dem Baum <audioFormatExtended>. Das ist das ADM. Es ist Text, es ist lesbar, und praktisch alle interessanten Fehler wohnen dort.

7.5 data — das verschachtelte PCM

Schlichte Interleaved-Samples wie im WAV. Nichts in data weiß irgendetwas von Objekten.

7.6 Reihenfolge — und die Falle, in die alle tappen

ds64 immer zuerst. fmt vor data. **axml darf legitim nach data stehen** und tut es oft, denn während der Aufnahme ist, wie BS.2088 anmerkt, die Länge der XML-Metadaten noch unbekannt. Eine Datei mit axml am Ende ist nicht fehlerhaft — aber ein Leser, der nur das erste Megabyte durchsucht, meldet „keine ADM-Metadaten gefunden". Ein überraschend großer Teil aller entsprechenden Fehlermeldungen hat genau diese Ursache und keine andere.

8. Das ADM-Objektmodell: ein Graph aus Referenzen

Die Hierarchie nach BS.2076, von oben nach unten:

• audioProgramme — eine vollständige Präsentation. Verweist auf ein oder mehrere audioContent.
• audioContent — ein redaktionell bedeutsamer Bestandteil: Musikstem, Sprachfassung, Kommentarspur. Verweist auf audioObject.
• audioObject — die Nahtstelle zwischen redaktioneller Absicht und technischem Format. Trägt Startzeit und Dauer und verweist auf audioPackFormat, verschachtelte audioObject und audioTrackUID. Hier trifft Inhalt auf Essenz.
• audioPackFormat — eine Gruppe zusammengehöriger Kanäle: ein 7.1.4-Bed, ein Stereopaar, ein HOA-Satz einer Ordnung. Packs dürfen verschachtelt werden.
• audioChannelFormat — das Verhalten eines Kanals über die Zeit. Enthält ein oder mehrere audioBlockFormat.
• audioBlockFormat — das Atom. Für Objects: Position (azimuth/elevation/distance oder kartesisch X/Y/Z), Gain, Größe, Diffusität sowie rtime und duration. Ein statisches Objekt ist ein Block, ein bewegtes eine Folge.
• audioTrackUID — das Blatt und das einzige Element, das einer physischen Spur entspricht. Kann sampleRate und bitDepth tragen.

audioStreamFormat und audioTrackFormat liegen zwischen Kanalformat und Track-UID und beschreiben die Stromcodierung. BS.2076-3 hält fest, dass sie für PCM entbehrlich sind — „the audioStreamFormat and the audioTrackFormat should be omitted" —, dass Leser aber damit rechnen müssen, dass ältere Dateien nach BS.2076-2 und früher sie enthalten. Beide Formen sind gültig. Ein Validator, der auf einer besteht, irrt sich über die andere.

Das ADM ist ein Graph aus Referenzen, kein verschachteltes Dokument — und jeder ernsthafte Auslieferungsfehler ist eine gebrochene Kante in diesem Graphen.

Was passiert, wenn eine Referenz ins Leere zeigt? Genau das ist das Problem: nichts Einheitliches. Ein Renderer, der eine audioPackFormatIDRef auf ein im XML fehlendes Pack auflöst, kann (a) den Parse abbrechen und die Datei zurückweisen, (b) dieses eine Objekt überspringen und den Rest rendern — Ergebnis ist eine Mischung, der still ein Stem fehlt —, oder (c) auf die Common Definitions zurückfallen, dort im Bereich ab 0x1000 nichts finden und Stille einsetzen. In allen drei Fällen gilt: „Die Datei ließ sich öffnen." Nur einer davon fällt beim Abhören auf, und auch das nur, wenn man weiß, was hätte da sein sollen. Deshalb muss ADM-QC automatisiert werden: Ein Ohr kann keine Abwesenheit hören, von der es nichts weiß.

9. Rendering: BS.2127 auf BS.2051-Anordnungen

Ein objektbasiertes Master ist kein Klangergebnis, sondern eine Anweisung. Erst der Renderer macht daraus Lautsprechersignale, und welche, hängt von der Zielanordnung ab. ITU-R BS.2127 definiert den Referenz-Renderer für ADM auf den fortgeschrittenen Systemen der BS.2051; die quelloffene Umsetzung EBU ADM Renderer (EAR, EBU Tech 3388) ist der praktische Weg zu einem reproduzierbaren Ergebnis.

Drei Konsequenzen, die in der Praxis unterschätzt werden:

1. Es gibt kein „das" Rendering. Dasselbe Objekt in 4+5+0 und in 9+10+3 erzeugt unterschiedliche Signale — unterschiedliche beteiligte Lautsprecher, unterschiedliche Verteilungsgewichte, unterschiedliche wahrgenommene Quellbreite. Was Sie prüfen, müssen Sie benennen.
2. Downmix ist ein Rendering, kein Nebenprodukt. Die Stereo- und Binauralfassungen sollten aus dem aktuellen Master gerendert und nicht aus einer früheren Version fortgeschrieben werden. Zeitversatz zwischen Master und Konform ist der häufigste Befund, der eine formal saubere Lieferung wertlos macht.
3. Binaural ist eine Kontrolle, kein Ersatz. Ein binauraler Render zeigt zuverlässig grobe Fehler — vertauschte Kanäle, ein stummes Bed, ein Objekt, das an der falschen Seite steht. Er zeigt nicht zuverlässig Timbre und Diffusfeld auf einer realen Anordnung. Für die Fälle aus §3 und §4 heißt das: Er taugt zur Verifikation, nicht zur Mischentscheidung über die Höhenebene.

10. Lautheit immersiver Inhalte nach BS.1770-5

Hier ist die Trennung zwischen Veröffentlichtem und Kursierendem besonders wichtig.

10.1 Was die Empfehlung festlegt

ITU-R BS.1770 liegt in sechs Ausgaben vor: -0 (2006), -1 (2007), -2 (2011), -3 (2012), -4 (2015) und -5 (November 2023). In Kraft ist BS.1770-5; BS.1770-4 ist überholt, auch wenn die Mehrzahl der ausgelieferten Messgeräte noch -4 auf dem Bildschirm nennt. Nennen Sie stets -5 als geltende Ausgabe.

Die Mechanik:

• K-Bewertung in zwei Stufen: zuerst ein Hochtonshelf („Head"-Filter, Modell einer starren Kugel), danach ein Hochpass (RLB).
• Verstärkung der K-Bewertungskurve bei 1 kHz: +0,698 dB (linear 1,0836).
• Messblöcke von 400 ms mit 75 % Überlappung.
• Absolutes Gate: Blöcke unter −70 LUFS werden verworfen.
• Relatives Gate: berechnet aus dem Mittelwert derjenigen Blöcke, die das absolute Gate überstanden haben, versetzt um −10 LU. Es ist nicht der ungegatete Mittelwert. Diese Unterscheidung wird oft falsch implementiert und falsch wiedergegeben.
• Loudness Range (LRA) nach EBU Tech 3342 verwendet ein relatives Gate von −20 LU, nicht −10 LU. Wer für LRA −10 einsetzt, hat einen klassischen Implementierungsfehler.
• Short-term 3 s, Momentary 400 ms (EBU Tech 3341).
• True Peak wird auf einem überabgetasteten Signal gemessen, nach BS.1770 mindestens 4×, besser 8×. Sample Peak ≠ True Peak; Intersample-Peaks können den höchsten Samplewert überschreiten.

Die Kanalgewichtung des Kernalgorithmus beträgt 1,0 (0 dB) für L, R und C sowie 1,41 (≈ +1,5 dB) für Ls und Rs; LFE bleibt ausgeschlossen. Der Basisalgorithmus ist auf „from one to five channels" ausgelegt. BS.1770-5 geht in seinen Anhängen darüber hinaus und behandelt die fortgeschrittenen Systeme der BS.2051 — beliebig positionierte Lautsprecher und Höhenkanäle — sowie objektbasiertes Audio, das vor jeder Messung gerendert werden muss.

Immersive Lautheit ist keine Eigenschaft der Datei, sondern eine Eigenschaft eines Renderings. Ändern Sie die Zielanordnung, ändert sich der Messwert.

Das ist der substanzielle Unterschied zu Stereo. Ein Stereomaster hat einen Lautheitswert. Ein objektbasiertes Master hat so viele, wie es Zielanordnungen gibt. Die einzige ehrliche Angabe nennt deshalb immer drei Dinge: Anordnung, Renderer, Messnorm.

10.2 Was für Musik veröffentlicht ist

Für kanalbasierte Stereomusik veröffentlicht Spotify ein integriertes Ziel von −14 LUFS und eine True-Peak-Grenze von −1 dBTP, verschärft auf −2 dBTP für Master, die lauter als −14 LUFS sind (Spotify, Loudness normalization). AES TD1008 empfiehlt −16 LUFS für Musik; die dort ebenfalls genannten −18 LUFS gelten für sprachgeführte Inhalte — Nachrichten, Talk, Hörspiel. Die Angabe „−18 LUFS ist das Musikziel" ist ein verbreiteter und ernster Fehler.

EBU R 128 setzt für den Rundfunk −23,0 LUFS („Die zulässige Abweichung vom Zielwert soll generell ±1,0 LU nicht überschreiten", deutsche Fassung). R 128 ist eine Rundfunkpraxis und kein Streaming-Ziel — auch wenn im deutschsprachigen Raum viele Werkzeuge und viele Reflexe zuerst darauf zeigen.

Zur Wirkungsweise: Dienste normalisieren bei der Wiedergabe. Ein Master über dem Ziel wird um die Differenz leiser gemacht. Aufwärtsnormalisierung existiert, ist aber bedingt: Spotify schreibt, „Positive gain is applied to softer masters so the loudness level is -14 dB LUFS", zugleich aber „We consider the headroom of the track, and leave 1 dB headroom for lossy encodings to preserve audio quality." Ein leises Master mit hohen Spitzen wird also möglicherweise nicht vollständig angehoben. Beide verbreiteten Kurzfassungen — „leise Master werden nicht angehoben" und „leise Master werden immer aufs Ziel angehoben" — sind falsch. Praktische Folge: Überlimitierung kauft keine Lautstärke, sondern Flachheit. Für die Aufnahmen aus §3 und §4, deren Wert in der Dynamik liegt, ist das kein akademischer Punkt.

10.3 Was nicht veröffentlicht ist

Kein Musikstreamingdienst veröffentlicht ein integriertes Lautheitsziel für immersive Auslieferung. In Foren und Schulungsunterlagen kursieren Zahlen; einige sind plausibel, manche wahrscheinlich richtig. Keine davon ist eine veröffentlichte Spezifikation, und dieses Dokument gibt keine davon als solche wieder.

Auch für Stereo gilt das für einen Großteil des Marktes: Apple Music, YouTube Music, Amazon Music, TIDAL und Deezer veröffentlichen kein Normalisierungsziel. Die kursierenden Werte (Apple ≈ −16, YouTube Music ≈ −14, Amazon ≈ −14, TIDAL ≈ −14, Deezer ≈ −15) sind weithin berichtet, aber vom Dienst nicht veröffentlicht. Behandeln Sie sie nie als Spezifikation und rechnen Sie aus ihnen keine Pegeländerung aus.

Wenn Sie heute eine belastbare immersive Lautheitsangabe brauchen: Messen Sie ein BS.2127-konformes Rendering auf eine benannte BS.2051-Anordnung mit einem BS.1770-5-Messgerät und schreiben Sie alle drei Angaben in die Lieferunterlagen.

10.4 Zu proprietären Systemen

Dolby Atmos ist eine proprietäre, lizenzierte Technologie der Dolby Laboratories; Sony 360 Reality Audio ist ein proprietäres System auf Basis von MPEG-H. Ihre Lieferanforderungen setzen die Eigentümer, unabhängig von den Zeitplänen von ITU und EBU. Nichts in diesem Dokument ist eine Aussage über die Anforderungen dieser Unternehmen; eine Zusammenarbeit, Zertifizierung oder Billigung wird weder behauptet noch impliziert. Wo ein Lizenzgeber eine Anforderung veröffentlicht, gilt dessen eigene aktuelle Dokumentation.

11. Die ehrliche Lage: Sie hören wahrscheinlich nicht immersiv ab

Auch in Deutschland, Österreich und der Schweiz — mit ihrer vergleichsweise dichten Landschaft aus Rundfunkanstalten, Hochschulstudios und Postproduktionshäusern — ist eine korrekt aufgebaute, eingemessene 7.1.4- oder 9.1.6-Regie außerhalb dieser Häuser selten. Die meisten Menschen, die eine immersive Datei abliefern müssen, arbeiten an Stereolautsprechern und einem Kopfhörer.

Das ist kein Grund, das Format zu meiden, aber es verschiebt, wo Ihre Sorgfalt hingehört. Wenn Sie nicht verlässlich abhören können, ist Ihr Beitrag zur Qualität nicht die Mischentscheidung im Höhenkanal, sondern:

• korrekte Auslieferung — der Container ist gültig, die Größen stimmen, die Datei ist vollständig;
• korrekte Metadaten — der Referenzgraph löst vollständig auf, die Zeiten sind lückenlos, die Typen passen zusammen;
• Verifikation ohne Abhören — nachweisen, dass in jedem deklarierten Bed-Kanal Signal liegt, dass jedes Objekt einen Block hat, dass jede UID ein Ziel hat.

Genau diese drei Dinge lassen sich vollständig maschinell prüfen, und genau daran scheitern die meisten Lieferungen. Ein kostenloses, im Browser laufendes BW64/ADM-Prüfwerkzeug auf mazufa.com liest Container und Metadaten vollständig auf Ihrem eigenen Gerät und lädt nichts hoch, was es auch für Material brauchbar macht, das das Haus vertraglich nicht verlassen darf.

12. Typische QC-Fehler und wie man sie erkennt

12.1 Kanalzahl-Widerspruch zwischen fmt und chna. fmt.nChannels sagt 16, chna.numTracks sagt 14. Meist ein Bounce, der die Spurzahl nach dem Authoring geändert hat. Erkennung: beide Chunks parsen, Ganzzahlen vergleichen, und prüfen, dass jeder trackIndex in 1 … fmt.nChannels liegt. Die billigste Prüfung der ganzen Kette, mit erstaunlicher Trefferquote.

12.2 Verwaiste Track-UIDs. Eine UID in chna, auf die kein audioObject verweist, oder eine audioTrackUIDRef im XML ohne Eintrag in chna. Erkennung: symmetrische Differenz beider Mengen bilden; sie muss leer sein. EBU Tech 3392 formuliert die Absicht: „If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs."

12.3 Fehlende oder nicht monotone Blockzeiten. BS.2076 ist eindeutig: „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" —, mit 00:00:00.00000 als Beginn des ersten Blocks und der Summe der Dauern gleich der Dauer des übergeordneten audioObject. Erkennung: Blöcke in Dokumentreihenfolge durchlaufen und rtime[n] + duration[n] == rtime[n+1] prüfen. Die Fehler treten in drei Formen auf: Lücken (Renderer-Verhalten undefiniert — manche halten die letzte Position, manche schalten stumm), Überlappungen und rückwärts laufende Blöcke.

12.4 Falsche Abtastrate oder Bittiefe. Widersprechen sampleRate/bitDepth einer audioTrackUID dem fmt , existieren zwei Behauptungen über dieselbe Essenz. Tech 3392 sagt, sie „should be ignored if available from the audio essence" — aber nicht jeder Renderer hält sich daran. Wichtiger noch: Eine Abtastratenwandlung nach dem ADM-Authoring entwertet jede in Samples ausgedrückte rtime und duration.

12.5 Konforme Stereo-/Binauralfassung fehlt oder driftet. Fehlen fällt auf, Drift nicht. Eine Stereofassung, die 40 ms vor dem immersiven Master liegt, besteht jede Existenzprüfung und fällt beim synchronen Hören durch. Erkennung: Dauern sampleweise vergleichen, bext-Startzeitcode vergleichen, Kreuzkorrelation gegen ein Rendering des Masters. Alles, was nicht nachweislich aus dem aktuellen Master abgeleitet ist, neu rendern statt nachprüfen.

12.6 Metadaten beschreiben ein Bed, das nicht in der Datei ist. Das XML deklariert ein 7.1.4-DirectSpeakers-Pack — zwölf Kanäle —, gedruckt wurde aber nur die 5.1-Teilmenge, oder die Höhenkanäle waren beim Bounce stumm und liegen als digitale Null vor. Der Referenzgraph ist intakt, das Audio nicht. Erkennung: Strukturprüfung hilft nicht; hier braucht es Essenzanalyse — für jeden vom Pack beanspruchten Kanal messen, ob überhaupt Signal vorhanden ist. Digitale Null ist nicht automatisch ein Fehler (siehe §3: ein leerer hinterer Höhenkanal kann eine Mischentscheidung sein), aber immer eine menschliche Entscheidung wert.

12.7 typeLabel-Bruch zwischen Kanal und Pack. Ein audioChannelFormat mit typeLabel 0003 in einem Pack mit 0001 ist ein Objekt, das in einem Bed steckt. Manche Renderer akzeptieren das stillschweigend und rendern falsch.

Der Container kann vollkommen gültig, das XML vollkommen wohlgeformt und die Lieferung trotzdem falsch sein. Für einen leeren Bed-Kanal gibt es nur eine Prüfung: in die Samples schauen.

13. Checkliste für die Auslieferung

Der Reihe nach abarbeiten. Strukturprüfungen zuerst — sie sind schnell und entwerten alles Nachgelagerte.

Container

1. Erste vier Bytes sind BW64. Stehen dort RIFF, ist es ein gewöhnliches WAV und kann 4 GiB nicht überschreiten.
2. ds64 ist der erste Chunk nach der Signatur; seine 64-Bit-Größen stimmen mit Datei- und data-Größe auf der Platte überein.
3. Jeder übergroße Chunk außer data hat einen ChunkSize64-Eintrag in der ds64-Tabelle.
4. axml gezielt suchen, auch hinter data. Aus einem Teilscan nie „kein ADM" schließen.

Essenz

1. Abtastrate und Bittiefe in fmt entsprechen exakt der Lieferspezifikation. Keine SRC nach dem Authoring.
2. fmt.nChannels = chna.numTracks.
3. Jeder trackIndex liegt im gültigen Bereich und ist 1-basiert.

chna

1. Jeder Eintrag genau 40 Bytes; Feldbreiten korrekt aufgefüllt; Chunkgröße = 12 + 40 × Einträge.
2. Jede packRef ab 0x1000 löst auf eine im axml vorhandene eigene Definition auf.
3. Mehrfach auftretende trackIndex-Werte sind beabsichtigt (Spur wechselt Definition), keine Duplikate.

ADM-Graph

1. Jede audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef und audioTrackUIDRef löst auf. Null hängende Kanten.
2. Keine verwaisten audioTrackUID in beiden Richtungen.
3. Keine zirkulären oder selbstbezüglichen Elemente.
4. typeLabel jedes audioChannelFormat passt zum übergeordneten audioPackFormat.

Zeit

1. Mehrblockige Kanalformate tragen auf jedem Block rtime und duration.
2. Blöcke lückenlos und monoton; Summe der Dauern = Dauer des audioObject.
3. Objekte beginnen bei 00:00:00.00000.

Inhalt

1. Jeder Kanal eines deklarierten Bed enthält, was er soll; digitale Null untersuchen.
2. Objektzahl und Bed-Konfiguration entsprechen der Spezifikation.
3. bext-Startzeitcode korrekt und über alle Dateien des Lieferpakets konsistent.

Renderings und Konforme

1. Stereo- und Binauralfassungen aus dem aktuellen Master neu gerendert.
2. Dauern und Startzeitcodes sampleweise deckungsgleich mit dem Master.
3. Lautheit gemessen auf einem benannten Rendering, einer benannten Anordnung, mit einem benannten Renderer — alle drei in den Lieferunterlagen notiert.

Nachvollziehbarkeit

1. Prüfsummen über alle Dateien, Manifest aufbewahren.
2. Session und ADM-XML getrennt von der BW64 archivieren. Ein XML, das man diffen kann, ist später mehr wert als eine Binärdatei, die man nur neu parsen kann.

Ein immersives Deliverable ist nicht fertig, wenn es richtig klingt. Es ist fertig, wenn eine Maschine, die es nie gehört hat, beweisen kann, dass seine Referenzen auflösen.

14. Schluss

BW64 und ADM sind offene, veröffentlichte, frei lesbare Normen. Das ist in dieser Ecke der Branche ungewöhnlich, und man sollte es nutzen: BS.2088 und BS.2076 kann man selbst lesen, einen chna-Chunk mit vierzig Zeilen Code parsen und nachsehen, was ein Exporter tatsächlich geschrieben hat statt dessen, was sein Dialogfenster behauptete. Genau in der immersiven Auslieferung fällt der größte Teil unnötiger Rückweisungen an, und fast alle davon sind Referenzfehler, die ein Validator in unter einer Sekunde findet.

Die Distribution über Mazufa ist kostenlos — keine Upload-Gebühr, kein Abonnement, keine Gebühr je Veröffentlichung —, die einzige Abzugsposition sind 5 % der eingehenden Tantiemen, und jede vollständige Bewerbung wird von einem Menschen geprüft.

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.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

EBU

• EBU Tech 3364 v1.0 (01/2014), Audio Definition Model Metadata Specification — https://tech.ebu.ch/files/live/sites/tech/files/shared/tech/tech3364v1_0.pdf
• 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 R 128 (deutsche Fassung), Lautheitsaussteuerung, Normalisierung und zulässiger Maximalpegel von Audiosignalen — https://tech.ebu.ch/docs/r/r128_2011_DE.pdf
• EBU Tech 3341 (Messgeräte) und EBU Tech 3342 (Loudness Range) — https://tech.ebu.ch/loudness/
• 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 Renderer (EAR), BW64-I/O — https://ear.readthedocs.io/en/latest/BW64.html
• libbw64 — https://github.com/ebu/libbw64 · libadm — https://github.com/ebu/libadm

AES und Dienstdokumentation

• AES TD1008, Recommendations for loudness of internet audio streaming and on-demand distribution — https://www.aes.org/community/technical-council/technical-document-aestd1008/
• Spotify, Loudness normalization — https://support.spotify.com/us/artists/article/loudness-normalization/

Deutschsprachiger Hintergrund

• Library of Congress, Audio Definition Model (Formatbeschreibung, Herkunft) — https://www.loc.gov/preservation/digital/formats/fdd/fdd000607.shtml
• Institut für Rundfunktechnik — https://de.wikipedia.org/wiki/Institut_f%C3%BCr_Rundfunktechnik
• Erich-Thienhaus-Institut, HfM Detmold, Geschichte des Tonmeisterstudiengangs — https://www.eti.hfm-detmold.de/de/institut/geschichte/der-tonmeisterstudiengang/
• Fraunhofer IIS, Audio und Medientechnologien (MPEG-H 3D Audio) — https://www.iis.fraunhofer.de/de/magazin/bereiche/audio-und-medientechnologien.html
• Elbphilharmonie, Großer Saal — https://de.wikipedia.org/wiki/Elbphilharmonie
• Werk (Orgel) — https://dewiki.de/Lexikon/Werk_(Orgel) · Rückpositiv — https://dewiki.de/Lexikon/R%C3%BCckpositiv
• Deutsche UNESCO-Kommission, Technokultur in Berlin — https://www.unesco.de/staette/technokultur-in-berlin/

Stand: September 2026. Normen werden revidiert; prüfen Sie vor jedem Zitat einer Klausel die aktuelle Ausgabe auf den Seiten von ITU und EBU.