exported from Nuendo, contains a one bar drumloop, if imported correctly the clips should line up in a "zig zag" manner in three stereo tracks starting at 5fps and play back seamlessly (clip fade ins/outs should be audible in the "with clip volume and fades" OMFs), Project settings: 25fps, 44,1 kHz.

The OMF2 files look similar to the ones plush2 provided (thanks again!), but the OMF1 ones seem to have a different TOC format. I will most likely get only OMF2 working, at least for now.

At the moment I'm able to transform that OMF binary gibberish into readable information, next step is figuring out what all these objects and properties actually do - it's not that hard since the names are quite self-explaining, but there are hundreds to thousands of objects in one file so I need to know what _every_ _single_ _one_ does.

The OMF2 files look similar to the ones plush2 provided (thanks again!), but the OMF1 ones seem to have a different TOC format. I will most likely get only OMF2 working, at least for now.

At the moment I'm able to transform that OMF binary gibberish into readable information, next step is figuring out what all these objects and properties actually do - it's not that hard since the names are quite self-explaining, but there are hundreds to thousands of objects in one file so I need to know what _every_ _single_ _one_ does.

I'll keep you posted!

Your post sounds very interesting, however I don't quite get it (maybe I've missed something). Are you working on a Reaper extension for OMF support?
That would be amazing!

Regarding OMF1-OMF2,
afaik the only difference is that OMF2 can additionally contain clip-based fade ins/outs and volume information. So I think OMF2 support would be totally fine (OMF1 seems redundant to me, or are there DAWs that can only work with OMF1, not sure...)

Regarding OMF1-OMF2,
afaik the only difference is that OMF2 can additionally contain clip-based fade ins/outs and volume information. So I think OMF2 support would be totally fine (OMF1 seems redundant to me, or are there DAWs that can only work with OMF1, not sure...)

Actually there are quite a lot of differences between OMF 1&2 plus unfortunately between different DAW's ideas/implementations of what an OMF is.
It is, not surprisingly, very video orientated.Eg a real minefield is the different ideas in use as to how to reconcile frame based as against sample time references.
A handy resource on this IMO is the ProConvert manualhttp://www.solid-state-logic.com/sup...umentation.asp

At the moment it works like this: I've written a small app that converts OMF files into a SQLite database which can be opened with Reaper afterwards. The converter is still Linux-only because it makes heavy use of POSIX-specific stuff like memory mapping but I'm going to set up MinGW or something to create a Windows executable that'll be launched automatically from within Reaper so everything works seamlessly.

Looks like I have to re-write the converter almost from scratch if I want to make it a single Extension DLL without additional files but that's actually a good way to get rid of the last pieces of the GPL code I based it on.

The import plugin still needs some fine-tuning, the volume values don't look right (could anyone open the sample files in another host and report the right values?) and I have no idea yet how panning information is stored. I'm not going to implement OMF1 since it's way too different from OMF2 and I also haven't had much success regarding endianness conversion - I don't think it's important anyway.

The big question is, do we need OMF export? OMF is a legacy format and we're already able to export projects to other hosts using stem rendering, so I doubt it's worth the work. Maybe AAF export makes more sense.

Please re-check in your host if the fade types really translate back into the original, I'm sure OMF handles only a small subset of fade types.

The panning pretty much looks like the one i send. Except i had overlapping fades like the ones in the screenshot you posted from my OMF. But the fades in my example where all the same.

I work in postproduction as well and the audiocapabilities of AVID are not very good. With this i would be able to get a timeline into Reaper and finish the audio there. I then could export it as a wav and import it into AVID. For my uses i wouldnt really need an OMF-export utility for Reaper, just the import would be suffice. I also could live with just one crossfade shape into Reaper. Usually thats the kind of stuff i want to tweak in a DAW anyway...

Oh, and this is really amazing that you got it this far!!!!!!!!!!!
I could use it pretty well this way so imagine when you get it all right.

also, is OMF a pro tools thing too? because I'd want to see pro tools import before anything else.

Yes effectively, Avid designed OMF & then had to work quite hard to make PT OMF aware, when they bought digidesign. This was/is quite tricky because for Eg Avid use a Clip based concept as makes sense in a post pro environment & digi for some crazy reason do stuff like level, pan, eq & automation with Ref to the timeline - just like old style linear 2" tape based automation systems.

Quote:

Originally Posted by pixeltarian

how was SSL able to make a converter? did they work out a deal with digi? can any company make file conversion software? .ptf support would be #1 on my list if it was possible...

A very good & interesting question, my guess is that SSL worked it out for themselves, I can't see Avid wanting such a thing to happen.
John L

First import worked on an embedded OMF2 exported from Avid DV Xpress 4.6.

Six tracks, 5:38 in length, not all full of audio. Some videos that were extracted but not placed on the timeline.

I've already told you about the memory leak. It wasted exorbitant amounts of memory in this conversion, which amounted to 650-700 MB for a 161 MB OMF.

Suggestions:

Ask user to specify target directory for creation of new project and copies of embedded files. Right now it extracts them where the OMF is, which further slows down the process.

Attach proper extensions to the filenames of the audio.

Let the user pick, which tracks get converted. The given track names are all that's needed. The users can make the decision based on information like that. Avid tracks are usually named A1...Ax for audio and V1...Vx for video tracks.

Pan Odd/Even tracks in the converted project. We should request that Reaper can build a stereo item from two mono items too. That'll further improve handling of OMF (and AAF) imports.

I then added your reaper_omf.dll (the latest beta2 version) to REAPER's Plugins folder. Upon opening REAPER I went directly to File|Open Project menu and was greeted by the new OMF format from the dropdown menu and OMF files were now identified as being compatible with REAPER. Woohoo!

I selected the OMF2 file that I had previously created from SONAR and REAPER proceeded to convert it which took a couple minutes. Then lo and behold the project files opened in REAPER just as they were previously in SONAR 8 (keeping all track & clip positions)along with all the track & media files being properly named as well. One media clip even had the proper clip fade which I guess SONAR treated as a destructive edit during the OMF export process, but it faded out properly nonetheless once in REAPER.

This a a great start and I applaud the efforts. I think once you can add the volume & panning info if will be truly fantastic.

Hmmm...I kinda knew that automation & FX would not translate over, but I was hoping that volume & pan settings would. Oh well.....you can't have everything, but it still makes it a lot easier to move projects between DAW apps. I think 75% of a loaf of bread is better than none and having OMF support in REAPER is kick ass!

Okay, upon some further testing there seems to be an issue with larger OMF files. Under 300MB seem to be okay, but larger files are causing a REAPER crash with the reaper_omf.dll as the likely culprit. I was having an issue opening a 724MB OMF2 file that I created from a SONAR 8 project using it's export to OMF. SONAR easily re-opens the OMF that it had created, so the file itself appears to be fine. The project contains (17) full length audio tracks and is about 4min & 23 seconds long. I then tried paring the project down by shortening the length first to 3 mins (520MB) and then to 2 mins(340MB) and doing a bounce to tracks each time to trim off any excess audio to get the final OMF file size down. Each time the resulting OMF file would cause REAPER to crash. It was not until I trimmed the project down to a 1:28 (263MB) that I was finally able to open the OMF in REAPER. I have attached the crash logs & mini dump file from Dr Watson.

Also of note: Opening the OMF's (depending on the size) in SONAR only takes 5-15 seconds (rather than a few minutes in REAPER). In addition, there is a convenient OMF related "Unpack OMF" dialog that pops up when you first open an OMF that tells you the sample & bit rates & tempo of the OMF and you can also alter the import settings (name/save location, etc..). This reads the bit rate/sample rate & tempo from the target OMF and once unpacked this info gets imported into SONAR as the new project settings. Note: When the OMF is unpacked and imported into SONAR the OMF's original tempo (unless manually changed in the dialog) is the set in SONAR as such. I noticed in REAPER that the project never changes from the project default when an OMF is opened as a new project. It would be nice if the original OMF tempo was assumed in REAPER as well.