Revision [1663]
This is an old revision of ParisOmf made by admin on 2010-03-01 00:01:24.
PARIS and OMF
(Scroll down for a pre-flight checklist for successful OMF export, a screencap of a translation from PARIS OMF to Reaper RPP via AATranslator, and a list of OMF FAQs)
Background: What is OMF, and how does it relate to PARIS?
Wikipedia defines OMF as "Open Media Framework (OMF) or Open Media Framework Interchange (OMFI)... a platform-independent file format intended for transfer of digital media between different software applications." Files could be created in either "embedded" (ie "self-contained", with all audio files used in the session stored inside them) and "non-embedded" forms.
PARIS supported the export of "embedded" OMFs. The "plain English" version of this is that in theory the "Export OMF" command would create a single file that contains 1) exactly what you see in your Editor Windows plus 2) the audio files from which those segments are derived, ready for seamless import into another DAW. Besides being much quicker and less cumbersome than "rendering all your tracks out from zero", OMF has the great advantage of not forcing you to commit to your edits (in OMF, copies of the audio files that the segments refer to are also included, so your audio segments remain editable "segments" and can be freely re-edited on arrival in their destination format).
Since its introduction in 2001, PARIS' advertised OMF export function would indeed generate such a file. It was virtually useless as too much of the meaningful information (for example, audio file names) was truncated. This was not entirely PARIS' fault - there were wide differences of interpretation of the OMF "standard" by most applications "supporting" it. As PARIS was discontinued around the same time as its OMF support was released, no application bothered to learn how to read PARIS' own implementation of OMF successfully. Further, problems existed in PARIS' OMF export function, which would often simply fail to export OMFs giving no clues "why" - which would have made the question of importing it elsewhere moot. Since no application learned to read PARIS OMF, it wasn't worth digging deeply into solving the problems blocking the OMF exports - a Catch-22.
PARIS OMF export remained in that limbo for nine years until 2010, when developer Michael Rooney from AATranslator discovered how the data in PARIS OMFs was stored, and coded AATranslator to extract that information and convert it into a host of other file formats. In the process of testing, we discovered what makes (or breaks) a good PARIS OMF export.
The ABC of OMF - a Pre-flight Checklist.
Exporting OMFs from PARIS is a simple process. There are no options to select or choices to make; you simply choose "Export OMF" from the file menu, and PARIS pops up a progress bar while it creates and exports an OMF. When it's done, it either reports success, or (as is often the case) failure. This checklist will help you export PARIS OMFs that don't fail.
A) Name things properly
As odd as it may sound, PARIS will allow you to name things in such a way that it can no longer deal with them internally itself. The "slash" character is a "forbidden" character (it's reserved for describing the directories on your disk) as is the "period" character; there may be more. Here are two frequent causes of a PARIS audio file accidentally acquiring an "illegal" character in its name:
- You have included an illegal character in the name of the Mixer Channel the audio is on. Not in itself an illegal act - but the moment you render audio, it picks up a new (and illegal) name from the track it's on... Step A1 is to check that you haven't named a channel with an illegal characters in the Mixer WIndow (try to use alphanumerical characters only).
- You have named segments on the playing field. Normally PARIS is fine with this. But if you look closely at the name on the edit screen, you'll see a "slash" character in it separating the name of the file from the name of the segment. This illegal character can prevent the OMF from exporting. Because the character is generated by PARIS itself, it's impossible to erase unless you go to the audio bin, right click on the name of the segment (it will turn red) and delete its name. PARIS will drop its insistence on the "slash" separator and your export can proceed. So step A2 is to check for named segments in the audio bin and delete their names with "right-click then backspace".
B) Make sure your audio isn't corrupted
If anything, PARIS' OMF export is even more intolerant of corrupted audio files than the application itself is ("corruption" here refers to the quite common issue of "corruption of the file header" rather than of the audio itself). A corrupted file in your exported OMF can either cause the OMF export to fail outright, or to successfully export a damaged OMF. The symptoms of a damaged PARIS OMF include incompleteness, wrong audio files being associated with a segment, or an OMF that won't open at all. Thus step B is to verify that you have no corrupted audio files in your PPJ. If you discover a corrupted file, the solution is to move the audio data the file contains into a fresh file with a clean, uncorrupted "file header". There is no menu command for this, but you have a number of choices to achieve this. The first is to render your file in place, but that's a somewhat crude approach since it commits you to the edits you've made to the file. The second is slightly longer but better - a) go to the Audio Bin b) samplerate convert the file, but make the destination sample rate the same as the origin, c) PARIS generates a new (identical) file with a fresh header; now you simply use "reset file path" to change the reference from the original to the new one. You could also try "duplicate files" and "reset file path".
C) Avoid mingling sample rates
One of PARIS' odd strengths is the ability to mingle 44.1k and 48k audio in the same session and have them both play back correctly. Unfortunately, very few DAWs can do this, so if you export an OMF with mingled sample rates it will complete correctly and open correctly, but the audio will play back "wrong" in most destination formats. This is obviously not a "bug" in PARIS per se (it's actually a PARIS *feature*) but since the net result will be that most other DAWs won't be able to read the session correctly, step C is to make sure all your audio is at the project sample rate (although mingling bit depth - ie 16 and 24 bit files - is fine).
Screencaps: OMF Translation of "See It My Way" compared to original
(And yes - they do sound exactly the same)
PARIS "FAQ of OMF"
Q: What is exported in a PARIS OMF?
A: Track structure. Audio segments and the files they reference. Fades and crossfades. All times, lengths and positions are correct.
Q: Is there any audio that is *not* exported?
A: Any audio that's not in one of the sixteen tracks of one of the eight submixes will not be exported. If you want to include the contents of your jail cells or of Scratch Tracks 17 and 18, use the Timelocked selector Tool to drag them onto the Playing Field in an unused submix before export.
Q: Is anything "broken" in it that we know about?
A: Yes, one thing; PARIS supports four fade types internally - linear, logarithmic, cosine and equal power - but PARIS OMF reports all its fades as either linear or equal power. All fades are correct location and length, but COSINE and LOGARITHMIC fades are also being reported incorrectly as either EqP or Lin. If you don't use COSINE or LOGARITHMIC fades, you won't be affected. If those two fade types are crucial to your workflow, the current workaround is: 1) export a segment list (FXB) from the Audio Window when you export your OMF, 2) use AAT to translate your OMF to the desired destination format, 3) open the segment list in WordPad, do a "find" on the word COSINE, note the segment names and locations, 4) open your converted session and correct those fades to COSINE, 5) repeat steps 3 and 4 for LOGARITHMIC.
Q: How is time handled in PARIS OMFs?
A: PARIS OMFs bypass FPS and use absolute time in samples as a reference. All of your audio should export in exact sample relationship to the timeline of the PPJ.
Q: Is there a possibility these functions might be developed further? What might be added?
A: Absolutely, there are several interesting things that could be developed further. The automation information in PARIS' OMFs has been detected, and might one day be translated. A "force all audio to one selectable sample rate" function is possible, as is a "force convert to X FPS". Exploring these things will depend entirely upon user interest.
