Some of my co-workers discovered an alarming bug with Quicktime based AMA workflows where changing the playback head position in QT Pro will modify the source timecode of a clip when it's imported into Avid. We're still working in 5.5.3 so the bug may have already been resolved in 6/6.5, but I haven't seen any mention of it on the forums and thought it was worth calling attention to.

If you open a file in Quicktime Pro and move the playback head to anywhere besides the first frame, Quicktime will allow you to save the position of the playback head so you can pickup where you left off at a later time. Simply hit command-S and close the file.  That's all you need to do.  No frames are re-encoded and the source timecode and duration remain the same. If this file is then imported into Avid, the start timecode will be shifted to reflect the position of playback head and NOT the actual start timecode.  The duration of the file remains the same and all frames are accounted for, however the source timecode is offset by however far the playback head was into the clip when it was saved.  This happens regardless of whether the file is brought in via AMA or File>Import...

Here's an example with some Alexa media to better demonstrate.

A015C003_120620_R396 ORIGINAL is the camera original file linked to via AMA.  Start TC is displayed as 18:56:55:23 which is correct.  I then duplicated the file, opened it in QT PRO, moved the playback head to 18:58:42:09, and saved it.  I renamed the file A015C003_120620_R396 SAVED and linked to it via AMA and the start TC is now offset to 18:58:42:09.  A015C003_120620_R396 SAVED.mov is that same file imported with File>Import.

The obvious workaround is to not save camera original files when you open them in QT Pro. This is easy policy to implement in a post facility, but what's to ensure a producer or DIT doesn't open files and accidentally (or even purposefully) save them before they get to you?  

Does anyone know if this is a known bug?  If so, was it fixed in later revisions? Thanks in advance for any insight.

Eric

Thank you for alerting us to the problem Eric.

This problem does not appear to affect MC 6.5.  I installed the demo today and the original and saved files imported with identical timecode.