The agenda and the report of the previous meeting, 2005-05-27, were accepted as written.
AES31-1-R: Review of AES31-1-2001: AES standard for network and file transfer of audio - Audio-file transfer and exchange - Part 1: Disk format.
No action requested or required
AES31-3-R: Review of AES31-3-1999, AES standard for network and file transfer of audio - Audio-file transfer and exchange - Part 3: Simple project interchange. including maintenance of annex F.
Editorial revision continues.
AES46-R: Review of AES46-2002: 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
No action requested or required
Clause 4.3 discusses the structure of the "bext" chunk.
A new paragraph says,
"The contents of the fields in the bext chunk shall be defined as in table 1. Note that where applications where ASCII text is inappropriate for human-readable information - for instance, where the language of the operator requires a multi-byte character set - the human-readable data in the "bext" chunk may be set to a default value and the information may be carried in some other way, (for example, in a dedicated metadata chunk added to the BWFF using one or more multi-byte character sets)."Ackerman asked for clarification of the default values for human-readable fields. It was felt that a minimum of a single null character. Implementors may choose to insert some other default ASCII text in these fields, but this falls outside the scope of this document. U. Henry pointed out that the special case of a full string (256 characters) would leave no room for a null character at the end. This case would need to be acccommodated by implementors.
A new column in the table of "bext" field definitions identifies each field as human- or machine-readable. Definitions for the human-readable fields now include a statement, "if data is not available .." to cover the case where such data is not provided in the "bext" chunk, although it may be carried elsewhere.
The content of the OriginatorReference field is specified divergently in the EBU and ITU BR.1352-2-2002 documents, reflecting different construction of a Unique Source Identifier (USID). Because this metadata element may be carried elsewhere in this specification provides machine-level compatibility with both specifications. [*****]. The normative reference to EBU R99 is not required in this core interchange document but should be removed to Annex B, informative references.
OriginationDate: Default is the origin of the Modified Julian Date of 1858-11-17. Accords with EBU spec.
OriginationTime: No default value in EBU spec. Specified as midnight (00:00:00) in this draft.
TimeReference: added words:
"This field contains the time code of the sequence. A 64-bit value which contains the count, since midnight, of the first sample in the audio data."This wording differs in detail from the EBU document. The default value is zero.
Henry felt that the time reference should not be confused with a "real-time clock" which could be sloppily interpreted. Caine preferred the term, "sample address count", which corresponds to a similar reference in AES3. It was felt that the value should be a positive number and that negative numbers that cross midnight were not acceptable. Value should be specified as a D-word. Henry felt that a 64-bit unsigned value should be specified. Default should be zero.
The Version value has not been changed because there is no essential change from the EBU spec.
The Reserved field is still reserved.
The CodingHistory definition has been reworded & simplified:
"A variable-size block of ASCII characters comprising 0 or more strings each terminated byHenry observed that the content of the file now provides an alternative route for multi-byte strings, but the issue of the filename remains. The file name should be ASCII for reliable interchange because some multi-byte character sets will break some traditional western file systems. It was also noted that multi-byte file names also represent a significant problem for file references in AES31-3. The issue is related to the computer file system which may not recognise a multi-byte string at all. Some operating systems will handle them correctly, others will not. (Henry has found that some Japanese file names cannot be deleted from his PC because the name is simply not recognised.) Although newer systems are more competent, the problem is still existing in the field.
. The last character in the block shall be set to null. Each string shall contain a description of a coding process applied to the audio data. Each new coding application should add a new string with the appropriate information."
An annex for filename conventions exists to clarify the use of the filename extension. It should also mention the filename issue. J. Yoshio reported no problem in current usage - Japanese companies have guidelines for international interchange to use ISO 646 character set for file names. JPPA have a new version 2 BWF-J which also recommends international exchange using ASCII filenames.
It was felt that ASCII filenames should be strongly recommended for interchange.
Annex A is essentially the same as the EBU T.3285 Annex A, but simplified to remove obsolete elements. References to 8-bit files have been removed as obsolete. In A.2.2, the reference to "9 or more bits" separates the specification from legacy formats. Henry felt that the style of annex A should be harmonised with the rest of the document. Requires minor editorial.
Additional annexes have been inserted to handle issues of file-size limits and multi-channel usage.
AES-X068: A Format for Passing Edited Digital Audio Between Systems of Different Type and Manufacture That Is Based on Object Oriented Computer Techniques
No action. Henry noted that the AAF Edit protocol document could now be considered.
AES-X128: Liaison with AAF Association
Nothing to report
AES-X149: Format and Recommend Usage of the Direct Stream Digital Interchange File Format (DSDIFF)
Continuing. [need to confirm].
Institute of Broadcast Sound (IBS)
In the UK, the IBS has been working on a metadata scheme for professional sound recordings. Unlike finished material for distribution, where it is simply necessary to identify a limited set of mono, stereo, or surround formats, production source recordings need to described with a wider range of meaningful labels. The project originally grew out of a recognition that the metadata space in the BWFF is finite and small.
IXML comprises an XML metadata structure for communicating information about what is recorded on each track of a multichannel location HD recorder, for example. Individual tracks could be identified as various personal radio mics, or boom mics, for example, or sub-sets could be identified as MS or AB stereo. This technique represents an important means for the location sound recordist to communicate with rest of the post-production chain that is currently missing from modern production methods. A specification has been published on the web site at http://www.ixml.info.
The IBS has offered the IXML format for standardisation. It may be appropriate to consider it in SC-03-06.
Yoshio mentioned that the DVD forum will support both BWF and iXML. The Japanese standards group Japan Electronics and Information Technology Industries Association (JEITA) will study BWF and BWF-J; the chair for this work is H. Nakashima.
Henry observed that the draft doesn't define what is in the RF64 chunk. Caine suggested a project for liaison with EBU to consider RF64.
The next meeting will be scheduled in conjunction with the AES 120th Convention in Paris, France, 2006-05.