SIST EN IEC 62942:2020

SLOVENSKI STANDARD
oSIST prEN IEC 62942:2018
01-december-2018
Format datoteke za profesionalni prenos in izmenjavo digitalnih avdio podatkov
(TA6)
File format for professional transfer and exchange of digital audio data (TA6)
Ta slovenski standard je istoveten z: prEN IEC 62942:2018
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
oSIST prEN IEC 62942:2018 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------
oSIST prEN IEC 62942:2018

---------------------- Page: 2 ----------------------
oSIST prEN IEC 62942:2018
100/3143/CDV

COMMITTEE DRAFT FOR VOTE (CDV)
PROJECT NUMBER:
IEC 62942 ED1
DATE OF CIRCULATION: CLOSING DATE FOR VOTING:
2018-10-12 2019-01-04
SUPERSEDES DOCUMENTS:
100/2969/CD,100/3136/CC

IEC TA 6 : STORAGE MEDIA, STORAGE DATA STRUCTURES, STORAGE SYSTEMS AND EQUIPMENT
SECRETARIAT: SECRETARY:
Japan Mr Koji Tsukada
OF INTEREST TO THE FOLLOWING COMMITTEES: PROPOSED HORIZONTAL STANDARD:


Other TC/SCs are requested to indicate their interest, if
any, in this CDV to the secretary.
FUNCTIONS CONCERNED:
EMC ENVIRONMENT QUALITY ASSURANCE SAFETY

SUBMITTED FOR CENELEC PARALLEL VOTING NOT SUBMITTED FOR CENELEC PARALLEL VOTING
Attention IEC-CENELEC parallel voting
The attention of IEC National Committees, members of
CENELEC, is drawn to the fact that this Committee Draft
for Vote (CDV) is submitted for parallel voting.
The CENELEC members are invited to vote through the
CENELEC online voting system.

This document is still under study and subject to change. It should not be used for reference purposes.
Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of
which they are aware and to provide supporting documentation.

TITLE:
File format for professional transfer and exchange of digital audio data (TA 6)

PROPOSED STABILITY DATE: 2023

NOTE FROM TC/SC OFFICERS:


Copyright © 2018 International Electrotechnical Commission, IEC. All rights reserved. It is permitted to download this
electronic file, to make a copy and to print out the content for the sole purpose of preparing National Committee positions.
You may not copy or "mirror" the file or printed version of the document, or any part of it, for any other purpose without
permission in writing from IEC.

---------------------- Page: 3 ----------------------
oSIST prEN IEC 62942:2018
100/3143/CDV – 2 – IEC CD 62942  IEC:2016


CONTENTS

FOREWORD . 3
INTRODUCTION . 5
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 BWF file . 8
4.1 Existing Chunks defined as part of the RIFF Format . 8
4.2 Additional chunks . 8
4.3 Contents of a BWFF . 8
4.4 Broadcast audio extension chunk . 8
Annex A (normative) RIFF WAVE file format . 12
A.1 General . 12
A.2 Resource Interchange File Format (RIFF) . 12
A.2.1 Chunks . 12
A.2.2 RIFF Forms . 13
A.3 Waveform Audio File Format (WAVE) . 13
A.3.1 WAVE format chunk . 13
A.3.2 WAVE format categories . 14
A.4 Storage of WAVE data . 16
Annex B (normative) Chunk order . 17
Annex C (normative) Filename conventions . 18
C.1 General . 18
C.2 File-name length . 18
C.3 File-name extension . 18
C.4 File-name character set . 18
Annex D (informative) Multi-channel usage . 20
D.1 General . 20
D.2 Multi-channel audio data packing . 20
D.3 Channel assignments in multi-channel files . 21
D.3.1 Distribution and archive . 21
D.3.2 Production recordings . 21
Annex E (informative) Other audio codings . 22
E.1 General . 22
E.2 MPEG files . 22
Annex F (normative) Extended file format (BWF-E) . 23
F.1 Introduction . 23
F.2 Exceeding the 4-gigabyte limit . 23
F.2.1 General . 23
F.2.2 64-bit resource interchange file format (RF64) . 24
F.3 Compatibility between BWF and BWF-E . 25
F.3.1 General . 25
F.3.2 Initialisation as BWF . 25

---------------------- Page: 4 ----------------------
oSIST prEN IEC 62942:2018
IEC 62942/CDV  IEC:2016 – 3 – 100/3143/CDV
F.3.3 Transition to BWF-E . 25
F.4 RIFF/WAVE and RF64/WAVE structures . 26
F.4.1 Chunks and structs specific to the RIFF/WAVE format . 26
F.4.2 Chunks and Structs specific to the RF64/WAVE (BWF-E)
format . 26
Annex G (normative) bext chunk versions . 28
G.1 Version 0 . 28
G.2 Version 1 . 28
G.3 Version 2 . 28
Annex H (normative) Loudness parameters . 29
H.1 Treatment of Loudness Parameters . 29
H.2 Loudness parameter references . 30
H.3 Loudness informative references . 30
Annex I (informative) Definition of the format for “Unique” Source Identifier (USID) for
use in the field . 31
I.1 USID . 31
I.2 Examples of USIDs . 31
Annex J (informative) Specification of the format for field . 32
J.1 Introduction . 32
J.2 Syntax . 32
J.3 Examples of coding history fields . 32
Annex K (normative) Universal broadcast audio extension chunk . 34
K.1 General . 34
K.2 Contents of a BWFF with ‘ubxt’ chunk . 34
K.3 Universal broadcast audio extension chunk . 34
Bibliography . 37

Figure D.1 – Data packing for 24-bit mono PCM audio data . 21
Figure D.2 – Data packing for 16-bit stereo (2-channel) PCM audio data . 21
Figure D.3 – Data packing for 24-bit, 4-channel PCM audio data . 21
Figure D.4 – 4-bit sample packing . 21
Figure F.1 – Conventional RIFF/WAVE format . 24
Figure F.2 – Extended RF64/WAVE format . 25
Figure F.3 – Compatible RIFF/WAVE structure . 26

Table 1 – bext field content definitions . 10
Table A.1 – Chunk Description . 13
Table A.2 – Format chunk - common fields . 15
Table A.3 – WAVE format categories . 15
Table A.3a – Data packing for 16-bit mono PCM . 16
Table A.3b – Data packing for 16-bit stereo PCM . 16
Table A.4 – PCM data format . 17
Table A.5 – PCM data format - 16-bit . 17
Table A.6 – PCM WAVE format chunk examples . 17
Table K.1 – ubxt field content definitions . 36

---------------------- Page: 5 ----------------------
oSIST prEN IEC 62942:2018
100/3143/CDV – 4 – IEC CD 62942  IEC:2016
1 INTERNATIONAL ELECTROTECHNICAL COMMISSION
2 ____________
3
4 FILE FORMAT FOR PROFESSIONAL TRANSFER AND EXCHANGE OF
5 DIGITAL AUDIO DATA
6
7
8
9
10 FOREWORD
11 1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
12 all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
13 international co-operation on all questions concerning standardization in the electrical and electronic fields. To
14 this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
15 Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
16 Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
17 in the subject dealt with may participate in this preparatory work. International, governmental and non-
18 governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
19 with the International Organization for Standardization (ISO) in accordance with conditions determined by
20 agreement between the two organizations.
21 2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
22 consensus of opinion on the relevant subjects since each technical committee has representation from all
23 interested IEC National Committees.
24 3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
25 Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
26 Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
27 misinterpretation by any end user.
28 4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
29 transparently to the maximum extent possible in their national and regional publications. Any divergence
30 between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
31 the latter.
32 5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
33 assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
34 services carried out by independent certification bodies.
35 6) All users should ensure that they have the latest edition of this publication.
36 7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
37 members of its technical committees and IEC National Committees for any personal injury, property damage or
38 other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
39 expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
40 Publications.
41 8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
42 indispensable for the correct application of this publication.
43 9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
44 patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
45 International Standard IEC 62942 has been prepared by subcommittee TA6: Storage media,
46 storage data structures, storage systems and equipment, of IEC technical committee TC100:
47 Audio, video and multimedia systems and equipment.
48 The text of this standard is based on the following documents:
FDIS Report on voting
XX/XX/FDIS XX/XX/RVD
49
50 Full information on the voting for the approval of this standard can be found in the report on
51 voting indicated in the above table.
52 This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.

---------------------- Page: 6 ----------------------
oSIST prEN IEC 62942:2018
IEC 62942/CDV  IEC:2016 – 5 – 100/3143/CDV
53 The committee has decided that the contents of this publication will remain unchanged until
54 the stability date indicated on the IEC web site under "http://webstore.iec.ch" in the data
55 related to the specific publication. At this date, the publication will be
56 • reconfirmed,
57 • withdrawn,
58 • replaced by a revised edition, or
59 • amended.
60
61 The National Committees are requested to note that for this publication the stability date
62 is 2018.
63 THIS TEXT IS INCLUDED FOR THE INFORMATION OF THE NATIONAL COMMITTEES AND WILL BE DELETED
64 AT THE PUBLICATION STAGE.
65

---------------------- Page: 7 ----------------------
oSIST prEN IEC 62942:2018
100/3143/CDV – 6 – IEC CD 62942  IEC:2016
66 INTRODUCTION
67
68 The broadcast-wave-format file (BWFF) is based on the Microsoft WAVE audio file format,
69 which is a type of file specified in the Microsoft resource interchange file format (RIFF).
70 WAVE files specifically contain audio data. The basic building block of a RIFF file is a chunk
71 which contains specific information, an identification field, and a size field. A RIFF file
72 contains a number of chunks.
73 The BWFF specifically includes a chunk to carry certain
74 metadata important for broadcast and professional use. For reliable interchange, some
75 restrictions apply to the format of the audio data.
76 The Broadcast Wave Format was first developed using ASCII text for all fields. Later, as the
77 format was further developed, it was proposed to use multi-byte characters to internationalize
78 the format. It was understood that to use multi-byte character sets within the existing format
79 would cause compatibility issues when multi-byte metadata was parsed by applications
80 expecting ASCII text. The separate nature of human-readable and machine-readable
81 metadata was established, and a new "universal" chunk was established to carry
82 internationalized human-readable metadata using multi-byte character sets without
83 interoperability issues. This is described in annex K.
84 This document contains the specification of the broadcast audio extension chunk and its use
85 with PCM-coded audio data. Basic information on the RIFF format and how it can be
86 extended to other types of audio data is given in annex E. Details of the PCM WAVE format
87 are also given in annex A.
88

---------------------- Page: 8 ----------------------
oSIST prEN IEC 62942:2018
IEC 62942/CDV  IEC:2016 – 7 – 100/3143/CDV
89 FILE FORMAT FOR PROFESSIONAL TRANSFER AND EXCHANGE OF
90 DIGITAL AUDIO DATA
91
92
93
94 1 Scope
95 This International Standard specifies a file format for interchanging audio data between
96 compliant equipment. It is primarily intended for audio applications in professional recording,
97 production, post production, and archiving.
98 It is derived from the EBU Broadcast Wave Format but is also compatible with variant
99 specifications including ITU-R BR.1352-3-2007 and the Japan Post Production Association’s
100 BWF-J.
101 An optional extended format, BWF-E, supports 64-bit addressing to permit file sizes greater
102 than 4 GBytes.
103 2 Normative references
104 The following documents are referred to in the text in such a way that some or all of their
105 content constitutes requirements of this document. For dated references, only the edition
106 cited applies. For undated references, the latest edition of the referenced document (including
107 any amendments) applies.
108 SMPTE ST 330-2011; SMPTE standard for television - Unique Material Identifier (UMID)
109 ISO/IEC 646:1991; Information technology - ISO-7-bit coded character set for information
110 exchange
111 ISO 8601; Data elements and interchange formats - Information interchange - Representation
112 of dates and times
113 ISO/IEC 10646:2012; Information technology - Universal Multiple-Octet Coded Character Set
114 (UCS)
115 IETF RFC 3629; UTF-8, a transformation format of ISO 10646
116 3 Terms and definitions
117 For the purposes of this document, the following terms and definitions apply.
118 ISO and IEC maintain terminological databases for use in standardization at the following
119 addresses:
120 • IEC Electropedia: available at http://www.electropedia.org/
121 ISO Online browsing platform: available at http://www.iso.org/obp
122 3.1
123 resource interchange file format
124 RIFF
125 a file representation upon which the WAVE file format is based

---------------------- Page: 9 ----------------------
oSIST prEN IEC 62942:2018
100/3143/CDV – 8 – IEC CD 62942  IEC:2016
126 3.2
127 chunk
128 data package within RIFF files containing related data
129 3.3
130 ASCII
131 7-bit character code compliant with ISO/IEC 646
132 3.4
133 waveform audio file format
134 WAVE
135 audio file format based on the RIFF file structure
136 3.5
137 broadcast wave format file
138 BWFF
139 WAVE file containing the bext chunk as described in this standard
140 3.6
141 broadcast extension chunk
142 bext
143 an extension chunk to WAVE
144 3.7
145 universal broadcast audio extension chunk
146 ubxt
147 the human-readable information of the bext chunk in multi-byte languages
148 3.8
149 UMID
150 unique material identifier as defined in SMPTE ST 330
151 3.9
152 broadcast wave format, extended
153 BWF-E
154 an optional extended format that replaces a RIFF header with an RF64 header to support 64-
155 bit addressing to permit file sizes greater than 4 GBytes
156 3.10
157 RF64
158 a structure equivalent to the RIFF file type supporting 64-bit addressing
159 3.11
160 CHAR
161 8-bit signed integer, representing integer values from –128 to +127. Equivalent C type:
162 “signed char”
163 3.12
164 BYTE
165 8 bit unsigned integer, representing integer values from 0 to 255. Equivalent C type:
166 “unsigned char”
167 3.13
168 INT
169 16-bit signed integer, representing integer values from –32768 to +32767. Equivalent C type:
170 “signed short int”. Multi-byte data types are little-endian

---------------------- Page: 10 ----------------------
oSIST prEN IEC 62942:2018
IEC 62942/CDV  IEC:2016 – 9 – 100/3143/CDV
171 3.14
172 WORD
173 16-bit unsigned integer, representing integer values from 0 to +65535. Equivalent C type:
174 “unsigned short int”. Multi-byte data types are little-endian
175 3.15
176 LONG
177 32-bit signed integer, representing integer values from –2,147,483,648 to +2,147,483,647.

178 Equivalent C type: “signed long int”. Multi-byte data types are little-endian
179 3.16
180 DWORD
181 32-bit unsigned integer, representing integer values from 0 to +4,294,967,295. Equivalent C
182 type: “unsigned long int”. Multi-byte data types are little-endian
183 4 BWF file
184 4.1 Existing Chunks defined as part of the RIFF Format
185 This specification uses a number of RIFF chunks which are already defined (See annex A).
186 These are:
Format Chunk
Audio data chunk
187 4.2 Additional chunks
188 Additional chunks may be present in the file. Some of these may be outside the scope of this
189 standard. Applications may or may not interpret or make use of these chunks, so the integrity
190 of the data contained in such unknown chunks cannot be guaranteed. However, compliant
191 applications should pass on unknown chunks with their contents unchanged.
192 4.3 Contents of a BWFF
193 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 */
194 4.4 Broadcast audio extension chunk
195 Extra parameters needed for exchange of material between broadcasters are added in a
196 specific Broadcast Audio Extension, or bext chunk. The structure of the bext chunk shall be
197 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” */

---------------------- Page: 11 ----------------------
oSIST prEN IEC 62942:2018
100/3143/CDV – 10 – IEC CD 62942  IEC:2016
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
198
199 The content of the fields in the bext chunk shall be defined as shown in table 1. Note that in
200 applications where ASCII text is inappropriate for human-readable information - for example
201 when a character set other than ISO 646 is required - it is necessary to carry it by another
202 means, for example, in a dedicated metadata chunk added to the BWFF. See also Annex K,
203 Universal broadcast audio extension chunk (ubxt).
204 All the items except Description, Originator, OriginatorReference and CodingHistory should
205 have the same content as that of each corresponding item of the ubxt chunk (see annex K), if
206 present. If machine-readable data in the 'bext' chunk is updated, the corresponding machine-
207 readable data in the 'ubxt' chunk should also be updated identically.
208 Table 1 – bext field content definitions
Description
Human ASCII string, 256 characters or less, 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 ).
16
  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 less, 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 ).
16
OriginatorReference
Human ASCII string, 32 characters or less, 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 ).
16

---------------------- Page: 12 ----------------------
oSIST prEN IEC 62942:2018
IEC 62942/CDV  IEC:2016 – 11 – 100/3143/CDV
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 9999
- = 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 00 - 59 if
time given
...