Oct 1, 2002 12:00 PM, BY OLIVER MASCIAROTTE

Although there have been weak efforts in the past and a good deal of lip service addressing file and session interchange, little actual help for the average practitioner is afforded by old-school methods, unless you are a single-vendor house. What began a decade ago as a proprietary solution, the OMF standard and its spawn, AAF, are, in large part, controlled by Avid and have not made life much easier for end-users and have made pure hell for other audio manufacturers. (For an in-depth look at the history of OMF, see “File-Format Interchange” on page 50.)

Back in 1998, the Audio Engineering Society, identifying a need in the industry for an open approach to session interchange, made a first attempt to bring some order to the chaos. So began the AES31 standard: open, international and designed to simply address interchange of audio content and metadata. Mel Lambert covered AES31 in detail in the October 2001 issue of Mix, so I won't dig into the gory details. The standards committee has now ratified two parts, AES31-1-2001, or Part 1, which describes “a common platform so that files may be interchanged among hardware of different manufacturers of audio and video equipment,” and AES31-3-1999, Part 3 of the spec, which provides a “simple but extensible system for passing audio material between systems.”

The essence of Part 1 is straightforward and succinct. In a word, fat. Whether it be 12-bit for floppies or 16- or 32-bit for rigid media, Microsoft's antique de facto disk file system is the foundation for AES31FT, the standard's file-allocation table disk format. Because this is a lowest-common-denominator standard, the more widespread FAT won out over the much-improved NTFS, because universality is paramount. NTFS, the file system developed for Microsoft's professional NT operating system, is a more robust approach than FAT32, a 32-bit version of the file-allocation table first developed for its original operating system, MS-DOS. NTFS has better user access control and handling of modern volume sizes and file counts, along with improved reliability. We all like reliability.

On we go to Part 3, which outlines a “…convention for expressing edit data in text form in a manner that enables simple and accurate computer parsing while retaining human readability.” In other words, it's sample-accurate session data expressed as ASCII text. ASCII text is the simplest data format for “human readability,” consisting of the upper and lowercase alphabet and common metacharacters like # and $, along with the numbers 0 through 9. So, like the CMX EDL (edit decision list) format for videotape editing that started it all, AES31 Audio Decision Lists (ADL) can be read by any engineer who has learned to parse or understands his or her grammar. As an example, the following fictitious entry would identify a source file used in a project:

(F) “URL:file:08/26/01/localhost/Kingston03/AUD001 .WAV”
030A2C68010101010202000230531M80-H9F4-28b2-DPDC-00T06703K9TC040603
09:11:03.03/1101 00:00:07.00/1101
“NAME: MOS RoomTone2”
N

The first line identifies a (F)ile entry, and then states the location of that file, as expressed in a URL as you'd see on the Web. That's followed on the second line by the unique identifier, a pseudorandom string that is unique to that file. The fourth line provides the starting timecode address from the source reel, followed by the file's starting timecode address. The fifth line gives the source reel name, and the sixth line completes or closes the entry. Not too scary, huh? AES31 ADL files can be identified by their — you guessed it — “.ADL” extension.

Part 3 also describes the Edit Decision Markup Language (EDML), a very simple “language designed to accommodate the requirements of edit data exchange. A primary design objective is to maximize platform and transmission compatibility and to provide simple and explicit parsing.” Notice how many times the word “simple” is used in the descriptions. Simplicity is a key feature of AES31, as most creatures — including software engineers and their project managers — are pain-adverse. In the world of computer-based products, one basic equation rules: Complexity equals pain. Remember, though, that “simple” is a relative term, and although AES31 is simplified relative to prior exchange methods in many regards, it's no walk in the park. Because there are so many proprietary session formats from products old and new, any solution can't help but be fairly complex.

By this time, you may wonder what happened to Part 2. This portion of the spec identifies a preferred audio file format — the EBU's Broadcast Wave Format (BWF) has been fingered as “suitable for this purpose.” BWAV files, a professional version of the ubiquitous .WAV sound file format used on Win systems, contains additional time stamp and sync info. Multichannel audio is represented as monaural rather than interleaved files. So, a 6-channel mix would be stored as six monaural files. At the time of this writing, the AES hadn't posted this part of the spec, so I assume that there are some last-minute details to work out.

By the way, interleaved files are a holdover from the days when all audio on computers was derived from studies in “computer music.” Those were the days when computers were big, the size of a 'fridge or two, and disk drives were slow and stupid. Anyway, interleaved files take all of the channels and time-domain multiplexes them into one chubby file by slicing each channel up into discrete chunks of time, then assembling the pieces, each in turn, into a serial string. Interleaved files, universally frowned upon these days, make disk transfer easier, but processing individual channels is a pain in the butt.

Much more complicated is Part 4, the effort to “…identify a system, capable of working cross-platform, using object-oriented computer techniques, because they offer much greater flexibility than is possible in a simple list.” Ouch! Though this process began in 1997, it isn't scheduled for completion until 2005, and my guess is even that date is optimistic. A liaison with the rich media-oriented AAF Association was started awhile back to promote audio interchange within the AAF framework to provide some cross-compatibility with AES31. Not surprisingly, recent activity in this area has languished because vested interests are usually stronger than any desire for improved interoperability.

Let's talk about vendor support. Since I last visited this topic, the list has grown considerably. The pioneers at SADiE have long been the champions of AES31, and now the list of participants includes Euphonix, Fairlight, WaveFrame, iZ, Nuendo, Zaxcom, Genex and Akai. AES31 implementation is in process at DAR, Merging Technologies, Studer, Mackie and Tascam.

In all of this, one cannot help but wonder how our little world of pro audio will fit into the much larger context of digital teleproduction and rich-media production as a whole. The AES is working with SMPTE to make AES31 part of a larger production infrastructure, and I applaud both organizations for taking the initiative to make all of our lives easier. Maybe someday, the AES, EBU, ITU, NAB and SMPTE will become one unified body creating harmonious pan-industry standards, but I'm not holding my breath. Until then, go with what works, and AES31 works.

This discussion of AES31 and other tools is all well and good, but the one important onlooker that's invisible — but essential — to these proceedings is Avid and its Digidesign division. Personally, I think AES31 is strong medicine for the session-interchange malaise, and, with vocal support from users like you, it can become an everyday success. I've said it once and I'll say it again: Demand support for AES31 in the products you purchase and use. You may not need it today, but you most likely will tomorrow. AES31 has reached a surprising state of maturity. So, don't stay asleep, wake up and participate!

---

OMas provides professional services to content creators and manufacturers large and small. For links to his previous installment of the AES31 soap opera and other useful arcana relating to this column, visit www.seneschal.net.

Acceptable Use Policy blog comments powered by Disqus