The FAQ Page
(Frequently Asked Questions)

Q: Why a "Cart Chunk"?
A: The Cart Chunk was developed in response to a need that it's authors, Dick Pierce and Geoff Steadman, saw when they were working on trying to integrate radio production systems with on-air systems. The need is obvious to anyone who ever tried to make two digital products interface with each other: our industry needed a way for a piece of audio to go from one platform to another, accompanied by what amounts to a "digital cart label". Custom, proprietary connections are very expensive to develop and prone to breakage as one system upgrades and changes the assumptions other systems depend on. Since most broadcast computer systems share common attributes in terms of how they describe audio files (e.g. title, length, outcue, etc), those common attributes were collected and became the basis for the Cart Chunk standard proposal.

Q: Our organization distributes audio as MPEG files, not WAVE files, so I can't use WAVE files and Cart chunks, right?
A: Yes, you can. One common misconception is that WAVE files can only hold linear PCM audio. This is simply not true! WAVE files support nearly every imaginable audio data format. The WAVE file standard can support not only linear PCM, but MPEG layer I and II, MPEG-3, Dolby AC-3 and more. In fact, the MPEG data in a MPEG-3 WAVE file is bit-for-bit identical to MP3 files.

One of the several supplements to the EBU Broadcast Wave Format specification describes the use of MPEG Audio in standard WAVE files for broadcast use.

WAVE files are simply convenient containers or wrappers for audio data. The .WAV extension does not determine what kind of audio data is in the file. The WAVE wrapper lets you also add labeling and meta-data, such as the EBU Broadcast Extension Chunk (a.k.a.: BWF) or the Cart Chunk.

Q: My application already has a format for holding traffic information. Does all our code have to be redesigned to handle the Cart Chunk format internally?
A: No. The Cart Chunk standard is not a mandate for storing traffic and other data within applications, and was never intended to be. It is only intended to mandate how different applications communicate with each other. Your own internal representation of data within your closed system is your business. The Cart Chunk simply provides a way of translating data to get it in and out of various proprietary systems in a standard, agreed upon manner.

Q: Why not use XML to describe traffic information?
A: There's no reason why you couldn't use XML as an external representation of traffic data. In fact, we propose an XML layout of this data and have sample applications that can insert and extract XML-style traffic data as Cart Chunks in WAVE files. However, the advantage of using the Cart Chunk is that it's a representation integral to the audio file itself. There's only one file, one package, to worry about. The audio data and traffic meta-data can be transported, stored, archived, indexed and retrieved as a single unit. This is a distinct advantage when transporting or e-mailing audio files. Moreover, many participants in the standardization process were adamant that a single file solution was preferable, given the risks of having information in two separable files, where one gets lost or corrupt.

As mentioned above, the WAVE file format itself is a container that can hold both audio data and meta-data together in a single package. This means simplified storage, retrieval, export and import, because you are concerned only with a single entity, rather than two.

Q: The Cart Chunk doesn't list every field I use in my on-air system. How come?
A: In creating the specification for the Cart Chunk, we polled the leading makers of broadcast play-out and other systems, and created fields using what was common among these systems. Not every field got included. For example, we did not include fields which mark a song or promo as "seasonal". We make no representation that the set of fields in the Cart Chunk represents every field under the sun, but we do suggest that the fields it contains correspond to the primary label components of most broadcast systems.

Q: Doesn't adding a Cart Chunk mean rewriting huge amounts of audio data?
A: No, the Cart Chunk can simply be appended onto the end of a WAVE file after all the audio data, something often done with INFO chunks. This is a very quick operation even on very large files. There is a downside: some older applications that can not handle WAVE files with so-called "end chunks", chunks that follow the audio "data" chunk.

Q: Speaking of INFO chunks, why not use them for storing traffic information?
A: The INFO chunk is a general purpose chunk that can hold a lot of diverse information. While some standard fields could hold some of the traffic information, The radio-specific data would have to be held in non-standard, private chunks anyway. Further, there could be conflicts in the use of some of the standard public chunks. By defining and standardizing a common, agreed-upon chunk specific to radio data, these problems are avoided.

Q: Why didn't you just use the Microsoft "LIST" Chunk as the standard?
A: We needed consensus from key players in our industry. We sought a specification which addressed the needs of broadcasters first, and we sought to run the standardization process through a real standards organization. Microsoft is a software vendor, not a standards body. As such, it reserves the right to change its mind at any time, and often it does. In putting our proposal through highly respected organizations like the AES and EBU, we all participate in an open process where no single company's competitive interests are allowed to dominate the specification's creation. The Cart Chunk standard reflects a consensus view of several segments of the radio and broadcast industry, and not the opinion of a single entity.

Q: Are Cart Chunks a public standard? I thought it was a proprietary format of Orban?
A: No. Geoff Steadman and Dick Pierce were associated with Orban when the standard was first launched, but they always intended the Cart Chunk to be a public-domain standard. The problem they were trying to solve was the ability to integrate editing systems and on-air systems from many different manufacturers, and not force other manufacturers to conform to several incompatible, proprietary interfaces. From the beginning of the process, they sought the advice, comments and active participation of many manufacturers, including competitors. Once a reasonable working consensus was formed, they then sought to have the format sanctioned by an independent standards organization, the Audio Engineering Society, where it has now been formally ratified as AES Standard AES46-2002.

Q: What is the current status of the standards process for the Cart chunk?
A: As of June 10, 2002, the cart chunk has been formally ratified by the AES Standards Committee as AES46-2002.

Q: I see references to RIFF WAVE files: How are they different than ordinary WAVE files?
A: They aren't. All WAVE files are RIFF WAVE files. RIFF is the formal name of the format upon which WAVE files are based. RIFF stands for Resource Interchange File Format, a definition for storing multi-media data originally formulated by Microsoft and IBM (Multimedia Programming Interface and Data Specification 1.0, issued as a joint design by IBM Corporation and Microsoft Corporation, August 1991). The format allows storage and transmission of a variety of media data such as audio. The original specification sites, as one of its prime purposes, "exchanging multimedia data between applications and across platforms."

RIFF files are based on a collection of one or more chunks, each chunk being a self-contained, self-identified package of data. Each chunk has a 4-character identifier and a 32-bit chunk data size. This is enough to allow any well-behaved RIFF/WAVE application to handle any chunk, even if does not recognize it: if such an application encounters a chunk it doesn't understand, it has enough information to skip over it and continue processing. This is key to the format's flexibility and universal compatibility, and has resulted in its adoption as a de-facto audio exchange medium.

So, don't worry: if it's a WAVE file, it is a RIFF WAVE file. They're one and the same.

Q: Who supports the Cart Chunk?
A: A number of leading industry manufacturers have or are in the process of implementing Cart Chunk compatibility. Check out the list of Participating Vendors

Q: So, I see this list of "participating vendors" on your web site. Does that mean that all of these systems are guaranteed to talk to one another. If a manufacturer states that a product is "cart-chunk compliant," or meets some AES or EBU standard, is everything going to talk to each other?
A: The list of compliant systems on this web site is based solely on manufacturers claims. is not a certification organization, and the contributors to have not verified this information as being accurate or complete. The presence of a manufacturer or a product name or version on the "Participating Vendors" list on this web page is no guarantee that the product is compliant, nor, for that matter, is the absence of a product a statement that it is not.

It is prudent that anyone contemplating the purchase of a system or systems where compliance with this or any other proposed or existing standard is important independently verify the degree of compliance and not depend solely on manufacturer's claims, no matter where they may appear.

Q: Why is your web site so boring and basic?
A: Because the authors of the Cart Chunk created this site as a public service to the radio industry, not as a showplace for our HTML design chops or to try to sell you stuff. We donate our time, pay hosting fees from our own pockets, answer questions, and keep the momentum moving because we believe this standard is for the good of our industry. If you'd like to volunteer to help improve this site, or want to send us money so we can pay someone to create some "cool" animation, be our guest! If you need serious technical help in development, we'll ask for consulting fees to cover our time. But we've tried to include enough information on this site so you can do it yourself. We invite your feedback and your participation.