Report 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 meeting, held in conjunction with the AES 115th Convention, NY., US., 2003-10-10

The meeting was convened by chair M. Yonge.

The circulated agenda was approved with the addition of a liaison report from the DVD Forum. The report of the previous meeting was approved as written

DVD Forum Liaison

J. Yoshio now chairs DVD forum WG10. Yoshio reported from DVD Forum Working Group 10. This group is considering professional applications of DVD optical disc.

There is currently no standard for professional audio recording on DVD. Application areas include studios and broadcast. The intention is to consider a new format for recording and playback of high quality audio data and associated data. The next generation of DVD technology will handle the higher bandwidth and storage capacity necessary for: a) timecode; b) metadata; c) video recording possibilities; d) audio recording for professional use.

Two possibilities are being considered for development as the DVD Audio Professional (DVD-AP) format: a) Broadcast Wave Format (BWF), a computer file format on DVD-ROM; b) a DVD Audio format dedicated for professional audio application.

It could be possible to have two sessions on a single DVD disc: DVD Audio plus a DVD-ROM area. However, this will need a special DVD AP recorder/player.

It had been noted that BWF files will be a standard for broadcasters. The Japanese Post Production Association (JPPA) had promoted the use of the BWF-J format on 2.5 in MO disc which was very popular in Japan although not so widely used elsewhere. A document describing this BWF variant was circulated. However, the capacity of an MO disc was not sufficient for multi-channel audio files. Further development of this style of interchange would require the capacity of the DVD-AP instead of the MO disc.

A copy of the presentation has been posted to the working group document site.

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.
There were no requests for revision.

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.
Note that this standard is due for mandatory review during 2004.

A proposed extension of AES31-3 is intended to provide a simple but reliable method of interchanging gain and pan automation data between workstations.

Should there be some maximum gain in a fader, referenced to unity? U. Henry observed that many workstations have difficulty applying more than 12 dB gain to an audio path; sometimes less. It would be helpful if it was generally understood that this was a realistic constraint on free interchange. J. Bull agreed but noted that replay systems should be prepared to accommodate larger gain maxima in case these are encountered in practice.

There was a discussion concerning fader gains in decibels expressed to two decimal places. Henry noted that because AES31-3 requires the value to be rendered in ASCII characters, some limit to the number of characters is practically necessary. It was noted also that receiving applications will need to interpolate, or ramp, between gain steps in any case, and this will largely eliminate the need for higher precision gain values; two decimal places were felt to be sufficient.

Bull felt that 100 points in each panning axis (left to right and front to back) would not be sufficient to define a smooth pan locus. Imagine a circular pan movement; there could be audible path errors, or gain artifacts similar to zipper noise. With such coarse steps, eliminating these artifacts would need a greater degree of look-ahead to upcoming data which could make practical implementations unnecessarily complex.

It was felt that the default pan position should be at front-center, which should be identified by a coordinate value of zero in both axes.

It was also felt that there needed to be an convention for interpreting pan points in a similar manner to that proposed for faders. This should avoid the appearance of instantaneous transitions�implementations should always use ramped coefficients in the same way as the faders.

Following a question about panning law, there was agreement that the document should define that the total SPL in the room from all speakers shall be independent of the pan position.

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
There were no requests for revision.

Development projects

AES-X66: File Format for Transferring Digital Audio Data Between Systems of Different Type and Manufacture
No draft was available

AES-X68: A Format for Passing Edited Digital Audio Between Systems of Different Type and Manufacture That Is Based on Object Oriented Computer Techniques
No development to report.

It was clearly felt that it would not be useful to generate an object oriented scheme from scratch. However unambiguous variables like, for example, level and pan control will still be relevant for simpler systems and could usefully be accommodate in AES31-3, as has been already discussed.

The desire for an inclusive hierarchy was reiterated. AES31-3 and the putative AES31-4 would be separate project options built on a common basis of AES31-1 and AES31-2. AES31-3 has been demonstrated to be reasonably simple and quick to implement. It was hoped that a suitable candidate for AES31-4 could be identified soon.

AES-X71: Liaison with SMPTE Registration Authority
No development to report.

This is now less clearly the business of SC-06-01 because SC-03-06 and SC-06-06 are now handling metadata. There may be no need to continue with this project.

AES-X128: Liaison with AAF Association
Bull reported that the Advanced Authoring Format (AAF), as it currently stands, has been implemented in the Sadie audio workstation. They have proven interchange: they can accept compositions from equipment by a number of different manufacturers and can generate apparently compliant compositions for export which can be read by some equipment. Detailed development relies on company to company cooperation rather than by reference to an objective specification. Noted that AAF uses BWF files as an audio file format.

New Business: International character sets

S. Aoki spoke on the subject of Broadcast Wave Format (BWF) files in international interchange.

He observed that the Broadcast Wave Format (BWF) as currently defined does not support international interchange because, for example, the metadata in the �bext� chunk is specified to use the ASCII character codes. While ASCII is a robust and simple character set, it is limited to representing the Roman alphabet; however ASCII code in Japanese operations means that operators cannot read information in their own language. Interchange becomes accordingly difficult when interchanging commercials for broadcasting where flexibility of interchange is very important.

Aoki felt that Japanese character sets based on ISO 10646 Universal Multi-Octet Coded Character Set (UCS) or its derivative UCS Transformation Format, UTF-16, would be appropriate. Unicode and the Japanese-specific �Shift-JIS� scheme are also in use. In the Japan industry there appeared no clear consensus as to which character code to prefer.

It was pointed out that any general standard should probably cover all international interchange and support all character sets, not just Japanese. UTF-16 appears to be derived from ISO 10646; Unicode may also be considered a subset of this same international standard.

Bull noted that it would be a significant task to convert existing applications to a different character code set. Also, character codes sets are not inter-operable so there will need to be some degree of active translation.

Henry observed that multi-octet filenames will be a problem; they may not be readable at all in some systems! Aoki said that the Japan Post Production Association (JPPA) has no special requirement but uses the filename scheme provided in the Japanese version of the computer operating system. Henry remained concerned that filenames will not be read correctly� AES31-3 depends on locating files by referencing their filenames. Multi-byte filenames could corrupt accurate filename reading.

Bull felt that the general question of multi-byte character sets is potentially huge in terms of its impact on software development. If filenames need to use the local language of the operator, no matter where they have been generated, then it seems likely that filenames will be translated during distribution and so any scheme that relies on using filenames to identify, for example, an audio clip must fail. Other referencing schemes could be possible but would involve a greater computing overhead and a reduced performance from software tools.

C. Garcha mentioned that the RIAA are considering database systems that will allow distributed queries across multiple databases beyond the US and which could involve non-roman character sets, including Japanese. For now, all music sold on the Internet uses 7-bit ASCII identifiers.

This issue will need to be considered carefully. Review of AES31-3 is due in 2004 and it is right to discuss this issue now for consideration as a possible revision.

New Business: audio file metadata

Henry raised the issue of storage of production information, such as scene, take and roll number, within a Broadcast Wave Format file; different companies have developed similar tools in different ways.

Experience indicates that there are a number of exclusive cultures with incompatible systems used around the world. Henry observed that a number of systems existed for displaying production data of various forms but their effectiveness was restricted because there are no clear standards for the metadata. It may be that different schemes could coexist at a display level without any need for formal mapping between them.

Aoki suggested the TV Anytime metadata framework as a basis for such metadata design. The next phase will include B-to B (business to business) applications as well as the existing B-to-C (business to consumer) scope. This is an XML structure and is independent of transport method.

Once the metadata elements have been agreed, could they be carried as an XML chunk associated with a BWF? It was felt possible, but further development should also involve the expertise of SC-03-06.

New Projects

No new projects were proposed.

The next meeting is scheduled to take place at the AES 116th Convention in Berlin, 2004-05.