IEC 62942:2019 pdf download

IEC 62942:2019 pdf download.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 [1 0], ITU-R BR.1 352-3-2007 [1 1 ] to [1 4], and the Japan Post Production Association’s BWF-J [1 5]. 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 1 0646:201 7, Information technology – Universal Coded Character Set (UCS) ISO 8601 , Data elements and interchange formats – Information interchange – Representation of dates and times SMPTE ST 330-201 1 ; 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 201 9-1 1 -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/obp3.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.1 0 RF64 structure equivalent to the RIFF file type supporting 64-bit addressing 3.1 1 CHAR 8-bit signed integer, representing integer values from −1 28 to +1 27 Note 1 to entry: Equivalent C type: “signed char”. 3.1 2 BYTE 8-bit unsigned integer, representing integer values from 0 to 255
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).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.