| The ABCs of OMF [message #104877] |
Wed, 24 February 2010 15:09  |
|
|
Hi folks. I just put some discoveries up on the Wiki and thought I'd save you all some headaches.
I can't imagine too many people wasted much time figuring out how to generate solid OMFs from PARIS - after all, since nobody could read them up until now, what'd be the point?
But since AATranslator has now cleared the way for us to use OMF to transfer our PARIS projects into a host of formats, I thought I'd take a moment to post what I've been discovering to be the PARIS "ABC's of OMF" for comment and refinement.
I've generated a lot of OMFs in the last little while, and not had a single failure of translation that didn't prove to be caused by one of these ABCs being violated. By the way - if you buy AATranslator (and I hope a lot of folks will), make certain to identify yourself as a PARIS user so Michael can send you the "hot off the presses" version that's not posted on his site yet.
| Quote: | 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 itself. The "slash" character is forbidden (it's reserved for describing file paths) as is the "period" character (reserved for OS functions); there may be more. Here are the frequent causes I've found of files acquiring "illegal" names accidentally:
1) You have included an illegal character in the name of the Mixer Channel the audio is on. This is not in itself an illegal action - but the moment you render a piece of audio in the Editor Window it picks up a new name from that of the track it's on. If that trackname contains an illegal character it can potentially lead to problems. So - if you encounter a problem with export, step A1 is to check that you haven't named a channel with an illegal character in the Mixer Window (probably best to stick to alphanumeric 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 (since there's no longer any names to separate) and your export can proceed. If you encounter a problem in export, 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. If you encounter a problem, step B is to check 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 - you have to do it by creating a new file with the same audio but a fresh header. For this you have several choices. The first is to render your file in place; this will likely solve the issue, but at the cost of committing you to any edits you've made. The second is a bit more involved but much better - a) go to the Audio Bin, b) samplerate convert the file at "highest" quality - but leaving the destination sample rate the same as the origin. PARIS will generate a new, effectively identical audio file with a fresh header. Use "reset file path" to change the reference from the original to the new one, and you're good to go.
C) Avoid mingling sample rates
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 besides PARIS 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 DAWs. Obviously this is not a "bug" in PARIS (it's actually a PARIS *feature*) but since no matter whose "fault" it is the net result is that other DAWs probably 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).
|
"... being bitter is like swallowing poison and waiting for the other guy to die..." - anon
[Updated on: Wed, 24 February 2010 21:51] Report message to a moderator |
|
|
|
|
|
| Re: The ABCs of OMF [message #104879 is a reply to message #104878] |
Wed, 24 February 2010 16:11  |
|
|
Yes, it would likely be visible in the header. Mike and I have a "working hypothesis" which we'd like to test: that the bulk of corruption we deal with in PAFs is just corruption of the file header, not the audio itself (after all, if the data itself was corrupted, it should affect the sound).
Simply duplicating the file in Explorer wouldn't fix it; it's not in the business of making value judgements about headers, so it would just duplicate the corrupted one. But it struck me that I could force PARIS itself to regenerate a fresh one. I used that "sample rate convert but without conversion" trick (although now I think about it, a simple "duplicate" might do it too) and as soon as I used "reset file path" to point the PPJ at the new file with a fresh "header" the issue went away.
I wonder exactly how many mysterious issues in the past were due to these fragile PAF headers getting corrupted. Mike and I are now talking about the great desirability of having a "PAF cleaner" utility - drag a folder (or even a drive) full of PAFs onto it and it scans for PAFs with corrupted headers and writes them fresh ones. That would be a pretty amazing fix for some balky projects.
"... being bitter is like swallowing poison and waiting for the other guy to die..." - anon
[Updated on: Wed, 24 February 2010 21:57] Report message to a moderator |
|
|
|
|
|
| Re: The ABCs of OMF [message #104881 is a reply to message #104880] |
Wed, 24 February 2010 21:54 |
|
|
Thanks guys - I should stress that I consider those ABCs a mere "work in progress", one that might get heavily revised as we find out more. It's complete "voodoo troubleshooting" - there's definitely a correlation between the problems that were solved and the things that I did to solve them (I can reproduce some of them reliably by reversing the process), but I might well be wildly wrong about the *why* behind it.
"... being bitter is like swallowing poison and waiting for the other guy to die..." - anon
[Updated on: Wed, 24 February 2010 21:55] Report message to a moderator |
|
|
|
The PARIS Forums
Search
Help
Members
Register
Login
Home
