Reply from M. Yonge, AES Standards Secretary 2011-07-07, to comments received from Mr. I. Rudd, 2011-06-16
Dear Mr Rudd,
I see that David Ackerman has replied to the substantive matters in your comments of 2011-06-16. As previously mentioned, I am replying here to the editorial matters. Please find attached a PDF document, "aes57-ir-comments-110616-ed-reponses.pdf" that lists your comments and my proposed editorial actions. I believe that all your comments will have been addressed by either David's responses or mine.
Original comments in plain text; secretariat responses in coloured text.
Item
Comment
1
General comments:
Reading through the document, I do think that a node-tree diagram or, preferably, UML class diagram and a hierarchical diagram of the elements and attributes would be an extremely useful pair of Annexes. (Were they not created in writing the draft document anyway?) In the official printed version, they would fold out so as to be visible wherever one was in the body of the document. These diagrams would tell me at once where a particular element or attribute sits when I'm looking at an audio object by having a reference to the section(s) in which it/ they appear. E.g. I find myself looking at a cylinder and wish to record its dimensions or I am looking at the audio object's reference to C_PASS and wish to know more about what that means.
Agreed - editorial. See provision in annex A - text will be corrected to correspond with the XML schema.
5
On the matter of presentation, it would be good if the rendering of the images could be improved.
Agreed - will be corrected before publication.
7
Typo: "later case" should be "latter case".
Agreed - will be corrected before publication.
12
Further, in section 4.3, "subclass" is not a verb and what is meant by "reasonably unique"? Further again, "should" implies "need not".
Agreed - will be amended editorially before publication.
14
Page 7 and passim; Table
Column "KIND" should be first but must at least be second so that the reader realises what the element/ attribute is. (It is - surely - more logical to think, "I have an ELEMENT with the NAME 'format' which is of DATA TYPE 'formatType' etc. " than, "I have the NAME "format" which is of DATA TYPE "formatType" etc." and only discover just what it is I have with that name, format etc. after I have looked at the optionality and cardinality.)
A further improvement would be two tables with, respectively, "NAME" replaced by"ELEMENT NAME" and "ATTRIBUTE NAME". That would mean there would be no need for the "KIND" column and the added benefit would be no wrapping of the ELEMENT NAME/ ATTRIBUTE NAME or DATA TYPE fields.
This is an editorial issue related to the order of columns in the table. David Ackerman has requested that I change the column order in these tables so that the 'KIND' column is at the left-hand side. This will be amended editorially before publication.
16
Page 7, Section 4.4.2 What is the force and meaning of the word "directly"? There is no other means (stated) of appearing in the element in question.
Agreed - will be amended editorially before publication.
21
Page 13 Section 4.4.2.1.2 Typo: "There are a series" should be "There is a series".
Agreed - will be amended editorially before publication.
36
Page 23 Section 4.4.16.2 Typo : 4.4.16.2.1.11 should be 4.4.16.2.1.1
Agreed - will be amended editorially before publication.
37
Page 24, Section 4.4.16.2.1.1 Typo: "edit UnitNumberType" should be "editUnitNumberType".
Agreed - will be amended editorially before publication.
38
Page 24, Section 4.4.16.2.1.2.1 Typo: "data type is a long" should be "data type is a long".
Agreed - will be amended editorially before publication.
39
Typo: the redundant spaces in the table before editRate, positiveInteger and factorNumerator can be removed.
Agreed - will be amended editorially before publication.
40
Page 26 - 28, Sections 4.4.16.3.4, 4.4.16.3.4.1, 4.4.16.3.4.2, 4.4.16.3.6, 4.4.16.3.6.2, 4.4.16.3.6.3, 4.4.16.4.1 Typos: all these sections point to sections 4.4.15.x(.y.z) instead of 4.4.16.x(.y.z) and Section 4.4.16.4 points to 4.2.17.4.1 instead of 4.4.16.4.1
Agreed - will be amended editorially before publication.
41
Page 26 Section 4.4.16.3.4.3 Typo: " ... described in 4.4.16.2.1 and 4.4.16.2.2.." (double stop -sic) should be " ... described in 4.4.16.2.1.1 and 4.4.16.2.1.2."
Agreed - will be amended editorially before publication.
44
Page 28 section 4.4.16.3.6.4: I didn't understand "... aid in the identification of the document section"; I can't provide guidance, except that if the reference is to the instance document, it is mixing up document attributes with the audio object's attributes - !
Isn't " ... should be displayed to the user through a software interface ..." redundant on the grounds that all the information will be so presented? I suggest removing the second sentence.
Agreed - will be amended editorially before publication.
45
Page 28 section 4.4.16.3.6.5 The explanatory "(point to)" in Section 4.4.16.3.8 needs to be in this Section because this is the first occurrence of it. Whether it then appears in 4.4.16.3.7 and 4.4.16.3.8 is optional.
Agreed - will be amended editorially before publication.
46
Pages 30 - 34 Section 4.4.17 - 4.4.17.4.7 Typos: all these sections point to sections 4.4.16.x(.y.z) instead of 4.4.17.x(.y.z)
Agreed - will be amended editorially before publication.
47
Pages 31 - 39 Section 4.4.17.4 and most sub-sections Typos: the FormatRegion is described in Section 4.4.17.2 and not Section 4.4.2. the baseFormatRegionType is described in Section 4.4.17.3 and not Section 4.3.
This [FormatRegion] reference is intended to refer to physical properties, not formatRegion. Will move reference in the sentence to make relationship clearer. This sentence [in 4.3] refers to objectType, not baseFormatRegionType and is correctly referenced.
48
Page 32 Section 4.4.17.4.2 "The speed element may be used to indicate the playback speed of the described audio object."As was pointed out in Section 4.4.17.2, different regions of the audio object may be played at different speeds. Therefore, I suggest that this sentence should be: "The speed element may be used to indicate the playback speed of the formatRegion of the described audio object."
Agreed - editorial. Propose to refer to "object or region" in all these cases.
50
Page 33 Section 4.4.17.4.3 "The bitDepth element shall declare the number of bits per sample for the audio content of the described audio object." As was pointed out in Section 4.4.17.2, different regions of the audio object may have different characteristics. Therefore, I suggest that this sentence should be: "The bitDepth element shall declare the number of bits per sample for the audio content of the formatRegion of the described audio object."
Agreed - editorial. Propose to refer to "object or region" in all these cases.
51
Page 33 Section 4.4.17.4.4 Similarly, we should talk of the sampleRate of the audio data of the formatRegion of the described audio object.
Agreed - editorial. Propose to refer to "object or region" in all these cases.
52
Typos: "sample-rate" should be "sample rate" (two occurrences) and "sampleRate" in the third line should be "sampleRate".
Agreed - editorial. Propose to refer to "object or region" in all these cases.
54
Pages 35 - 37 Sections 4.4.17.4.10 - 4.4.17.4.13.8 and 4.4.17.4.13.9.1.2.1 Again, we need to specify the formatRegion of the audio object and not the entire audio object in each case. (E.g. this is a mono passage between two stereo passages or an inadvertent operation at the mixing desk introduced a high-frequency cut in this passage.)
Agreed - will be amended editorially before publication.
55
Page 35 Section 4.4.17.4.13 Typo: The reference to Section 4.4.16.4.11.1 should be to 4.4.17.4.13.1
Agreed - will be amended editorially before publication.
56
Page 36 Section 4.4.17.4.13.8 The grammar and syntax of the first sentence can be tidied here to read: "The dataRateMode shall be used to indicate that the described formatRegion of the audio object's [NB apostrophe] audio data has been processed to achieve a FIXED (constant) or a VARIABLE bit rate."
Agreed - will be amended editorially before publication.
57
Page 36 Section 4.4.17.4.13.9 Typo: The header of this Section, "packetList" and "bitrateReduction" need the correct formatting.
Agreed - will be amended editorially before publication.
58
Page 36 Section 4.4.17.4.13.9.1 Typo: "packetListType" should be "packetListType".
Agreed - will be amended editorially before publication.
59
Page 37 Section 4.4.17.4.13.9.1.1 Typo: "The packet element shall be used ..." should be "The packet element shall be used ...".
Agreed - will be amended editorially before publication.
60
Page 37 Section 4.4.17.4.13.9.1.2.2 Typo: "packetLength" should be "packetLength".
Agreed - will be amended editorially before publication.
63
Page 40 Section 4.4.18 Syntax: "metadata" is redundant and may be removed.
Agreed - will be amended editorially before publication.
65
Page 40 Section 4.4.20.1 " ... designed to be independent of its physical housing" implies that the FILE_DIGITAL audio object has a physical housing and that is by no means certain. The words need to be: " ... designed to be independent of a physical housing".
Agreed - will be amended editorially before publication.
67
Page 40 Section 4.4.22 I think that "final disposition" should be "current disposition" because numerous archives have a retention policy which determines that certain items will be discarded after some event or period of time. Therefore, although I might have [this item] in my archive at the moment, I know that its final location will be the skip. I would wish to know whether or not I still actually have the item.
Agreed - editorial. Propose simply "disposition" as "current" only describes an instant.
