EN IEC 62942:2020
(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.
Dateiformat für die professionelle Übertragung und den Austausch digitaler Audiodaten
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.
Format datoteke za profesionalni prenos in izmenjavo digitalnih avdio podatkov (TA6) (IEC 62942:2019)
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-oktober-2020
Format datoteke za profesionalni prenos in izmenjavo digitalnih avdio podatkov
(TA6) (IEC 62942:2019)
File format for professional transfer and exchange of digital audio data (TA6) (IEC
62942:2019)
Dateiformat für die professionelle Übertragung und den Austausch digitaler Audiodaten
(IEC 62942:2019)
Format de fichier pour le transfert et l'échange professionnels de données
audionumériques (IEC 62942:2019)
Ta slovenski standard je istoveten z: EN IEC 62942:2020
ICS:
33.160.99 Druga avdio, video in Other audio, video and
avdiovizuelna oprema audiovisual equipment
35.040.40 Kodiranje avdio, video, Coding of audio, video,
multimedijskih in multimedia and hypermedia
hipermedijskih informacij information
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
EUROPEAN STANDARD EN IEC 62942
NORME EUROPÉENNE
EUROPÄISCHE NORM
March 2020
ICS 33.160.30
English Version
File format for professional transfer and exchange of digital
audio data
(IEC 62942:2019)
Format de fichier pour le transfert et l'échange Dateiformat für die professionelle Übertragung und den
professionnels de données audionumériques Austausch digitaler Audiodaten
(IEC 62942:2019) (IEC 62942:2019)
This European Standard was approved by CENELEC on 2020-01-16. CENELEC members are bound to comply with the CEN/CENELEC
Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.
Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC
Management Centre or to any CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation
under the responsibility of a CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the
same status as the official versions.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the
Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2020 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Ref. No. EN IEC 62942:2020 E
European foreword
The text of document 100/3143/CDV, future edition 1 of IEC 62942, prepared by IEC/TC 100 "Audio,
video and multimedia systems and equipment", was submitted to the IEC-CENELEC parallel vote and
approved by CENELEC as EN IEC 62942:2020.
The following dates are fixed:
• latest date by which the document has to be implemented at national (dop) 2020-10-16
level by publication of an identical national standard or by endorsement
• latest date by which the national standards conflicting with the (dow) 2023-01-16
document have to be withdrawn
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CENELEC shall not be held responsible for identifying any or all such patent rights.
Endorsement notice
The text of the International Standard IEC 62942:2019 was approved by CENELEC as a European
Standard without any modification.
In the official version, for Bibliography, the following note has to be added for the standard indicated:
ISO 3166-1 NOTE Harmonized as EN ISO 3166-1
Annex ZA
(normative)
Normative references to international publications
with their corresponding European publications
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.
NOTE 1 Where an International Publication has been modified by common modifications, indicated by (mod), the relevant
EN/HD applies.
NOTE 2 Up-to-date information on the latest versions of the European Standards listed in this annex is available here:
www.cenelec.eu.
Publication Year Title EN/HD Year
ISO 8601 - Data elements and interchange formats - - -
Information interchange - Representation of
dates and times
ISO/IEC 10646 2017 Information technology - Universal Coded - -
Character Set (UCS)
SMPTE ST 330 2011 SMPTE standard for television - Unique - -
Material Identifier (UMID)
RFC 3629 - UTF-8, User Datagram Protocol - -
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
IEC 62942:2019 © IEC 2019 – 3 –
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
IEC 62942:2019 © IEC 2019 – 5 –
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.
IEC 62942:2019 © IEC 2019 – 7 –
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
IEC 62942:2019 © IEC 2019 – 9 –
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 */
IEC 62942:2019 © IEC 2019 – 11 –
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.
IEC 62942:2019 © IEC 2019 – 13 –
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.
IEC 62942:2019 © IEC 2019 – 15 –
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.
------------------
...
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...