Updates

• June 10, 2002: The cart chunk format has now been formally ratified by the AES Standards Committee and is now designated as AES46-2002. The final standard icludes some minor editorial revisions (refer to AES46-2002 for more details

• March 10, 2002: The AES Standards Committee has started the formal public call-for-comment period, lasting 90 days. During this time any commenbts regarding changes to the standard must be submitted through the formal comment review process as described in the AES standards procedures. If no adverse comments are received during this period, the next step will be formal adoption

• December 6, 2001: Several changes and additions were made to ensure the information presented on this website regarding AES standards status and business were in compliance with the standards process.

• December 4, 2001: The WaveView utility has been upgraded to properly handle odd chunk sizes.

• December 2, 2001: The AES SC06-01 standards committee met at the AES convention in New York. where final updates were discussed. As soon as more information is available from the AES, we'll update this site.
  
  A further important update: Ed MacKenty has stepped in to provide web support services for the cart chunk web site, including hosting the site. "Mack" is someone who we have worked closely with over the last several years, and we are excited that Mack has volunteered his services and facilities for this purpose. Thanks, Mack!

• September 19, 2001: We have uploaded a trial version of the WaveView utility for viewing and analyzing common chunks within Wave files, including cart and EBU broadcast wave information. We have also uploaded a sample wave file that's compliant with version 01.01 of the cart specification.

• August 20, 2001: A proposed working group draft of the cart chunk standard has been published to the AES SC-06-01 Working Group for their comments and correction as "AES standard for network and file transfer of audio - Audio-file transfer and exchange - Radio traffic audio delivery extension to the broadcast WAVE file format," a.k.a. AES-46. Some significant changes to the document were required to meet the documentation standards. None of these changes materially effect the actual data.
  
  The secretariat, in preparing the document for draft release, made a small number of comments, one of which has a potential for materially affecting the data format. Their sugggestion was to make the time and data strings, e.g., StartDate, StartTime, EndDate, and EndTime conform to the appropriate ISO standard for date and time presentation. Following the example of AES31-3, the description of the data and time formats may be changed to be compliant with ISO8601, which limits date field separator characters to "/" and time field separators to ":". The original cart chunk spec followed the lead of the EBU 3285 Broadcast Wave Extension, which allowed any number of non-alphanumeric field separators.
  
  The change, at the force of a recommendation and not a requirement, would restrict date formats to the recommendations of ISO8601, e.g., "2001-08-20" and "11:14:37."

• May 21, 2001: The AES Standards Committee SC-06-01 met at the 110th AES Convention in Amsterdam on May 11, 2001. At that meeting, the status of the Cart Chunk standard AES Project X87 was raised. It was reported that no adverse comments were received by the working group since the last meeting, and the proposal is being prepared for the call-for-comment process as AES-46. For more details, including the latest AES official status, check out SC-06-01 committee report, on the the AES Standards web site.

• March 5, 2001: New vendor information has been added to the website, and the current state of the standards process has been updated.

• February 1, 2001: The Cart Chunk document was edited to conform more closely with AES standards requirements, explanatory notes were removed as required, and the final draft submitted. Currently, we are awaiting the start of the "call for comment" period before finalization.
  
  Please note that the document submitted to and approved by the AES will be considered as the "official" versions.

• September 30, 2000: At the most recent meeting of the AES SC06-01 Subcommittee on File Formats, the latest proposal for the Cart Chunk standard was submitted as AES Project X87. No objections were raised by any committee members, and the current intent is to move it to the Call for Comment phase as soon as feasible.

• August 15, 2000: Currently, there is an active discussion on finalizing the addition of URL field to the Cart chunk before going to the finalization of the standard. The URL field will allow the inclusion of a relevant URL linked to the audio directly. A URL could be used, for example, as a hyperlink in a commercial to an advertiser's web site, in a music spot as a pointer to the composer/artist's web site, in a news spot as a pointer to more details about the story, etc..
  We have discussed this with several parties and are proposing the following modification to the Cart Chunk structure:

1. The contents of the Version field shall be incremented to reflect a new version of the structure. This will allow applications to differentiate between the new and prior versions of the structure. The first released version was tagged as "0100" corresponding to version 1.00. The additions describe here shall constitute version 1.01, and the Version field will be set at "0101" accordingly.
2. The current Reserved field shall remain as described. This shall be available for future utilization by compact data. This, for example, would allow expansion of the PostTimers array if needed.
3. The new URL field shall immediately follow the Reserved array field and be 1024 bytes long. The URL field contents shall meet the "Internet Official Protocol Standards (STD 1), Uniform Resource Identifiers (URI) Generic Syntax" as described in RFC2396. If the URL/URI string is less than 1024 bytes in length, it shall be terminated by a null byte, and the terminator and the remainder of the 1024 byte field shall be ignored.
4. The TagText field will start immediately following the URL field, and be utilized as before. The only difference is its starting point in the cart Chunk.

The resulting cart data structure would then be (the modified or new fields are highlighted in red and underlined):

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/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];          /* ASCII URL/URI information           */
  CHAR TagText[];          /* ASCII text for scripts or tags      */
} CART_EXTENSION;

The change results in a 2048-byte size for the Cart Chunk data area, not including the optional TagText data. Given that WAVE files of several megabytes are routine, this increase is insignificant at best. Applications shall determine from the Version field whether the new URL field is present, and from the chunk size whether TagText is present as well. (note that one consensus of the group is that the TagText field is considered relatively unimportant: not a small number of respondants said that their produce applications did not add TagText information, while consumer applications ignored it if it was present. Only a single application of those sampled utilized the TagText field, thus the increment in version number is required to ensure backwards and forwards compatibility).

We have arrived at this consensus after discussing this with several vendors and users who are already using the Cart Chunk. We believe that it represents the best copromise and provides a high degree of both forwards and backwards compatibility at the lowest development and implementation cost.

The method we propose here can be used in the future for expansion: the version number shall indicate which form of the structure is in use, and new fields shall be added before the TagText, which shall always be found following the last defined field of the structure (in the present proposal, the URL field).

We will attempt to have this addition finalized and ready for the next stage of standardization.

We welcome your comments and suggestions.

Contact us for if you wish to contribute to this and other processes regarding the Cart Chunk.

Home