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 113th Convention in Los Angeles, CA, US, 2002-10-05
The meeting was convened by chair M. Yonge.

The agenda and the report of the previous meeting at the 112th Convention in Munich was approved as written.

As a matter arising from the report, R. Caine asked to discuss the informal use of ".bwf" filename extension; discussion deferred to be part of AES-X66

Open projects

AES31-1-R, AES Standard for Network and File Transfer of Audio - Part 1: Disk Format
U. Henry proposed that the standard should mention FAT32 in order to stay compatible with implementations in the field and retain the spirit of the format. Yonge felt that this would not require a normative change and could be accommodated in an informative note.

AES31-3-R AES Standard for Network and File Transfer of Audio - Part 3: Simple Project Interchange
C. Garza observed that sample rates shown in Table 6 do not show the higher sampling frequencies needed for the record industry. 192 kHz PCM is definitely required and Direct Stream Digital (DSD) formats are envisaged. J. Palmer mentioned that film studios predominantly used the single rates, but occasionally a record company would ask them to handle material at 96 kHz as a capture and archive format. Delivery material will probably stay at 48 kHz. Caine observed that digital cinema audio was anticipated to use 48 kHz only. Caine asked whether the higher sampling frequencies required would always be binary multiples of the baseline sampling frequencies already specified. No contrary view was expressed.

J. Bull noted that DSD operates at 64 times the baseline sampling frequency but that a Sony/Philips interchange file format, DSD-IFF, had already been proposed which was significantly unlike AES31.

Caine noted that expanding the range of sampling frequencies will require an amendment rather than simply an editorial change. B. Harris observed that there was a limit on the number of characters available to code these frequencies into TCF.

Henry suggested that a single value in the ADL header could be used to increase the sampling frequencies in the whole project by a binary multiple. Concern was expressed that mixed sampling frequencies were becoming increasingly common and this scheme would not handle mixed sampling frequencies that crossed the boundary of a given multiple.

Harris considered that an alternate TCF format that could use a rational number to define the sampling frequency more flexibly. This would be a substantial change to the existing standard but would allow non-standard samping frequencies to be indicated.

There was significant resistance to the idea of radical change at this point in the interests of implementors who were operating satisfactorily with the existing standard.

Bull observed that the original goal was to be simple and strong, for all manufacturers, not just the majors. There was a danger that a more complex scheme might miss this goal by striving for all possible options. Ultimately, the users will choose�they will have to pay for the research and development costs in the end. Palmer was also concerned that applications become incompatible while their designers try to implement new changes. Accordingly, the meeting felt that the simplest change to accommodate these emerging needs while retaining existing code would be preferred at this time. Future changes could be more comprehensive.

Harris asked whether one more character to support 192 kHz would be sufficient. Garza felt that 176.4 kHz (quad rate 44.2 kHz) would be required also. The meeting agreed that the existing sampling frequency table should be extended. Harris volunteered to write a proposal.

AES46-R Review of AES46-2002, Radio Traffic Data Extension to Broadcast Wave Files
Was AES-X87. Completed CFC in mid-June. The standard is now published. Review will be required in 2007 at the latest.

AES-X66 File Format for Transferring Digital Audio Data between Systems of Different Type and Manufacture
Yonge introduced a draft document derived from the EBU document. Its finalisation has awaited the publication of the SMPTE UMID which has taken longer than expected. The UMID now appears to be stable in terms of its data structure and it is not time to proceed.

Some earlier working principles were discussed. Palmer spoke against including anything other than linear PCM in this standard. He observed that some non-standard wave files can�t be reproduced by some applications right now. He was also concerned to minimise complexity and coding in film audio archives to simplify later retrieval.

Garza noted that some lossless codecs may be used.

The meeting agreed that the document should describe linear PCM and discuss alternative codings in an informative annex. The document will return to Task Group SC-06-01-C. Henry, Lyman and Harris agreed to contribute.

Harris asked whether we should include details of UMID useage policies? It was felt that the UMID should be considered simply as a unique identifier; useage policies could be discussed elsewhere as appropriate.

Lyman mentioned that a BWF sound file could also be transported in a "Material Exchange Format" (MXF) file, which was passing through SMPTE standardisation. Harris opined that an MXF file with a BWF head should be transparent to both and MXF parser and a BWF parser.

Edit automation.
No progress was reported. Palmer stressed the need for this function. Continuing in Task Group SC-06-01-F.

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 action was reported.

Palmer observed that there seemed to be some external opposition between AES31 and the Advanced Authoring Format (AAF), an object oriented exchange format encompassing video and other media. The meeting felt that this make little practical sense. There is a clear advantage to all users through having AES31 elements being compatible with similar audio elements in an object oriented format, and vice versa where appropriate.

AES-X71 Liaison with SMPTE Registration Authority
No action to date. Felt that the AES should investigate registering a SMPTE label for the AES31-1 data format.

AES-X128 Liaison with AAF Association
No progress was reported

New projects

No new projects were received or proposed

New business

There was no new business

The next meeting will be held in conjunction with the AES 114th Convention in Amsterdam, the Netherlands.