Wiki source for ParisOmf
=====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?====
[[http://en.wikipedia.org/wiki/Open_Media_Framework 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" form (ie "self-contained", with all audio files used in the session stored inside one large OMF file) and "non-embedded" form (with the audio as separate files in an accompanying folder and the OMF carrying the info on where in the session they were positioned etc).
PARIS supported the export of the first type of "embedded" OMFs. The "plain English" version: 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 which those segments reference, ready for seamless import into another DAW. Besides being much quicker and less cumbersome than the traditional method of "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 often generate such a file. It was virtually useless - too much important information (for example, audio file names) was truncated. As we've discovered, this was not entirely PARIS' fault; there were wide differences of interpretation of the OMF "standard" by most vendors "supporting" it. PARIS was discontinued immediately after the version with OMF support (3.0) was released, so no application bothered to learn how to successfully read PARIS' own implementation of OMF. Further, problems existed in PARIS' OMF export function, which would often simply fail to export OMFs giving no clues "why", making the question of importing it elsewhere moot. Since no application learned to read PARIS OMF, it wasn't worth digging deeply into solving the additional problems blocking OMF exports since they were unreadable anyway - it was a Catch-22.
PARIS OMF export remained in that limbo for nine years until 2010, when developer Michael Rooney from [[http://aatranslator.com.au 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) good PARIS OMF exports.
----
====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 "/" character appears to be a "forbidden" character (possibly since it's reserved for describing directories on your disk) as is the "." character; there may be more. Here are two frequent causes of a PARIS audio file accidentally acquiring an "illegal" character in its name:
1) 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 possibly illegal) name from the track it's on... **Step A1** is to check that you haven't named a channel with an illegal character in the Mixer WIndow (try to use alphanumerical characters only).
2) You have named segments on the playing field. Normally PARIS is fine with this, but named segments can prevent PARIS OMF exports from completing. The current speculation: if you look closely at the name on the edit screen, you'll see a "/" character in it separating the name of the file from the name of the segment. This character appears to 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__, at which point PARIS will drop its insistence on the "/" separator and your export can proceed. Whether or not this is "technically" the cause of the issue, **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 project might still play back acceptably but when included in an 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. Watch for clues in your song that can help identify a problem file, such as playback problems that occur at exactly the same place in the song coinciding with the start of a particular audio region (or exporting an OMF that seems to have problems around a particular file). If you discover a corrupted file, the solution is to copy the audio data the file contains into a fresh file with a clean, uncorrupted "file header". There is no specific menu command for this, but you have a number of easy ways to achieve this anyway. The first is to simply render your file in place (rendering two files together creates a fresh new third file), but that's a somewhat crude approach since it commits you to the edits you've made. A slightly longer but much more refined method:
a) go to the Audio Bin
b) samplerate convert the problem file, but make the destination sample rate the same as the origin,
c) PARIS generates a new (identical) file with a fresh header;
d) use "reset file path" to change the reference from the original to the new one.
You could also try "duplicate files", followed by "reset file path" to direct PARIS to use the new copy.
==C) **__Avoid mingling sample rates__**==
[UNTESTED ASSUMPTION - NEEDS FURTHER RESEARCH:] PARIS appears to be able to mingle 44.1k and 48k audio in the same session and have them both play back correctly [note that this behaviour, which is *not* included in the manual, is still being studied - see screenshot of "See It My Way" audio bin below]. Unfortunately, very few DAWs can do this, so if you export an OMF with mingled sample rates it would 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 (possibly 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, AAT will convert them both to the desired format).
====Screencaps: OMF Translation of "See It My Way" compared to original====
{{image url="http://kerrygalloway.com/PARIS%20resources/SeeItMyWay.jpg" title="The familiar original PARIS demo, See It My Way" alt="text"}}
----
{{image url="http://kerrygalloway.com/PARIS%20resources/ReapItMyWay.jpg" title="See It My Way translated into Reaper RPP via AATranslator" alt="text"}}
----
=====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:// Do I need to worry about framerates etc?//
A: Nope. PARIS OMFs bypass FPS, it uses absolute time in samples from the beginning of the song as their timing reference. All of your audio will export in exact sample relationship to the timeline of the PPJ regardless of framerate settings, which are irrelevant here. Since ADAT sync uses the same timing system, they should also match transfers via ADAT sync with sample accuracy. There's no problem exporting audio from a song at 25 FPS to another at 29.97 with full accuracy.
Q: //Are EQ settings or plugin settings exported?//
A: EQ and plugin settings aren't part of OMF.
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 OMFs report all their 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://Does this mean the PARIS "Import OMF" function will work now too?//
A: No, that hasn't changed. We'd need more investigation from us users to know if there was a chance of it ever becoming useful. It would be great if PARIS' import and export routines used the same assumptions about OMF, but if they did, logically PARIS should be able to re-import its own OMFs properly, which it can't. We now know the assumptions PARIS makes when exporting an OMF but we still don't know what assumptions its imports are based on. An important clue would be if anyone's ever had a successful OMF import (ie with region/track names intact) from PARIS. Knowing what DAW that OMF came from could be important; if one OMF type can be made to work, we'd know a lot more about how PARIS OMF import "thinks" and what it "expects" and could tailor translation in AATranslator accordingly.
Q: //Is there a possibility these functions might be developed further? What might be added?//
A: There are several interesting things that could be developed further. For one thing, the volume/pan/mute track automation information in PARIS' OMFs has been detected, and might one day be translated. Exploring things like this will depend entirely upon user interest.
----
{{image url="http://kerrygalloway.com/PARIS%20resources/See%20It%20My%20Way%20audio%20bin.jpg" title="The Audio Window from See It My Way showing mixed sample rates" alt="text"}}
//(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?====
[[http://en.wikipedia.org/wiki/Open_Media_Framework 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" form (ie "self-contained", with all audio files used in the session stored inside one large OMF file) and "non-embedded" form (with the audio as separate files in an accompanying folder and the OMF carrying the info on where in the session they were positioned etc).
PARIS supported the export of the first type of "embedded" OMFs. The "plain English" version: 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 which those segments reference, ready for seamless import into another DAW. Besides being much quicker and less cumbersome than the traditional method of "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 often generate such a file. It was virtually useless - too much important information (for example, audio file names) was truncated. As we've discovered, this was not entirely PARIS' fault; there were wide differences of interpretation of the OMF "standard" by most vendors "supporting" it. PARIS was discontinued immediately after the version with OMF support (3.0) was released, so no application bothered to learn how to successfully read PARIS' own implementation of OMF. Further, problems existed in PARIS' OMF export function, which would often simply fail to export OMFs giving no clues "why", making the question of importing it elsewhere moot. Since no application learned to read PARIS OMF, it wasn't worth digging deeply into solving the additional problems blocking OMF exports since they were unreadable anyway - it was a Catch-22.
PARIS OMF export remained in that limbo for nine years until 2010, when developer Michael Rooney from [[http://aatranslator.com.au 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) good PARIS OMF exports.
----
====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 "/" character appears to be a "forbidden" character (possibly since it's reserved for describing directories on your disk) as is the "." character; there may be more. Here are two frequent causes of a PARIS audio file accidentally acquiring an "illegal" character in its name:
1) 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 possibly illegal) name from the track it's on... **Step A1** is to check that you haven't named a channel with an illegal character in the Mixer WIndow (try to use alphanumerical characters only).
2) You have named segments on the playing field. Normally PARIS is fine with this, but named segments can prevent PARIS OMF exports from completing. The current speculation: if you look closely at the name on the edit screen, you'll see a "/" character in it separating the name of the file from the name of the segment. This character appears to 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__, at which point PARIS will drop its insistence on the "/" separator and your export can proceed. Whether or not this is "technically" the cause of the issue, **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 project might still play back acceptably but when included in an 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. Watch for clues in your song that can help identify a problem file, such as playback problems that occur at exactly the same place in the song coinciding with the start of a particular audio region (or exporting an OMF that seems to have problems around a particular file). If you discover a corrupted file, the solution is to copy the audio data the file contains into a fresh file with a clean, uncorrupted "file header". There is no specific menu command for this, but you have a number of easy ways to achieve this anyway. The first is to simply render your file in place (rendering two files together creates a fresh new third file), but that's a somewhat crude approach since it commits you to the edits you've made. A slightly longer but much more refined method:
a) go to the Audio Bin
b) samplerate convert the problem file, but make the destination sample rate the same as the origin,
c) PARIS generates a new (identical) file with a fresh header;
d) use "reset file path" to change the reference from the original to the new one.
You could also try "duplicate files", followed by "reset file path" to direct PARIS to use the new copy.
==C) **__Avoid mingling sample rates__**==
[UNTESTED ASSUMPTION - NEEDS FURTHER RESEARCH:] PARIS appears to be able to mingle 44.1k and 48k audio in the same session and have them both play back correctly [note that this behaviour, which is *not* included in the manual, is still being studied - see screenshot of "See It My Way" audio bin below]. Unfortunately, very few DAWs can do this, so if you export an OMF with mingled sample rates it would 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 (possibly 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, AAT will convert them both to the desired format).
====Screencaps: OMF Translation of "See It My Way" compared to original====
{{image url="http://kerrygalloway.com/PARIS%20resources/SeeItMyWay.jpg" title="The familiar original PARIS demo, See It My Way" alt="text"}}
----
{{image url="http://kerrygalloway.com/PARIS%20resources/ReapItMyWay.jpg" title="See It My Way translated into Reaper RPP via AATranslator" alt="text"}}
----
=====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:// Do I need to worry about framerates etc?//
A: Nope. PARIS OMFs bypass FPS, it uses absolute time in samples from the beginning of the song as their timing reference. All of your audio will export in exact sample relationship to the timeline of the PPJ regardless of framerate settings, which are irrelevant here. Since ADAT sync uses the same timing system, they should also match transfers via ADAT sync with sample accuracy. There's no problem exporting audio from a song at 25 FPS to another at 29.97 with full accuracy.
Q: //Are EQ settings or plugin settings exported?//
A: EQ and plugin settings aren't part of OMF.
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 OMFs report all their 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://Does this mean the PARIS "Import OMF" function will work now too?//
A: No, that hasn't changed. We'd need more investigation from us users to know if there was a chance of it ever becoming useful. It would be great if PARIS' import and export routines used the same assumptions about OMF, but if they did, logically PARIS should be able to re-import its own OMFs properly, which it can't. We now know the assumptions PARIS makes when exporting an OMF but we still don't know what assumptions its imports are based on. An important clue would be if anyone's ever had a successful OMF import (ie with region/track names intact) from PARIS. Knowing what DAW that OMF came from could be important; if one OMF type can be made to work, we'd know a lot more about how PARIS OMF import "thinks" and what it "expects" and could tailor translation in AATranslator accordingly.
Q: //Is there a possibility these functions might be developed further? What might be added?//
A: There are several interesting things that could be developed further. For one thing, the volume/pan/mute track automation information in PARIS' OMFs has been detected, and might one day be translated. Exploring things like this will depend entirely upon user interest.
----
{{image url="http://kerrygalloway.com/PARIS%20resources/See%20It%20My%20Way%20audio%20bin.jpg" title="The Audio Window from See It My Way showing mixed sample rates" alt="text"}}
