Pourquoi un master immersif passe l'éditeur audio et échoue au contrôle qualité

Un livrable immersif peut s'ouvrir dans un éditeur de forme d'onde, afficher douze ou seize pistes d'apparence saine, se lire sans anomalie — et être rejeté quand même. La raison est structurelle : dans un fichier BW64, l'audio et les métadonnées sont deux choses distinctes qui doivent concorder exactement, et rien dans le format ne les y oblige. Un moteur de rendu résout des références. Un éditeur dessine des échantillons. Deux métiers différents — et c'est pourquoi le contrôle qualité ADM consiste à vérifier l'intégrité des références, pas à écouter. Voici ce que disent les deux normes, où les références se rompent, et quel contrôle attrape quelle défaillance.

Trois natures d'audio, et pourquoi la distinction décide de tout

Tout problème de livraison immersive commence par une confusion sur laquelle de ces trois choses une piste est.

L'audio canalisé (channel-based) affecte chaque piste à une position d'enceinte fixe. La stéréo est canalisée, le 5.1 aussi, un lit 7.1.4 aussi. La position est inscrite dans l'identité du canal : la piste 3 est l'enceinte centrale, et elle est l'enceinte centrale sur tout système qui la lit. ITU-R BS.2051 formalise cela pour les systèmes sonores avancés, en décrivant les configurations par des effectifs de couches supérieure + médiane + basse — le système A est 0+2+0 (stéréo), le système B est 0+5+0 (5.1), le système D est 4+5+0, le système J est 4+7+0, le système H est 9+10+3, la configuration 22.2. En ADM, c'est la typeDefinition DirectSpeakers, typeLabel 0001.

L'audio objet (object-based) transporte un signal mono (ou un pack multicanal) accompagné de métadonnées de position qui évoluent dans le temps. Le moteur de rendu décide quelles enceintes réelles le reproduisent, selon la configuration présente dans la pièce. Rien dans la piste ne présuppose une enceinte. C'est la typeDefinition Objects, typeLabel 0003.

L'audio de scène (scene-based), en pratique de l'ambisonie d'ordre supérieur, encode le champ sonore entier sous forme de composantes harmoniques sphériques. Aucune composante ne correspond à elle seule à une direction ; la direction émerge de la combinaison linéaire. C'est HOA, typeLabel 0004. L'ADM définit aussi Matrix (0002) pour les signaux matricés comme le Mid-Side ou le Lt/Rt, et Binaural (0005).

La distinction n'est pas taxinomique. Un livrable canalisé se décrit assez lui-même pour survivre en simple WAV : mettez l'ordre des canaux correct et il se lit. Un livrable objet ou scène n'a aucun sens sans ses métadonnées : l'audio n'est qu'un tas de flux mono indifférenciés, et l'ADM est la seule chose qui dise le contraire. C'est cette asymétrie qui justifie l'existence du BW64 et de l'ADM.

Le BW64 existe à cause d'un nombre sur 32 bits

Le WAV classique est un fichier RIFF. RIFF, qui date de 1991, préfixe chaque chunk d'un champ de taille sur 32 bits. Trente-deux bits adressent 4,294,967,296 octets — 4 GB — et c'est le plafond dur, pour le fichier entier comme pour le chunk data qu'il contient.

Pour de la stéréo en 48 kHz / 24-bit, le débit est de 288,000 octets par seconde : 4 GB, cela fait environ 4 hours 8 minutes. Sans intérêt. Pour un master objet de 128 pistes en 96 kHz / 24-bit, le débit est de 36,864,000 octets par seconde, et 4 GB représentent moins de deux minutes — 116.5 secondes.

Les masters immersifs franchissent cette limite couramment, et un encodeur WAV qui la heurte produit soit un fichier tronqué, soit un fichier dont les tailles déclarées ont silencieusement débordé. L'EBU a traité le problème en premier avec le RF64 (EBU Tech 3306) ; l'UIT l'a repris sous la forme de la Recommandation ITU-R BS.2088 — le BW64.

L'astuce de la sentinelle : 0xFFFFFFFF et un chunk ds64

BS.2088 est explicite sur le mécanisme. « The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file », et les champs de taille 32 bits d'origine deviennent des drapeaux d'échappement : « If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead. »

Toute l'astuce tient là, et il vaut la peine de le dire nettement : le BW64 n'élargit pas les champs de taille du RIFF. Il les remplit de 0xFFFFFFFF en guise de sentinelle et place les vraies tailles 64 bits dans un chunk ds64 qui doit figurer en tête de fichier. Un fichier BW64 de moins de 4 GB est donc compatible octet pour octet avec un lecteur WAV à tous égards, à l'exception de la signature de quatre caractères. Beaucoup d'outils l'acceptent ; certains s'y refusent obstinément.

Les chunks, et celui qui fait exactement 40 octets par entrée

Selon BS.2088, un fichier BW64 est censé contenir au minimum ds64, fmt , chna, axml (avec bxml et sxml comme porteurs de métadonnées alternatifs) et les données audio.

ds64 doit être le premier chunk après la signature, parce qu'un lecteur doit connaître les tailles réelles avant de pouvoir parcourir quoi que ce soit d'autre. Il porte des moitiés basse/haute sur 32 bits pour la taille du fichier entier et pour la taille de data, plus une table d'entrées ChunkSize64 pour tout autre chunk surdimensionné — un chunk axml décrivant des milliers d'objets avec une automation à l'échantillon près peut lui-même approcher ou dépasser 4 GB.

fmt est le chunk de format WAVE standard — format d'échantillon, fréquence d'échantillonnage, nombre de canaux, bits par échantillon, alignement de bloc. C'est le seul énoncé faisant autorité sur le nombre de canaux entrelacés présents dans data. Tout ce qui vient ensuite est une métadonnée à propos de ces canaux, et une métadonnée peut mentir.

chna est le pont entre les pistes physiques et l'ADM. Après ckID, ckSize, un numTracks sur 2 octets et un numUIDs sur 2 octets, il contient un tableau plat d'entrées audioID de largeur fixe, chacune faisant exactement 40 octets :

2 + 12 + 14 + 11 + 1 = 40. Ces largeurs ne sont pas indicatives : ce sont des champs ASCII de largeur fixe, et un encodeur qui produit un UID de 13 caractères a produit une table corrompue, pas une table un peu inhabituelle.

La convention d'identifiants compte aussi. Les valeurs inférieures ou égales à 0x0FFF renvoient aux définitions communes de l'ADM — les formats de canaux et de packs standard, prédéfinis — tandis que 0x1000 et au-delà signalent des définitions personnalisées qui doivent être présentes dans axml. AP_00010003 est du 5.1 par définition commune et n'exige aucun XML ; AP_00031001 est un pack d'objets personnalisé et exige du XML, faute de quoi la référence pend dans le vide.

numUIDs peut aussi légitimement dépasser numTracks : les recommandations de l'EBU notent que lorsque « 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 », si bien qu'un même trackIndex peut apparaître dans plusieurs entrées. Les outils de QC qui supposent un UID par piste signalent comme cassés des fichiers corrects.

axml est un document XML en UTF-8 contenant l'arbre <audioFormatExtended>. C'est l'ADM, et c'est là que vivent pour ainsi dire toutes les défaillances intéressantes. data est du PCM entrelacé ordinaire ; rien à l'intérieur ne sait quoi que ce soit des objets.

Ordre : ds64 en premier, toujours ; fmt avant data. Mais axml peut légitimement se trouver après data, et c'est souvent le cas car — comme le fait observer BS.2088 — pendant l'enregistrement « the XML metadata will likely be of an unknown length. » Un fichier dont l'axml est en fin de fichier n'est pas malformé, mais un lecteur qui ne balaye que le premier mégaoctet signalera l'absence totale d'ADM. Cela explique une part étonnante des signalements du type « mon fichier n'a pas de métadonnées ».

L'ADM est un graphe, et les défaillances sont des arêtes rompues

La hiérarchie d'ITU-R BS.2076 va de audioProgramme → audioContent → audioObject → audioPackFormat → audioChannelFormat → audioBlockFormat, avec audioTrackUID comme feuille et seul élément correspondant à une piste physique.

C'est un graphe de références, pas un document imbriqué, et toute défaillance de livraison sérieuse y est une arête rompue. Ce qui rend une référence pendante dangereuse, c'est qu'il n'existe aucun comportement unique lorsqu'elle se rompt. Un moteur de rendu qui résout un audioPackFormatIDRef désignant un pack absent du XML peut interrompre l'analyse et rejeter le fichier ; peut ignorer cet objet et rendre tout le reste, produisant un mixage auquel il manque discrètement un stem ; ou peut se rabattre sur les définitions communes, y trouver un identifiant de la plage personnalisée au-delà de 0x1000 sans correspondance, et lui substituer du silence. Ces trois issues répondent à « le fichier s'est ouvert ». Une seule est détectée à l'écoute, et uniquement si vous savez ce qui aurait dû s'y trouver.

Les quatre défaillances qui expliquent la plupart des rejets

Un nombre de pistes dans fmt en désaccord avec chna. fmt .nChannels annonce 16 ; chna.numTracks annonce 14. Le fichier est incohérent avec lui-même dès les deux premiers chunks — généralement un export dont le nombre de pistes a changé après la rédaction des métadonnées, ou un outil qui a supprimé des pistes sans réécrire chna. La détection consiste à analyser deux entiers et à les comparer : le contrôle le moins cher de toute la chaîne, et il attrape une proportion saisissante des défaillances. Vérifiez en même temps que chaque trackIndex se situe dans 1 … fmt .nChannels.

Un audioTrackUID qu'aucun objet ne référence. Un UID présent dans chna qu'aucun audioObject ne référence signifie qu'il existe de l'audio que rien ne rendra ; le cas miroir, un audioTrackUIDRef dans le XML sans entrée chna correspondante, signifie que les métadonnées attendent une piste qui n'est pas là. Construisez l'ensemble des UID issus de chna et celui issu de axml, puis prenez la différence symétrique ; elle doit être vide. EBU Tech 3392 énonce l'intention directement : « If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs. »

Un chronométrage de blocs qui remonte le temps. BS.2076 est sans ambiguïté : « When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present. » EBU Tech 3392 resserre cela en exigeant la contiguïté — « rtime + duration of an audioBlockFormat should match the rtime of the following block » — avec un premier bloc d'objet démarrant à 00:00:00.00000, aucun bloc plus court qu'un échantillon, et des durées dont la somme égale celle de l'audioObject parent. Parcourez les blocs dans l'ordre du document et vérifiez que rtime[n] + duration[n] == rtime[n+1]. Les défaillances prennent trois formes : les trous, où le comportement du moteur de rendu est indéfini — certains maintiennent la dernière position, d'autres coupent ; les recouvrements, où les blocs se disputent ; et les blocs hors ordre chronologique, c'est-à-dire une automation qui saute en arrière en plein programme.

Un lit décrit dans le XML qui n'a jamais été gravé sur le disque. Le XML déclare un pack DirectSpeakers en 7.1.4 — douze canaux — mais seul le sous-ensemble 5.1 a été gravé, ou les canaux de hauteur étaient coupés à l'export et sont gravés en noir numérique. Le graphe de références est intact ; l'audio ne l'est pas. Les contrôles structurels ne peuvent pas attraper cela : il faut une analyse de l'essence, mesurant si chaque canal revendiqué par un pack DirectSpeakers contient le moindre signal. Du noir numérique sur un canal de lit déclaré n'est pas automatiquement une erreur — un mixage légitime peut laisser un canal arrière supérieur vide — mais cela mérite toujours une décision humaine.

Ce qui est publié sur le volume immersif, et ce qui ne l'est pas

Un chiffre ne survit pas au passage depuis la stéréo, et il vaut la peine de dire pourquoi.

BS.1770-5 (November 2023) est l'édition en vigueur ; BS.1770-4 est remplacée, même si la plupart des mesureurs déployés la citent encore. Son algorithme central pondère L, R et C à 1.0 et Ls et Rs à 1.41 (environ +1.5 dB), exclut le LFE, et a pour périmètre « from one to five channels ». BS.1770-5 va au-delà dans ses annexes, couvrant les systèmes sonores avancés de BS.2051 et l'audio objet — lequel doit être rendu avant de pouvoir être mesuré. Le volume immersif n'est donc pas une propriété du fichier mais d'un rendu, et changer la configuration cible change le chiffre. Mesurez un rendu conforme à BS.2127 vers une configuration BS.2051 nommée, avec un mesureur BS.1770-5, et consignez les trois éléments dans vos notes de livraison ; BS.2127 définit le moteur de rendu ADM de référence, et son homologue open source, l'EBU ADM Renderer (EBU Tech 3388), est le moyen pratique d'obtenir un chiffre reproductible.

Aucun service de streaming musical ne publie de cible de volume intégré pour la livraison immersive. Des chiffres circulent sur les forums et dans les supports de formation d'éditeurs ; aucun n'est une spécification publiée, et cet article n'en reprendra aucun comme s'il en était une. Ce qui est publié concerne la stéréo canalisée — la cible intégrée de Spotify à −14 LUFS avec un plafond de crête réelle à −1 dBTP, resserré à −2 dBTP au-dessus de −14 LUFS, et les −16 LUFS pour la musique d'AES TD1008 (son chiffre de −18 LUFS s'applique aux contenus dominés par la parole, et annoncer −18 comme cible pour la musique est une erreur fréquente et sérieuse).

Dolby Atmos est une technologie propriétaire et sous licence de Dolby Laboratories, et Sony 360 Reality Audio est un système propriétaire bâti sur MPEG-H. Leurs exigences sont fixées par leurs détenteurs, changent sans égard aux calendriers de l'UIT ou de l'EBU, et ne sont pas énoncées ici ; aucune affiliation ni aucune approbation n'est revendiquée. Reportez-vous à la documentation à jour du concédant lui-même.

Ce qu'il faut vérifier avant d'envoyer

Les contrôles structurels d'abord ; ils sont rapides et ils invalident tout ce qui vient après.

• Les quatre premiers octets sont BW64. S'ils indiquent RIFF, c'est un WAV ordinaire et il ne peut pas dépasser 4 GB.
• ds64 est le premier chunk après la signature, ses tailles 64 bits correspondent aux tailles du fichier et de data sur le disque, et tout chunk surdimensionné autre que data possède une entrée ChunkSize64 dans la table.
• Localisez axml explicitement, y compris après data — ne concluez jamais à l'absence d'ADM depuis un balayage partiel.
• La fréquence d'échantillonnage et la profondeur de bits de fmt correspondent exactement à la spécification de livraison. Aucune conversion de fréquence d'échantillonnage après la rédaction de l'ADM — elle invalide chaque rtime et chaque duration exprimés en échantillons.
• fmt .nChannels égale chna.numTracks ; chaque trackIndex est dans la plage et compté à partir de 1.
• Chaque entrée chna fait exactement 40 octets, avec des champs de largeur fixe correctement remplis, et chaque packRef à 0x1000 ou au-delà se résout en une définition personnalisée présente dans axml.
• Chaque audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef et audioTrackUIDRef se résout. Zéro arête pendante, dans un sens comme dans l'autre, et aucune référence circulaire.
• Les formats de canaux multi-blocs portent à la fois rtime et duration sur chaque bloc ; les blocs sont contigus et monotones ; les objets démarrent à 00:00:00.00000.
• Chaque canal d'un lit déclaré contient ce qu'il doit contenir. Enquêtez sur le noir numérique.
• Le timecode de départ bext est cohérent sur tout le lot, et les conformations stéréo et binaurale sont re-rendues depuis le master courant. Une conformation en avance de 40 ms sur son parent immersif passe un contrôle de présence de fichier et échoue à une écoute synchronisée.
• Calculez une somme de contrôle pour chaque livrable, conservez le manifeste, et archivez le XML ADM séparément du BW64 — un XML que vous pouvez comparer ligne à ligne vaudra plus, plus tard, qu'un binaire que vous ne pouvez que ré-analyser.

Le BW64 et l'ADM sont des normes ouvertes, publiées et librement consultables, ce dont il vaut la peine de se servir : vous pouvez lire BS.2088 et BS.2076 vous-même, analyser un chunk chna en quarante lignes de code, et vérifier ce que l'exporteur d'un éditeur a réellement écrit plutôt que ce que sa boîte de dialogue prétendait. La quasi-totalité des rejets immersifs évitables sont des erreurs d'intégrité référentielle qu'un validateur attrape en moins d'une seconde.

L'inspecteur BW64/ADM gratuit de Mazufa, à l'adresse mazufa.com/immersive-master-check, analyse le conteneur et les métadonnées entièrement sur votre propre appareil et ne téléverse rien, ce qui le rend utilisable sur du matériel qui, contractuellement, ne peut pas sortir des murs. Mazufa lui-même est gratuit pour publier, prend 0% de commission, et fonctionne sur invitation avec une relecture humaine de chaque candidature complète.

Sources

Recommandations ITU-R

• ITU-R BS.2088-2 (11/2025), Long-form file format for the international exchange of audio programme materials with metadata (BW64) — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2088-2-202511-I!!PDF-E.pdf
• ITU-R BS.2076-3 (02/2025), Audio Definition Model — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2076-3-202502-I!!PDF-E.pdf
• ITU-R BS.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

Documents techniques EBU

• EBU Tech 3306, RF64: An extended file format for audio data — https://tech.ebu.ch/docs/tech/tech3306.pdf
• EBU Tech 3285 (et suppléments), 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
• Implémentation de référence libbw64 — 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/

Documentation des services

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