As described in the first part of this two-part series on file-format interchange, the quest for a way to allow digital audio workstations to exchange files has found a partial solution in OMFI (Open Media Framework Interchange). However, nagging issues of dependable operation and OMFI as an unsuitable formal standard have resulted in some important new interchange file formats (and more cryptic names and acronyms with which to impress your friends). In this article, we’ll cover AES31 — the first and only recognized international standard for file interchange from the Audio Engineering Society — the OpenTL initiative from Tascam (www.tascam.com), and the heir apparent to OMFI, the Advanced Authoring Format (AAF).
AES31
Once digital audio workstations became a permanent feature of the pro audio landscape, the Audio Engineering Society began looking into creating a standard for file interchange between systems. The official body charged by the AES with examining the issue and proposing a solution is the AESSC-06-01 Working Group on Audio-File Transfer and Exchange. (See www.aes.org for information.) The audio community needed a format that allowed for reliable project interchange without placing undue difficulties on manufacturers.
The partition of the audio computer world into systems based on Windows, Macintosh and various proprietary operating systems gave birth to multiple disk file systems, audio file formats and as many proprietary EDLs as there are brands of workstation. For this reason, the file format issue for DAWs is really composed of three basic problems: defining an audio file format; defining a disk media format; and defining one or more edit data formats (EDLs or Edit Decision Lists).
The work was divided into four sections, which became the basis of the AES31 Standard: Audio Format, Disk Format, Simple Project Format and Object-Oriented Project Format (subdividing the EDL issue into both simple and object-oriented formats).
The first and second sections of the standard were settled by adopting AES31-1, the Broadcast Wave audio file format (already adopted as a standard by the EBU), and AES31-2, a disk file system that is compatible with the Microsoft FAT32 disk format. In both cases, a document that describes the technical aspects of these formats in detail is available through the AESSC-06-01 committee. These documents provide enough detail to allow software engineers to support a FAT32-compatible disk file system and the Broadcast Wave media format, even on systems not based on the Windows OS.
One advantage of FAT32 is that it is a 32-bit file system that provides access to drives up to 2 terabytes in size. The Broadcast Wave audio media format headers contain important data about the file (metadata), such as a unique media identifier and timecode stamp. Other headers can contain additional information, or even private data, so it is an extensible audio format with a great deal of power and flexibility.
The majority of DAW systems now support FAT32 and Broadcast Wave, so they can also legitimately claim to support these first two components of the AES31 standard. This support means that a user can successfully move a Broadcast Wave audio file from one AES31-1-compliant system to another, and can even move the disk drive containing that audio file from one AES31-2 compliant system to another.
But the real heart of file interchange is moving an edited project with the edits and fades intact from one system to another. A means to achieve this took a bit more work from the committee. The turning point came when Brooks Harris, an engineer with deep experience in EDL management and digital media, submitted a detailed technical proposal to the committee that fulfilled its criteria for simple edit data interchange. With the support of AESSC-06-01 chairman Mark Yonge and input from the members of the committee, details were hammered out and AES31-3, the simple project data-interchange component of AES31, was formally ratified as a standard in June 1999.
This third section of the AES31 standard uses an Audio Decision List (ADL) with several key features. First, it is an ASCII text file, which is extremely important because it allows a human operator to identify an error by looking at the ADL file itself — something that is impossible with the more complex OMFI format. Second, AES31-3 supports sample-accurate timecode stamps through what is called TCF, or Timecode Character Format — an extension to SMPTE timecode that adds sample-count numbers to the usual format of Hours:Minutes:Seconds:Frames.
ADL supports definition of fade-in/out or crossfade amounts, identification of media-source files, and Media File Locators that use a URL to identify the source of a media file. This last point is very important because it provides a means to locate a media file wherever it might live, even if it is on a network rather than local storage. Further extensions and additions to the AES31 format specification are entertained by the committee through the formal but open process used to hammer out AES standards.
Joe Bull, managing director of DAW manufacturer SADiE (www.sadie.com), echoes the sentiments of most DAW manufacturers when he says, “It is vital for our industry to adopt low-cost and practical methods of interchange — commercially aware customers are beginning to demand it. However, practical considerations of billable time suggest that they need a simple, native solution rather than a complex, comprehensive solution that would slow down the whole post-production process.”
The undeniable ease of implementation and reliability of AES31 are beginning to lead to more widespread support in the professional audio community. According to Digby Richards of AV Media (www.avtransferonline.com/index.htm), “For us, OMF is still the most requested format, followed recently by AES-31. We do currently provide AES31 support in AV Transfer.”
Among the many products and companies offering support for AES31 are: Artemis from SADiE, Pyramix from Merging Technologies (www.merging.com), Euphonix AES31 Transfer Station for the R-1 recorder, Nuendo from Steinberg, Logic from Emagic, EDL Convert Pro from Cui Bono-Soft (www.cuibonosoft.com/index.htm), AV Transfer from AV Media (also distributed by Fairlight, www.fairlightesp.com.au, for use with its systems), OMR8 from Digital Audio Research (www.dar.uk.com), DD Series from Akai, Media Magic from Dark Matter Digital (www.darkmatterdigital.com) and others.
Digidesign, the largest DAW maker, has so far decided not to implement the AES31-3 EDL Standard in its Pro Tools system. Product manager Gordon Lyon states, “Digidesign has supported AES level 1 [Broadcast Wave] and level 2 [FAT 32] formats for two years now. Currently, we do not have plans to support AES31 level 3 [EDL format], as we feel it does not add any advantage over the current OMF2 capabilities. The majority of interchange-capable workstations that support AES31 also support the more capable OMF2 format. We feel supporting AES31-3 as well as OMF2 would confuse and defocus interchange.”
OPENTL
Perhaps the most popular of the “open” format initiatives to come from an individual company is the OpenTL (Open Track List) format. When Tascam began distributing the MMR Series digital dubbers made by TimeLine Vista, the manufacturer encountered the confusion of multiple incompatible file formats used in the post-production world. TimeLine’s approach was to implement direct support for several of the most popular formats used in post-production sound editing: Pro Tools, WaveFrame, Akai, Fairlight and OMFI. This strategy proved to be successful and led to the widespread adoption of the Tascam dubbers in the worldwide post community.
As a follow-up, Tascam and TimeLine developed the less-expensive but (in many ways) more powerful MX-2424 hard disk recorder. This time, rather than go the expensive route of providing support for multiple formats, TimeLine engineers decided to publish the internal format of the machine (which is the same as the MM Series dubbers) and make it widely available to anyone who wanted to achieve compatibility with the MX-2424 or MM Series.
The OpenTL toolkit is now managed by Tascam, which has inherited the rights and responsibilities for maintaining the format in the wake of TimeLine’s recent demise. A number of products now claim support for OpenTL, among them Steinberg’s Nuendo, Emagic’s Logic, Tascam’s SX-1 workstation, Merging Technologies’ Pyramix system, Media Magic from Dark Matter Digital, AV Media’s audio-transfer program AV Transfer and EDL Convert Pro from Cui Bono-Soft.
AES31 AND OPENTL: KEEPING IT SIMPLE
According to Ultan Henry from Dark Matter Digital, there are several important reasons for the popularity of both AES31 and OpenTL. “AES31 and OpenTL are both remarkably straightforward to implement,” he says. “Being simple text files, both of these formats are easy to read, write and check. Object-oriented formats like OMF and AAF are many times more difficult to handle efficiently and reliably. With both of these formats, the content of files can vary dramatically from one application to another. This makes implementation and testing many times more complex.”
Ultan’s comments are supported by Digby Richards of AV Media. He gives the following list of reasons why AES-31 and OpenTL are generally very easy to implement:
They are text formats, which allow a developer to examine/edit the generated file with any text editor. They are “simple” formats, meaning that they don’t allow you to put everything including the kitchen sink into the file; but AES-31 and OpenTL do allow you to describe an audio EDL, with some parameters (e.g., clip levels, etc). The EDL file never contains media; the audio is always contained in external “well-understood files,” such as BWF or .WAV. The syntax of these formats is well-specified. The syntax/semantics of the format do not encourage interpretation; i.e., there is only one way to put a source clip into an EDL. The manufacturers concerned are talking to each other to iron out minor compatibility issues.
He concludes by commenting on the trade-offs involved: “With AES31 and OpenTL, one sacrifices flexibility [can’t easily add new functionality] for increased compatibility [meaning, it’s more difficult to get it wrong].”
OpenTL is also being used in networked audio-file transfers. According to Jim Bailey, Tascam’s production products manager, “Tascam has an application in testing that uses Rocket Network to translate between their protocol and OpenTL. The advantage is that other systems such as Logic and SADiE can then use Rocket Network to exchange projects, taking advantage of Rocket’s compression [as needed], translation and dynamic EDL updating.”
ADVANCED AUTHORING FORMAT
Growing out of a multimedia task force originally put together by Microsoft, the Advanced Authoring Format (AAF) is a major undertaking to develop a comprehensive interchange format for every type of digital media data, including audio, video, text, graphics and various other types of media objects. The business of AAF is now conducted through the AAF Association. Founding members of the AAF association are Avid, the BBC, CNN, Discreet, Liberty Media, Matrox, Microsoft, Pinnacle, Quantel, Sony, Turner Entertainment Networks and the U.S. National Imaging and Mapping Agency. Clearly, this is an effort on a different scale from the simple audio media and EDL interchange efforts represented by AES31 and OpenTL. The scope of AAF is so vast that we’ll just scratch the surface here and make a few points about how it may end up affecting the pro audio community. More information is available at www.aafassociation.org.
According to the Association, AAF builds substantially upon the original capabilities of OMFI. This is a simplified explanation, but it largely takes the object model from OMFI and combines it with Microsoft’s Structured Storage container format rather than the Apple Bento format used in OMFI. Microsoft Structured Storage is the same basic container format used by Microsoft to store Word, Excel and other Microsoft Office documents. The presence of so many broadcast and digital video companies in the AAF Association is a good indication of the principal focus of AAF: to be a “Super EDL” for the complex content used in video and broadcast media production (which, of course, includes audio). The heritage of OMFI within AAF is strong, 95% of the AAF Software Development Kit (SDK) has been written by Avid.
So far, many in the pro audio community are taking a wait-and-see attitude toward AAF. Henry of Dark Matter Digital says, “At the moment, I would be reluctant to commit engineering effort to supporting AAF until it is at least more widely used on Avid products.”
According to Joe Bull of SADiE, “When the dust has finally settled, SADiE may decide to implement AAF, although it has yet to be widely adopted in the audio community. Many audio facilities cannot afford the luxury of paying for the perfect interchange of graphics files, etc., while only delivering limited audio interchange.” Chief software engineer Dominique Brulhart of Merging Technologies adds, “AAF could be added easily as a new plug-in for Pyramix if the demand is serious, but this is not the case for now — not a single request so far.”
One company that has voiced support for AAF as a future direction is Digidesign, a division of Avid Technology. Digidesign product manager Gordon Lyon said, “We have long been strong promoters of ‘OMF till AAF.’ Digidesign and Avid have been deeply invested in interchange for longer than any other media workstation company, and we feel strongly about the ability of the new open AAF standard to make interchange standards independent and robust.” Gordon also lists several points about how Digidesign views the advantages of AAF and how it sees the future there: “AAF is not controlled by a single company but by the AAF members, allowing equal contribution. AAF is open-source, allowing anyone to contribute all the way down to the source code level.”
Digby Richards of AV Media points to some of the similarities with OMFI and some of the potential upsides to how the format is being handled: “The AAF SDK has remarkable similarities to the OMFI SDK. There are a lot of similar terms, such as master mobs, source mobs, etc. Adding AAF functionality to an application is relatively easy; it’s the verification phase that is difficult. We are still at the ‘adding AAF’ stage with AV Transfer, so I can’t yet tell you how it went. We expect to have learned somewhat from our experience with OMFI. We do expect to see variation in AAF files. One thing I think is great is that AAF is truly open-source, and there are discussion forums available so that manufacturers and developers like ourselves can talk to other third-party developers.”
CONVERGENCE OF AES31 AND AAF?
Recognizing the usefulness of a more sophisticated, object-oriented format for complex interchange, the AESSC-06-01 committee has reserved the last section of the AES31 specification, AES31-4, for an object-oriented format. Although this last section has not yet been ratified or formally submitted for ratification, it is widely expected that AAF will be the prime candidate to fill this role. Toward that end, discussions between the AESSC-06-01 committee and the AAF Association have begun. It remains to be seen how quickly AAF or something like it makes it into AES31 as the final part of the specification. It is expected that when this happens, there will be tools from some of the companies that are focused on digital-format translation to move projects between the AES31-3 and AES31-4 formats. As AAF becomes an adopted format in the digital video and broadcast world, there will clearly be an impetus for some of the audio DAW manufacturers to pay attention and add this format to their arsenal.
Whether proponents of AAF can avoid the difficulties and fragility many have experienced with OMFI remains to be seen. With so many major media companies signed on, there is reason to hope that the community of such high-powered users will not long abide a file-interchange format unless it lives up to its promise and provides robust and trustworthy service.
Ron Franklin is president of Atira Media, a multimedia production company in San Diego, Calif., and Ron Franklin Associates, a digital media and marketing consulting company. Visitwww.ronfranklin.netfor more.
MXF
Originated by the Pro-MPEG forum to handle digital-file exchange, the Material Exchange Format (MXF) is applicable to different audio and video-compression schemes used in the digital broadcast industry. An MXF file serves as a data wrapper that can contain any type of audio or video material in a playable format.
Although audio is a necessary component of MXF, it is initially oriented toward broadcast video production, and its data structure is based on existing SMPTE standards for metadata coding. MXF is now supported by other groups, including the AAF Association and the G-Fors (Generic Format for Storage) project of the European Information Society Technologies Program. It can be viewed as a subset of AAF, and it is expected that any AAF-compliant system will be able to read and write MXF files.
A massive undertaking with a 180-page spec (and more sections yet to come), the scope of MXF is comprehensive, offering solutions for key issues in the larger world of video and broadcast production, such as: retaining metadata regardless of the type of data compression (if any) used; library and archival application;, access/use of files before a file transfer is completed; and support for partial file transfers (moving a section of a file without transferring the entire project).
MXF is being submitted to the Society of Motion Picture and Television Engineers for consideration as a standard. In the minds of many, this is a key step to bring file-format interchange technology out of the control of an individual company or consortium and into universal recognition as an ISO standard.
The effort is gaining momentum in the larger broadcast/post-production communities. At least 16 companies — including Avid, JVC Pro, Leitch, Matrox, Sony and Snell & Wilcox — have committed to using MXF in future products, perhaps with some as soon as the end of this year.
MXF’s complexities and full details are complex and beyond this article’s scope, but sites such as www.pro-mpeg.org offer useful material for further studies.
— Ron Franklin
