In the early days of digital audio workstations, the industry was captivated by the new-found power and flexibility of these digital wonders. We were so amazed by all of the cool things we could do that we didn’t notice minor irritations, such as why my Studer Dyaxis system couldn’t share a drive or swap files with someone else’s NED Post Pro.
However, as DAWs became more ubiquitous, the problem of moving a project from one workstation or facility to another started to loom as a real barrier to effective workflow. Why not just patch my output to your input? Obviously, that could transfer the audio tracks, but in the process, edit data and source information would be lost — an unacceptable situation in editing-intensive areas such as audio post and music production.
Standards organizations such as AES and SMPTE were aware that the issue existed, but by nature, they moved slowly. Eventually, a workstation manufacturer made the first serious attempt to move us out of this tower of digital babble. Avid Technology introduced the concept called Open-Media Framework Interchange (OMFI) in 1992 to facilitate moving complex audio/video media and edit data between workstations. The very first public presentation of OMFI to the professional audio community came at the 1992 SPARS workstation “shoot-out” at Hollywood’s Beverly Garland Hotel. The presentation by Avid’s Mack Leathurby was met with a cautious and somewhat suspect reception. After all, sage audiophiles reasoned, what does a company that makes nonlinear video-editing systems know about audio?
As it turns out, the problem involved not so much audio, per se, but the matter of creating an extensible data model for digital files that would allow a complete representation of which media was used and how the media pieces related to each other in time, encoding various parameters associated with the media. Computer-based editing systems did not have the same concerns as analog — or even digital — tape machines. PCs don’t care about settings such as nanoWebers per meter (the measure of tape fluxivity) — everything is simply data. With a linear medium (tape), the relationships among recorded elements are bound together by the linear medium itself. With the computer, the organization of elements is completely dependent on an internal database that describes the relationships. Every element that appears in the timeline of an Edit Decision List (EDL) must be meticulously tracked in the computer filing system, along with important parameters attached to those elements, such as fades, clip levels, timecode stamp, source origin of each element and many others.
To be truly future-proof, the model needed to be extensible so that new data types and parameters could be added over time without breaking previous implementations. Therefore, the types of classic EDLs used by linear video editors from CMX, Grass Valley, Sony and others were insufficient to deal with nonlinear computer-based editors. Rather than an ASCI text-based list that made each of the EDL parameters explicit, Avid’s OMFI used an object-oriented approach with multiple levels of indirection and “nested” relationships. This makes it incredibly powerful and extensible, but also incredibly slippery and subject to multiple interpretations and implementations. Therein lie both the blessing and the curse of OMFI.
Now, 10 years into the life of OMFI, let’s examine what works (and what doesn’t) and try to gauge where this attempt at forging a file-system Esperanto is heading. To provide accurate accounts of some of the issues that exist with OMFI, I spoke directly to OMFI software engineers and users — folks in the trenches who grapple with these issues directly.
WHY ISN’T OMFI A “STANDARD”?
If OMFI provides a way to move material between workstations of different manufacturers, then why hasn’t it been adopted as a standard by organizations like AES or SMPTE? This hasn’t happened for several reasons, but a big one has to do with a key component of OMFI. The OMFI data structure uses a “container format” called Bento, which is the intellectual property of Apple Computer, a company that has never been keen on letting such intellectual property be placed in the public domain for use in a standard. This was a major stumbling block when OMFI was investigated as a candidate for the basis of an AES file-format interchange standard in the mid-1990s. Standards must be based on intellectual work that can be described completely in the standard and used by anyone. Apple would not allow Bento to be included in this way in a standard, thus eliminating OMFI as a candidate for the AES. The eventual evolution of the current AES31 standard for file-format interchange will be discussed in part two of this article, along with AAF and OpenTL.
FLAVORS OF OMFI
The import/export of OMFI projects requires a good deal of software development by the DAW manufacturer to translate the workstation’s native format (every DAW has a unique native format) into an OMFI composition. Some systems only do this one way (e.g., import only), because a separate and serious software effort is required to implement either import or export.
The next issue that DAW manufacturers and users must contend with is determining what “flavor” of OMFI is supported: OMFI 1 or OMFI 2. The original OMFI was hammered out by Avid engineers and then refined through a number of annual conferences. These were sponsored by the OMF Developer’s Desk and were open to interested parties from the video and audio communities they served. From these meetings, it became clear that certain aspects of the original approach needed improvement, so in 1996, OMFI went through a major change resulting in OMFI 2. The earlier work was then referred to as OMFI 1.
Brooks Harris, of Brooks Harris Film and Tape, has created software for OMFI translation in his own EDL Max program (www.edlmax.com) and OMFI Developers Toolkit, as well as for other workstation systems, including Sony’s XPRI editor. “OMFI 1 and OMFI 2 are different enough to be considered separate formats from the developer’s point of view,” Harris explains. “Many of the data structures [classes] are similar, but there are important differences that make them incompatible. OMFI 2 introduced several data-type changes and additions, including an updated Bento container format. The most difficult difference between OMFI 1 and OMFI 2 is that the syntax with which the structures are linked together is different. This requires a program to select between two very different logical flows to contend with both formats.”
Of course, this can create real-world issues for users who are offered a choice of using OMFI 1 or OMFI 2 for import/export. It’s important to know the capabilities of the target system before creating the OMFI file in order to be sure that file can be imported properly. David “Digby” Richards is principal engineer for AV Media, a company offering a file-translation utility called AV transfer (www.avtransferonline.com). “The early OMFI-enabled applications written to work with OMFI Version 1 cannot read or write OMFI Version 2,” Richards notes. “And, as many manufacturers concentrate only on OMFI Version 2, they cannot read or write OMFI Version 1 files.”
THE OMFI TOOLKIT BLUES
Most software engineers who spend time huddled over a hot computer implementing OMFI code for a DAW will give you an earful on toolkit issues. When Avid’s OMFI group released OMFI to developers, they included a suite of software tools — the OMFI Toolkit — to facilitate implementing OMFI support in workstations. However, even the most recent revisions of the Toolkit have some issues and gotchas. Additionally, some DAWs implement certain functions in ways that conflict with how other workstations have approached the same issues, leaving a minefield for the unwary engineer trying to produce a robust OMFI implementation.
“As supplied by Avid, the OMFI Toolkit is both a blessing and a curse for developers. In many respects, it is brilliant and ambitious, but it succumbs to its own complexity,” says Harris. “It is intended to provide a cross-platform development environment to simplify OMFI development, and in some respects, it accomplishes this. But nobody expects code of this complexity to be bug-free, and it is not. With so many target development environments and platforms, together with the complexity of edit projects, expressed as OMFI, bugs can, and do, appear unexpectedly. These include memory leaks, memory damage, run-away recursion, stack overflows, incorrect calculations — you name it.”
Ultan Henry of Dark Matter Digital (www.darkmatterdigital.com) is an engineer with wide experience implementing OMFI utilities for Akai and for Dark Matter’s own Media Magic program. “I’ve found the problem with the toolkit is not due so much to ‘bugs,’ but the fact that many of the higher-level routines cannot be used to read or write ‘real-world’ OMFI files,” he says. “Although these high-level routines do actually conform to the OMFI specification, they are not sufficient to handle the way in which OMFI has evolved and the manner in which the individual elements of OMFI are now being used. This is why I believe that the expandability of OMFI has been one of its weaknesses.”
The result? Most engineers use the Toolkit as a starting point but add considerable work on their own to create import/export routines used in their programs. This can lead to variations in the ability of a given implementation to work with files made by another system.
Another engineer with considerable OMFI experience is Bill Claghorn of Diaquest (www.diaquest.com), who created the OMFI import/export routines for the WaveFrame DAW. “The real problem is that OMFI importers expect a very restricted and specific OMFI implementation. An export must be targeted to the expectations of the destination system. Conversely, every new version of every system exports OMFI differently,” Claghorn explains. “Because OMFI is like a Tinker toy™ connection between software objects, there are many combinations of ways to assemble something. For example, some systems attach gain to a clip. Other systems attach gain to a sound. Some systems even have many layers between a clip and a sound file with effects in between. Handling all of this is rather complicated.”
Claghorn goes on to say that “a proper OMFI implementation will handle the flexibility of various interpretations on import and also handle the specific requirements for those particular targets on export. It’s impossible to put a programmer in a closed room with the OMFI Toolkit and expect an import/export to work with other systems. There are just too many undefined relationships in the Toolkit.”
The great variability of OMFI files has even produced the ultimate absurdity in a few isolated cases, with certain workstations seemingly incapable of importing some of their own exported OMFI files! Occasionally, even a manufacturer’s own software quality-assurance department has a hard time with OMFI.
USING OMFI IN THE REAL WORLD
Lest I be accused of inventing bogeymen where none exist, OMFI is used successfully every day in many facilities. The key seems to be identifying the particular details of how the export file should be created so that it will match the capabilities of the system that will be used to import the file. To avoid some of the potential problems, experienced sound supervisors at facilities that use OMFI on a regular basis have come up with detailed procedures for engineers and editors to follow.
One rule of thumb: Find a method that seems to work and don’t deviate from it — in fact, make it into an exact formula and put it in writing. A casual Internet search at www.google.com turned up examples of this from various facilities. Here’s how some facilities formalize their OMFI procedures:
- Media City Sound (Studio City, Calif.) — click on the item labeled “OMFI Info”: www.mcsound.com.
- Audio Post and Picture (Burbank, Calif.) — visit their OMFI page: www.audiopostpicture.com/omf.html.
- Los Angeles Final Cut Pro Users Group — check out instructions on getting from FCP to Pro Tools using OMFI: www.lafcpug.org/basic_omf_export.html.
I received some enlightening comments on using OMFI in the real world of feature film sound editorial from a sound supervisor at a major Hollywood film studio (who asked to remain anonymous to avoid the attention of the megaconglomerate’s nervous corporate lawyers). “OMFI has met with mixed success in feature editorial. The degree of success usually depends on coordinating the process with picture editorial in advance of turnover to sound editorial.”
One practical decision to be made when creating OMFI export files is the choice of using encapsulated media and composition, or a composition referencing separate external media files. With encapsulated OMFI, one large file is generated that contains all of the OMFI media files (the “ingredients”) together, as well as the OMFI composition (the “recipe”). Here, a composition referencing external media is a collection of files with all of their attendant path names and file organization. Each has its advantages and disadvantages, but they are mutually exclusive in implementation — if you make an encapsulated export and bring it to a workstation that only supports OMFI compositions with externally referenced media, it won’t work.
The Hollywood sound supervisor noted how this issue comes into play: “If we plan to go with OMFI during post, and we are confident that original dailies have been loaded, there are definite procedures that must be followed to ensure success. We have a procedure written out that we give to the picture assistant for exporting the OMFI list. Its highlights include exporting with media and making the handles as long as possible. We definitely do not use the export option of consolidating media, as that gives just one long audio file containing all of the takes. It’s impossible to retrieve anything specific from that option.”
One of the issues of real concern to working editors is the fact that the names of audio media files at the system level use a unique file ID scheme that can be confusing when trying to locate a sound. The Hollywood sound supervisor points out that “even with proper loading of dailies and a successful export, there are still pitfalls in the process. One of the main ones is that the OMFI process changes all of the file names to a computer-literate, user-irritant, hexadecimal scheme. Want to get an alternate take for scene 21, take 5? While the original file-naming procedure might show this file as ‘21/5,’ the OMFI export process might call this ‘Audio_01 8903658FHJKLIOUYDDN’ or some such nonsense that a human can’t possibly interpret as ‘21/5.’ So, we go back to the dailies for that alt take. Even if it might already be loaded, you’d never find it unless it appeared in the region names list. To make matters worse, when — not if — there are picture changes, an additional OMFI export will name the same takes completely differently, so the dialog editor would not be able to reference the original files and would be back to square one with the edit. For us, this makes OMFI useful only for the first export from picture. All changes after that must be done from change notes. Or, more commonly from the tried-and- true cut-and-drag-’em-till-the-waveforms-line-up method.”
HOW MANY BITS DO WE NEED?
Another issue mentioned by sound editors and software engineers alike is the fact that the standard OMFI Toolkit only deals with 16-bit audio files. In the early ’90s, when OMFI was formulated, that certainly was not a problem, but these days, most every device in the signal chain is capable of dealing with 24-bit audio, so this seems a bit of a limitation. Again, from our Hollywood sound supervisor: “Another common OMFI problem is the bit depth of the audio files. Avid is only capable of using 16-bit files, so if the sessions are to be 24-bit — desirable if the dailies are quality analog or high-definition digital — then OMFI is out of the question.”
AV Media’s David “Digby” Richards points this out, as well: “The biggest item missing from the OMFI Toolkit [as far as audio is concerned] is the inability to read and write 24-bit. There is no reason OMFI files cannot contain 24-bit audio, and about two lines of code added to the OMFI Toolkit fixes this up pretty quick. Our AV Transfer software can read and write 24-bit OMFI files.”
DEGREE OF INDUSTRY SUPPORT
Though OMFI support is by no means universal in the DAW industry, most of the significant players, especially those with a market share in audio post, support some form of OMFI interchange. Market leader Digidesign intends to offer continued OMFI support. According to Digi’s product manager Gordon Lyon, “OMFI is currently our main avenue for file and session interchange with Avid and third-party systems. It is realistic to assume that with OMFI being the established standard for interchange between Pro Tools, Avid, SoftImage and third-party products, Digidesign will continue to broaden support for OMFI going forward, including with our OS X migration. However, we anticipate that the most enhanced functionality in the future will come with integration and further development of AAF interchange.”
THE FUTURE OF OMFI
Do we still need a means for exchanging digital files between different proprietary systems? The obvious answer is that as long as there are indeed different proprietary DAW systems in use at production facilities around the world, we will always need a way to do file-format interchange. Even though the workstation market has fewer players these days, there are still enough different systems to make this a necessity.
The follow-up question is, are there better ways to do this than OMFI? Given some of the problems and issues mentioned in this article, this is a very legitimate question. Until all workstations are made by the same company (not going to happen), the need will be there, and it isn’t going away.
Based on interviews with OMFI engineers and users, OMFI — despite its complexities and dangers — still provides a useful means to move complex edited material between DAWs. The watchwords seem to be verify and codify — that is, for most reliable results, find an exact method that allows material to be reliably moved between specific systems for a specific purpose, and then write it up as a set of procedures to be followed precisely. Don’t expect OMFI to just automatically work between two different systems the first time. Test it first to find the gotchas and work-arounds ahead of time, and you will minimize the risk of failing to interchange when the deadline (and the client) are looming.
What’s next for OMFI? In a nutshell, it’s here to stay, but it has no future. As one indication of how far off the plate OMFI has fallen at Avid is the fact that the formerly working link to the OMFI Website at www.omfi.org now goes to a “404 error — not found” page on the Avid Website. The fact is, OMFI has no future as an ongoing, living project. There will be no further development of OMFI — no bug fixes, no extensions, no OMFI Version 3. This hardly means that the effort to have a working interchange technology for digital media is dead — it has simply grown beyond OMFI.
In the past few years, a new effort to expand the scope of what can be accomplished with complex, object-oriented file interchange has been taken up by a consortium of companies (including Avid, Microsoft and others) through an initiative called the Advanced Authoring Format. So there is a way forward, and that is part of the story for an upcoming issue. OMFI is dead — long live file-format interchange!
Ron Franklin, the president of Ron Franklin Associates (a digital media and marketing consulting company), has worked for more DAW manufacturers than he cares to admit and did a stint as a Hollywood sound editor in the early years of DAWs. His real passion these days is guitar, songwriting and performing. His home on the Web is atwww.ronfranklin.net.
