IEC 62942:2019
(Main)File format for professional transfer and exchange of digital audio data
File format for professional transfer and exchange of digital audio data
IEC 62942:2019 specifies a file format for interchanging audio data between compliant equipment. It is primarily intended for audio applications in professional recording, production, post-production, and archiving.
It is derived from the AES31-2 [2] but is also compatible with variant specifications including EBU Tech 3285 [3] to [10], ITU-R BR.1352-3-2007 [11] to [14], and the Japan Post Production Association's BWF-J [15].
This document contains the specification of the broadcast audio extension chunk and its use with PCM-coded audio data. Basic information on the RIFF format and how it can be extended to other types of audio data is given in Annex E. Details of the PCM WAVE format are also given in Annex A.
An optional extended format, BWF-E, supports 64-bit addressing to permit file sizes greater than 4 GB.
Format de fichier pour le transfert et l'échange professionnels de données audionumériques
L'IEC 62942:2019 spécifie un format de fichier qui permet d'échanger des données audio entre des équipements conformes. Il vise principalement les applications audio en ce qui concerne l'enregistrement, la production, la postproduction et l'archivage professionnels.
Il est obtenu à partir de l'AES31-2, mais est également compatible avec des spécifications proches, notamment l'EBU Tech 3285, l'ITU-R BR.1352-3-2007, et le BWF-J de la Japan Post Production Association.
Le présent document contient la spécification du fragment d'extension audio pour diffusion et de son utilisation avec des données audio codées MIC. Des informations de base sur le format RIFF et sur la façon dont il peut être étendu à d'autres types de données audio sont données à l'Annexe E. Des détails sur le format WAVE MIC sont également donnés à l'Annexe A.
Un format étendu facultatif, BWF-E, prend en charge l'adressage 64 bits pour permettre l'utilisation de fichiers dont la taille est supérieure à 4 Go.
General Information
Standards Content (Sample)
IEC 62942 ®
Edition 1.0 2019-12
INTERNATIONAL
STANDARD
File format for professional transfer and exchange of digital audio data
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.
IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.
About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.
IEC publications search - webstore.iec.ch/advsearchform Electropedia - www.electropedia.org
The advanced search enables to find IEC publications by a The world's leading online dictionary on electrotechnology,
variety of criteria (reference number, text, technical containing more than 22 000 terminological entries in English
committee,…). It also gives information on projects, replaced and French, with equivalent terms in 16 additional languages.
and withdrawn publications. Also known as the International Electrotechnical Vocabulary
(IEV) online.
IEC Just Published - webstore.iec.ch/justpublished
Stay up to date on all new IEC publications. Just Published IEC Glossary - std.iec.ch/glossary
details all new publications released. Available online and 67 000 electrotechnical terminology entries in English and
once a month by email. French extracted from the Terms and Definitions clause of
IEC publications issued since 2002. Some entries have been
IEC Customer Service Centre - webstore.iec.ch/csc collected from earlier publications of IEC TC 37, 77, 86 and
If you wish to give us your feedback on this publication or CISPR.
need further assistance, please contact the Customer Service
Centre: sales@iec.ch.
IEC 62942 ®
Edition 1.0 2019-12
INTERNATIONAL
STANDARD
File format for professional transfer and exchange of digital audio data
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 33.160.30 ISBN 978-2-8322-7722-5
– 2 – IEC 62942:2019 © IEC 2019
CONTENTS
FOREWORD . 5
INTRODUCTION . 7
1 Scope . 8
2 Normative references . 8
3 Terms and definitions . 8
4 BWF file . 10
4.1 Existing chunks defined as part of the RIFF Format . 10
4.2 Additional chunks . 10
4.3 Contents of a BWFF . 10
4.4 Broadcast audio extension chunk . 11
4.5 Filename . 13
4.6 Channel usage . 13
4.7 File size . 13
Annex A (normative) RIFF WAVE file format . 14
A.1 General . 14
A.2 Resource Interchange File Format (RIFF) . 14
A.2.1 General . 14
A.2.2 Chunks . 14
A.2.3 RIFF forms . 15
A.3 Waveform audio file format (WAVE) . 15
A.3.1 General . 15
A.3.2 WAVE format chunk . 16
A.3.3 WAVE format categories . 16
A.4 Storage of WAVE data . 19
Annex B (normative) Chunk order . 20
Annex C (normative) Filename conventions . 21
C.1 General . 21
C.2 File-name length . 21
C.3 File-name extension . 21
C.4 File-name character set . 21
Annex D (informative) Multi-channel usage . 23
D.1 General . 23
D.2 Multi-channel audio data packing . 23
D.3 Channel assignments in multi-channel files . 24
D.3.1 General . 24
D.3.2 Distribution and archive . 24
D.3.3 Production recordings . 24
Annex E (informative) Other audio codings . 25
E.1 General . 25
E.2 MPEG files . 25
Annex F (normative) Extended file format (BWF-E) . 26
F.1 General . 26
F.2 Exceeding the 4-GB limit . 26
F.2.1 General . 26
F.2.2 64-bit resource interchange file format (RF64) . 27
F.3 Compatibility between BWF and BWF-E . 28
F.3.1 General . 28
F.3.2 Initialisation as BWF . 28
F.3.3 Transition to BWF-E . 28
F.4 RIFF/WAVE and RF64/WAVE structures . 29
F.4.1 Chunks and structs specific to the RIFF/WAVE format . 29
F.4.2 Chunks and structs specific to the RF64/WAVE (BWF-E) format . 29
Annex G (normative) bext chunk versions . 31
G.1 Version 0 . 31
G.2 Version 1 . 31
G.3 Version 2 . 31
Annex H (normative) Loudness parameters. 32
H.1 Treatment of loudness parameters . 32
H.2 Loudness parameter references . 33
Annex I (informative) Definition of the format for "Unique" Source Identifier (USID) for
use in the field . 34
I.1 USID . 34
I.2 Examples of USIDs . 34
Annex J (informative) Specification of the format for field . 35
J.1 General . 35
J.2 Syntax . 35
J.3 Examples of coding history fields . 35
Annex K (normative) Universal broadcast audio extension chunk . 37
K.1 General . 37
K.2 Contents of a BWFF with 'ubxt' chunk . 37
K.3 Universal broadcast audio extension chunk . 37
Bibliography . 40
Figure D.1 – Data packing for 24-bit mono PCM audio data . 23
Figure D.2 – Data packing for 16-bit stereo (2-channel) PCM audio data . 23
Figure D.3 – Data packing for 24-bit, 4-channel PCM audio data . 23
Figure D.4 – 24-bit sample packing . 24
Figure F.1 – Conventional RIFF/WAVE format . 26
Figure F.2 – Extended RF64/WAVE format . 27
Figure F.3 – Compatible RIFF/WAVE structure . 28
Table 1 – bext field content definitions . 12
Table A.1 – Chunk description . 14
Table A.2 – Format chunk – Common fields . 16
Table A.3 – WAVE format categories . 17
Table A.4 – Data packing for 16-bit mono PCM . 17
Table A.5 – Data packing for 16-bit stereo PCM . 18
Table A.6 – PCM data format . 18
Table A.7 – PCM data format – 16-bit . 18
Table A.8 – PCM WAVE format chunk examples . 18
Table C.1 – Permitted file-name characters . 21
– 4 – IEC 62942:2019 © IEC 2019
Table C.2 – Non-permitted file-name characters . 22
Table C.3 – Non-permitted file-name terminators . 22
Table H.1 – Rounding negative values . 32
Table H.2 – Rounding positive values . 32
Table J.1 – CodingHistory parameters . 35
Table K.1 – ubxt field content definitions . 38
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
FILE FORMAT FOR PROFESSIONAL TRANSFER AND
EXCHANGE OF DIGITAL AUDIO DATA
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as "IEC
Publication(s)"). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 62942 has been prepared by technical area 6: Storage media,
storage data structures, storage systems and equipment, of IEC technical committee 100:
Audio, video and multimedia systems and equipment.
The text of this standard is based on the following documents:
CDV Report on voting
100/3143/CDV 100/3226/RVC
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
– 6 – IEC 62942:2019 © IEC 2019
The committee has decided that the contents of this publication will remain unchanged until
the stability date indicated on the IEC web site under "http://webstore.iec.ch" in the data
related to the specific publication. At this date, the publication will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
A bilingual version of this publication may be issued at a later date.
INTRODUCTION
The Broadcast Wave format file (BWFF) is based on the Microsoft WAVE audio file format,
which is a type of file specified in the Microsoft resource interchange file format (RIFF) [1]
WAVE files specifically contain audio data. The basic building block of a RIFF file is a chunk
which contains specific information, an identification field, and a size field. A RIFF file
contains a number of chunks.
The BWFF specifically includes a chunk to carry certain
metadata important for broadcast and professional use. For reliable interchange, some
restrictions apply to the format of the audio data.
The Broadcast Wave Format was first developed using ASCII text for all fields. Later, as the
format was further developed, it was proposed to use multi-byte characters to internationalize
the format. It was understood that to use multi-byte character sets within the existing format
would cause compatibility issues when multi-byte metadata was parsed by applications
expecting ASCII text. The separate nature of human-readable and machine-readable
metadata was established, and a new "universal" chunk was established to carry
internationalized human-readable metadata using multi-byte character sets without
interoperability issues. This is described in Annex K.
——————
Microsoft® is a registered trademark, and Windows™ is a trademark of Microsoft Corp. This information is
given for the convenience of users of this document and does not constitute an endorsement by IEC of the
product named. Equivalent products may be used if they can be shown to lead to the same results.
Numbers in square brackets refer to the Bibliography.
– 8 – IEC 62942:2019 © IEC 2019
FILE FORMAT FOR PROFESSIONAL TRANSFER AND
EXCHANGE OF DIGITAL AUDIO DATA
1 Scope
This document specifies a file format for interchanging audio data between compliant
equipment. It is primarily intended for audio applications in professional recording, production,
post-production, and archiving.
It is derived from the AES31-2 [2] but is also compatible with variant specifications including
EBU Tech 3285 [3] to [10], ITU-R BR.1352-3-2007 [11] to [14], and the Japan Post Production
Association's BWF-J [15].
This document contains the specification of the broadcast audio extension chunk and its use
with PCM-coded audio data. Basic information on the RIFF format and how it can be extended
to other types of audio data is given in Annex E. Details of the PCM WAVE format are also
given in Annex A.
An optional extended format, BWF-E, supports 64-bit addressing to permit file sizes greater
than 4 GB.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their
content constitutes requirements of this document. For dated references, only the edition
cited applies. For undated references, the latest edition of the referenced document (including
any amendments) applies.
ISO/IEC 10646:2017, Information technology – Universal Coded Character Set (UCS)
ISO 8601, Data elements and interchange formats – Information interchange –
Representation of dates and times
SMPTE ST 330-2011; SMPTE standard for television – Unique Material Identifier (UMID)
INTERNET ENGINEERING TASK FORCE (IETF). RFC 3629: UTF-8, a transformation format
of ISO 10646 [online]. Edited by F. Yergeau. November 2003 [viewed 2019-11-26]. Available
at https://www.rfc-editor.org/rfc/rfc3629.txt
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following
addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp
3.1
resource interchange file format
RIFF
file representation upon which the WAVE file format is based
3.2
chunk
data package within RIFF files containing related data
3.3
ASCII
7-bit character code compliant with ISO/IEC 646
3.4
waveform audio file format
WAVE
audio file format based on the RIFF file structure
3.5
Broadcast Wave format file
BWFF
WAVE file containing the bext chunk as described in this document
3.6
broadcast extension chunk
bext
extension chunk to WAVE
3.7
universal broadcast audio extension chunk
ubxt
human-readable information of the bext chunk in multi-byte languages
3.8
UMID
unique material identifier as defined in SMPTE ST 330
3.9
Broadcast Wave format, extended
BWF-E
optional extended format that replaces a RIFF header with an RF64 header to support 64-bit
addressing to permit file sizes greater than 4 GB
3.10
RF64
structure equivalent to the RIFF file type supporting 64-bit addressing
3.11
CHAR
8-bit signed integer, representing integer values from −128 to +127
Note 1 to entry: Equivalent C type: "signed char".
3.12
BYTE
8-bit unsigned integer, representing integer values from 0 to 255
Note 1 to entry: Equivalent C type: "unsigned char".
– 10 – IEC 62942:2019 © IEC 2019
3.13
INT
16-bit signed integer, representing integer values from −32 768 to +32 767
Note 1 to entry: Equivalent C type: "signed short int".
Note 2 to entry: Multi-byte data types are little-endian.
3.14
WORD
16-bit unsigned integer, representing integer values from 0 to +65 535
Note 1 to entry: Equivalent C type: "unsigned short int".
Note 2 to entry: Multi-byte data types are little-endian.
3.15
LONG
32-bit signed integer, representing integer values from −2 147 483 648 to +2 147 483 647
Note 1 to entry: Equivalent C type: "signed long int".
Note 2 to entry: Multi-byte data types are little-endian.
3.16
DWORD
32-bit unsigned integer, representing integer values from 0 to +4 294 967 295
Note 1 to entry: Equivalent C type: "unsigned long int".
Note 2 to entry: Multi-byte data types are little-endian.
4 BWF file
4.1 Existing chunks defined as part of the RIFF Format
This specification uses a number of RIFF chunks which are already defined (see Annex A).
These are:
Format Chunk
Audio data chunk
4.2 Additional chunks
Additional chunks can be present in the file. Some of these can be outside the scope of this
document. Applications may or may not interpret or make use of these chunks, so the integrity
of the data contained in such unknown chunks cannot be guaranteed. However, compliant
applications should pass on unknown chunks with their contents unchanged (but see also
Annex B).
4.3 Contents of a BWFF
A BWFF shall contain the RIFF "WAVE" header and at least the following chunks:
RIFF('WAVE'
/* Format of the audio signal: PCM/MPEG */
/* information on the audio sequence */
) /* sound data */
4.4 Broadcast audio extension chunk
Extra parameters needed for exchange of material between broadcasters are added in a
specific broadcast audio extension, or bext chunk. The structure of the bext chunk shall be
defined as follows:
typedef struct chunk_header {
DWORD ckID; /* (broadcastextension)ckID=bext */
DWORD ckSize; /* size of extension chunk */
BYTE ckData[ckSize]; /* data of the chunk */
} CHUNK_HEADER;
typedef struct broadcast_audio_extension {
CHAR Description[256]; /* ASCII: "Description of the sound
sequence" */
CHAR Originator[32]; /* ASCII: "Name of the originator" */
CHAR OriginatorReference[32]; /* ASCII: "Reference of the originator" */
CHAR OriginationDate[10]; /* ASCII: "yyyy-mm-dd" */
CHAR OriginationTime[8]; /* ASCII: "hh:mm:ss" */
DWORD TimeReferenceLow; /* First sample count since midnight, low
word */
DWORD TimeReferenceHigh; /* First sample count since midnight, high
word */
WORD Version; /* Version of the BWF; unsigned binary
number. See Annex G */
BYTE UMID_0; /* Binary byte 0 of SMPTE UMID */
....
BYTE UMID_63; /* Binary byte 63 of SMPTE UMID */
INT LoudnessValue; /* Integrated Loudness Value of the file in
LKFS (multiplied by 100) see Annex H */
INT LoudnessRange; /* Loudness Range of the file in LU
(multiplied by 100), see Annex H */
INT MaxTruePeakLevel; /* Maximum True Peak Level of the file
expressed as dBTP (multiplied by 100), see
Annex H */
INT MaxMomentaryLoudness; /* Highest value of the Momentary Loudness
Level of the file in LKFS (multiplied by
100), see Annex H */
INT MaxShortTermLoudness; /* Highest value of the Short-Term Loudness
Level of the file in LKFS (multiplied by
100), see Annex H */
BYTE Reserved[180]; /* 180 bytes, reserved for future use, set
to "NULL" */
CHAR CodingHistory[]; /* ASCII: « History coding » */
} BROADCAST_EXT
The content of the fields in the bext chunk shall be defined as shown in Table 1. Note that in
applications where ASCII text is inappropriate for human-readable information (for example
when a character set other than ISO 646 is required), it is necessary to carry it by another
means, for example, in a dedicated metadata chunk added to the BWFF. See also Annex K.
All the items except "Description", "Originator", "OriginatorReference" and "CodingHistory"
should have the same content as that of each corresponding item of the ubxt chunk (see
Annex K), if present. If machine-readable data in the "bext" chunk is updated, the
corresponding machine-readable data in the "ubxt" chunk should also be updated identically.
– 12 – IEC 62942:2019 © IEC 2019
Table 1 – bext field content definitions
Description
Human ASCII string, 256 characters or fewer, containing a description of the
sequence. If line breaks are used, lines shall be terminated by
. If data is not available or if the length of the string is less
than 256 characters, the first unused character shall be a null character
(00 ).
To help applications that only display a short description, a summary of
the description should be contained in the first 64 characters. The last
192 characters may be used for details.
Originator
Human ASCII string, 32 characters or fewer, containing the name of the
originator of the audio file. If data is not available or if the length of the
string is less than 32 characters, the first unused character shall be a
null character (00 ).
OriginatorReference
Human ASCII string, 32 characters or fewer, containing a reference allocated
by the originating organization. See Annex I.
If data is not available or if the length of the string is less than 32
characters, the first unused character shall be a null character (00 ).
OriginationDate
Human ASCII string, 10 characters, containing the date of creation of the audio
sequence.
Format: yyyy-mm-dd
yyyy = 4 characters for year shall contain a value between 0000 and
- = 1 character
mm = 2 characters for month shall contain a value between 01 and 12
- = 1 character
dd = 2 characters for day of month shall contain a value between 01
and 31
All components shall be present.
Hyphen characters, "-", shall be used as separators within the date
expression in compliance with ISO 8601. For compatibility with
alternative implementations, reproducing equipment should also
recognise the following separator characters: "_" underscore, ":"
colon, " " space, "." period.
OriginationTime
Human ASCII string, 8 characters, containing the time of creation of the audio
sequence in hours, minutes and seconds. If data is unavailable, the
default value shall be 00:00:00.
Format: hh:mm:ss
hh = 2 characters for hours shall contain a value between 00 and 23 if
time given
: = 1 character
mm = 2 characters for minutes shall contain a value between 00 and 59
if time given
: = 1 character
ss = 2 characters for seconds shall contain a value between 00 and 59
All components shall be present.
Colon characters, ":", shall be used as separators within the time of
day expression in compliance with ISO 8601. For compatibility with
alternative implementations, reproducing equipment should also
recognise the following characters: "_" underscore, "-" hyphen,
" " space, "." period.
TimeReference
Machine This field shall contain the sample address count [time code] of the
sequence. It is a 64-bit unsigned value which contains the sample count
since midnight of the first sample in the audio data. The number of
samples per second depends on the sample frequency, which is defined
in the field from the .
The default value is zero, corresponding to midnight.
Version
Machine An unsigned binary number indicating the version of the BWF.
For Version 1 it shall be set to 000116 and
for Version 2 it shall be set to 00021 .
This is set to 0002 . See Annex G.
UMID
Machine 64 bytes containing an extended UMID to SMPTE ST 330. If a 32-byte
basic UMID is used, the last 32 bytes shall be filled with zeros. If no
UMID is available, the 64 bytes shall be filled with zeros.
NOTE The length of the UMID is coded at the head of the UMID itself
LoudnessValue
Machine The integrated loudness value of the file in LKFS (multiplied by 100). A
16-bit signed integer, being the integer of (100 × the Integrated
Loudness value of the file in LKFS) ± 0,5. See Annex H for more details
on the method of conversion.
LoudnessRange
Machine A 16-bit signed integer, representing the loudness range of the file in
LU. See Annex H.
MaxTruePeakLevel
Machine A 16-bit signed integer, being the integer of (100 × the maximum true
peak value of the file in dBTP) ± 0,5. See Annex H for more details on
the method of conversion.
MaxMomentaryLoudness
Machine A 16-bit signed integer, being the integer of (100 × the highest value of
the momentary loudness level of the file in LKFS) ± 0,5. See Annex H
for more details on the method of conversion.
MaxShortTermLoudness
Machine A 16-bit signed integer, being the integer of (100 × the highest value of
the short-term loudness level of the file in LKFS) ± 0,5. See Annex H for
more details on the method of conversion.
Reserved
Machine 180 bytes reserved for extension. These 180 bytes shall be set to zero.
CodingHistory
Human A variable-size block of ASCII characters comprising 0 or more strings
each terminated by . The first unused character shall be a
null character (0016).
Each string shall contain a description of a coding process applied to
the audio data. Each new coding application should add a new string
with the appropriate information.
See Annex J.
4.5 Filename
A BWF file should be saved with a filename that can be interchanged with the widest range of
different computer types. See Annex C.
4.6 Channel usage
Audio files are typically mono (1-channel) or stereo (2-channel). For multi-channel usage in
Broadcast Wave format files, see Annex D.
4.7 File size
The 32-bit address space of a WAVE file limits its maximum size to 4 GB. Some practical
computer systems may impose a lower limit of 2 GB. For larger file sizes, Annex F describes
an extended file format, BWF-E.
– 14 – IEC 62942:2019 © IEC 2019
Annex A
(normative)
RIFF WAVE file format
A.1 General
The information in this annex follows the specification documents of the Microsoft RIFF file
format. See [1].
A.2 Resource Interchange File Format (RIFF)
A.2.1 General
The Resource Interchange File Format (RIFF) is a tagged file structure developed for use on
multimedia platforms. This clause describes a "chunk" and "RIFF form".
A.2.2 Chunks
The basic building block of a RIFF file is called a "chunk". Using C syntax, a chunk can be
defined as follows:
typedef unsigned long DWORD;
typedef unsigned char BYTE;
typedef DWORD FOURCC; /* Four-character code */
typedef FOURCC CKID; /* Four-character-code chunk identifier */
typedef DWORD CKSIZE; /* 32-bit unsigned size value */
typedef struct { /* Chunk structure */
CKID ckID; /* Chunk type identifier */
CKSIZE ckSize; /* Chunk size field (size of ckData) */
BYTE ckData[ckSize]; /* Chunk data */
} CK;
A "FOURCC" is represented as a sequence of one to four ASCII alphanumeric characters,
padded on the right with blank characters (ASCII character value 32) as required, with no
embedded blanks.
For example, the four-character code (FOURCC) "FOO " is stored as a sequence of four bytes:
"F", "O", "O", " " in ascending addresses. For quick comparisons, a four-character code may
also be treated as a 32-bit number.
The three parts of the chunk are described in Table A.1.
Table A.1 – Chunk description
Part Description
ckID
A four-character code that identifies the representation of the chunk data data.
A program reading a RIFF file can skip over any chunk whose chunk ID it doesn't recognize; it simply
skips the number of bytes specified by ckSize plus the pad byte, if present.
ckSize
A 32-bit unsigned value identifying the size of ckData. This size value does not include the size of the
ckID or ckSize fields or the pad byte at the end of ckData.
ckData
Binary data of fixed or variable size. The start of ckData is word-aligned with respect to the start of
the RIFF file. If the chunk size is an odd number of bytes, a pad byte with value zero is written after
ckData. The ckSize value does not include the pad byte.
We can represent a chunk with the following notation (in this example, the ckSize and pad
byte are implicit):
( )
A RIFF chunk may contain nested chunks, or subchunks.
All other chunk types store a single element of binary data in .
A.2.3 RIFF forms
A RIFF form is a chunk with a "RIFF" chunk ID. The term also refers to a file format that
follows the RIFF framework. A "WAVE" is registered to a "RIFF Form Type".
Using the notation for representing a chunk, a RIFF form looks like the following:
RIFF ( . )
The first four bytes of a RIFF form make up a chunk ID with values "R", "I", "F", "F". The
ckSize field is required, but for simplicity it is omitted from the notation.
The first DWORD of chunk data in the "RIFF" chunk (shown above as ) is a four-
character code value identifying the data representation, or form type, of the file. Following
the form-type code is a series of subchunks. Which subchunks are present depends on the
form type.
The definition of a particular RIFF form typically includes the following:
– a unique four-character code identifying the form type;
– a list of required chunks;
– a list of optional chunks;
– possibly, a required order for the chunks.
A.3 Waveform audio file format (WAVE)
A.3.1 General
The WAVE form is defined as follows. Programs shall expect (and shall ignore) any unknown
chunks encountered, as with all RIFF forms (but see Annex B). However, shall
always occur before , and both of these chunks are required in a WAVE file.
->
RIFF ( "WAVE"
/* Format chunk */
[] /* Fact chunk */
[cue-ck] /* Cue points */
[] /* playlist */
[] /* Associated data list */
) /* Wave data */
The WAVE chunks are described in A.3.2.
NOTE , , and are not used in this specification.
– 16 – IEC 62942:2019 © IEC 2019
A.3.2 WAVE format chunk
The WAVE format chunk specifies the format of the .
The shall be defined as follows:
-> fmt(
)
->
struct{
WORD wFormatTag; /* Format category */
WORD nChannels; /* Number of channels */
DWORD nSamplesPerSec; /* Sampling frequency */
DWORD nAvgBytesPerSec; /* For buffer estimation */
WORD nBlockAlign; /* Data block size */
}
The content of the fields in the portion of the chunk shall be defined as
shown in Table A.2.
Table A.2 – Format chunk – Common fields
Field Description
wFormatTag A number indicating the WAVE format category of the file. The content of the
portion of the format chunk and the
interpretation of the waveform data depend on this value.
nchannels The number of channels represented in the waveform data, such as 1 for mono or 2
for stereo.
nSamplesPerSec The sampling frequency, in samples per second, at which each channel should be
reproduced.
nAvgBytesPerSec The average number of bytes per second at which the waveform data should be
transferred. Playback software can estimate the buffer size using this value.
nBlockAlign The block alignment in bytes of the waveform data. Playback software needs to
process a multiple of bytes of data at a time, so the value of
can be used for buffer alignment.
The shall comprise zero or more bytes of parameters. Which
parameters occur depends on the WAVE format category. Playback software should allow for
(and ignore) any unknown parameters that occur at the end of this
field.
A.3.3 WAVE format categories
A.3.3.1 General
The format category of a WAVE file shall be specified by the value of the field
of the format chunk. The representation of data in , and the content of the
of the format chunk, shall depend on the format category.
Currently defined open non-proprietary WAVE format categories are shown in Table A.3.
Table A.3 – WAVE format categories
wFormatTag Value Format category
WAVE_FORMAT_PCM 0001 Pulse code modulation (PCM) format
NOTE Although other WAVE formats exist, only the above formats are at present used with the BWFF. Details of
the PCM WAVE format are provided in Clause A.2. General information on other WAVE formats is given in Annex F.
A.3.3.2 PCM format
If the field of the is set to WAVE_FORMAT_PCM, then the waveform
data shall consist of samples represented in PCM format. For PCM waveform data, the
shall be defined as follows:
->
struct{
WORD nBitsPerSample; /* Sample size */
}
The field shall specify the number of bits of data used to represent each
audio sample of each channel. If there are multiple channels, the sample size shall be the
same for each channel.
The field should be equal to the following formula, rounded to the next whole
number:
nChannels x BytesPerSample
The value of BytesPerSample shall be calculated by rounding up nBitsPerSample to the next
whole byte. Where the audio sample word is less than an integer number of bytes, the most
significant bits of the audio sample shall be placed in the most significant bits of the data
word; the unused data bits adjacent to the least-significant bits shall be set to zero.
For PCM data, the field of the format chunk shall be equal to the
following formula:
nSamplesPerSec x nBlockAlign
NOTE The original WAVE specification permits, for example, 20-bit samples from two channels packed into
5 bytes – sharing a single byte for the least significant bits of the two channels. This document specifies a whole
number of bytes per audio sample in order to reduce ambiguity in implementations and to achieve maximum
interchange compatibility.
A.3.3.3 Data packing for PCM WAVE files
In a single-channel WAVE file, samples shall be stored consecutively.
For stereo WAVE files, channel 0 shall represent the left channel, and channel 1 shall
represent the right channel. Table A.4 and Table A.5 show examples of data packing for
16-bit mono and stereo WAVE files.
Table A.4 – Data packing for 16-bit mono PCM
Sample 1 Sample 2
Channel 0 Channel 0 Channel 0 Channel 0
low-order byte high-order byte low-order byte high-order byte
– 18 – IEC 62942:2019 © IEC 2019
Table A.5 – Data packing for 16-bit stereo PCM
Sample 1
Channel 0 (left) Channel 0 (left) Channel 1 (right) Channel 1 (right)
low-order byte high-order byte low-order byte high-order byte
In multiple-channel WAVE files, samples shall be interleaved in channel sequence (see
Annex E for examples).
A.3.3.4 Data format of the samples
Each sample is contained in an integer i. The size of i is the smallest number of bytes
required to contain the specified sample size. The least significant byte shall be stored first.
The bits that represent the sample amplitude are stored in the most significant bits of i, and
the remaining bits shall be set to zero.
For example, if the sample size recorded in
...
IEC 62942 ®
Edition 1.0 2019-12
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
File format for professional transfer and exchange of digital audio data
Format de fichier pour le transfert et l'échange professionnels de données
audionumériques
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.
Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite
ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie
et les microfilms, sans l'accord écrit de l'IEC ou du Comité national de l'IEC du pays du demandeur. Si vous avez des
questions sur le copyright de l'IEC ou si vous désirez obtenir des droits supplémentaires sur cette publication, utilisez
les coordonnées ci-après ou contactez le Comité national de l'IEC de votre pays de résidence.
IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.
About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.
IEC publications search - webstore.iec.ch/advsearchform Electropedia - www.electropedia.org
The advanced search enables to find IEC publications by a The world's leading online dictionary on electrotechnology,
variety of criteria (reference number, text, technical containing more than 22 000 terminological entries in English
committee,…). It also gives information on projects, replaced and French, with equivalent terms in 16 additional languages.
and withdrawn publications. Also known as the International Electrotechnical Vocabulary
(IEV) online.
IEC Just Published - webstore.iec.ch/justpublished
Stay up to date on all new IEC publications. Just Published IEC Glossary - std.iec.ch/glossary
details all new publications released. Available online and 67 000 electrotechnical terminology entries in English and
once a month by email. French extracted from the Terms and Definitions clause of
IEC publications issued since 2002. Some entries have been
IEC Customer Service Centre - webstore.iec.ch/csc collected from earlier publications of IEC TC 37, 77, 86 and
If you wish to give us your feedback on this publication or CISPR.
need further assistance, please contact the Customer Service
Centre: sales@iec.ch.
A propos de l'IEC
La Commission Electrotechnique Internationale (IEC) est la première organisation mondiale qui élabore et publie des
Normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.
A propos des publications IEC
Le contenu technique des publications IEC est constamment revu. Veuillez vous assurer que vous possédez l’édition la
plus récente, un corrigendum ou amendement peut avoir été publié.
Recherche de publications IEC - Electropedia - www.electropedia.org
webstore.iec.ch/advsearchform Le premier dictionnaire d'électrotechnologie en ligne au
La recherche avancée permet de trouver des publications IEC monde, avec plus de 22 000 articles terminologiques en
en utilisant différents critères (numéro de référence, texte, anglais et en français, ainsi que les termes équivalents dans
comité d’études,…). Elle donne aussi des informations sur les 16 langues additionnelles. Egalement appelé Vocabulaire
projets et les publications remplacées ou retirées. Electrotechnique International (IEV) en ligne.
IEC Just Published - webstore.iec.ch/justpublished Glossaire IEC - std.iec.ch/glossary
Restez informé sur les nouvelles publications IEC. Just 67 000 entrées terminologiques électrotechniques, en anglais
Published détaille les nouvelles publications parues. et en français, extraites des articles Termes et Définitions des
Disponible en ligne et une fois par mois par email. publications IEC parues depuis 2002. Plus certaines entrées
antérieures extraites des publications des CE 37, 77, 86 et
Service Clients - webstore.iec.ch/csc CISPR de l'IEC.
Si vous désirez nous donner des commentaires sur cette
publication ou si vous avez des questions contactez-nous:
sales@iec.ch.
IEC 62942 ®
Edition 1.0 2019-12
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
File format for professional transfer and exchange of digital audio data
Format de fichier pour le transfert et l'échange professionnels de données
audionumériques
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
COMMISSION
ELECTROTECHNIQUE
INTERNATIONALE
ICS 33.160.30 ISBN 978-2-8322-8696-8
– 2 – IEC 62942:2019 © IEC 2019
CONTENTS
FOREWORD . 5
INTRODUCTION . 7
1 Scope . 8
2 Normative references . 8
3 Terms and definitions . 8
4 BWF file . 10
4.1 Existing chunks defined as part of the RIFF Format . 10
4.2 Additional chunks . 10
4.3 Contents of a BWFF . 10
4.4 Broadcast audio extension chunk . 11
4.5 Filename . 13
4.6 Channel usage . 13
4.7 File size . 13
Annex A (normative) RIFF WAVE file format . 14
A.1 General . 14
A.2 Resource Interchange File Format (RIFF) . 14
A.2.1 General . 14
A.2.2 Chunks . 14
A.2.3 RIFF forms . 15
A.3 Waveform audio file format (WAVE) . 15
A.3.1 General . 15
A.3.2 WAVE format chunk . 16
A.3.3 WAVE format categories . 16
A.4 Storage of WAVE data . 19
Annex B (normative) Chunk order . 20
Annex C (normative) Filename conventions . 21
C.1 General . 21
C.2 File-name length . 21
C.3 File-name extension . 21
C.4 File-name character set . 21
Annex D (informative) Multi-channel usage . 23
D.1 General . 23
D.2 Multi-channel audio data packing . 23
D.3 Channel assignments in multi-channel files . 24
D.3.1 General . 24
D.3.2 Distribution and archive . 24
D.3.3 Production recordings . 24
Annex E (informative) Other audio codings . 25
E.1 General . 25
E.2 MPEG files . 25
Annex F (normative) Extended file format (BWF-E) . 26
F.1 General . 26
F.2 Exceeding the 4-GB limit . 26
F.2.1 General . 26
F.2.2 64-bit resource interchange file format (RF64) . 27
F.3 Compatibility between BWF and BWF-E . 28
F.3.1 General . 28
F.3.2 Initialisation as BWF . 28
F.3.3 Transition to BWF-E . 28
F.4 RIFF/WAVE and RF64/WAVE structures . 29
F.4.1 Chunks and structs specific to the RIFF/WAVE format . 29
F.4.2 Chunks and structs specific to the RF64/WAVE (BWF-E) format . 29
Annex G (normative) bext chunk versions . 31
G.1 Version 0 . 31
G.2 Version 1 . 31
G.3 Version 2 . 31
Annex H (normative) Loudness parameters. 32
H.1 Treatment of loudness parameters . 32
H.2 Loudness parameter references . 33
Annex I (informative) Definition of the format for "Unique" Source Identifier (USID) for
use in the field . 34
I.1 USID . 34
I.2 Examples of USIDs . 34
Annex J (informative) Specification of the format for field . 35
J.1 General . 35
J.2 Syntax . 35
J.3 Examples of coding history fields . 35
Annex K (normative) Universal broadcast audio extension chunk . 37
K.1 General . 37
K.2 Contents of a BWFF with 'ubxt' chunk . 37
K.3 Universal broadcast audio extension chunk . 37
Bibliography . 40
Figure D.1 – Data packing for 24-bit mono PCM audio data . 23
Figure D.2 – Data packing for 16-bit stereo (2-channel) PCM audio data . 23
Figure D.3 – Data packing for 24-bit, 4-channel PCM audio data . 23
Figure D.4 – 24-bit sample packing . 24
Figure F.1 – Conventional RIFF/WAVE format . 26
Figure F.2 – Extended RF64/WAVE format . 27
Figure F.3 – Compatible RIFF/WAVE structure . 28
Table 1 – bext field content definitions . 12
Table A.1 – Chunk description . 14
Table A.2 – Format chunk – Common fields . 16
Table A.3 – WAVE format categories . 17
Table A.4 – Data packing for 16-bit mono PCM . 17
Table A.5 – Data packing for 16-bit stereo PCM . 18
Table A.6 – PCM data format . 18
Table A.7 – PCM data format – 16-bit . 18
Table A.8 – PCM WAVE format chunk examples . 18
Table C.1 – Permitted file-name characters . 21
– 4 – IEC 62942:2019 © IEC 2019
Table C.2 – Non-permitted file-name characters . 22
Table C.3 – Non-permitted file-name terminators . 22
Table H.1 – Rounding negative values . 32
Table H.2 – Rounding positive values . 32
Table J.1 – CodingHistory parameters . 35
Table K.1 – ubxt field content definitions . 38
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
FILE FORMAT FOR PROFESSIONAL TRANSFER AND
EXCHANGE OF DIGITAL AUDIO DATA
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as "IEC
Publication(s)"). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 62942 has been prepared by technical area 6: Storage media,
storage data structures, storage systems and equipment, of IEC technical committee 100:
Audio, video and multimedia systems and equipment.
The text of this standard is based on the following documents:
CDV Report on voting
100/3143/CDV 100/3226/RVC
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
– 6 – IEC 62942:2019 © IEC 2019
The committee has decided that the contents of this publication will remain unchanged until
the stability date indicated on the IEC web site under "http://webstore.iec.ch" in the data
related to the specific publication. At this date, the publication will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
INTRODUCTION
The Broadcast Wave format file (BWFF) is based on the Microsoft WAVE audio file format,
which is a type of file specified in the Microsoft resource interchange file format (RIFF) [1]
WAVE files specifically contain audio data. The basic building block of a RIFF file is a chunk
which contains specific information, an identification field, and a size field. A RIFF file
contains a number of chunks.
The BWFF specifically includes a chunk to carry certain
metadata important for broadcast and professional use. For reliable interchange, some
restrictions apply to the format of the audio data.
The Broadcast Wave Format was first developed using ASCII text for all fields. Later, as the
format was further developed, it was proposed to use multi-byte characters to internationalize
the format. It was understood that to use multi-byte character sets within the existing format
would cause compatibility issues when multi-byte metadata was parsed by applications
expecting ASCII text. The separate nature of human-readable and machine-readable
metadata was established, and a new "universal" chunk was established to carry
internationalized human-readable metadata using multi-byte character sets without
interoperability issues. This is described in Annex K.
——————
Microsoft® is a registered trademark, and Windows™ is a trademark of Microsoft Corp. This information is
given for the convenience of users of this document and does not constitute an endorsement by IEC of the
product named. Equivalent products may be used if they can be shown to lead to the same results.
Numbers in square brackets refer to the Bibliography.
– 8 – IEC 62942:2019 © IEC 2019
FILE FORMAT FOR PROFESSIONAL TRANSFER AND
EXCHANGE OF DIGITAL AUDIO DATA
1 Scope
This document specifies a file format for interchanging audio data between compliant
equipment. It is primarily intended for audio applications in professional recording, production,
post-production, and archiving.
It is derived from the AES31-2 [2] but is also compatible with variant specifications including
EBU Tech 3285 [3] to [10], ITU-R BR.1352-3-2007 [11] to [14], and the Japan Post Production
Association's BWF-J [15].
This document contains the specification of the broadcast audio extension chunk and its use
with PCM-coded audio data. Basic information on the RIFF format and how it can be extended
to other types of audio data is given in Annex E. Details of the PCM WAVE format are also
given in Annex A.
An optional extended format, BWF-E, supports 64-bit addressing to permit file sizes greater
than 4 GB.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their
content constitutes requirements of this document. For dated references, only the edition
cited applies. For undated references, the latest edition of the referenced document (including
any amendments) applies.
ISO/IEC 10646:2017, Information technology – Universal Coded Character Set (UCS)
ISO 8601, Data elements and interchange formats – Information interchange –
Representation of dates and times
SMPTE ST 330-2011; SMPTE standard for television – Unique Material Identifier (UMID)
INTERNET ENGINEERING TASK FORCE (IETF). RFC 3629: UTF-8, a transformation format
of ISO 10646 [online]. Edited by F. Yergeau. November 2003 [viewed 2019-11-26]. Available
at https://www.rfc-editor.org/rfc/rfc3629.txt
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following
addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp
3.1
resource interchange file format
RIFF
file representation upon which the WAVE file format is based
3.2
chunk
data package within RIFF files containing related data
3.3
ASCII
7-bit character code compliant with ISO/IEC 646
3.4
waveform audio file format
WAVE
audio file format based on the RIFF file structure
3.5
Broadcast Wave format file
BWFF
WAVE file containing the bext chunk as described in this document
3.6
broadcast extension chunk
bext
extension chunk to WAVE
3.7
universal broadcast audio extension chunk
ubxt
human-readable information of the bext chunk in multi-byte languages
3.8
UMID
unique material identifier as defined in SMPTE ST 330
3.9
Broadcast Wave format, extended
BWF-E
optional extended format that replaces a RIFF header with an RF64 header to support 64-bit
addressing to permit file sizes greater than 4 GB
3.10
RF64
structure equivalent to the RIFF file type supporting 64-bit addressing
3.11
CHAR
8-bit signed integer, representing integer values from −128 to +127
Note 1 to entry: Equivalent C type: "signed char".
3.12
BYTE
8-bit unsigned integer, representing integer values from 0 to 255
Note 1 to entry: Equivalent C type: "unsigned char".
– 10 – IEC 62942:2019 © IEC 2019
3.13
INT
16-bit signed integer, representing integer values from −32 768 to +32 767
Note 1 to entry: Equivalent C type: "signed short int".
Note 2 to entry: Multi-byte data types are little-endian.
3.14
WORD
16-bit unsigned integer, representing integer values from 0 to +65 535
Note 1 to entry: Equivalent C type: "unsigned short int".
Note 2 to entry: Multi-byte data types are little-endian.
3.15
LONG
32-bit signed integer, representing integer values from −2 147 483 648 to +2 147 483 647
Note 1 to entry: Equivalent C type: "signed long int".
Note 2 to entry: Multi-byte data types are little-endian.
3.16
DWORD
32-bit unsigned integer, representing integer values from 0 to +4 294 967 295
Note 1 to entry: Equivalent C type: "unsigned long int".
Note 2 to entry: Multi-byte data types are little-endian.
4 BWF file
4.1 Existing chunks defined as part of the RIFF Format
This specification uses a number of RIFF chunks which are already defined (see Annex A).
These are:
Format Chunk
Audio data chunk
4.2 Additional chunks
Additional chunks can be present in the file. Some of these can be outside the scope of this
document. Applications may or may not interpret or make use of these chunks, so the integrity
of the data contained in such unknown chunks cannot be guaranteed. However, compliant
applications should pass on unknown chunks with their contents unchanged (but see also
Annex B).
4.3 Contents of a BWFF
A BWFF shall contain the RIFF "WAVE" header and at least the following chunks:
RIFF('WAVE'
/* Format of the audio signal: PCM/MPEG */
/* information on the audio sequence */
) /* sound data */
4.4 Broadcast audio extension chunk
Extra parameters needed for exchange of material between broadcasters are added in a
specific broadcast audio extension, or bext chunk. The structure of the bext chunk shall be
defined as follows:
typedef struct chunk_header {
DWORD ckID; /* (broadcastextension)ckID=bext */
DWORD ckSize; /* size of extension chunk */
BYTE ckData[ckSize]; /* data of the chunk */
} CHUNK_HEADER;
typedef struct broadcast_audio_extension {
CHAR Description[256]; /* ASCII: "Description of the sound
sequence" */
CHAR Originator[32]; /* ASCII: "Name of the originator" */
CHAR OriginatorReference[32]; /* ASCII: "Reference of the originator" */
CHAR OriginationDate[10]; /* ASCII: "yyyy-mm-dd" */
CHAR OriginationTime[8]; /* ASCII: "hh:mm:ss" */
DWORD TimeReferenceLow; /* First sample count since midnight, low
word */
DWORD TimeReferenceHigh; /* First sample count since midnight, high
word */
WORD Version; /* Version of the BWF; unsigned binary
number. See Annex G */
BYTE UMID_0; /* Binary byte 0 of SMPTE UMID */
....
BYTE UMID_63; /* Binary byte 63 of SMPTE UMID */
INT LoudnessValue; /* Integrated Loudness Value of the file in
LKFS (multiplied by 100) see Annex H */
INT LoudnessRange; /* Loudness Range of the file in LU
(multiplied by 100), see Annex H */
INT MaxTruePeakLevel; /* Maximum True Peak Level of the file
expressed as dBTP (multiplied by 100), see
Annex H */
INT MaxMomentaryLoudness; /* Highest value of the Momentary Loudness
Level of the file in LKFS (multiplied by
100), see Annex H */
INT MaxShortTermLoudness; /* Highest value of the Short-Term Loudness
Level of the file in LKFS (multiplied by
100), see Annex H */
BYTE Reserved[180]; /* 180 bytes, reserved for future use, set
to "NULL" */
CHAR CodingHistory[]; /* ASCII: « History coding » */
} BROADCAST_EXT
The content of the fields in the bext chunk shall be defined as shown in Table 1. Note that in
applications where ASCII text is inappropriate for human-readable information (for example
when a character set other than ISO 646 is required), it is necessary to carry it by another
means, for example, in a dedicated metadata chunk added to the BWFF. See also Annex K.
All the items except "Description", "Originator", "OriginatorReference" and "CodingHistory"
should have the same content as that of each corresponding item of the ubxt chunk (see
Annex K), if present. If machine-readable data in the "bext" chunk is updated, the
corresponding machine-readable data in the "ubxt" chunk should also be updated identically.
– 12 – IEC 62942:2019 © IEC 2019
Table 1 – bext field content definitions
Description
Human ASCII string, 256 characters or fewer, containing a description of the
sequence. If line breaks are used, lines shall be terminated by
. If data is not available or if the length of the string is less
than 256 characters, the first unused character shall be a null character
(00 ).
To help applications that only display a short description, a summary of
the description should be contained in the first 64 characters. The last
192 characters may be used for details.
Originator
Human ASCII string, 32 characters or fewer, containing the name of the
originator of the audio file. If data is not available or if the length of the
string is less than 32 characters, the first unused character shall be a
null character (00 ).
OriginatorReference
Human ASCII string, 32 characters or fewer, containing a reference allocated
by the originating organization. See Annex I.
If data is not available or if the length of the string is less than 32
characters, the first unused character shall be a null character (00 ).
OriginationDate
Human ASCII string, 10 characters, containing the date of creation of the audio
sequence.
Format: yyyy-mm-dd
yyyy = 4 characters for year shall contain a value between 0000 and
- = 1 character
mm = 2 characters for month shall contain a value between 01 and 12
- = 1 character
dd = 2 characters for day of month shall contain a value between 01
and 31
All components shall be present.
Hyphen characters, "-", shall be used as separators within the date
expression in compliance with ISO 8601. For compatibility with
alternative implementations, reproducing equipment should also
recognise the following separator characters: "_" underscore, ":"
colon, " " space, "." period.
OriginationTime
Human ASCII string, 8 characters, containing the time of creation of the audio
sequence in hours, minutes and seconds. If data is unavailable, the
default value shall be 00:00:00.
Format: hh:mm:ss
hh = 2 characters for hours shall contain a value between 00 and 23 if
time given
: = 1 character
mm = 2 characters for minutes shall contain a value between 00 and 59
if time given
: = 1 character
ss = 2 characters for seconds shall contain a value between 00 and 59
All components shall be present.
Colon characters, ":", shall be used as separators within the time of
day expression in compliance with ISO 8601. For compatibility with
alternative implementations, reproducing equipment should also
recognise the following characters: "_" underscore, "-" hyphen,
" " space, "." period.
TimeReference
Machine This field shall contain the sample address count [time code] of the
sequence. It is a 64-bit unsigned value which contains the sample count
since midnight of the first sample in the audio data. The number of
samples per second depends on the sample frequency, which is defined
in the field from the .
The default value is zero, corresponding to midnight.
Version
Machine An unsigned binary number indicating the version of the BWF.
For Version 1 it shall be set to 000116 and
for Version 2 it shall be set to 00021 .
This is set to 0002 . See Annex G.
UMID
Machine 64 bytes containing an extended UMID to SMPTE ST 330. If a 32-byte
basic UMID is used, the last 32 bytes shall be filled with zeros. If no
UMID is available, the 64 bytes shall be filled with zeros.
NOTE The length of the UMID is coded at the head of the UMID itself
LoudnessValue
Machine The integrated loudness value of the file in LKFS (multiplied by 100). A
16-bit signed integer, being the integer of (100 × the Integrated
Loudness value of the file in LKFS) ± 0,5. See Annex H for more details
on the method of conversion.
LoudnessRange
Machine A 16-bit signed integer, representing the loudness range of the file in
LU. See Annex H.
MaxTruePeakLevel
Machine A 16-bit signed integer, being the integer of (100 × the maximum true
peak value of the file in dBTP) ± 0,5. See Annex H for more details on
the method of conversion.
MaxMomentaryLoudness
Machine A 16-bit signed integer, being the integer of (100 × the highest value of
the momentary loudness level of the file in LKFS) ± 0,5. See Annex H
for more details on the method of conversion.
MaxShortTermLoudness
Machine A 16-bit signed integer, being the integer of (100 × the highest value of
the short-term loudness level of the file in LKFS) ± 0,5. See Annex H for
more details on the method of conversion.
Reserved
Machine 180 bytes reserved for extension. These 180 bytes shall be set to zero.
CodingHistory
Human A variable-size block of ASCII characters comprising 0 or more strings
each terminated by . The first unused character shall be a
null character (0016).
Each string shall contain a description of a coding process applied to
the audio data. Each new coding application should add a new string
with the appropriate information.
See Annex J.
4.5 Filename
A BWF file should be saved with a filename that can be interchanged with the widest range of
different computer types. See Annex C.
4.6 Channel usage
Audio files are typically mono (1-channel) or stereo (2-channel). For multi-channel usage in
Broadcast Wave format files, see Annex D.
4.7 File size
The 32-bit address space of a WAVE file limits its maximum size to 4 GB. Some practical
computer systems may impose a lower limit of 2 GB. For larger file sizes, Annex F describes
an extended file format, BWF-E.
– 14 – IEC 62942:2019 © IEC 2019
Annex A
(normative)
RIFF WAVE file format
A.1 General
The information in this annex follows the specification documents of the Microsoft RIFF file
format. See [1].
A.2 Resource Interchange File Format (RIFF)
A.2.1 General
The Resource Interchange File Format (RIFF) is a tagged file structure developed for use on
multimedia platforms. This clause describes a "chunk" and "RIFF form".
A.2.2 Chunks
The basic building block of a RIFF file is called a "chunk". Using C syntax, a chunk can be
defined as follows:
typedef unsigned long DWORD;
typedef unsigned char BYTE;
typedef DWORD FOURCC; /* Four-character code */
typedef FOURCC CKID; /* Four-character-code chunk identifier */
typedef DWORD CKSIZE; /* 32-bit unsigned size value */
typedef struct { /* Chunk structure */
CKID ckID; /* Chunk type identifier */
CKSIZE ckSize; /* Chunk size field (size of ckData) */
BYTE ckData[ckSize]; /* Chunk data */
} CK;
A "FOURCC" is represented as a sequence of one to four ASCII alphanumeric characters,
padded on the right with blank characters (ASCII character value 32) as required, with no
embedded blanks.
For example, the four-character code (FOURCC) "FOO " is stored as a sequence of four bytes:
"F", "O", "O", " " in ascending addresses. For quick comparisons, a four-character code may
also be treated as a 32-bit number.
The three parts of the chunk are described in Table A.1.
Table A.1 – Chunk description
Part Description
ckID
A four-character code that identifies the representation of the chunk data data.
A program reading a RIFF file can skip over any chunk whose chunk ID it doesn't recognize; it simply
skips the number of bytes specified by ckSize plus the pad byte, if present.
ckSize
A 32-bit unsigned value identifying the size of ckData. This size value does not include the size of the
ckID or ckSize fields or the pad byte at the end of ckData.
ckData
Binary data of fixed or variable size. The start of ckData is word-aligned with respect to the start of
the RIFF file. If the chunk size is an odd number of bytes, a pad byte with value zero is written after
ckData. The ckSize value does not include the pad byte.
We can represent a chunk with the following notation (in this example, the ckSize and pad
byte are implicit):
( )
A RIFF chunk may contain nested chunks, or subchunks.
All other chunk types store a single element of binary data in .
A.2.3 RIFF forms
A RIFF form is a chunk with a "RIFF" chunk ID. The term also refers to a file format that
follows the RIFF framework. A "WAVE" is registered to a "RIFF Form Type".
Using the notation for representing a chunk, a RIFF form looks like the following:
RIFF ( . )
The first four bytes of a RIFF form make up a chunk ID with values "R", "I", "F", "F". The
ckSize field is required, but for simplicity it is omitted from the notation.
The first DWORD of chunk data in the "RIFF" chunk (shown above as ) is a four-
character code value identifying the data representation, or form type, of the file. Following
the form-type code is a series of subchunks. Which subchunks are present depends on the
form type.
The definition of a particular RIFF form typically includes the following:
– a unique four-character code identifying the form type;
– a list of required chunks;
– a list of optional chunks;
– possibly, a required order for the chunks.
A.3 Waveform audio file format (WAVE)
A.3.1 General
The WAVE form is defined as follows. Programs shall expect (and shall ignore) any unknown
chunks encountered, as with all RIFF forms (but see Annex B). However, shall
always occur before , and both of these chunks are required in a WAVE file.
->
RIFF ( "WAVE"
/* Format chunk */
[] /* Fact chunk */
[cue-ck] /* Cue points */
[] /* playlist */
[] /* Associated data list */
) /* Wave data */
The WAVE chunks are described in A.3.2.
NOTE , , and are not used in this specification.
– 16 – IEC 62942:2019 © IEC 2019
A.3.2 WAVE format chunk
The WAVE format chunk specifies the format of the .
The shall be defined as follows:
-> fmt(
)
->
struct{
WORD wFormatTag; /* Format category */
WORD nChannels; /* Number of channels */
DWORD nSamplesPerSec; /* Sampling frequency */
DWORD nAvgBytesPerSec; /* For buffer estimation */
WORD nBlockAlign; /* Data block size */
}
The content of the fields in the portion of the chunk shall be defined as
shown in Table A.2.
Table A.2 – Format chunk – Common fields
Field Description
wFormatTag A number indicating the WAVE format category of the file. The content of the
portion of the format chunk and the
interpretation of the waveform data depend on this value.
nchannels The number of channels represented in the waveform data, such as 1 for mono or 2
for stereo.
nSamplesPerSec The sampling frequency, in samples per second, at which each channel should be
reproduced.
nAvgBytesPerSec The average number of bytes per second at which the waveform data should be
transferred. Playback software can estimate the buffer size using this value.
nBlockAlign The block alignment in bytes of the waveform data. Playback software needs to
process a multiple of bytes of data at a time, so the value of
can be used for buffer alignment.
The shall comprise zero or more bytes of parameters. Which
parameters occur depends on the WAVE format category. Playback software should allow for
(and ignore) any unknown parameters that occur at the end of this
field.
A.3.3 WAVE format categories
A.3.3.1 General
The format category of a WAVE file shall be specified by the value of the field
of the format chunk. The representation of data in , and the content of the
of the format chunk, shall depend on the format category.
Currently defined open non-proprietary WAVE format categories are shown in Table A.3.
Table A.3 – WAVE format categories
wFormatTag Value Format category
WAVE_FORMAT_PCM 0001 Pulse code modulation (PCM) format
NOTE Although other WAVE formats exist, only the above formats are at present used with the BWFF. Details of
the PCM WAVE format are provided in Clause A.2. General information on other WAVE formats is given in Annex F.
A.3.3.2 PCM format
If the field of the is set to WAVE_FORMAT_PCM, then the waveform
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...