File-Exchange Specification Will Soon Become International Standard
(click thumbnail)
The lack of a file-exchange standard for digital audio + metadata in the radio broadcast environment may soon be a thing of the past.
The so-called Cart Chunk data format has been submitted to the Audio Engineering Society’s Standards Committee (AESSC) and the International Electrotechnical Committee’s Technical Committee 100 (IEC TC-100). Barring any unforeseen difficulty, the specification should become an official standard under the auspices of AES by mid-2002. IEC standardization may follow thereafter.
The Cart Chunk specification was developed within the SC-06-01 Working Group on Audio-File Transfer and Exchange of the AES’s SC-06 Subcommittee on Network and File Transfer of Audio.
The work was performed under the AES X-87 project, entitled “Radio Traffic Data Extension to Broadcast Wave Files.” The output of this effort is a draft standard now being vetted for comment by the Society, under the proposed title of AES46-xxxx (where xxxx is the year of final approval).
Comments will be accepted until June 7, after which any negative comments must be addressed and resolved. Following resolution of those comments, the AES will bless the AES46 draft as an official standard.
Some history
The authors of the original Cart Chunk specification and the AES46-xxxx draft are Dick Pierce and Geoff Steadman, two former Orban staffers who determined that such a file-exchange format was necessary when trying to integrate PC-based digital audio workstations and radio automation systems.
Although audio files of known coding type have been possible to exchange with relative ease for some time, the labeling data associated with the files never survived any transfer between systems, and typically had to be transmitted separately and/or manually re-entered following the audio transfer. The ideal solution called for a file-interchange format that could be broadly implemented across the industry, which would include both essence (audio) and metadata (description) components in a manner that could be automatically interpreted by any manufacturer’s system.
Such a solution was not intended to force all manufacturers to adopt a common method of representation for audio and descriptive data within their systems, but simply to support a standard file-exchange protocol for data I/O that could be converted to/from their respective native formats.
The final result was the AES46 draft, which specifies a manner of identifying audio coding type (from a limited list of possibilities), along with semantics and syntax for expressing most common metadata (“cart labeling”) fields used by broadcasters. This will allow a spot producer to write a variety of identification and descriptive metadata (e.g., title, running time, outcue, pull date, etc.) into an audio file when production is complete, then transfer that file from the original production workstation to one or more automated playout systems, in compressed or uncompressed form.
As long as all involved systems support AES46, the audio data will transfer compatibly, and the label data entered in the original production phase will appear in the appropriate places on the automation systems’ databases and displays.
A layered approach
Like many other successful standards, AES46 is built upon other broadly accepted standards. The first is the Resource Interchange File Format (RIFF) for audio, better known as the WAVE or WAV file (designated by the file extension .wav), which was specified in 1991 by IBM and Microsoft. Although WAVE files are often thought to inherently and exclusively use linear PCM audio representation, WAVE files can actually include many other audio representation schemes, including compressed formats such as the MPEG-1 Audio Layer II or III commonly used by radio broadcasters (.mp2 or .mp3 files).
The WAVE format is simply a standardized wrapper that packages the audio data with a series of mandatory and optional headers or “data chunks.” The structure of these chunks is established in the original RIFF specification, such that the first four characters of each chunk identify it, followed by 32-bits of data of that type. If a device does not recognize the chunk type, it simply ignores the data in the chunk. This allows extensibility of the format without causing problems in legacy devices.
One such chunk developed by the EBU in 1996-7 is the Broadcast Audio Extension chunk (bext-ck), which when added to the RIFF WAVE format defines the Broadcast Wave Format (BWF). This creates a specified subset of the WAVE format, designed specifically for broadcast audio file interchange.
(BWF is specified in EBU Tech 3285 and subsequent Supplements 1-3, and in EBU Standard N22-1997; recommended practice for the format’s application is explained in EBU Recommendation R85. See www.ebu.ch.)
The Cart Chunk (cart-ck) in turn adds a specified metadata set to the BWF format, as yet another optional RIFF WAVE data chunk. Therefore an AES46-compliant device would read and write RIFF WAVE files of the types specified by the BWF format, including the labeling data defined in the Cart Chunk specification.
The data types included in the current AES draft are listed in the following table.
What it all means
The practical result of all this is far greater compatibility, particularly for metadata, when transferring audio files among production and playout systems. A number of leading workstation, automation system and audio card manufacturers already support the draft specification in their current equipment, with others pledging their compliance in upcoming offerings. Following the approval of AES46, it is likely that even more widespread support will emerge.
In the meantime, to learn more about the Cart Chunk specification, its authors have established a resource-rich website at www.cartchunk.org.
