Report of the SC-02-08 Working Group on Audio-File Transfer and Exchange of the SC-06 Subcommittee on Network and File Transfer of Audio meeting, held in New York, NY., US., 2005-10-09
The meeting was convened by chair M. Yonge
The agenda and the report of the previous meeting, 2005-05-27, were accepted as written.
Open projects
AES-R1-R: Task Force on High-Capacity Digital Audio Carriers (AES-R1)
No action requested or required
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
Development projects
AES-X066: File Format for Transferring Digital Audio Data Between Systems of Different Type and Manufacture
A new draft, modified during the meeting to become x066-draft-051009.doc, was discussed. The structure of this document is intended to achieve backwards compatibility with the EBU, ITU, and JPPA variants of the BWF specification. The draft is based on EBU Tech. Doc. 3285-2001. The content has been subdivided and re-organised to concentrate on the Broadcast Extension, or "bext", chunk which forms the necessary core of the Broadcast Wave File Format (BWFF). The discussion of additional chunks in a BWFF was removed from 4.1 to Annex C.
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 by . 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."
Henry 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.
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].
Liaisons
SC-03-06
Ackerman reported, for information, that SC-03-06 planned to include the character-based Time Code Format (TCF) as part of the XML-formatted metadata in AES-X098, "Administrative metadata for audio objects". The group had found that some TCF characters are not compatible with XML (for example, the characters "<", ">"). A criticism that the verbosity of TCF increases file sizes excessively was not found to be relevant in XML schemas where the amount of data is already large.
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.
DVD Forum
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.
New projects
EBU RF64
A proposal from EBU P/AGA has been received regarding a 64-bit audio file format to overcome the 4 GB file size limit in Wave files. The file-size limit becomes more restrictive when it contains interleaved multichannel audio. The RF64 proposal creates a new kind of Wave file with 64-bit addresses; but is otherwise as compatible with Wave files as possible. It is not proposed to confuse AES-X066 with this topic - but it could potentially become a new standard as a companion to BWFF.
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.
New business
Ackerman noted that Harvard Library was using AES31-3, but he would prefer an XML version for compatibility with other metadata structures. Such a development could also solve the filename problems mentioned earlier. Ackerman expressed willingness to work on an XML version of AES31-3.
The next meeting will be scheduled in conjunction with the AES 120th Convention in Paris, France, 2006-05.
