The meeting was convened by chair M. Yonge.
The agenda and the report of the previous meeting, held in Warsaw, 2015-05-07, were approved as written.
Projects assigned to this group but not mentioned here had no action requested or required - see www.aes.org/standards/meetings/project-status.cfm for details.
AES-X236 - IEC 62942 liaison, IEC 62942 liaison, Broadcast Wave Format file
This project in IEC TC100 TA4 is at committee draft (CD) stage. It is scoped as:
“… specifies a file format for interchanging audio data between compliant equipment. It is primarily intended for audio applications in professional recording, production, post production, and archiving.
It is derived from the EBU Broadcast Wave Format but is also compatible with variant specifications including ITU-R BR.1352-3-2007 and the Japan Post Production Association’s BWF-J.
An optional extended format, BWF-E, supports 64-bit addressing to permit file sizes greater than 4 GBytes."
There was a useful discussion about the need to resolve the situation where apparently similar data in both the required 'bext' chunk and the optional 'ubxt' chunk conflicts. C. van Winkle made a number of suggested related to the reliable implementation of recording and playback software.
The machine-readable data in the required 'bext' chunk should always have priority over the machine-readable data in the optional ubxt chunk. This is hinted in a note using "shall" in note 1 beneath figure L.1, but this should be required normatively in body text.
When entering multi-byte characters in the human-readable fields of the 'ubxt' chunk, care should be taken to enter either a meaningful plain text equivalent, or a suitable default string, in the 'bext' chunk. In this way, implementations that only implement the 'bext' chunk will at least be aware that this metadata is available in a different place. The default string could simply say, "See 'ubxt' chunk".
When entering UTF-8 multibyte characters into a fixed-length data field, care should be taken to truncate the string where necessary on a valid character boundary to avoid decoding errors.
The 'bext' and 'ubxt' chunks, are currently shown with sets of identical field names. It was felt that this could lead to confusion. It was suggested that the 'ubxt' field names should carry a 'u' prefix in order to keep them distinct.
In addition, it would be useful to explain the relationship between 'bext' and 'ubxt' in the introduction to the standard
No new liaison information.
No new projects were proposed.
There was no new business.
The next meeting will be scheduled in conjunction with the AES 140th Convention in Paris, France, 4 to 7 June, 2016.