AccueilđŸ‡«đŸ‡·Chercher

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
Type de format
Spécification

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

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
Cet article est issu de wikipedia. Text licence: CC BY-SA 4.0, Des conditions supplĂ©mentaires peuvent s’appliquer aux fichiers multimĂ©dias.