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.

Pour les articles homonymes, voir BWF.

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␣ (code signifiant format, le glyphe « ␣ » représente une espace) 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] :

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 déscriptives 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.

Notes et références
  1. (en) The National Archives (uk), « Référence Format », (consulté le )
  2. (en) BBC Research & Development, « Broadcast WAV File Format » (consulté le )
  3. (en) UER, « Tech 3285 - Specification of the Broadcast Wave Format (BWF) » [PDF],  : « The Broadcast Wave Format is based on the Microsoft WAVE audio file format, to which the EBU has added a “Broadcast Audio Extension” chunk. », p. 3
  4. (Fabricant) Sound Devices : SD688, SD552
  5. (Fabricant) Nagra : Nagra LB, Nagra V, Nagra Seven, Nagra VI, Nagra SD
  6. (Fabricant) Aaton : Cantar-X2
  7. (Fabricant) Zaxcom : Deva 24, Nomad, Zax Max
  8. (Fabricant) Fostex : UR-2
  9. IASA, « Recommandations pour la production et la conservation des objets audionumériques » (consulté le ) : « Les Recommandations de IASA préconisent le format PCM (Pulse Code Modulation) (Modulation par impulsions codées) linéaire, entrelacé pour la stéréo, dans un fichier .wav ou de préférence .wav BWF (UER Tech 3285) pour toutes séquences audio deux pistes. »
  10. (en) UER, « Tech 3285 - Specification of the Broadcast Wave Format (BWF) » [PDF],  : « Version 1 is backwards compatible with Version 0 [...] The change is also forwards compatible. », p. 8
  11. (en) UER, « Tech 3285 - Specification of the Broadcast Wave Format (BWF) » [PDF],  : « Version 2 is backwards compatible with Versions 1 and 0 [...] The change is also forwards compatible. », p. 8
  12. (en) UER, « Tech 3285 - Specification of the Broadcast Wave Format (BWF) » [PDF],  : « A Broadcast Wave Format file shall start with the mandatory Microsoft RIFF “WAVE” header and at least the following chunks: <broadcast_audio_extension> <fmt-ck> <wave-data> », p. 9
  13. (en) UER, « Tech 3285 - Specification of the Broadcast Wave Format (BWF) » [PDF],  : « As well as the audio data, a BWF file contains the minimum information — or metadata — which is considered necessary for all broadcast applications. », p. 3
  14. (en) UER, « Tech 3285 - Specification of the Broadcast Wave Format (BWF) » [PDF],  : « Although other WAVE formats are registered with Microsoft, only the above formats [WAVE_FORMAT_PCM, WAVE_FORMAT_MPEG] are at present used with the BWF. [...] Other WAVE formats may be defined in future Supplements. », p. 16
  15. (en) The National Archives (uk), « Formats de compression supportés », (consulté le )
  16. (en) UER, « Tech 3285-S1 - Supplement 1 – MPEG audio » [PDF],  : « The Microsoft Corporation has specified how MPEG audio data can be organised in WAVE files. An extension to the format chunk and a fact chunk carry further information needed to specify MPEG coding options. [...] For MPEG Layer 2, it has been found that extra information needs to be carried about the coding of the signal. This is carried in the <mpeg_audio_extension> chunk, developed by the MPEG Layer 2 Audio Interest group. », p. 4
  17. (en) UER, « Tech 3285-S3 - Supplement 3 – Peak Envelope Chunk » [PDF],  : « a standard for storing and transferring data about the signal peaks obtained by sub-sampling the audio. This data in the chunk can be used to provide the envelope of the audio essence in the file. This will allow an audio application to display the audio files quickly, without loosing too much accuracy. », p. 1
  18. (en) UER, « Tech 3285-S3 - Supplement 3 – Peak Envelope Chunk » [PDF],  : « it is possible to send the peak-of-peaks, which is the first audio sample whose absolute value is the maximum value of the entire audio file. An audio application can use this information to normalize a file in real-time without having to scan the entire file. (Since this has already been done by the sender). », p. 1
  19. (en) UER, « Tech 3285-S4 - Supplement 4 – <link> Chunk » [PDF],  : « The <link /> chunk provides link-up data for a seamless audio output spread over several files. », p. 1
  20. (en) UER, « Tech 3285-S5 - Supplement 5 – <axml> Chunk » [PDF],  : « The <axml> chunk may contain any data compliant with the XML 1.0 format or later, a widespread format for data exchange. Note that the <axml> chunk may contain XML fragments from more than one Schema. », p. 1
  21. (en) UER, « Tech 3285-S5 - Supplement 5 – <axml> Chunk » [PDF],  : « Exemple [...] the XML content of the <axml> chunk follows EBU documents Tech 3293 and Tech 3295. », p. 2
  22. (en) UER, « Tech 3285-S6 - Supplement 6 – Dolby Metadata, <dbmd> Chunk » [PDF],  : « The Dolby Audio Metadata Chunk is identified by the chunk id ‘dbmd’. It is comprised of a variable number of metadata segments. This syntax is loosely based upon the existing Dolby E audio metadata serial bitstream fields submitted as a SMPTE Registered Disclosure Document, which will facilitate the interaction of existing hardware equipment with software that processes these WAVE files. », p. 6
  23. (en) Dolby Laboratories, Inc, « Dolby® DP600 Program Optimizer Manual » [PDF] : « File‐based Dolby E, Dolby Digital, and Dolby Digital Plus bitstreams can be encoded and decoded to and from multichannel .wav or Broadcast WAV Format (BWF) files with metadata (included in the Dolby audio metadata chunk). », p. 3

Voir aussi

Liens externes

Le standard

Recommandations associées

Ressources complémentaires

Articles
  • Portail de l’informatique
Cet article est issu de Wikipedia. Le texte est sous licence Creative Commons - Attribution - Partage dans les Mêmes. Des conditions supplémentaires peuvent s'appliquer aux fichiers multimédias.