Timecode inconsistent with 24P DVCPRO HD

This may be a topic Walter Murch discussed in October, but I have not seen the DVD of that meeting.

In December, I digitized the new Alan Cumming directed feature "Suffering Man's Charity" here in LA before it was shipped off to NY for post. The movie was shot with the Varicam in 24p. Sound was recorded to BWF files which were delivered on DVD-Rs to me. Both the hard disk recorder and the camera were fed time-of-day timecode by a 3rd device.

I'll get to the "bug" in the next paragraph, but first, here is my process for syncing the audio and video clips. I used Sebsky Tools, (primarily, but BWF2XML produced the same bug when it was tried,) to convert the BWF to MOV files with their timecode. In FCP, I simply dumped the MOV files into the same bin with the video dailies for the same day and sorted by timecode. As a rule of thumb, each video clip was preceeded by its corresponding audio clip. I selected each corresponding pair and merged the clips, telling FCP to "use timecode." The clips were merged perfectly. I then dragged all the merged clips to a timeline, un-linked them, deleted the original camera audio, and generated new merged clips that only contained the 24bit .MOV audio. This is what I delivered to NY, believing everything was fine.

Our editor in NY discovered a disparity in the audio and video timecode within the merged clips. Whenever he tried using matchframe on audio, it would pull up the wrong section of audio from the clip. A visual manifestation of the disparity occurred when the TCR filter was dropped onto a merged clip. The TC reading on the filter and the TC reading in the viewer window would be off by 10 to 20 seconds. In any given clip, the disparity remained consistent - but every clip was "off" by what seemed to be a completely random number.

I remind that audio and video always SOUNDED and LOOKED in perfect sync - and timecode was the ONLY way that these clips were synced in the first place.

We tried every imagineable solution including Cinema Tools conversions (23.98 vs. true 24p,) proxy files, stripping TC and generating new TC and this problem remained. We briefly flirted with Apple Pro Care and they took the easy route blaming our difficulties on Sebsky/BWF2XML so I decided to create a controlled experiment and I generated, using compressor, a 24bit MOV audio file from scratch and a 24p DVCPRO HD video file from scratch, imported them into FCP, assigned both new timecode with the identical starting time - and merged via timecode. Same problem! By this time our Pro Care had expired and I couldn't call back to seek the verbal revenge I had fantasized about...

While this bug would not be an issue for me because I do not make use of the matchframe feature, our editor felt he had one hand tied behind his back. The simple workaround was to export every merged clip as a new quicktime file and reimport those, assigning them the correct video starting timecode. This was time-consuming and sort of a shame after we had all been assured that working with DVCPRO HD would be a smooth operation.

I urge others to try to recreate the issue I encountered, and if anyone remembers Murch discussing this particular issue in October, let me know what the details were and if they ever found a workaround.

Hi,

Michael Horton asked me to have a look at your problem.

As far as I understand you seem to have run into the the oldest long term FCP trap: "audio before video". This trap works "fine" with both merged and subclips. It has nothing to do with 24P or 25 or 25P or whatever framerate or format.
Since I can insert a small graphic, I'll try to do create one with letters:
   vVvvvvvvv
aaaAaaaaaaaaa
This it what normally happens in FCP when you are shooting film and audio on different devices. You can synch this clips on TC or clapper (capital V,A), cut off unused material:
vVvvvvvvv
aAaaaaaaa
And those clips are working fine as long you are not using the TC.

That's why I did an AppleScript utitlity some years ago to synch picture and sound, which does the correct "cut off" in advance before FCP does mess it up.

So - finally no good help, but you did everything the way it normally should work. The only workaround currently is the one you described: exporting the synched clips, or make the imported audio shorter then the video part in advance.

If I missunderstood your problem let me know.

Regards
Andreas



Some workflow tools for FCP [www.spherico.com]
TitleExchange -- juggle titles within FCS, FCPX and many other apps.
[www.spherico.com]

Thank you for the graphic!

So, to paraphrase, if audio had started rolling AFTER video, then FCP would not display these peculiar timecode disparities?

-Alex

In my experience over the years it did not happen, but I can't guarantee, as I'm not the FCP development team - which is a good luck for you ;-)

Regards
Andreas



Some workflow tools for FCP [www.spherico.com]
TitleExchange -- juggle titles within FCS, FCPX and many other apps.
[www.spherico.com]

I believe what you are describing is correct. Given what you said, I figured there must be a correlation between how "off" the TC is and how much ealier the audio clip begins. Indeed, the TC is off by a consistent ratio to the "earlyness" of the audio from one clip to another. That ratio is 1.7. Why, I'll probably never know.

Is your applescript available anywhere?

Thank you so much for your answer!

-Alex

I haven't tried the app on Tiger (to be honest), but it should work. I will have a look at it tomorrow (currently 01.44 a.m. local time here).

Regards
Andreas



Some workflow tools for FCP [www.spherico.com]
TitleExchange -- juggle titles within FCS, FCPX and many other apps.
[www.spherico.com]

Regarding the application, there are good news and bad news. So the app runs fine on Tiger without any trouble, but a lot of QT scripting seems to be not compatible anymore. It needs some time to go thru that, especially since there are obviously quite a lot of different handlings of scripting within the subversions of QT 7.x (in this special case).

Depending in your timelime the next version of XML2Text might be the solution, since it does include a logging feature, which can be easily extended to a synch feature.

Kind regards
Andreas



Some workflow tools for FCP [www.spherico.com]
TitleExchange -- juggle titles within FCS, FCPX and many other apps.
[www.spherico.com]