Technical OverviewTechnical Overview
The following is an informal technical summary of the proposed Cart Chunk file format.
Note: This is a technical summary of the proposed CartChunk file format only. Neither CartChunk.org nor any of its participants represent this as the official text of the AES X-87 project, nor as the proposed AES-46 standard. For information regarding AES project X-87, AES-46, or any other AES standards information, we recommend you check out the AES Standards website or contact the AES Standards Organization directly.
CART/Audio Delivery Extension
to the
WAVE File Format
('cart' Chunk)
Technical Overview
Dick Pierce
Geoff Steadman
The proposed "cart" format describes a file convention for communicating audio and associated basic radio traffic and continuity data via a dedicated chunk embedded in EBU Broadcast Wave File (BWF, B-Wave or ‘bext’) compliant wave files.
0 INTRODUCTION
The radio broadcast industry utilizes a wide variety of production, on-air and other equipment in daily operation. No single vendor dominates the industry. Users have long complained about the inability to transport audio and traffic/continuity data between systems in a uniform and easy fashion. This is due to the lack of any uniform agreed-upon exchange format for communicating this information between systems. Different on-air delivery systems often use proprietary audio file formats and incompatible access methods to manage audio storage and playback, yet the scheduling, continuity or traffic information they use to label audio files share many common attributes. Further, audio data itself is represented in various, often proprietary formats. To simplify the communication between different systems such as audio production and on-air delivery systems, a common representation for both continuity/traffic information and audio data is desirable.
The RIFF WAVE format has emerged as a dominant audio representation, and supports a wide variety of audio formats (linear PCM, MPEG, different samples rates and sample sizes, multiple tracks, etc.). The RIFF conventions allow the arbitrary addition of other data without impacting the ability of diverse RIFF-compliant applications from reading and interpreting needed data. Thus, adding an extension to a WAVE file allows inclusion of needed continuity/traffic data to a widely accepted representation.
The RIFF specification requires all readers to be able to read all compliant RIFF files. When such an application encounters data that it is not prepared to handle, it can simply ignore the data and move on. There are some RIFF WAVE consumer applications that are intolerant of new and unknown chunks. For this reason alone, these applications are not RIFF-compliant. They may be front-ended by so-called "chunk stripper" utilities, the combination of which are then RIFF-compliant.
The ‘cart’ format described here utilizes a widely used audio file format (WAVE and EBU BWF). It incorporates the common cart ‘labeling’ information into a specialized chunk within the file itself, As a result, the burden of linking multiple systems is reduced to producer applications writing a single file, and the consumer applications reading it. The destination application can extract information and insert it into the native database application as needed.
Communication between a production/delivery system can be reduced to a simple, purely passive link. Production applications can write the properly formatted WAVE file in a "drop box" location. Consumer applications (such as radio delivery systems) periodically poll the drop-box for new additions, opens them, and uses theirit’s own native access methods for adding this information to theirits database. Providing this type of "translation layer" offers vendors a means of integration with other systems, without impacting their own native file formats and access methods.
The result is that both production/editing systems and on-air delivery systems can communicate readily without the need for implementation-specific intelligence or design. However, the use of this new data is not necessarily limited to these applications or the examples illustrated here.
1 SCOPE
This proposed format provides a convention for communicating basic radio traffic and continuity data via a dedicated chunk embedded in EBU BWF-compliant wave files. The new RIFF chunk supports most common data used in radio traffic and continuity systems, while the WAVE format itself supports most sample rates, sample widths, and audio formats.
Note that this format does not purport to suggest representation of this or other data within a specific application’s space, only in the public interchange between disparate systems. Any such private representation may be covered by other conventions irrelevant to this standard, or by a particular vendor’s best judgement.
2 'CART' CHUNK DESCRIPTION
An EBU/BEXT wave format file with an added optional cart chunk will have the following minimal chunks:
<WAVE-form> ->
RIFF(‘WAVE’
<fmt-ck> // mandatory for all WAVE files
[<fact-ck>] // required for MPEG format files
<bext-ck> // EBU Broadcast Extension information
[<mpeg-ck>] // required for EBU MPEG format files
[<cart-ck>] // optional cart information
<data-ck> // audio data, required for all WAVE files
Note: Any additional chunk types that are present in the file are considered private. Applications are not required to interpret or make use of these chunks.
The ‘cart’ chunk is described in the following C-style data definitions:
typedef struct cartchunk_tag
{
DWORD ckID; // FOURCC chunk ID: "cart"
DWORD ckSize; // chunk data length in bytes
BYTE ckData[ckSize]; // data, as CART_EXTENSION type
}
typedef struct cart_extension_tag
{
CHAR Version[4]; // Version of the data structure
CHAR Title[64]; // ASCII title of cart audio sequence
CHAR Artist[64]; // ASCII artist/creator name
CHAR CutID[64]; // ASCII cut number identification
CHAR ClientID[64]; // ASCII client identification
CHAR Category[64]; // ASCII Category ID, PSA, NEWS, etc
CHAR Classification[64]; // ASCII Classification or auxiliary key
CHAR OutCue[64]; // ASCII out cue text
CHAR StartDate[10]; // ASCII yyyy/mm/dd
CHAR StartTime[8]; // ASCII hh:mm:ss
CHAR EndDate[10]; // ASCII yyyy/mm/dd
CHAR EndTime[8]; // ASCII hh:mm:ss
CHAR ProducerAppID[64]; // Name of vendor/application
CHAR ProducerAppVersion[64]; // Version of producer application
CHAR UserDef[64]; // User defined text
DWORD dwLevelReference; // Sample value for 0 dB reference
CART_TIMER PostTimer[8]; // 8 time markers after head
CHAR Reserved[276]; // Reserved for future expansion
CHAR URL[1024]; // Uniform resource locator
CHAR TagText[]; // Free form text for scripts or tags
} CART_EXTENSION;
typedef struct cart_timer_tag
{ // Post timer storage unit
FOURCC dwUsage; // FOURCC timer usage ID
DWORD dwValue; // timer value in samples from head
} CART_TIMER;
4.1.1 Field Descriptions
The date and time representations have been updated to recommend
compliance with date and time representation as described in ISO 8601.
3 APPENDICES
3.1 Recommended Category Names
The following is a list of recommended categories and aliases.
Category |
Aliases |
All |
ALL |
Beds |
BED, BEDS |
Sound bits |
BIT, BITS |
Commercials |
COM, COMM |
Contests |
CON, CONT |
Daily playlists |
DAY |
Emergency broadcast |
EB |
Sound effects |
EFX, SND |
Fillers |
FIL, FILL |
Station ID |
ID |
Intros |
INT, INTR |
Jingles |
JIN, JING |
Liners |
LIN, LINE |
Logos |
LOG, LOGO |
Magic call |
MAG, MAGI |
Music |
MUS, MUSC |
Network delay |
NET, NETW |
News |
NEW, NEWS |
Promos |
PRO, PROM |
Public Service Announcements |
PSA |
Segues |
SEG |
Shows |
SHW, SHOW |
Spots |
SPO, SPOT |
Sports |
SPR, SPRT |
Stagers |
STG, STAG |
Announcer stack |
STK, STAK |
Sweeps |
SWP, SWEP |
Test tones |
TST, TEST |
Temporary |
TMP, TEMP |
3.2 Recommended Mark Timer Identification
Below is a list of basic timer types, and their proposed (FOURCC) names. The basic types may be qualified by appending "s" (lower-case) to signify a start, "e" (lower case) to signify an end, or a digit to signify a sequence.
Timer ID |
Description |
Start/End |
Enumerated |
Multiples |
Unused |
No |
No |
Yes |
|
SEG |
Segue timer |
Yes |
Yes |
Yes |
AUD |
Audio boundary |
Yes |
No |
No |
INT |
Intro |
Yes |
Yes |
Yes |
OUT |
Outtro |
Yes |
Yes |
Yes |
SEC |
Secondary |
Yes |
Yes |
Yes |
TER |
Tertiary |
Yes |
Yes |
Yes |
MRK |
Generic marker |
No |
Yes |
Yes |
EOD |
End-of-data |
No |
No |
Yes |
Timers so designated in the timers can be specified in one of three ways:
Each application should prioritize the order in which the timers are written so that the important timers, like EOD, will always be present and the less important ones, like "MRK", can be dropped if the limit of 8 is reached.
3.3 Legacy Version
The previous 'cart' chunk format prior to Version 0100 did not include provision for the URL/URI field. That version is included here for comparison and completeness
typedef struct cart_extension_tag_V0000
{
CHAR Version[4]; // Version of the data structure
CHAR Title[64]; // ASCII title of cart audio sequence
CHAR Artist[64]; // ASCII artist/creator name
CHAR CutID[64]; // ASCII cut number identification
CHAR ClientID[64]; // ASCII client identification
CHAR Category[64]; // ASCII Category ID, PSA, NEWS, etc
CHAR Classification[64]; // ASCII Classification or auxiliary key
CHAR OutCue[64]; // ASCII out cue text
CHAR StartDate[10]; // ASCII yyyy/mm/dd
CHAR StartTime[8]; // ASCII hh:mm:ss
CHAR EndDate[10]; // ASCII yyyy/mm/dd
CHAR EndTime[8]; // ASCII hh:mm:ss
CHAR ProducerAppID[64]; // Name of vendor/application
CHAR ProducerAppVersion[64]; // Version of producer application
CHAR UserDef[64]; // User defined text
DWORD dwLevelReference // Sample value for 0 dB reference
CART_TIMER PostTimer[8]; // 8 time markers after head
CHAR Reserved[276]; // Reserved for future expansion
CHAR TagText[]; // Free form text for scripts or tags
} CART_EXTENSION_V000;
typedef struct cart_timer_tag
{ // Post timer storage unit
FOURCC dwUsage; // FOURCC timer usage ID
DWORD dwValue; // timer value in samples from head
} CART_TIMER;