DigiTranslator 2.01, PT6.7cs8, OSX 10.3.7

[SteveH44]

We are a post facility specializing dialog for feature animation, which requires the dialog tracks to be created first, then later imported into Avid Film Composer for assembly.
Why is it that Digitranslator OMF converter finds it necessary to rewrite the media files and change media names when exporting from Pro-Tools ? Often the file names that are created in Pro-Tools, carry though to the end of production. An editor looking at a file name like "PT24OutOMFw56ggGNNe5Rk.wav" has no clue what that means. At least allow us to utilize the existent file names (unchanged media) like other systems do. Another important requirement, would be to allow us to navigate to our own media files through the use of a file browser when importing to Pro-Tools and not using embedded file sets, instead of the way it is now - that the media must be located in the same folder as the OMF file is located. And lastly - re-including 30 frame capability, as it was in Translator 1.0, would be helpful since the majority of CG animation is created at this framerate.

The purpose of OMF/AAF is to provide a container that is sharable with OTHER applications, not just to use in another Pro-Tools platform. Digi seems to have made the converter work within the confines of Pro-Tools itself, but is unstandard to the rest of the world (ie; Fairlight AVtransfer, Neuendo 2, and even current Avid workstations). Since most computers are limited to the magical 2 gigabyte file rule, utilizing embedded files don't work, as a project these days can exceed 7-8 gigabytes, so standalone media is generally the rule. Another problem with converters in general (this includes Translator 2), is their inaccuracies in spotting media correctly on the timeline - even in Avids. This seems to stem from the fact that most sound editors are sample rate based (not hh:mm:ss:ff, but hh:mm:ss:sss or ticks), while Avids are frame rate based, and the truncation of samples to frames and visa versa, often inserts or delete frames, so that overall, the time is shifted - short or long. This fact is also what precludes us from relying on BWF's timestamps, between platforms. And lastly, will Translator ever be a software package that we can use ?

Thanks

[Chief Technician]

Why is it that Digitranslator OMF converter finds it necessary to rewrite the media files and change media names when exporting from Pro-Tools ? Often the file names that are created in Pro-Tools, carry though to the end of production. An editor looking at a file name like "PT24OutOMFw56ggGNNe5Rk.wav" has no clue what that means. At least allow us to utilize the existent file names (unchanged media) like other systems do.

Not a bad idea.

Another important requirement, would be to allow us to navigate to our own media files through the use of a file browser when importing to Pro-Tools and not using embedded file sets, instead of the way it is now - that the media must be located in the same folder as the OMF file is located.

I don't see how having the media in a folder with the OMFI is a problem. I prefer it this way.

Digi seems to have made the converter work within the confines of Pro-Tools itself, but is unstandard to the rest of the world (ie; Fairlight AVtransfer, Neuendo 2, and even current Avid workstations).

OMFI is a de-factor standard, there is no hard and fast rules developers have to follow with OMFI. This is why it is problematic, and is also why AAF should be the transfer format of the future.

Another problem with converters in general (this includes Translator 2), is their inaccuracies in spotting media correctly on the timeline - even in Avids. This seems to stem from the fact that most sound editors are sample rate based (not hh:mm:ss:ff, but hh:mm:ss:sss or ticks), while Avids are frame rate based, and the truncation of samples to frames and visa versa, often inserts or delete frames, so that overall, the time is shifted - short or long. This fact is also what precludes us from relying on BWF's timestamps, between platforms.

I have not seen this problem. I know if you go from PT-->AVID you will get "sample accurate edit" regions that pad your edits out to the nearest frame, but I have not seen audio get blatantly shifted around the timeline. The "sample accurate edit" regions make handles practically useless on an AVID, and in turn makes animation against audio difficult since they audio cannot be shifted by subframes on an AVID.

And lastly, will Translator ever be a software package that we can use ?

I use it everyday. Ever since the fixes in the cs releases for v6.4.x, I have not had a problem with it.

[lightning ad]

Another problem with converters in general (this includes Translator 2), is their inaccuracies in spotting media correctly on the timeline - even in Avids. This seems to stem from the fact that most sound editors are sample rate based (not hh:mm:ss:ff, but hh:mm:ss:sss or ticks), while Avids are frame rate based, and the truncation of samples to frames and visa versa, often inserts or delete frames, so that overall, the time is shifted - short or long. This fact is also what precludes us from relying on BWF's timestamps, between platforms.

I have not seen this problem. I know if you go from PT-->AVID you will get "sample accurate edit" regions that pad your edits out to the nearest frame, but I have not seen audio get blatantly shifted around the timeline. The "sample accurate edit" regions make handles practically useless on an AVID, and in turn makes animation against audio difficult since they audio cannot be shifted by subframes on an AVID.

[/QUOTE]

I also use it for animation, and have not had this problem....we have had the annoying "sample accurate edits" thing but there is a way around this. Depends on how you are using the audio, but as we tend not to need the handles once a dialogue edit has been locked down, we found that if you finish the edit, then go back and drag out the start and end frame of each and every edit with the grid switched to single frame, then you don't get the 'SAE"s. I also find that consolidating and edited clips removes the SAE's that often get inserted in the middle of a sentence. If you can't extend the clip because of other extraneous sounds, then consolidate a new clip with silence up to the frame boundary.

I agree with your comment about the file names, yet once they have been imported into our avids, the original names are apparent on the clips in the timeline, as well as in the bins.

Also I don't see how the problem of sample accurate verses frame accurate make a jot of difference with animation. The animation should be shot to sync up after dialogue has been cut, and as its shot to frames and not samples, there is no need for subframe accuracy once the dialogue has left the ProTools.