Broadcast Wave Format

Le standard Broadcast Wave Format (BWF, parfois BWAVE^[1],[2] ) définit une évolution du format conteneur audio RIFF/WAVE^[3], permettant notamment l'ajout de métadonnées « broadcast » comme le timecode, des informations d'identification, ou encore de mesure audio.

BWF
Broadcast Wave Format

Caractéristiques

Extensions	.wav, .WAV, .bwf
Type MIME	audio/x-wav
Développé par	Union européenne de radio-télévision
Type de format	Format conteneur audio
Spécification	Format ouvert

modifier - modifier le code - modifier Wikidata

Le BWF est rétro-compatible avec le format WAVE. C'est-à-dire qu'un lecteur WAVE pourra décoder l'audio d'un fichier au format BWF.

Le BWF a été défini pour la première fois en 1997 par l'UER sous la référence Tech 3285. Il a ensuite connu plusieurs révisions et suppléments.

Le BWF reste à ce jour le format de prédilection en production musicale et audiovisuelle^{[4],[5],[6],[7],[8]}. Il est également recommandé pour l'archivage par l'IASA (International Association of Sound and Audiovisual Archives (en)) comme format pour la préservation du patrimoine sonore^[9].

Historique

Versions

• 1997 (version 0) : Publication initiale.
• 2001 (version 1) : Ajout du support de l'UMID (Unique Material IDentifier), tel que défini par la SMPTE dans le standard ST 330:2011.
• 2011 (version 2) : Ajout du support des mesures audio du Loudness, telles que définies dans la recommandation R-128 de l'UER.

Chaque version est compatible avec les versions antérieures et ultérieures. C'est-à-dire qu'une implémentation prévue pour une version antérieure ignorera simplement les informations qu'elle ne supporte pas. Inversement, une implémentation prévue pour une version ultérieure associera des valeurs nulles aux champs manquants^[10],[11].

Suppléments

• 1997 (Supplément 1) : MPEG Audio
• 2001 (Supplément 2) : Capturing Report
• 2001 (Supplément 3) : Peak Envelope Chunk
• 2003 (Supplément 4) : <link> Chunk
• 2003 (Supplément 5) : <axml> Chunk
• 2009 (Supplément 6) : Dolby Metadata, <dbmd> Chunk.

Le standard

Le format conteneur BWF est défini à partir du format RIFF/WAVE de Microsoft^[3]. Un fichier BWF doit donc, comme un fichier WAVE, commencer par un en-tête RIFF/WAVE valide et contenir au minimum un chunk fmt␣(le glyphe « ␣ » représente une espace) (code signifiant format) contenant les informations nécessaires au décodage de l'audio et un chunk data contenant les données audio utiles. Le chunk fmt␣ doit se trouver dans le fichier en amont du chunk data .

Le standard BWF complète ces spécifications par l'ajout d'un nouveau chunk bext (Broadcast audio EXTension)^[3],[12], contenant le minimum d'informations considérées comme étant nécessaires à toute application broadcast^[13].

Contenu du chunk bext

Nom	Description
Description	Ce champ est souvent employé par les fabricants pour stocker des informations complémentaires (Numéro de piste, Nombre d'images par seconde, etc.)
Originator	Nom du producteur de l'enregistrement. Généralement celui du fabricant de l'enregistreur.
OriginatorReference	Identifiant attribué par le producteur de l'enregistrement.
OriginationDate	Date de l'enregistrement au format aaaa-mm-jj
OriginationTime	Heure de l'enregistrement au format hh:mm:ss
TimeReference	Valeur appelée Sample Count Since Midnight. Il s'agit du nombre de samples passés depuis minuit au moment du début de l'enregistrement. Cette valeur permet, pour une fréquence d'échantillonnage et un nombre d'images par seconde donné, de retrouver le Time Code horaire du début de l'enregistrement au sample près.
— À partir de la version 1
Version	Version du standard auquel correspond le fichier. Peut être 0, 1 ou 2.
UMID	UMID (Unique Material IDentifier) tel que défini par la SMPTE.
— À partir de la version 2
LoudnessValue	Valeur du Loudness intégré en LUFS (multipliée par 100)
LoudnessRange	Valeur du Loudness Range en LU (multipliée par 100)
MaxTruePeakLevel	Valeur maximum de crête réelle (True Peak) en dBTP (multipliée par 100)
MaxMomentaryLoudness	Valeur maximum du Loudness momentané en LUFS (multipliée par 100)
MaxShortTermLoudness	Valeur maximum du Loudness Short-Term en LUFS (multipliée par 100)
— Toutes versions
Reserved	Espace réservé pour un éventuel usage dans de futures versions.
CodingHistory	Historique des codages apportés au flux audio. Le format de ce champ est détaillé dans la recommandation R-98 de l'UER.

Aussi, le standard WAVE supporte de nombreux formats de codage audio. Le BWF restreint le support à deux formats^[14],[15] :

• Audio PCM
• Audio MPEG

Enfin, le standard BWF ne prévoit pas d'extension de fichier. En conséquence, les fichiers .bwf n'existent pas, ou du moins ne sont pas standardisés. Ainsi on considère que toute extension valide pour un fichier WAVE sera valide pour un fichier BWF — généralement .wav ou .WAV.

Les suppléments

Les suppléments définissent chacun un chunk de métadonnées optionnel. Ils peuvent ou non être ajoutés à un fichier BWF en fonction des besoins.

MPEG Audio

Le format RIFF/WAVE tel que défini par Microsoft permet déjà de supporter des flux audio MPEG. Ce supplément permet d'embarquer des options de codage supplémentaires^[16].

Ce supplément définit le chunk mext (mpeg audio extension), chargé de recevoir ces nouvelles options.

Capturing Report

Ce supplément définit le chunk qlty (quality), qui contiendra notamment une liste d’évènements (events), pouvant être renseignés manuellement par l'opérateur, ou automatiquement par le système d'enregistrement.

Un évènement permet de repérer un moment précis dans le flux audio ou se produit par exemple un clic numérique, une saturation ponctuelle, un décrochage de liaison HF, etc.

Ce supplément permettra aussi de stocker des données de mesure sur l'ensemble du signal : crête maximum (dBFS), niveau moyen (dBFS), corrélation de phase, dynamique (dB), samples écrêtés (aux valeurs extrêmes), rapport signal sur bruit, etc.

Peak Envelope Chunk

Ce supplément définit le chunk levl (level) qui permet d’accélérer le chargement, l'affichage et le traitement d'un fichier WAVE dans un logiciel, en rendant disponible les données de niveaux de crêtes audio du signal.

Ces données sont nécessaires à l'affichage de la forme d'onde^[17] et aux processus de normalisation audio^[18].

Ainsi, le fait de les intégrer aux fichiers BWF évitera aux logiciels compatibles d'avoir à les recalculer à chaque ouverture.

<link> Chunk

La taille du fichier étant codée dans l'en-tête RIFF sur 32 bits, le format RIFF/WAVE accepte une taille de fichier maximum de 4 Gio. Cette limite est souvent réduite à 2 Gio par les implémentations qui utilisent des entiers signés.

Ce supplément définit le chunk link , qui permet à un ou plusieurs flux audio excédant les 2 Gio d'être répartis sur plusieurs fichiers^[19].

<axml> Chunk

Ce supplément définit le chunk axml , permettant d'embarquer des métadonnées descriptives au format XML^[20].

Ces métadonnées peuvent être formatées en accord avec les documents Tech 3293 (anciennement Core Metadata Set for Radio Archives devenu EBUCore) et Tech 3295 (P_Meta)^[21].

Dolby Metadata, <dbmd> Chunk

Ce supplément définit le chunk dbmd (dolby metadata), permettant le support de métadonnées audio associées aux différentes technologies Dolby : Dolby E, Dolby Digital et Dolby Digital Plus.

La syntaxe de ces métadonnées est basée sur le document SMPTE RDD 6-2006, facilitant ainsi l’interaction des équipements existant et des logiciels qui exploitent ces fichiers^[22],[23].

Compatibilité avec le format WAVE

Le format WAVE, tel que défini par Microsoft repose sur le format RIFF. Celui-ci définit une structure en blocs de données (chunk). Si un lecteur rencontre un bloc qu'il ne connaît pas, il est simplement censé l'ignorer.

Le standard BWF reposant sur l'ajout d'au moins un nouveau bloc, une implémentation compatible avec le format WAVE sera par corollaire compatible avec le BWF.