Deck2OMF

Introduction

Deck2OMF is a tool for converting BIAS Deck® project files to a format compatible with OMF® 2.x, along with a suite of tools for analyzing binary file formats and converting them into a more useful format. It includes the following functionality:

Background

The primary purpose of Deck2OMF was to be able to translate Deck projects into a form that could be read by OMF-compatible audio editing platforms such as Digital Performer, Pro Tools, or Logic. Deck (at least in 3.5) lacked OMF export functionality, meaning that you could bring projects into Deck, but could never pull them back out. Hence, the Deck2OMF suite was created.

The binary diff tool is an obvious mechanism for comparing two versions of a binary file. For well-designed binary files, this works well, as you can make a change and see exactly what changed.

The problem, at least in Deck's case, was that the sheer volume of changes exceeded my ability to cope, and even resaving the same file would result in changes. It quickly became obvious that raw pointers were being used as cross-references. Unless you were looking for changes to these pointers, those changes were quite irrelevant. Clearly, another tool was needed to make it easier to ignore them. The most obvious mechanism was a three-way diff tool.

The concept of tridiff is simple. Take a file and make a copy of it with Finder. Call this "orig". Open the file, make a change, and save it. Quit the application. Duplicate the file, call this "changed". Open that file again. Save the file without making changes (making a trivial change and then reversing the change if necessary). Quit the app and duplicate the resulting file as "resaved". Now, do a "tridiff orig changed resaved".

Assuming a reasonable degree of randomness, the pointers are likely to be different in all three files (or mostly so). Unchanged data should be the same in all three. Thus, the real changes tend to stand out. The basic algorithm is that a difference is only flagged as a change if two of the files contain one value and the remaining file contains a different value. Sometimes this gives false positives (since order isn't considered), but this eliminates enough of the fake changes to make comparison practical.

The last binary analysis tool is bindump. Towards the end of analyzing a binary format, once you have a basic understanding of the structure itself, it often becomes convenient to be able to stare at the raw data file without comparing it to any other file.

In addition to these tools, the Deck2OMF suite includes one tool for analyzing the contents of OMF files. Sadly, Avid's OMF debugging tools are somewhat lacking. A number of semantic analysis errors (in OMF 2.0, which their debug tools were compiled against) generate no useful error messages beyond "Cannot open file". And heaven forbid you should need useful information about what's wrong with a Bento-compatible container.

Thus, yet another tool was needed for figuring out what was going on. The result was bentodump, a tool for dumping Bento-compatible TOCs. This was used to figure out what mechanisms for fader automation were supported by Digital Performer, to figure out the TOC object and cross-reference object formats used in the Bento container format (which, though quite trivial, aren't fully specified in the 1.0d5 spec), and generally to do about 90% of the OMF debugging.

The bentodump tool attempts to cross-reference types and properties, but otherwise largely amounts to printing a human-readable string for each of the TOC control bytes and printing hex, decimal, float, and string forms of the data that the TOC points to (and/or includes). As such, it is immune to many problems that one would occur if you tried to read a file containing a malformed Bento container using the real Bento libraries.

But What About Deck?

Of course the whole point of the suite was to analyze the Deck file format and write a tool to convert to OMF. Because of quirks in certain OMF importers, there are a few options:

--debug
enable lots of debugging output.
--dp_interpolation_workaround
Digital Performer (at least in 4.12) doesn't handle constant interpolation in effects. The result is that pan and fader automation will change linearly, often over long multi-second periods when they should suddenly change. This flag causes an extra point to be inserted one sample prior to any existing point unless there's already a point there, with the same value as the point prior to that one. It's gross, but it can't hurt anything. If you see weird behavior on pan and fader automation, enable this.
--fades_as_regions
In an ideal world, an audio app shouldn't rebuild crossfades if a final rendering already exists on disk and is referenced from the effect in the OMF file. However, Digital Performer (at least in 4.12) rebuilds them every time. Because OMF doesn't readily support the fade types that Deck supports, the only good workaround is to insert the Deck-generated audio region instead of the fade. This option does exactly that.
--omit_automation
This hasn't been tested in many weeks, but in theory, should produce a file without any automation information. Apparently some programs (Final Cut in particular) can't handle automation data.

In theory, the OMF files generated by this tool should be readable by any application with either OMF 2.0 or OMF 2.1 support. However, it has only been tested with Digital Performer, and while I wouldn't mind accepting patches to add support for other applications, I don't have time to write them myself... unless, of course, the manufacturer of another application wants to give me a free copy, in which case, I'll see what I can do. :-)

Where do I Get It?

You can download the suite as a source tarball from the project area at SourceForge.

You can also read the HeaderDoc content for the libraries here.

License

This software is provided AS-IS with NO WARRANTY. It is donation-ware, licensed under the GNU General Public License version 2. If you like the software, please consider donating $20 to one of the following organizations:

(They need all the help they can get.)

Disclaimers, Thanks, and Other Legal Crap

BIAS and Deck are trademarks or registered trademarks of BIAS (Berkley Integrated Audio Systems), Inc. OMF is a registered trademark of Avid. Bento, Logic, and Final Cut Pro are trademarks or registered trademarks of Apple Computer, Inc. Digital Performer is a registered trademark of MOTU (Mark of the Unicorn), Inc. Use of these marks is intended to represent file format compatibility. These tools do not represent the owners of those marks in any way, and no representation of their support is implied in any way.

Deck2OMF does not include any source code derived from reverse engineering of any application or library. All code was developed based upon published specifications and/or trivial examination of data files. Deck2OMF is not based on the Avid OMF Toolkit, Apple Bento, or BIAS Deck in any way. It merely supports their file formats.

Special thanks to Avid for never returning emails requesting a copy of the "freely-available" OMF toolkit, thus resulting in the need to write the partially-implemented abomination that is Otneb. :-)

Special thanks to MOTU for at least scratching their heads over my bug reports, and to BIAS for creating a file format whose data structures are so very nearly self-describing.

Powered by SourceForge.net Logo.