OMF Translation?

[The Audio Cave]

Below are two links to two OMF 2.0 files. I started with a single small drum clip and placed it on different tracks and did some things like panning, volume, muting, clip automation etc. across the different tracks. At the very least it should play as a seamless drum track.

The weird thing is the panning and mutes didn't even translate back to Cubase from the file it created. The sample OMF files I downloaded from Automatic Duck brought pans in with them. The clip automation on the files I exported and then imported translated (but wrong) and the real automation didn't translate at all, but the segment fades translated into edited files with the fades.

If anyone can import these into various daws and report back I'd be curious to see how they translate. They're very small downloads. Reaper, PTLE, whatever.

www.theaudiocave.com/OMF_Test.zip is the OMF file and the clips in seperate folders in a zip archive. 739kb.

www.theaudiocave.com/OMF_Test_single_file.omf is the same session in an OMF single file. 1.05mb

The attached clip shows what it -should- be doing with proper translation. I'm curious how much of this will translate to HD or LE... or the others.

Here's a link to a short mix mp3 which reflects what it was really doing and when, automation, mutes, fades in and out. 668kb

 

[RezN8]

Very interesting. I had these issues with Cubase VST (before SX3). Sometimes exporting with the Real time option fixed it but not always. It was VERY frustrating to say the least.


Which version are you running?

 

[The Audio Cave]

SX3, but the "export" I'm talking about with *.omf files is different from a normal mix export.

The *.omf file gathers data about the project (or is supposed to) to import it into another daw, keeping the pans, levels and automation. I'm trying to use that for achiving instead of importing into PTLE.

 

[dgatwood]

The OMF music is anything but usable, IMHO. It is very poorly designed for typical DAW use. The way that plug-ins are added, for example, is heinous. You create this container object for the plug-in and enclose the audio clip inside that. If they span clips, you have to do a container over the entire track and then a container around that for each plug-in or something... I've forgotten the details, but it's horrible.

The math for automation is also horrid. They require you to have a sample rate, but instead of sanely measuring the automation times in terms of samples, they're all represented as a pair of numbers that represent a fraction of the distance from the start of a clip to the end. Of course, lazy people like me will always make the denominator the number of samples and the numerator the sample position, but reading back data, you have to be able to handle whatever asshat scheme somebody else came up with.

The crossfade types are linear or "none"---there is no support for any audio taper crossfades, which makes the format damn near useless unless you calculate the crossfades yourself and shove in the rendered audio instead of the crossfade.

And don't get me started on the inconsistent support for different interpolation types for automation data. What an unbelievable mess!

And so on. Basically, the format is a perfect example of why Avid should never be allowed to design a portable format, and its successor, AAF, is based on the same, horrible, broken data model. There's not enough crack in the world to provide an excuse for the OMF file format.

That said, if you'd like to see in painful detail what's in an OMF file, you can take a look at bentodump, part of the Deck2OMF suite. If your bento container is little endian, it might not work. I'm not sure. And I haven't tried it on a little endian CPU, so it might not work there, either. I'm not sure. I think it will work with a LE file on a LE CPU or a BE file on a BE CPU, but not cross-endian. I don't have any samples of LE OMF files to work with. Either way, if you try it and it throws up its hands, send me the file and I'll fix the code.