Comments to date on Draft AES46-xxxx DRAFT 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 published for comment.
Gerhard 2002-03-15. Yonge reply 2002-04-14. Gerhard response 2002-04-19. Yonge reply 2002-05-05. Gerhard acceptance 2002-05-29. Comment period is closed.
concerning the chunk order in your proposal (6.1 Layout and 6.2 Chunkordering):
As I understood the chunk order was chosen to keep reading the cart data for humans easy. With a simple text editor it is possible reading the cart data without going through the whole file. But there are a lot of good reasons that the Microsoft RIFF standard allows flexibility in the chunk order.
If the data chunk is positioned after the metadata chunks as suggested, changes in the metadata chunks (bext/mext/cart) with a modification of the chunk length will necessitate the movement of the audio data. This can be large amounts of data up to 2 Giga Byte. Typical examples of such changes would be appending a string in the coding history of the bext chunk or adding some text in the free text filed 'TagText' in the cart chunk.
We recommend the order fmt - fact - data - bext - mext - cart (as in 6.2 bext, mext and cart in any relative order) with the data chunk preceding the metadata chunks in the form of a "can" rule (no strong recommendation). In this case after editing of the metadata the file can be saved without any movement of the audio data.
You are of course correct to observe that RIFF files are designed to be flexible in their chunk order, and AES46-xxxx is not intended to be more restrictive. Clause 6.2 correctly indicates that "The last chunk should be the data chunk", expressing a preferred, though not mandatory, chunk sequence.
I observe that clause 6.1 appears to contradict information in 6.2 and, in any case, serves only as an example. Clause 6.1 does not, in fact, appear to be necessary. Accordingly, Clause 6.1, including the example in table 4, will be removed as an editorial action to clarify the issue.
I hope this answers your comment satisfactorily.
regards,
Mark Yonge Chair, SC-06-01
Gerhard response, 2002-04-19
From: SMTP%"[email protected]" 19-APR-2002 07:46:07.00To: Subj: AES46-xxxx further suggestions
Dear Mr. Younge,
Thank you very much for your reply to our suggestions!
We think it is necessary to take the following point into consideration: If an user implements his software according to the "should" rule (last chunk should be the data chunk) and expects chunks to have the recommended order in an imported file there could be problems with files from other correct software which does not follow this rule. Therefore we suggest the add-on "All chunk sequences have to be supported" in clause 6.2. This would clarify this point and prevent such kind of errors.
Thank you for your additional comment regarding AES46-xxxx.
It is clear, I think, that the RIFF format requires that all chunk sequences have to be supported. However, a clarification to this effect can be added as an editorial matter without changing the document in any substantive way. I propose to modify clause 6.2 to read as follows:
******** 6.2 Chunk ordering
The first chunk in a cart WAVE file shall be the format chunk.
If required, the fact chunk should be second. The last chunk should be the data chunk. Other chunks in the file may be in any order.
NOTE: This chunk order is expected to provide optimum speed of access to the radio traffic data with a wide range of computer filing systems. Any RIFF compliant chunk sequence may be encountered in practical interchange.
An example of an MPEG-encoded WAVE file with both BWF and cart chunks, in addition to the fact chunk and mpeg chunk is shown.
EXAMPLE
< WAVE-form> - RIFF('WAVE'
< fmt-ck> // required for all WAVE files
< fact-ck> // required for non-PCM data
< bext-ck> // EBU BWF chunk
< mpeg-ck> // EBU MPEG-extension data chunk
< cart-ck> // cart information
< data-ck> // audio data, required for all WAVE files
*******
I hope this additional wording satisfies the concern raised in your comment. Please reply by the end of the comment period if this reply is not acceptable to you. You may also ask us to consider your comments again for the next revision of the document. You may also appeal our decision to the Standards Secretariat.
with regards,
Mark Yonge Chair SC-06-01
Gerhard acceptance, 2002-05-29
From: "Marc Gerhard" To: [email protected]: Re: COMMENTS ON DRAFT AES46-XXXXDate: Wed, 29 May 2002 13:32:21 +0200
Dear Mr Younge,
Sorry for not answering until now. We have no further objections to your last revision with the note on RIFF compliant chunk sequences.
