Report of the meeting of the SC-06-01 working group on audio-file transfer and exchange of the SC-06 Subcommittee on Network and File transfer of audio, held on 2004-05-09 in Berlin, Germany.
The meeting was convened by chair M. Yonge.
The agenda and the report of the previous meeting held in New York, NY., US., 2003-10-10 were agreed as written.
Open Projects
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 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.
A revision is anticipated during this year. U. Henry addition for pan & gain accepted for incorporation in the draft revision. Parameters now include left-right panning with right limit at +100.0%, left limit at -100.0% and centre at zero. Front/back panning with front limit at 0.0% and back limit +200.0%. This allows the horizontal plane to be described with equal precision in both axes.
A proposal for international character sets (non-ASCII) needs more general consideration, especially in the issues raised later in AES-X066.
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 required
Development projects
AES-X066: File Format for Transferring Digital Audio Data Between Systems of Different Type and Manufacture
Variations of the Broadcast Wave Format (BWF) have appeared in the past few months to accommodate workers in territories that do not use the ASCII character set for human-readable information, for example Japan. Issues concerned with this development have also been raised in EBU P/AGA and in ITU-R Working Party 6R. S. Aoki, who was present to raise the matter, has been appointed by ITU-R W6R as special rapporteur tasked to request AES "... to manage the metadata space of the BWF to insure international interchange of files".
Some of the background was discussed briefly for reference. The original specification for the Broadcast Wave Format (BWF) was published by the EBU in 1995 as Tech Doc 3285. A subsequent ITU-R document, BR1352, also specifies a form of BWF but it is not identical to the EBU document. Both, however, specify a RIFF file architecture with ASCII characters for all fields in the Broadcast Extension chunk ("bext"). As used here, the term "ASCII" refers to ISO/IEC 646: ISO 7-bit coded character set for information interchange. Some of the "bext" fields are intended to support automatic systems and are intended to be machine readable; other fields contain human-readable descriptive information. With the introduction of non-Latin, or multi-byte, character sets, a number of important issues arise that affect the desirable goal of predictable international interchange of professional audio files.
Multi-byte character sets, where used to replace ASCII directly, can have a number of unintended, and potentially disastrous, effects. Henry and J. Bull pointed out that some codes arising in multi-byte character strings can be misinterpreted as non-printing ASCII codes and cause malfunctions in equipment designed to parse BWF files to the original specification. Even if the specific audio software tolerated such codes, fundamental problems would still lie in the computer operating systems. It is also the case that human-readable information in a language that the operator does not understand is not very useful to the interchange process. It will also be necessary to consider interchange between organisations that use different multi-byte character sets where any single-language solution will not be adequate. It was also strongly felt that any system that required special copies to be made for international interchange while permitting incompatible formats locally would be likely to fail in service.
The meeting agreed that the practical way to achieve the broadest international interchange without introducing backwards compatibility problems was to retain the machine readable metadata in the "bext" chunk that continues to be required for interchange of the audio content and for referencing metadata held in external databases. This metadata would include general time and date information as well as sample-count timestamp and unique identifier. The human readable elements may then be handled separately to suit the requirements of each organisation.
The steps that were identified included:
Identify and specify machine-readable fields in as currently specified
Confirm ASCII codes for the human readable fields in , using default strings where appropriate in place of Latin text where this is not available.
Create a new "International metadata" chunk to carry human readable information in any language and character set, fully specified to indicate the language(s) and character set(s) used for its content. XML was proposed as a possible structure. It was suggested that the character set should reference ISO/IEC 10646: Universal Multiple-Octet Coded Character Set (UCS).
Aoki will develop a draft document for this group to specify the new International chunk.
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 progress
AES-X071: Liaison with SMPTE Registration Authority
Continuing
AES-X128 : Liaison with AAF Association
No progress
Liaisons:
Need to confirm liaison with EBU group P/AGA with regard to international interchange.
New Projects:
No new projects were proposed
New Business:
Henry requested consideration of a standard or recommended practice on file names for files. When considering international exchange, it will be important to understand how filenames using multi-byte characters may be used on computer operating systems that do not.
The next meeting is scheduled to be held in conjunction with the AES 117th Convention in San Francisco, CA., US., 2004-10.
