history "ParisOmf": The PARIS Wiki

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).

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 characters in the Mixer WIndow (try to use alphanumerical characters only).

[[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 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.
[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).
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.

[[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" (ie "self-contained", with all audio files used in the session stored inside one large OMF file) and "non-embedded" (with the audio as separate files and the OMF carrying their positional info etc) 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 [[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) a good PARIS OMF export.
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 simply 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 problem 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", followed by "reset file path" to direct PARIS to use the new copy instead. Watch for clues in your song that can help identify the problem file, such as problems that occur at exactly the same place in the song that coincides with the start of a particular audio region.
[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).
Q:// How is time handled in PARIS OMFs?//
A: PARIS OMFs bypass FPS and use absolute time in samples from the beginning of the song as a reference. All of your audio should export in exact sample relationship to the timeline of the PPJ. Since ADAT sync uses the same timing system, they should also match transfers via ADAT sync with sample accuracy.

[[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" (ie "self-contained", with all audio files used in the session stored inside one large OMF file) and "non-embedded" (with the audio as separate files and the OMF carrying their positional info etc) forms.

[[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" (ie "self-contained", with all audio files used in the session stored inside them) and "non-embedded" forms.

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. 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 simply 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 problem 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", followed by "reset file path" to direct PARIS to use the new copy instead. Watch for clues in your song that can help identify the problem file, such as problems that occur at exactly the same place in the song that coincides with the start of a particular audio region.
[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).

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".
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 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).

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".

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** in a seis to check for named segments in the audio bin and delete their names with "right-click then backspace".

A: PARIS OMFs bypass FPS and use absolute time in samples from the beginning of the song as a reference. All of your audio should export in exact sample relationship to the timeline of the PPJ. Since ADAT sync uses the same timing system, they should also match transfers via ADAT sync with sample accuracy.
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.
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.

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.
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. One 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 "thinks".
A: Absolutely, 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.

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 characters 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** in a seis to check for named segments in the audio bin and delete their names with "right-click then backspace".

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 appears to be a "forbidden" character (possibly since it's reserved for describing 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:
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 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).
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 "slash" 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 "slash" separator and your export can proceed. Whether or not this is "technically" the cause of the issue, **step A2** in a seis to check for named segments in the audio bin and delete their names with "right-click then backspace".

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 appears to be a "forbidden" character (possibly since it's reserved for describing 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:

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:

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 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).
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 "slash" 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 "slash" separator and your export can proceed. Whether or not this is "technically" the cause of the issue, **step A2** in a seis to check for named segments in the audio bin and delete their names with "right-click then backspace".
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".
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 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).

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 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).
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 "slash" 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 "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".
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".
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 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).

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 "slash" 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 "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".

2) 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".

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. One 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 "thinks".

A: No, that hasn't changed. We'd need more investigation from us users to know if there was a chance of it happening. One 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 "thinks".

~~A: No, that hasn't changed.~~

~~(And yes - they do sound exactly the same)~~

Q://Does this mean the PARIS "Import OMF" function will work now too?//

~~Q://Does this mean the PARIS "Import OMF" function will work now too?~~

Q://Does this mean the PARIS "Import OMF" function will work now too?
A: No, that hasn't changed.

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 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).
{{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"}}

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).

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.
A: Absolutely, 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.

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.
A: Absolutely, there are several interesting things that could be developed further. The volume/pan/mute track 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.

Q: //Are EQ settings or plugin settings exported?//
A: EQ and plugin settings aren't part of OMF.
A: Absolutely, there are several interesting things that could be developed further. The volume/pan/mute track 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.

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.

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.

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?//

Q: Is anything "broken" in it, either trivial or major?
A: Yes. "Trivial" or "major" will depend on your workflow. PARIS supports four fade types internally - linear, logarithmic, cosine and equal power - but all fades in a PARIS OMF are reported as being either linear or equal power. The fades are there, but COSINE and LOGARITHMIC are reported incorrectly as EqP or Lin. If those two fade types are crucial to your workflow, the workaround is: 1) export a segment list from the Audio Window at the same time as you export your OMF, 2) export your OMF to the desired format, 3) open the segment list in WordPad, do a "find" on the word COSINE and note the segment name and location, 4) open your converted session and correct any mis-mapped COSINE fades, 5) repeat steps 3 and 4 for LOGARITHMIC. If you don't use COSINE or LOGARITHMIC fades, you won't be affected.
Q: How are start times and locations handled in PARIS OMFs?
A: PARIS OMFs 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?

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.

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, either trivial or major?
A: Yes. "Trivial" or "major" will depend on your workflow. PARIS supports four fade types internally - linear, logarithmic, cosine and equal power - but all fades in a PARIS OMF are reported as being either linear or equal power. The fades are there, but COSINE and LOGARITHMIC are reported incorrectly as EqP or Lin. If those two fade types are crucial to your workflow, the workaround is: 1) export a segment list from the Audio Window at the same time as you export your OMF, 2) export your OMF to the desired format, 3) open the segment list in WordPad, do a "find" on the word COSINE and note the segment name and location, 4) open your converted session and correct any mis-mapped COSINE fades, 5) repeat steps 3 and 4 for LOGARITHMIC. If you don't use COSINE or LOGARITHMIC fades, you won't be affected.
Q: How are start times and locations handled in PARIS OMFs?
A: PARIS OMFs use absolute time in samples as a reference; all of your audio should export in exact sample relationship to the timeline of the PPJ.

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".
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).

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 simply generate a fresh "file header". There is no menu command for this, so you have two choices. The first is to render your file in place, but that commits you to your edits. 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.
One of PARIS' bizarre 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 samplerates it will complete correctly and open correctly, but the audio will play back "wrong" in most destination formats. Obviously this is not really a "bug" in PARIS (it's a PARIS *feature*) but since 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** (mingling bit depth - ie 16 and 24 bit files - is fine).

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) a good PARIS OMF export.

PARIS OMF export remained in that limbo for nine years until 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) a good PARIS OMF export.

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.

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 - the OMF "standard" was loosely adhered to by most applications "supporting" it, and its implementation varied widely. 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.

Since its introduction in 2001, PARIS' advertised OMF export function would indeed generate such a file. It was virtually useless as much of the meaningful information was truncated. This was not entirely PARIS' fault - the OMF "standard" was loosely adhered to by most applications "supporting" it, and its implementation varied widely. 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.

[[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" (ie "self-contained", with all audio files used in the session stored inside them) and "non-embedded" forms.

[[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 came as either embedded (containing all audio from the session within themselves) and non-embedded forms.

=====PARIS "FAQ of OMF"=====

~~PARIS "FAQ of OMF"~~

PARIS "FAQ of OMF"

Since its introduction in 2001, PARIS' advertised OMF export function would indeed generate such a file. It was virtually useless as much of the meaningful information was truncated. This was not entirely PARIS' fault - the OMF "standard" was loosely adhered to by most applications "supporting" it, and its implementation varied widely. 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.

Since its introduction in 2001, PARIS' advertised OMF export function would indeed generate such a file. It was virtually useless as much of the meaningful information was truncated. This was not entirely PARIS' fault - the OMF "standard" was loosely adhered to by most applications "supporting" it, and its implementation varied widely. 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.

//(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 came as either embedded (containing all audio from the session within themselves) 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 much of the meaningful information was truncated. This was not entirely PARIS' fault - the OMF "standard" was loosely adhered to by most applications "supporting" it, and its implementation varied widely. 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 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) a good PARIS OMF export.

//(Scroll down for a screencap of a translation from PARIS OMF to Reaper RPP via AATranslator)//
Wikipedia [[http://en.wikipedia.org/wiki/Open_Media_Framework states]] that OMF is "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."
The "plain English" version of this is that in theory you would use OMF to export a single file that contains exactly what you see in your Editor Windows, as well as the audio files from which those segments are derived. Besides being much quicker and less cumbersome than "rendering all your tracks out from zero", "rendering" forces you to commit to your edits by printing the edited audio as a new file, whereas using OMF means you don't have to "commit" - audio segments in your OMF are still associated with copies of the original files, so they can be freely re-edited on arrival in their destination format.
PARIS' own advertised OMF export function has been of virtually no use since its introduction. This was not entirely PARIS' fault - the OMF "standard" was loosely adhered to and its implementation varied widely, and as PARIS was discontinued around the same time as OMF support was released - no application ever learned to read PARIS OMFs properly. Further, problems existed in PARIS' OMF export function, which would often simply fail to export OMFs giving no information on "why", which made the question of importing it elsewhere moot. And since no application learned to read PARIS OMF, it wasn't worth digging deeply into solving the problems blocking PARIS' OMF exports - a Catch-22.
PARIS OMF remained in limbo for nine years until developer Michael Rooney from [[http://aatranslator.com.au AATranslator]] discovered how the data in PARIS OMFs was stored, and taught AATranslator to extract the information from PARIS OMFs 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.

PARIS' own advertised OMF export function has been of virtually no use since its introduction. This was not entirely PARIS' fault - the OMF "standard" was loosely adhered to and its implementation varied widely, and as PARIS was discontinued around the same time as OMF support was released - no application ever learned to read PARIS OMFs properly. Further, problems existed in PARIS' OMF export function, which would often simply fail to export OMFs giving no information on "why", which made the question of importing it elsewhere moot. And since no application learned to read PARIS OMF, it wasn't worth digging deeply into solving the problems blocking PARIS' OMF exports - a Catch-22.

Since 2001 OMF export has been of virtually no practical use to the PARIS community. As the OMF "standard" was loosely adhered to and its implementation varied widely, and as PARIS was discontinued around the same time as OMF support was released - no application ever learned to read PARIS OMFs properly. The situation became a Catch-22 - problems existed in PARIS' OMF export function often causing it to fail to export OMFs properly, making the question of importing it elsewhere moot - and since no application learned to read it, it was never really worth digging deeply into solving the problems in PARIS' OMF.

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:

This may seem odd, but PARIS will allow you to name things in such a way that it can no longer deal with them. The "slash" character is forbidden (it's reserved for describing directories) as is the "period" character; there may be more. Here are the most frequent causes of illegal names:

Since 2001 OMF export has been of virtually no practical use to the PARIS community. As the OMF "standard" was loosely adhered to and its implementation varied widely, and as PARIS was discontinued around the same time as OMF support was released - no application ever learned to read PARIS OMFs properly. The situation became a Catch-22 - problems existed in PARIS' OMF export function often causing it to fail to export OMFs properly, making the question of importing it elsewhere moot - and since no application learned to read it, it was never really worth digging deeply into solving the problems in PARIS' OMF.

Since 2001 OMF export has been practically useless to the PARIS community. The OMF "standard" was very loosely adhered to and its implementation varied widely; no application ever learned to read PARIS OMFs properly. The situation became a Catch-22 - because no application learned to read it, it was never really worth digging deeply into problems in PARIS' OMF export function; because problems existed in PARIS' OMF export function, it often failed to export OMFs at all - making the question of importing it elsewhere moot.

//(Scroll down for a screencap of a translation from PARIS OMF to Reaper RPP via AATranslator)//
Since 2001 OMF export has been practically useless to the PARIS community. The OMF "standard" was very loosely adhered to and its implementation varied widely; no application ever learned to read PARIS OMFs properly. The situation became a Catch-22 - because no application learned to read it, it was never really worth digging deeply into problems in PARIS' OMF export function; because problems existed in PARIS' OMF export function, it often failed to export OMFs at all - making the question of importing it elsewhere moot.
PARIS OMF remained in limbo for nine years until developer Michael Rooney from [[http://aatranslator.com.au AATranslator]] discovered how the data in PARIS OMFs was stored, and taught AATranslator to extract the information from PARIS OMFs 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.

Since 2001 OMF export has been practically useless to the PARIS community. The OMF "standard" was very loosely adhered to and its implementation varied widely, and no application ever learned to read PARIS OMFs properly. And because no application learned to read it, it was never really worth digging deeply into problems in PARIS' OMF export function that often made it fail to export in the first place. It remained at that status for nine years until developer Michael Rooney from [[http://aatranslator.com.au AATranslator]] discovered how the data in PARIS OMFs was stored and taught AATranslator to extract the information from PARIS OMFs and convert it into a host of other file formats. Scroll down for a screencap of a translation from PARIS OMF to Reaper RPP via AATranslator.

2) 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".

2) 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 will 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".

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 simply generate a fresh "file header". There is no menu command for this, so you have two choices. The first is to render your file in place, but that commits you to your edits. 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.

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 simply generate a fresh "file header". There is no menu command for this, so you have two choices. The first is to render your file in place, but that commits you to your edits. 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; now you simply use "reset file path" to change the reference from the original to the new one.

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 simply generate a fresh "file header". There is no menu command for this, so you have two choices. The first is to render your file in place, but that commits you to your edits. 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; now you simply use "reset file path" to change the reference from the original to the new one.
One of PARIS' bizarre 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 samplerates it will complete correctly and open correctly, but the audio will play back "wrong" in most destination formats. Obviously this is not really a "bug" in PARIS (it's a PARIS *feature*) but since 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** (mingling bit depth - ie 16 and 24 bit files - is fine).

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 simply generate a fresh "file header". There is no menu command for this, so you have two choices.
One of PARIS' bizarre 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 samplerates it will complete correctly and open correctly, but the audio will play back "wrong" in most destination formats. Obviously this is not really a "bug" in PARIS (it's a PARIS *feature*) but since other DAWs won't be able to read the session correctly, step 3 is to **make sure all your audio is at the project sample rate** (mingling bit depth - ie 16 and 24 bit files - is fine).

Since 2001 OMF export has been practically useless to the PARIS community. The OMF "standard" was very loosely adhered to and its implementation varied widely, and no application ever learned to read PARIS OMFs properly. And because no application learned to read it, it was never really worth digging deeply into problems in PARIS' OMF export function that often made it fail to export in the first place. It remained at that status for nine years until developer Michael Rooney from [[http://aatranslator.com.au AATranslator]] discovered how the data in PARIS OMFs was stored and taught AATranslator to extract the information from PARIS OMFs and convert it into a host of other file formats. Scroll down for a screencap of a translation from PARIS OMF to Reaper RPP via AATranslator.
====Screencaps: OMF Translation of "See It My Way" compared to original====
(And yes - they do sound exactly the same)
{{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"}}

Since 2001 OMF export has been practically useless to the PARIS community. The OMF "standard" was very loosely adhered to and its implementation varied widely, and no application ever learned to read PARIS OMFs properly. And because no application learned to read it, it was never really worth digging deeply into problems in PARIS' OMF export function that often made it fail to export in the first place. It remained at that status for nine years until developer Michael Rooney from [[http://aatranslator.com.au AATranslator]] discovered how the data in PARIS OMFs was stored and taught AATranslator to extract the information from PARIS OMFs and convert it into a host of other file formats.

The "plain English" version of this is that in theory you would use OMF to export a single file that contains exactly what you see in your Editor Windows, as well as the audio files from which those segments are derived. Besides being much quicker and less cumbersome than "rendering all your tracks out from zero", "rendering" forces you to commit to your edits by printing the edited audio as a new file, whereas using OMF means you don't have to "commit" - audio segments in your OMF are still associated with copies of the original files, so they can be freely re-edited on arrival in their destination format.
Since 2001 OMF export has been practically useless to the PARIS community. The OMF "standard" was very loosely adhered to and its implementation varied widely, and no application ever learned to read PARIS OMFs properly. And because no application learned to read it, it was never really worth digging deeply into problems in PARIS' OMF export function that often made it fail to export in the first place. It remained at that status for nine years until developer Michael Rooney from [[http://aatranslator.com.au AATranslator]] discovered how the data in PARIS OMFs was stored and taught AATranslator to extract the information from PARIS OMFs and convert it into a host of other file formats.
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.

The "plain English" version of this is that you can use OMF to export a single file that contains exactly what you see in your Editor Windows, as well as the files from which those segments are derived. This is far superior to "rendering" tracks out - besides being much quicker, using OMF means you don't have to "commit" to your edits.
Unfortunately the question for the last decade has been "what can it be exported to?" - and since 2001 the answer has been "pretty much nothing"; the OMF "standard" was very loosely adhered to and its implementation varied widely, and no application ever learned to read PARIS OMFs properly.
It stayed at that status for nine years until developer Michael Rooney from AATranslator discovered how the data in PARIS OMFs was stored and taught AATranslator to extract the information from PARIS OMFs and convert it into a host of other file formats.
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 working OMFs.

{{image class="right" image url="http://www.kerrygalloway.com/PARIS%20resources/LightGreyDemo.jpg" title="text" alt="text"}}

==**__A) Name things properly__**==
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 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).
==**__B) Make sure your audio isn't corrupted__**==
==C) **__Avoid mingling sample rates__**==

===**__A) Name things properly__**===
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 the audio and it picks up a new 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).
===**__B) Make sure your audio isn't corrupted__**===
===C) **__Avoid mingling sample rates__**===

Wikipedia [[http://en.wikipedia.org/wiki/Open_Media_Framework states]] that OMF is "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."
The "plain English" version of this is that you can use OMF to export a single file that contains exactly what you see in your Editor Windows, as well as the files from which those segments are derived. This is far superior to "rendering" tracks out - besides being much quicker, using OMF means you don't have to "commit" to your edits.
Unfortunately the question for the last decade has been "what can it be exported to?" - and since 2001 the answer has been "pretty much nothing"; the OMF "standard" was very loosely adhered to and its implementation varied widely, and no application ever learned to read PARIS OMFs properly.
It stayed at that status for nine years until developer Michael Rooney from AATranslator discovered how the data in PARIS OMFs was stored and taught AATranslator to extract the information from PARIS OMFs and convert it into a host of other file formats.
====The ABC of OMF - a Pre-flight Checklist.====
===**__A) Name things properly__**===
This may seem odd, but PARIS will allow you to name things in such a way that it can no longer deal with them. The "slash" character is forbidden (it's reserved for describing directories) as is the "period" character; there may be more. Here are the most frequent causes of illegal names:
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 the audio and it picks up a new 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).
2) 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 will 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 simply generate a fresh "file header". There is no menu command for this, so you have two choices.
===C) **__Avoid mingling sample rates__**===

Wikipedia [[http://en.wikipedia.org/wiki/Open_Media_Framework tersely states]] that OMF is "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."
The "plain English" version of this is "exactly what you see in your Editor Window gets exported", as well as the files from which those segments are derived (so you can, for example, re-do an edit on a segment, lengthening the exposing more of the audio file that segment came from). As to "what it gets exported to", the answer since 2001 has been "pretty much nothing"; the OMF was very loosely adhered to, its implementation varied widely, and no application ever learned to read PARIS OMFs properly.
There it sat for nine years until developer Michael Rooney from AATranslator discovered how data was stored in PARIS OMFs and taught his application to parse them into other file formats.
====The PARIS OMF Pre-flight Checklist.====
===1) Name things properly===
This may seem odd, but PARIS will allow you to name things in such a way that it can no longer deal with them. The "slash" character is forbidden (it's reserved for describing directories) as is the "period" character; there may be more.
Here are the most frequent causes of illegal names:
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 the audio and it picks up a new name from the track it's on... Step 1A 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 will prevent
===2) 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. 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. Step 2 is to verify that you have no corrupted audio files in your PPJ.
===3) Avoid mingling sample rates===

===2) Make sure your audio isn't corrupted===
===3) Avoid mingling sample rates===

===2) MAKE SURE YOUR AUDIO ISN'T CORRUPTED===
===3) AVOID MIXING SAMPLE RATES===

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 working OMFs.

Exporting OMFs from PARIS is a simple process. There are no options or choices to make; you simply choose "Export OMF" from the file menu, PARIS begins the process of creating an OMF and either reports success, or, as is most often the case, failure. This checklist will help you export working OMFs.

----
====The PARIS OMF Pre-flight Checklist.====
===1) Name things properly===
===2) MAKE SURE YOUR AUDIO ISN'T CORRUPTED===
===3) AVOID MIXING SAMPLE RATES===

===The PARIS OMF Pre-flight Checklist.===
==1) NAME THINGS PROPERLY==
==2) MAKE SURE YOUR AUDIO ISN'T CORRUPTED==
==3) AVOID MIXING SAMPLE RATES==

The PARIS Wiki : ParisOmf

Revision history for ParisOmf

Revision [2020]

Additions:

Deletions:

Revision [1887]

Additions:

Deletions:

Revision [1882]

Additions:

Deletions:

Revision [1881]

Additions:

Deletions:

Revision [1880]

Additions:

Deletions:

Revision [1879]

Additions:

Deletions:

Revision [1878]

Additions:

Deletions:

Revision [1873]

Additions:

Deletions:

Revision [1725]

Additions:

Deletions:

Revision [1724]

Additions:

Deletions:

Revision [1723]

Additions:

Deletions:

Revision [1722]

Additions:

Deletions:

Revision [1687]

Deletions:

Revision [1686]

Additions:

Deletions:

Revision [1685]

Additions:

Revision [1669]

Additions:

Deletions:

Revision [1666]

Additions:

Deletions:

Revision [1665]

Additions:

Deletions:

Revision [1664]

Additions:

Deletions:

Revision [1663]

Additions:

Deletions:

Revision [1662]

Additions:

Revision [1661]

Additions:

Revision [1660]

Additions:

Deletions:

Revision [1650]

Additions:

Deletions:

Revision [1649]

Additions:

Deletions:

Revision [1648]

Additions:

Deletions:

Revision [1647]

Additions:

Deletions:

Revision [1646]