Comments to date on DRAFT AES31-2-xxxx, AES standard on network and file transfer of audio - Audio-file transfer and exchange - File format for transferring digital audio data between systems of different type and manufacture,
published 2006-04-03 for comment.
Comment received from J. Yoshio, 2006-06-30
Dear Yonge-san / Draft Comments Dept.
This is Junichi Yoshio, on behalf of Technical Standardization Group on Digital Audio for Professional Use (TSG/DAP) of JEITA, Japan, I forward our comments on the call for comment on AES31-2.
I reported to TSG/DAP what I confirmed at AESSC SC-02-08 meeting in Paris, that was the meaning of the sentence from the bottom of p.6 to the top of p.7 of AES31-2, quoted below.
"The content of the fields in the bext chunk shall be defined as shown in table 1. Note that in applications where ASCII text is inappropriate for human-readable information - for example where the language of the operators requires a multi-byte character set - the human readable data in the bext chunk may be set to a default value while the multi-byte human readable information may be carried in some other way (for example: a dedicated metadata chunk added to the BWFF)."
Now we clearly understand the meaning but we feel the description of this sentence may not be so clear to the people other than native English speakers. Our understanding of this sentence is as follows.
"ISO 646 character code is used in bext chunk. When the necessity for using other character codes is caused, it is necessary to achieve it by another means, for example, a dedicated metadata chunk added to the BWFF."
We had an idea to indicate the above as a note, but I think it will be wordiness. So I would like to ask you to manage the sentence. If you feel the current description is enough, leave it as it is, but if it can be revised to make it more clear for Japanese or others, please make some new description.
Best regards,
Junichi Yoshio
Reply from Mark Yonge, chair SC-02-08, 2006-06-30
Dear Yoshio-san,
I can understand the need for special clarity in this paragraph and this can be done as an editorial matter. I propose the following paragraph as a replacement:
"The content of the fields in the bext chunk shall be defined as shown in table 1. Note that in applications where ASCII text is inappropriate for human-readable information - for example when a character set other than ISO 646 is required - it is necessary to carry it by another means, for example, in a dedicated metadata chunk added to the BWFF. "
I note that other issues, such as default content for bext human-readable fields, are already specified in Table 1 so do not need to be repeated.
Please let me know if you feel this is satisfactory.
best regards,
Mark Yonge
Chair: SC-02-08
Comment received from J. Yoshio, 2006-07-13
Dear Yonge-san,
Just now, at the meeting of JEITA Pro Audio Group, the members have
confirmed the comments and reply dated 2006-06-30 on draft AES31-2.
Thank you for waiting our confirmation.
Best regards,
Junichi Yoshio
Comment received from H. Nakashima, 2006-05-12
Dear Standard Manager,
It is Hirokazu Nakashima, chair of Technical Standardization Group on
Digital Audio for Professional Use (TSG/DAP) in JEITA.
As a result of having examined "Call for comment on draft AES31-2-xxxx"
in TSG/DAP, I will send some comments. Please check it.
Page 2: ANNEX C
CHUNK ORDER
==> CHUNK ORDER
[COMMENT] Last "R" of "ORDER" is not set by bold
Page 5: 3.3 ASCII
7-character code compliant with ISO/IEC 646
==> 7-bit character code compliant with ISO/IEC 646
[COMMENT] Will not "bit" fall out?
Page 6: 4.3 Contents of a BWFF
//Format of the audio signal: PCM/MPEG
==> /* Format of the audio signal: PCM/MPEG */
//information on the audio sequence
==> /* information on the audio sequence */
//sound data
==> /* sound data */
[COMMENT] Change comment style from C++ to C
/* ASCII : "Description of the sound sequence"*/
==> /* ASCII : "Description of the sound sequence" */
[COMMENT] Insert a space between [sequence"] and [*/]
/*First sample count since midnight, low word */
==> /* First sample count since midnight, low word */
[COMMENT] Insert a space between [/*] and [First]
/*First sample count since midnight, high word */
==> /* First sample count since midnight, high word */
[COMMENT] Insert a space between [/*] and [First]
;/* 190 bytes, reserved for future use, set to "NULL" */
==> /* 190 bytes, reserved for future use, set to "NULL" */
[COMMENT] Delete [;]
Page 7: Table 1:bext field content definitions (OriginationDate)
MM = 2 characters for month shall contain a value between 1 and 12
==> MM = 2 characters for month shall contain a value between 01 and 12
DD = 2 characters for day of month shall contain a value between 1 and 31
==> DD = 2 characters for day of month shall contain a value between 01 and 31
[COMMENT] Change 1 to 01 (need 2 characters)
Page 8: Table 1:bext field content definitions (OriginationTime)
hh(hours), 2 characters shall contain a value between 00 and 23 if time given
==> hh(hours) = 2 characters shall contain a value between 00 and 23 if time given
mm(minutes), 2 characters shall contain a value 00 - 59 if time given
==> mm(minutes) = 2 characters shall contain a value between 00 and 59 if time given
ss(seconds), 2 characters shall contain a value between 00 and 59 if time given
==> ss(seconds) = 2 characters shall contain a value between 00 and 59 if time given
[COMMENT] Unify the style of sentences
Page 9: A.1.2 Required Wave chunks
/* Wave data*/
==> /* Wave data */
[COMMENT] Insert a space between [data] and [*/]
Page 12: A.2.3 Examples of PCM Wave files
Examples of Format-Chunk settings for three cases are shown in table A.6.
==> Examples of Format-Chunk settings for four cases are shown in table A.6.
[COMMENT] Because number of examples became 4, it is "four cases" instead of "three cases"
Reply from Mark Yonge, chair SC-02-08, 2006-05-12
Dear Nakashima-san,
Thank you for reading this draft so carefully.
I believe that all your comments relate to editorial corrections or to consistency of style. Accordingly, I propose to implement all the changes you suggest prior to publication of this standard.
I trust you will find this a satisfactory response to your comments. Please let me know if you have any other comments.
