Recommendation itu-r br. 1352 file format for the exchange of audio programme materials on information technology media

Yüklə 165.1 Kb.
ölçüsü165.1 Kb.
  1   2   3   4   5   6

Rec. ITU-R BR.1352



(Question ITU-R 215/10)


Rec. ITU-R BR.1352

The ITU Radiocommunication Assembly,


a) that storage media based on Information Technology, including data disks and tapes, are expected to penetrate all areas of audio production for radio broadcasting, namely non-linear editing, on-air play-out and archives;

b) that this technology offers significant advantages in terms of operating flexibility, production flow and station automation and it is therefore attractive for the up-grading of existing studios and the design of new studio installations;

c) that the adoption of a single file format for signal interchange would greatly simplify the interoperability of individual equipments and remote studios, it would facilitate the desirable integration of editing, on-air play-out and archiving;

d) that a minimum set of broadcast related information must be included in the file to document the audio signal;

e) that, to ensure the compatibility between applications with different complexity, a minimum set of functions, common to all the applications able to handle the recommended file format must be agreed;

f) that Recommendation ITU-R BS.646 defines the digital audio format used in audio production for radio and television broadcasting;

g) that various multichannel formats are the subject of Recommendation ITU-R BS.775 and that they are expected to be widely used in the near future;

h) that the need for exchanging audio materials also arises when ISO/IEC 11172-3 and ISO/IEC 13818-3 coding systems are used to compress the signal;

j) that several world broadcasters have already agreed on the adoption of a common file format for programme exchange;

k) that the compatibility with currently available commercial file formats could minimize the industry efforts required to implement this format in the equipment,


1 that, for the exchange of audio programmes on Information Technology media, the audio signal parameters sampling frequency, coding resolution and pre-emphasis should be set in agreement with the relevant parts of Recommendation ITU-R BS.646;

2 that the file format specified in Annex 1 should be used for the interchange1 of audio programmes in linear PCM format on Information Technology media;

3 that, when the audio signals are coded using ISO/IEC 11172-3 or ISO/IEC 13818-3 coding systems, the file format specified in Annex 1 and complemented with Annex 2 should be used for the interchange of audio programmes on Information Technology media2.


Specification of the broadcast wave format
A format for audio data files in broadcasting

1 Introduction

The broadcast wave format (BWF) is based on the Microsoft WAVE audio file format which is a type of file specified in the Microsoft “Resource Interchange File Format”, RIFF. WAVE files specifically contain audio data. The basic building block of the RIFF file format, called a chunk, contains a group of tightly related pieces of information. It consists of a chunk identifier, an integer value representing the length in bytes and the information carried. A RIFF file is made up of a collection of chunks.

For the BWF, some restrictions are applied to the original WAVE format. In addition the BWF file includes a chunk. This is illustrated in Figure 1 below.

This document contains the specification of the broadcast audio extension chunk which is used in all BWF files. In addition, information on the basic RIFF format and how it can be extended to other types of audio data is given in the appendix. Details of the PCM wave format are also given in the appendix. Detailed specifications of the extension to other types of audio data will be published in other annexes to this Recommendation.

2 Broadcast wave format file

2.1 Contents of a broadcast wave format file

A broadcast wave format file shall start with the mandatory Microsoft RIFF “WAVE” header and at least the following chunks:



//information on the audio sequence

//Format of the audio signal: PCM/MPEG

[] //Fact chunk is required for MPEG formats only

[] //MPEG Audio Extension chunk is required for MPEG formats only

) //sound data

NOTE – Any additional types of chunks that are present in the file have to be considered as private. Applications are not required to interpret or make use of these chunks. Thus the integrity of the data contained in any chunks not listed above is not guaranteed. However BWF applications should pass on these chunks whenever possible.

2.2 Existing chunks defined as part of the RIFF standard

The RIFF standard is defined in documents issued by the Microsoft Corporation. This application uses a number of chunks which are already defined. These are:



The current descriptions of these chunks are given for information in Appendix 1 to Annex 1.

2.3 Broadcast audio extension chunk

Extra parameters needed for exchange of material between broadcasters are added in a specific “Broadcast Audio Extension” chunk defined as follows:

broadcast_audio_extension typedef struct {

DWORD ckID; /* (broadcastextension)ckID=bext. */

DWORD ckSize; /* size of extension chunk */

BYTE ckData[ckSize]; /* data of the chunk */


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 */

CHAR Reserved[254] ; /* Reserved for future use, set to "NULL" */

CHAR CodingHistory[]; /* ASCII : « History coding » */





ASCII string (maximum 256 characters) containing a free description of the sequence. To help applications which only display a short description it is recommended that a resume of the description is contained in the first 64 characters and the last 192 characters are used for details.


If the length of the string is less than 256 characters the last one is followed by a null character. (00)


ASCII string (maximum 32 characters) containing the name of the originator/producer of the audio file. If the length of the string is less than 32 characters the field is ended by a null character.

OriginationDate 10

ASCII characters containing the date of creation of the audio sequence. The format is « ‘,year’,-,’month,’-‘,day,’» with 4 characters for the year and 2 characters per other item.

Year is defined from 0000 to 9999

Month is define from 1 to 12

Day is defined from 1 to 31

The separator between the items can be anything but it is recommended that one of the following characters be used:

‘-‘ hyphen

‘_’ underscore

‘:’ colon

‘ ’ space

‘.’ stop


8 ASCII characters containing the time of creation of the audio sequence. The format is « ’hour,’-‘,minute,’-‘,second’» with 2 characters per item.

Hour is defined from 0 to 23.

Minute and second are defined from 0 to 59.

The separator between the items can be anything but it is recommended that one of the following characters be used:

‘-‘ hyphen

‘_’ underscore

‘:’ colon

‘ ’ space

‘.’ stop


This field contains the time-code of the sequence. It is a 64 bit value which contains the first sample count since midnight. The number of samples per second depends on the sample frequency which is defined in the field from the <format chunk>.


An unsigned binary number giving the version of the BWF. Initially this is set to zero.


254 bytes reserved for extension. These 254 bytes must be set to a NULL value. In the future the null value will be used as a default to maintain compatibility.


Non-restricted ASCII characters containing a collection of strings terminated by CR/LF. Each string contains a description of the coding process applied. Each new coding application is required to add a new string with the appropriate information.

This information must contain the type of sound (PCM or MPEG) with its specific parameters:

PCM: mode (mono, stereo), size of the sample (8, 16 bits) and sample frequency,

MPEG: sampling frequency, bit rate, layer (I or II) and the mode (mono, stereo, joint stereo or dual channel),

It is recommended that the manufacturers of the coders provide an ASCII string for use in the coding history.

NOTE – Studies are under way to propose a format for coding history which will simplify the interpretation of the information provided in this field.
  1   2   3   4   5   6

Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur © 2016
rəhbərliyinə müraciət

    Ana səhifə