BW64 et ADM : référence technique pour la livraison d'audio immersif

Document de travail pour les ingénieurs du son qui préparent des masters par objets ou par scène, et pour les musiciens à qui l'on a remis un « livrable immersif » avec pour seule consigne de le faire passer le contrôle qualité.

La réponse en dix lignes

L'Audio Definition Model (ADM), Recommandation UIT-R BS.2076, est un modèle de métadonnées ouvert qui décrit ce qu'est chaque piste d'un fichier audio — un canal de haut-parleur, un objet mobile, ou une composante ambisonique — et comment ces pistes se combinent en un programme. Il est transporté sous forme de XML à l'intérieur d'un conteneur BW64 (Recommandation UIT-R BS.2088), extension 64 bits du RIFF/WAVE qui s'affranchit du plafond de 4 Go du WAV classique. Les livraisons immersives échouent au contrôle qualité parce que l'audio et les métadonnées sont deux objets distincts qui doivent concorder exactement, et que rien dans le format ne les y contraint. Un nombre de canaux dans fmt qui contredit la table chna, un audioTrackUID que nul objet ne référence, un bloc dont l'horodatage recule, un bed décrit en XML mais jamais gravé sur le disque: chacune de ces erreurs est invisible dans un éditeur de forme d'onde et fatale pour un moteur de rendu. Le contrôle qualité ADM est une vérification d'intégrité référentielle, pas une séance d'écoute.

1. Un préalable français : l'acousmonium, et ce que l'ADM ne sait pas porter

Il faut commencer par là, parce que c'est la question que se pose n'importe quel praticien français avant d'ouvrir la moindre spécification de l'UIT.

La France possède l'une des plus longues pratiques continues de composition multicanale et spatiale au monde. La musique concrète, puis la tradition acousmatique, ont produit un répertoire considérable qui n'a jamais été pensé pour une paire d'enceintes. L'INA GRM a inauguré l'Acousmonium en 1974: « Ce projecteur sonore a été conçu et inauguré par François Bayle en 1974 pour INA grm », avec un concert inaugural le 12 février 1974 à l'Espace Cardin, précédé d'un essai le 16 janvier 1974 à l'église Saint-Séverin (INA). Il s'agit d'un orchestre de haut-parleurs — des dizaines d'enceintes de tailles, de timbres et de directivités différents, disposées autour et au-dessus du public — que l'interprète joue depuis une console pendant le concert.

Il faut nommer le problème sans le contourner, parce que la littérature technique anglophone l'ignore et que la littérature française le connaît trop bien pour le formuler.

Une œuvre acousmatique n'est ni du channel-based, ni de l'object-based, ni du scene-based au sens de l'ADM. Le support est le plus souvent stéréophonique, parfois octophonique, parfois multipiste sans affectation fixe. Ce ne sont pas des canaux de haut-parleurs au sens de BS.2051, parce qu'ils ne désignent pas des positions normalisées; ce ne sont pas des objets, parce qu'aucune trajectoire n'est écrite dans le fichier; ce n'est pas une scène ambisonique, parce que rien n'encode le champ. Ce qui fait l'œuvre spatiale, dans cette tradition, c'est la diffusion: un geste d'interprétation, en temps réel, sur un dispositif de salle donné, par quelqu'un qui connaît la pièce et connaît l'orchestre de haut-parleurs de ce soir-là.

L'ADM ne modélise pas cela, et il n'y a aucune raison de prétendre le contraire. On peut décrire dans l'ADM le support d'origine, on peut décrire une captation de la diffusion, on peut décrire une version rendue de l'œuvre pour une disposition donnée. On ne peut pas décrire l'œuvre. La sortie honnête est celle-ci:

L'ADM peut transporter un rendu d'une pièce acousmatique; il ne transporte pas la pièce. Ce qui fait l'objet du livrable, ce n'est pas la partition de diffusion, c'est une interprétation figée parmi d'autres possibles.

Conséquence pratique, et elle est simple: si vous éditez un catalogue acousmatique en immersif, la décision artistique — quelle projection est fixée, par qui, sur quelle disposition de référence — se prend en amont, et se documente. Cette décision-là ne se rattrape pas dans le XML. Ce que l'ADM apporte réellement à ce répertoire, c'est la traçabilité: la disposition cible est nommée, le moteur de rendu est nommé, l'auteur de la projection est nommé dans les notes de livraison. C'est déjà beaucoup plus que ce qu'offrait un fichier stéréo anonyme.

2. Trois natures d'audio, et pourquoi la distinction décide du format

Avant le conteneur, le modèle. Tout problème de livraison immersive commence par une confusion sur ce qu'est réellement une piste.

**L'audio par canaux (channel-based).** Chaque piste est assignée à une position fixe de haut-parleur. La stéréo est par canaux, le 5.1 aussi, et le « bed » 7.1.4 également. La position est incorporée dans l'identité du canal: la piste 3 est le canal central, et elle l'est sur tous les systèmes qui la lisent. L'UIT-R BS.2051 formalise cela pour les systèmes sonores avancés, en décrivant les dispositions de haut-parleurs sous la forme supérieur + médian + inférieur: le système A est 0+2+0 (stéréo), le système B 0+5+0 (5.1), le système D 4+5+0, le système J 4+7+0, et le système H 9+10+3, c'est-à-dire le 22.2. Dans l'ADM, ce contenu emploie la typeDefinition DirectSpeakers, typeLabel 0001.

**L'audio par objets (object-based).** Une piste mono (ou un groupe de pistes formant un pack) accompagnée de métadonnées de position qui varient dans le temps. C'est le moteur de rendu qui décide quels haut-parleurs réels reproduisent l'objet, et comment, en fonction de la disposition réellement présente dans la salle. Rien dans la piste ne présuppose une enceinte. typeDefinition Objects, typeLabel 0003.

**L'audio par scène (scene-based).** En pratique, l'ambisonie d'ordre supérieur (HOA): le champ sonore entier est encodé comme un jeu de composantes harmoniques sphériques. Aucune composante ne correspond seule à une direction; la direction naît de la combinaison linéaire. typeDefinition HOA, typeLabel 0004. L'ADM définit également Matrix (0002) pour les signaux matricés — Mid/Side, Lt/Rt — et Binaural (0005) pour une paire destinée au casque.

L'audio par canaux dit au fichier où sont les haut-parleurs; l'audio par objets refuse de le deviner; l'audio par scène décrit le champ plutôt que les sources.

Ce n'est pas de la taxonomie pour elle-même. Un livrable par canaux est suffisamment auto-descriptif pour survivre en WAV nu: l'ordre des canaux est correct, il se lit. Un livrable par objets ou par scène est dépourvu de sens sans ses métadonnées: l'audio n'est qu'un empilement de flux monophoniques indifférenciés, et l'ADM est la seule chose qui affirme le contraire. Cette asymétrie explique à la fois l'existence de BW64 et d'ADM, et le fait que le contrôle qualité immersif soit plus difficile que le contrôle qualité stéréo.

3. Le grand orgue et l'orgue de chœur : le cas où « bed + objets » s'impose de lui-même

Si l'on cherche l'exemple qui justifie le mieux, en France, l'architecture bed plus objets, il est dans les cathédrales, et il ne demande aucun effort d'imagination.

Prenons une disposition documentée. À la cathédrale Saint-Étienne de Bourges, le grand orgue est « en tribune, au revers de la façade ouest », 50 jeux, reconstruit par Kern entre 1982 et 1985; l'orgue de chœur est « au sol, dans le chœur, côté nord », 15 jeux (Inventaire national des orgues, orgue de chœur). Deux instruments, aux deux extrémités d'un même vaisseau, l'un en hauteur, l'autre au sol. Cette disposition — grand orgue en tribune occidentale, orgue de chœur dans le chœur — est la norme française et non l'exception.

Un enregistrement de ce dispositif contient trois choses de nature différente, et l'ADM les distingue proprement:

1. Le grand orgue est une source ponctuelle du point de vue de l'auditeur assis dans la nef, mais une source ponctuelle en hauteur et derrière. Son élévation est réelle, pas simulée. Dans un master immersif, c'est un objet, ou un petit pack d'objets si l'on veut préserver la largeur du buffet.
2. L'orgue de chœur est une autre source ponctuelle, à l'autre bout du bâtiment, au niveau du sol, avec un timbre et une puissance entièrement différents. Deuxième objet.
3. La réverbération du bâtiment n'est ni l'un ni l'autre. Elle est le milieu qui relie les deux, elle est diffuse, elle vient de partout, elle dure plusieurs secondes et elle est la moitié de ce que l'on vient écouter. Elle relève du bed — un pack DirectSpeakers, 5.1.4 ou 7.1.4, alimenté par les micros d'ambiance placés dans la nef et dans les tribunes latérales.

C'est la justification la plus limpide qui soit de l'architecture hybride. Tenter de tout mettre dans un bed écrase la localisation des deux instruments et détruit précisément la distance ouest/est qui fait l'intérêt du dialogue. Tenter de tout mettre en objets oblige à traiter la réverbération d'un vaisseau gothique comme une collection de sources ponctuelles, ce qu'elle n'est pas, et produit un champ diffus discontinu dès que l'auditeur bouge la tête. Le bed porte le champ, les objets portent les sources.

Deux pièges concrets s'ajoutent, et ils sont spécifiquement français:

• Le décalage temporel n'est pas un défaut à corriger. Entre la tribune occidentale et une position d'écoute dans le chœur, il y a plusieurs dizaines de mètres, donc plus de cent millisecondes de propagation dans l'air. Un alignement de phase automatique appliqué « pour faire propre » détruit la profondeur que l'objet est censé encoder. Si vous alignez, alignez consciemment et notez-le.
• La distance dans l'ADM n'est pas la distance en mètres. Le paramètre distance d'un audioBlockFormat de type Objects est normalisé, pas métrique. Il ne remplacera jamais la distance réellement captée par le rapport son direct/son réverbéré. Le bed fait le travail que le paramètre distance ne fait pas.

4. L'orchestre déployé autour du public

La musique contemporaine française fournit le second cas d'usage, et il est plus exigeant que le premier. Le répertoire des cinquante dernières années comporte un nombre considérable d'œuvres où les instrumentistes sont volontairement répartis dans la salle: cuivres en fond de balcon, percussions aux quatre angles, groupes instrumentaux séparés qui jouent des tempi indépendants, solistes qui se déplacent pendant l'exécution.

Pour ce répertoire, l'audio par objets n'est pas une technique de production: c'est la seule représentation fidèle. Un pupitre placé au balcon arrière-gauche est un objet, à une position déterminée, éventuellement variable. Le forcer dans un bed 7.1.4 revient à reproduire la partition sur un dispositif qui n'est pas celui qu'elle prescrit.

Trois recommandations, tirées de ce que ce répertoire impose au fichier:

• Un objet par source réelle, pas un objet par microphone. La tentation est de créer un objet par piste de la session. Un groupe instrumental capté par trois micros reste un groupe: c'est un audioObject référençant un audioPackFormat de trois canaux, pas trois objets indépendants dont les trajectoires vont diverger au premier automatisme.
• Les déplacements d'exécutants sont des séquences de blocs, et ces blocs doivent être contigus. C'est là que la règle de temporalité de l'ADM cesse d'être une formalité (voir § 7).
• L'écoute de référence est celle du chef ou celle du public ? Ces deux choix produisent deux masters différents et incompatibles. Décidez avant de placer le premier objet, et écrivez-le dans les notes.

5. BW64 : ce que c'est, et l'arithmétique exacte du plafond de 4 Go

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

Faisons l'arithmétique nous-mêmes, avec le débit brut PCM = canaux × (bits/8) × fréquence d'échantillonnage.

(Calculs vérifiés ligne à ligne: 4 294 967 296 ÷ débit.)

La cinquième ligne est celle qu'il faut retenir. Un bed 7.1.4 accompagné de 118 objets, en 48 kHz/24 bits, franchit les 4 Go au bout de trois minutes et quarante-neuf secondes. Autrement dit: une chanson de format courant dépasse la capacité du WAV classique. Ce n'est pas un cas limite réservé aux longs métrages, c'est le régime normal du travail par objets. Un moteur d'écriture WAV qui atteint la limite produit soit un fichier tronqué, soit un fichier dont les tailles déclarées ont silencieusement débordé — et le second cas est bien pire, parce qu'il s'ouvre.

L'EBU a traité le problème d'abord avec le RF64 (EBU Tech 3306). L'UIT a repris ce travail dans la Recommandation UIT-R BS.2088, Long-form file format for the international exchange of audio programme materials with metadata — le BW64. 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 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. »

C'est toute l'astuce, et elle mérite d'être énoncée sans détour:

BW64 n'élargit pas les champs de taille du RIFF; il y écrit 0xFFFFFFFF comme sentinelle et place les vraies tailles 64 bits dans un chunk ds64 qui doit se trouver en tête de fichier.

BW64 se comprend le mieux comme la troisième génération d'une même lignée. RIFF/WAVE a donné le conteneur par chunks. Le Broadcast Wave (BWF, EBU Tech 3285) a ajouté le chunk bext — originateur, référence de timecode, historique de codage — faisant du WAV un format d'échange de production. BW64 conserve tout cela, ajoute l'adressage 64 bits, et ajoute les chunks qui portent l'ADM. Un fichier BW64 de moins de 4 Go est compatible octet pour octet avec un lecteur WAV, à la seule exception de la signature de quatre caractères en tête. Beaucoup d'outils l'acceptent; certains s'y refusent obstinément, et c'est une cause fréquente de « le fichier ne s'ouvre pas » qui n'a rien à voir avec les métadonnées.

6. La disposition des chunks, octet par octet

Selon BS.2088, un fichier BW64 doit contenir au minimum <ds64-ck>, <fmt-ck>, <chna-ck>, <axml-ck> (avec <bxml-ck> et <sxml-ck> comme porteurs de métadonnées alternatifs) et <wave-data>.

6.1 ds64 — la table des tailles 64 bits

Il doit être le premier chunk après la signature BW64, parce qu'un lecteur doit connaître les vraies tailles avant de pouvoir parcourir quoi que ce soit. Ses champs sont des moitiés 32 bits de quantités 64 bits:

Faisons ici aussi l'arithmétique. La charge utile fait 8 + 8 + 8 + 4 = 28 octets, donc ckSize = 28 quand la table est vide, et le chunk complet, en-tête comprise, fait 4 + 4 + 28 = 36 octets. Chaque entrée de la table pèse 12 octets (identifiant de chunk sur 4 octets, puis la taille 64 bits en deux moitiés de 4 octets), ce qui donne un chunk de 36 + 12 × n octets. L'implémentation de référence de l'EBU confirme ce calcul: dans libbw64, la taille du chunk est sizeof(bw64Size()) + sizeof(dataSize()) + sizeof(dummySize()) + sizeof(tableLength()) + table_.size() * 12 (libbw64, chunks.hpp).

La table compte davantage qu'il n'y paraît. 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 Go; la table est le seul moyen pour un chunk autre que data de déclarer une taille 64 bits. Un exportateur qui écrit un axml géant sans entrée dans la table produit un fichier dont la moitié des lecteurs ne verra pas les métadonnées.

6.2 fmt — la description de l'essence

Chunk de format WAVE standard: format d'échantillon, fréquence d'échantillonnage, nombre de canaux, bits par échantillon, alignement de bloc. C'est la seule affirmation faisant autorité sur le nombre de canaux réellement entrelacés dans data. Tout le reste est de la métadonnée à propos de ces canaux, et une métadonnée peut mentir.

6.3 chna — la table d'allocation des canaux, et son arithmétique des 40 octets

Le chna est le pont entre les pistes physiques et l'ADM. Il commence par:

• ckID — 4 octets, 'chna'
• ckSize — 4 octets
• numTracks — 2 octets, nombre de pistes dans le fichier
• numUIDs — 2 octets, nombre d'entrées audioTrackUID qui suivent

Vient ensuite un tableau plat d'entrées audioID de largeur fixe. Chaque entrée fait exactement 40 octets:

2 + 12 + 14 + 11 + 1 = 40. Vérifions les largeurs sur les chaînes elles-mêmes, puisque ce sont des champs ASCII à largeur fixe et non des chaînes terminées par un zéro: ATU_00000001 compte 4 + 8 = 12 caractères; AT_00031001_01 compte 3 + 8 + 3 = 14 caractères; AP_00031001 compte 3 + 8 = 11 caractères. Les largeurs du tableau ne sont pas indicatives: elles sont exactement la longueur des identifiants normalisés. Un exportateur qui émet un UID de 13 caractères n'a pas produit une table légèrement inhabituelle, il a produit une table corrompue.

Le champ ckSize se déduit: ckSize = 2 (numTracks) + 2 (numUIDs) + 40 × N. Les guidelines ADM de l'EBU donnent la relation inverse, qui est le contrôle à écrire dans votre validateur: « N = (ckSize – 4) / 40 » (EBU ADM Guidelines, chunk CHNA). Pour notre master à 130 pistes avec un UID par piste: ckSize = 4 + 40 × 130 = 5 204 octets, et le chunk complet en fait 5 212 avec son en-tête. Si ckSize – 4 n'est pas divisible par 40, le fichier est corrompu et le diagnostic tient en une ligne de code.

Notez également la convention d'identifiants: les valeurs de 0x0FFF et en dessous renvoient aux définitions communes de l'ADM — les formats de canaux et de packs prédéfinis et normalisés — tandis que 0x1000 et au-dessus désignent des définitions personnalisées qui doivent être présentes dans le chunk axml. Un packRef valant AP_00010003 est du 5.1 par définition commune et n'a besoin d'aucun XML; AP_00031001 est un pack d'objets personnalisé, et sans XML la référence pend dans le vide.

Un track UID est le numéro de série que le fichier attribue à l'identité d'une piste physique, et il existe précisément pour qu'une piste puisse légitimement changer de contenu en cours de programme.

C'est la raison pour laquelle numUIDs peut dépasser numTracks. L'EBU précise: « The number of tracks used in the file. Even if a track contains more than one set of IDs, it is still just one track » pour numTracks, et pour numUIDs: « As it is possible to give a single track multiple UIDs (covering different time periods), this could be a greater value than numTracks. » Un même trackIndex peut donc apparaître dans plusieurs entrées. Les outils de contrôle qualité qui supposent un UID par piste signalent des fichiers corrects comme défectueux — et le cas est loin d'être théorique dans une œuvre où une piste porte successivement deux instruments placés à des endroits différents. Enfin, lorsqu'un emplacement d'identifiant est inutilisé, « the trackIndex should be given the value of zero and the other fields should be given null strings ».

6.4 axml — l'ADM proprement dit

Un document XML, en UTF-8, contenant l'arbre <audioFormatExtended>. C'est l'ADM. C'est du texte, c'est inspectable, et c'est là que vit la quasi-totalité des pannes intéressantes. Corollaire pratique pour un catalogue français: les noms d'éléments (audioProgrammeName, audioObjectName) sont du texte libre en UTF-8, et il n'y a donc aucune raison technique d'écrire Cathedrale Saint-Etienne sans accents. En revanche, prenez l'habitude de vérifier l'encodage réel du fichier plutôt que la déclaration en tête: un XML déclaré UTF-8 mais écrit en Latin-1 par une chaîne d'outils ancienne transforme « chœur » en mojibake, et certains parseurs abandonnent la lecture du document entier sur ce seul caractère. Le caractère « œ » (U+0153) est le révélateur le plus fiable de ce défaut dans un fichier français.

6.5 data — le PCM entrelacé

Des échantillons entrelacés, exactement comme dans un WAV. Rien dans data ne sait quoi que ce soit des objets.

6.6 L'ordre des chunks, et le piège qui prend tout le monde

ds64 en premier, toujours. fmt avant data. En revanche axml peut légitimement être placé après data, et l'est souvent, parce que — comme l'observe BS.2088 — pendant l'enregistrement « the XML metadata will likely be of an unknown length ». Un fichier dont l'axml est en queue n'est pas malformé; mais un lecteur qui ne balaie que le premier mégaoctet rapportera qu'il n'y a aucun ADM. Ce seul fait explique une part surprenante des signalements « mon fichier n'a pas de métadonnées ».

7. Le modèle ADM : un graphe de références

L'UIT-R BS.2076 sépare le modèle en deux moitiés. La partie format « describes the technical nature of the audio so it can be decoded or rendered correctly » et peut être écrite avant que le moindre audio existe. La partie contenu décrit « the language of dialogue, the loudness, etc. » et ne peut être complétée qu'une fois les signaux disponibles. Savoir à quelle moitié appartient un élément vous dit à quelle étape de production l'erreur a été introduite.

La hiérarchie, du haut vers le bas:

• audioProgramme — une présentation complète et livrable. Référence un ou plusieurs audioContent.
• audioContent — une composante du programme dotée d'un sens éditorial: stem de dialogue, stem de musique, version linguistique. Référence un ou plusieurs audioObject.
• audioObject — la jonction entre l'intention éditoriale et le format technique. Il porte un temps de début et une durée, et référence zéro ou plusieurs audioPackFormat, zéro ou plusieurs audioObject imbriqués, et zéro ou plusieurs audioTrackUID. C'est ici que le contenu rencontre l'essence.
• audioPackFormat — un groupe de canaux qui vont ensemble: un bed 7.1.4, une paire stéréo, un jeu HOA d'un ordre donné. Référence des audioChannelFormat, et peut imbriquer d'autres packs.
• audioChannelFormat — le comportement d'un canal au fil du temps. Contient un ou plusieurs audioBlockFormat.
• audioBlockFormat — l'atome. Pour Objects: une position (azimuth/elevation/distance, ou cartésienne X/Y/Z), un gain, une taille, une diffusivité, plus rtime et duration. Un objet statique tient en un bloc; un objet mobile est une séquence.
• audioTrackUID — la feuille, et le seul élément qui corresponde à une piste physique. Porte des attributs optionnels sampleRate et bitDepth et référence un audioTrackFormat et un audioPackFormat.

audioStreamFormat et audioTrackFormat s'intercalent entre le format de canal et le track UID pour décrire l'encodage du flux. BS.2076-3 note que pour du PCM ils sont en pratique redondants — « the audioStreamFormat and the audioTrackFormat should be omitted » — mais que les lecteurs « should be aware that existing ADM files (based on Recommendation ITU-R BS.2076-2 and earlier) for PCM audio may contain » ces éléments. Les deux formes sont légales. Un validateur qui exige l'une se trompe sur l'autre.

L'ADM est un graphe de références, pas un document imbriqué, et toute défaillance sérieuse de livraison est une arête cassée dans ce graphe.

Ce qui se passe réellement quand une référence pend. Il n'y a pas de comportement unique, et c'est précisément le problème. 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 0x1000+ sans correspondance, et substituer du silence. Les trois issues se résument à « le fichier s'est ouvert ». Une seule est détectable à l'oreille, et seulement si vous savez ce qui aurait dû s'y trouver. C'est la raison pour laquelle le contrôle qualité ADM doit être automatisé: une oreille humaine ne peut pas entendre une absence dont on ne l'a pas prévenue.

La règle de temporalité, et pourquoi elle frappe les œuvres à exécutants mobiles. BS.2076 est sans ambiguïté: « When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present. » L'EBU Tech 3392 resserre en une règle de contiguïté — « rtime + duration of an audioBlockFormat should match the rtime of the following block » — avec un premier bloc démarrant à 00:00:00.00000, aucun bloc plus court qu'un échantillon, et une somme des durées égale à celle de l'audioObject parent. Un instrumentiste qui traverse la salle produit une longue séquence de blocs; il suffit qu'un outil d'édition ait recalculé une durée en arrondissant pour que la chaîne se rompe au milieu du parcours. Les défaillances se répartissent en trois formes: les trous (comportement du renderer indéfini — certains maintiennent la dernière position, d'autres coupent), les recouvrements (des blocs qui se disputent le même instant), et les blocs hors ordre chronologique (une automation qui recule).

8. Le rendu : BS.2127 vers les dispositions BS.2051

Un fichier ADM par objets ne « sonne » pas. Il faut le rendre, et le rendu est une opération nommée, reproductible, et normalisée.

L'UIT-R BS.2127 définit le moteur de rendu ADM de référence pour les systèmes sonores avancés: à partir d'un fichier BW64/ADM et d'une disposition de haut-parleurs cible choisie parmi celles de BS.2051, il produit les signaux de haut-parleurs. Son pendant en logiciel libre, l'EBU ADM Renderer (EBU Tech 3388), est le moyen pratique d'obtenir un résultat que quelqu'un d'autre pourra reproduire à l'identique.

Trois conséquences que l'on sous-estime systématiquement:

1. Le même fichier a autant de rendus que de dispositions cibles. Un objet à 45° d'azimut et 30° d'élévation n'est pas reproduit de la même façon par un système D (4+5+0) et par un système J (4+7+0). Les deux sont corrects. Ils ne sont pas identiques.
2. Le rendu binaural n'est pas la salle, mais il n'est pas non plus un gadget. Pour la vaste majorité des auditeurs, l'écoute se fera au casque, donc le rendu binaural est le livrable qui sera réellement entendu. Cela n'en fait pas un substitut de vérification: une erreur de position d'objet qui saute aux oreilles sur douze haut-parleurs peut être imperceptible dans un rendu binaural, et l'inverse est vrai aussi.
3. Nommer le renderer fait partie du livrable. « Mesuré à −18 LUFS » ne veut rien dire pour un master par objets. « Mesuré à −18 LUFS sur un rendu BS.2127 vers une disposition BS.2051 système J, mètre conforme BS.1770-5 » est une affirmation vérifiable.

9. Le loudness immersif sous BS.1770-5

Il faut ici séparer soigneusement ce qui est publié de ce qui circule.

9.1 Ce que la Recommandation spécifie

L'édition en vigueur est la BS.1770-5, de novembre 2023. Elle supersède la BS.1770-4 (octobre 2015), qui reste l'édition citée par la majorité des mètres déployés. Nommez toujours la -5 comme édition courante; si votre outil affiche « BS.1770-4 », ce n'est pas nécessairement faux pour de la stéréo, mais ce n'est plus la référence à citer dans des notes de livraison.

La BS.1770 définit la pondération K: un filtre en plateau haut (filtre « de tête », modélisant une sphère rigide) suivi d'un passe-haut RLB. Le gain de la courbe à 1 kHz vaut +0,698 dB (soit 1,0836 en linéaire). La mesure emploie des blocs de 400 ms avec 75 % de recouvrement, une porte absolue qui écarte les blocs sous −70 LUFS, et une porte relative calculée à partir de la moyenne des blocs ayant survécu à la porte absolue, puis décalée de −10 LU.

Ce dernier point mérite d'être répété parce qu'il est mal implémenté avec une régularité déprimante: la porte relative se calcule sur les blocs survivants, pas sur la moyenne non gatée. Deux mètres qui divergent d'un demi-LU sur le même fichier ont presque toujours ce défaut-là.

La pondération des canaux dans l'algorithme de base vaut 1,0 (0 dB) pour L, R et C, et 1,41 (≈ +1,5 dB) pour Ls et Rs, le LFE étant exclu. L'algorithme de base est explicitement défini « from one to five channels ». La BS.1770-5 va au-delà dans ses annexes, en couvrant les systèmes sonores avancés de la BS.2051 — haut-parleurs positionnés arbitrairement, canaux de hauteur — et l'audio par objets, qui doit être rendu avant de pouvoir être mesuré.

Le loudness immersif n'est pas une propriété du fichier; c'est une propriété d'un rendu, et changer de disposition cible change le chiffre.

C'est la différence de fond avec la stéréo. Un master stéréo a une valeur de loudness. Un master par objets en a autant qu'il a de cibles de rendu.

Documents EBU associés. L'EBU Tech 3341 définit le comportement des mètres: momentary sur 400 ms, short-term sur 3 s. L'EBU Tech 3342 définit le Loudness Range (LRA), qui emploie une porte relative de −20 LU — et non −10 LU; utiliser −10 pour le LRA est un bug d'implémentation courant. L'EBU R 128 fixe la cible de programme en radiodiffusion à −23 LUFS: c'est une pratique de normalisation broadcast, pas une spécification de streaming musical. Cette distinction compte particulièrement en France, où une part importante des studios travaillant en immersif viennent de la production audiovisuelle et ont R 128 comme réflexe.

9.2 Ce qui est publié pour la musique

Pour la musique stéréo par canaux, Spotify publie une cible intégrée de −14 LUFS et un plafond de vraie crête de −1 dBTP, resserré à −2 dBTP pour les masters plus forts que −14 LUFS. L'AES TD1008 recommande −16 LUFS pour la musique; son chiffre de −18 LUFS s'applique aux contenus dominés par la parole (information, entretien, fiction radiophonique), et présenter −18 comme la cible musicale est une erreur fréquente et sérieuse.

Rappelons aussi que la normalisation vers le haut existe mais qu'elle est conditionnelle. Spotify indique: « Positive gain is applied to softer masters so the loudness level is -14 dB LUFS », mais également « We consider the headroom of the track, and leave 1 dB headroom for lossy encodings to preserve audio quality. » Un master silencieux mais à crêtes élevées peut donc ne pas être remonté jusqu'à la cible. Ni « les masters faibles ne sont jamais remontés » ni « les masters faibles sont toujours remontés à la cible » ne sont exacts.

Sur la vraie crête, enfin: elle se mesure sur un signal suréchantillonné (4× au minimum selon la BS.1770, 8× de préférence). La crête d'échantillon n'est pas la vraie crête, et les crêtes intersample peuvent dépasser la valeur du plus haut échantillon. Sur un master immersif, cette différence se paie deux fois, puisque le rendu vers une disposition donnée peut sommer des objets sur un même haut-parleur et créer des crêtes qui n'existaient dans aucune piste prise isolément.

9.3 Ce qui n'est pas publié

Aucun service de streaming musical ne publie de cible de loudness intégré pour la livraison immersive. Des chiffres circulent abondamment dans les forums et dans les supports de formation d'éditeurs de logiciels; plusieurs sont plausibles et certains sont probablement justes. Aucun n'est une spécification publiée, et ce document ne les répétera pas comme s'ils l'étaient.

De même, pour la stéréo: Apple Music, YouTube Music, Amazon Music, TIDAL et Deezer ne publient aucune cible de normalisation. Les chiffres souvent cités pour ces services (Apple ≈ −16, YouTube Music ≈ −14, Amazon ≈ −14, TIDAL ≈ −14, Deezer ≈ −15) relèvent de la mention largement rapportée, non publiée par le service, et il ne faut jamais en déduire un écart de gain à appliquer.

Si vous avez besoin aujourd'hui d'un chiffre de loudness immersif défendable: mesurez un rendu conforme BS.2127 vers une disposition BS.2051 nommée, avec un mètre conforme BS.1770-5, et inscrivez les trois éléments dans vos notes de livraison.

9.4 Sur les systèmes propriétaires

Dolby Atmos est une technologie propriétaire et sous licence de Dolby Laboratories; Sony 360 Reality Audio est un système propriétaire bâti sur MPEG-H. Leurs exigences de livraison sont fixées par leurs propriétaires et évoluent indépendamment des calendriers de l'UIT ou de l'EBU. Rien dans ce document ne constitue un énoncé des exigences de ces sociétés, et aucune affiliation, certification ou approbation n'est revendiquée ni suggérée. Lorsqu'un donneur de licence publie une exigence, lisez sa documentation courante et citez-la.

10. La position honnête : vous n'avez probablement pas d'écoute immersive

Il faut le dire, parce que c'est la réalité de la plupart des lecteurs francophones de ce document.

En dehors d'une poignée de studios de post-production, de quelques structures institutionnelles et de centres de création, l'écoute immersive calibrée est rare en France. Elle existe, et à un niveau technique remarquable: l'Espace de projection de l'Ircam, sous la place Stravinsky, offre une acoustique variable dont le temps de réverbération se règle « de 0,4 à 4 secondes » grâce à 171 périactes à trois faces (absorbante, réfléchissante, diffusante), dans un volume de 24 m × 15,50 m à hauteur de plafond variable de 1,50 m à 10,50 m, et dispose de 339 haut-parleurs exploités en WFS et en ambisonie (Ircam). Le réseau des centres nationaux de création musicale et les grandes maisons de production audiovisuelle disposent également de dispositifs sérieux.

Mais entre cela et le home studio ou le petit studio de quartier, il n'y a rien. Et la conclusion qu'il faut en tirer n'est pas décourageante, elle est libératrice:

Si vous ne pouvez pas auditionner correctement un master immersif, votre travail n'est pas d'en juger le rendu spatial à l'oreille sur un casque. Votre travail est de garantir que le fichier est exact, que ses métadonnées sont cohérentes, et que le studio ou le moteur de rendu qui l'ouvrira après vous obtiendra ce que vous avez décrit.

Ce que vous pouvez faire sans salle immersive, et qui a une valeur réelle:

• Vérifier la signature BW64 et la présence de ds64 en tête.
• Comparer fmt.nChannels et chna.numTracks — deux entiers, cinq lignes de code, et une proportion étonnante des rejets attrapée.
• Vérifier que (ckSize − 4) du chna est divisible par 40.
• Extraire l'axml, le passer dans un parseur XML, et résoudre toutes les références.
• Vérifier la contiguïté temporelle des blocs.
• Mesurer, canal par canal, quelles pistes déclarées dans un bed contiennent réellement du signal.
• Comparer les durées et les timecodes de départ des conformes stéréo et binaural avec le master.

Aucune de ces vérifications ne demande une seule enceinte. Toutes attrapent des erreurs qu'une écoute même parfaite ne détecterait pas.

Un inspecteur BW64/ADM gratuit fonctionnant dans le navigateur est disponible sur mazufa.com: il analyse le conteneur et les métadonnées entièrement sur votre propre appareil et n'envoie aucun fichier, ce qui le rend utilisable sur du matériel qui, contractuellement, n'a pas le droit de sortir des locaux.

11. Liste de contrôle de livraison

À parcourir dans cet ordre. Les vérifications structurelles d'abord: elles sont rapides et elles invalident tout ce qui suit.

Conteneur

1. Les quatre premiers octets sont BW64. S'ils valent RIFF, le fichier est un WAV ordinaire et ne peut pas dépasser 4 Go.
2. ds64 est le premier chunk après la signature, et ses tailles 64 bits correspondent à la taille réelle du fichier et du chunk data sur le disque.
3. Tout chunk surdimensionné autre que data possède une entrée ChunkSize64 dans la table du ds64.
4. Localisez explicitement l'axml, y compris après data. Ne concluez jamais « pas d'ADM » à partir d'un balayage partiel.

Essence

1. La fréquence d'échantillonnage et la résolution de fmt correspondent exactement à la spécification de livraison. Aucune conversion de fréquence après l'écriture de l'ADM: elle invalide tout rtime et toute duration exprimés en échantillons.
2. fmt.nChannels égale chna.numTracks.
3. Chaque trackIndex du chna est dans la plage et indexé à partir de 1.

Intégrité du chna

1. Chaque entrée fait exactement 40 octets, champs ASCII à largeur fixe correctement complétés; (ckSize − 4) est divisible par 40.
2. Chaque packRef en 0x1000 ou au-dessus se résout vers une définition personnalisée présente dans l'axml.
3. Les trackIndex répétés sont intentionnels (une piste qui change légitimement de définition), et non des doublons.

Graphe ADM

1. Chaque audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef et audioTrackUIDRef se résout. Zéro arête pendante.
2. Aucun audioTrackUID orphelin dans un sens ou dans l'autre: construisez l'ensemble des UID du chna et celui de l'axml, et prenez la différence symétrique — elle doit être vide.
3. Aucun élément circulaire ou auto-référent.
4. Le typeLabel de chaque audioChannelFormat correspond à celui de son audioPackFormat parent.

Temporalité

1. Les formats de canaux à blocs multiples portent rtime et duration sur chaque bloc.
2. Les blocs sont contigus et monotones: rtime[n] + duration[n] == rtime[n+1]; la somme des durées égale la durée de l'audioObject parent.
3. Les objets démarrent à 00:00:00.00000.

Contenu

1. Chaque canal d'un bed déclaré contient ce qu'il doit contenir. Un silence numérique sur un canal de hauteur n'est pas automatiquement une erreur — un mixage peut légitimement laisser un canal arrière-haut vide — mais il mérite toujours une décision humaine.
2. Le nombre d'objets et la configuration du bed correspondent à la spécification.
3. Le timecode de départ du bext est correct et cohérent entre tous les livrables du lot.

Rendus et conformes

1. Les conformes stéréo et binaural sont re-rendus depuis le master courant, pas reportés d'une version antérieure. Le défaut n'est presque jamais l'absence — qui se voit — mais la dérive: un conforme décalé de quelques images, ou avec un timecode de départ différent, passe un contrôle de présence et échoue à une écoute synchronisée.
2. Les durées et les timecodes de départ concordent à l'échantillon près.
3. Le loudness est mesuré sur un rendu nommé vers une disposition nommée avec un moteur nommé, et les trois sont consignés dans les notes.

Reproductibilité

1. Calculez une somme de contrôle pour chaque livrable et conservez le manifeste.
2. Archivez la session et l'XML ADM séparément du BW64. Un XML que l'on peut comparer ligne à ligne vaut beaucoup plus, deux ans plus tard, qu'un binaire que l'on ne peut que ré-analyser.

Un livrable immersif n'est pas terminé quand il sonne juste; il est terminé quand une machine qui ne l'a jamais entendu peut prouver que ses références se résolvent.

12. Pour finir

BW64 et ADM sont des normes ouvertes, publiées et librement lisibles. C'est suffisamment rare dans ce coin de l'industrie pour qu'il faille en profiter: vous pouvez lire vous-même la BS.2088 et la BS.2076, analyser un chunk chna en quarante lignes de code, et vérifier ce que l'exportateur d'un éditeur a réellement écrit plutôt que ce qu'affichait sa boîte de dialogue. C'est en immersif que se concentre aujourd'hui la plus grande part des rejets évitables, et la quasi-totalité d'entre eux sont des erreurs d'intégrité référentielle qu'un validateur attrape en moins d'une seconde.

Et pour revenir à ce par quoi nous avons commencé: la tradition française de la spatialisation est plus ancienne que les normes qui prétendent la décrire. L'ADM ne remplace pas l'interprétation spatiale, et il ne la remplacera pas. Ce qu'il fait, et qu'il fait bien, c'est garantir que ce que vous avez décidé de fixer arrive intact à l'autre bout de la chaîne. C'est une ambition modeste et c'est exactement la bonne.

La distribution chez Mazufa est gratuite — pas de frais de dépôt, pas d'abonnement, pas de facturation par sortie — la seule retenue étant 5 % des royalties perçues, et chaque dossier complet fait l'objet d'un examen humain.

Sources

Recommandations UIT-R

• UIT-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
• UIT-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
• UIT-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
• UIT-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
• UIT-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
• UIT-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
• Page de la Recommandation BS.2127 — https://www.itu.int/rec/R-REC-BS.2127

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, 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 Tech 3343, Practical guidelines for production and implementation in accordance with EBU R 128 — https://tech.ebu.ch/files/live/sites/tech/files/shared/tech/tech3343v2_0.pdf
• EBU R 128, EBU Tech 3341 (mètres), EBU Tech 3342 (Loudness Range) — https://tech.ebu.ch
• EBU ADM Guidelines — chunk CHNA — https://adm.ebu.io/reference/excursions/chna_chunk.html
• EBU ADM Guidelines — BW64 et ADM — https://adm.ebu.io/reference/excursions/bw64_and_adm.html
• EBU ADM Guidelines — audioTrackUID — https://adm.ebu.io/reference/adm_elements/audio_track_uid.html
• EBU ADM Renderer (EAR), entrées/sorties BW64 — https://ear.readthedocs.io/en/latest/BW64.html
• Implémentation de référence libbw64 — https://github.com/ebu/libbw64
• Implémentation de référence libadm — https://github.com/ebu/libadm

AES

• AES TD1008, Recommendations for loudness of internet audio streaming and on-demand distribution — https://www.aes.org/community/technical-council/technical-document-aestd1008/

Documentation de service

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

Sources françaises

• INA, Connaissez-vous l'Acousmonium ? — https://www.ina.fr/actualites-ina/connaissez-vous-l-acousmonium
• INA GRM, présentation de l'Acousmonium — https://inagrm.com/en/showcase/news/202/the-acousmonium
• Ircam, Espace de projection — https://www.ircam.fr/fr/ircam/les-espaces/espace-de-projection
• Inventaire national des orgues — grand orgue de la cathédrale Saint-Étienne de Bourges — https://inventaire-des-orgues.fr/detail/orgue-bourges-cathedrale-saint-etienne-fr-18033-bzges-stetie1-t/
• Inventaire national des orgues — orgue de chœur de la cathédrale Saint-Étienne de Bourges — https://inventaire-des-orgues.fr/detail/orgue-bourges-cathedrale-saint-etienne-fr-18033-bzges-stetie1-c/

Dernière révision: septembre 2026. Les normes sont révisées; vérifiez toujours les pages de l'UIT et de l'EBU ci-dessus pour connaître l'édition en vigueur avant de citer un numéro de clause.