Serious Sync Drift after Merge Clip

[rotberg]

I'm currently syncing footage for a feature using FCP and merge clip.
I'm using the 'M' proxy files as my video and the audio is .wav.
The camera team used an old school slate so I'm syncing with inpoints.

The first 15 days of footage were fine, but the footage now drifts noticeably within about 3 minutes (about 2-3 frames off). By 7 mins into the shot its off by about 6 frames. Nothing in the specs of the either the video or audio is any different from the earlier footage that doesn't drift. (camera frame rate at 24, audio rate and format stay at 48khz/24 bit integer)

The audio was recorded on a Fostex FR2 LE.

I've read on this board that converting the files to aiff will fix this issue, but it doesn't work for me. Neither does converting the audio to 100.1% speed.

Any ideas? This is really screwing me since the only way I see to fix the issue is to resync the clips every 3 min by eye.

thanks,

jonathan e rotberg

 

[Meryem Ersoz]

I had a file that had sync drift in the file but, when I output the file, it disappeared. It was visible in the timeline but not in the finished file. Don't know how to explain it, but it might be worth a shot...

 

[Cail Young]

FCP has (at least for us) major issues with 24.00 audio/video as opposed to 23.98 - if you recorded BWF, use Sebsky Tools to convert your BWF audio to MOV files and this should fix FCP's "helpful" sample rate conversion which is blowing your sync.

 

[Nick Gallegos]

FCP has (at least for us) major issues with 24.00 audio/video as opposed to 23.98 - if you recorded BWF, use Sebsky Tools to convert your BWF audio to MOV files and this should fix FCP's "helpful" sample rate conversion which is blowing your sync.

This issue actually happens to a lot of people, not just RED users. FCP treats an imported WAV or AIFF file as a capture and therefore uses whatever time base is set in the capture settings. About a month ago, my capture setting was 23.98 when I got a completed 24 fps WAV file from a sound designer, causing a drift in the audio - I was annoyed to no end because you would never even think to look at capture settings on a tapeless workflow.

Sebsky Tools works like a charm. Free program, too.

 

[Uli Plank]

Or try BWF2XML from www.spherico.com/filmtools
(No, I'm not affiliated to that company)

 

[rotberg]

So I've realized that all my footage is f**ked with this problem.

Changing the capture settings does not help my problem.

And Sebsky Tools isn't around anymore. I'm downloading the trial version of that BWF2XML, but doesn't anyone know of a freeware program like Sebsky?

 

[I Bloom]

I'm not sure if you have the same situation but I found that just transcoding from wav to aiff and leaving all other settings alone took care of a similar problem for me. In my case we believed the problem to be embedded timecode in broadcast wav files.

IBloom

 

[rotberg]

That's funny. I believe our problem is embeded timecode in the bwf's also. But the transcoding to aiff didn't help the situation, although I've heard of that from several sources.

Just to be sure you transcoded using Compressor 48khz/24 bit?

I think the timecode on this files is 29.97 since the change over on the timecode of the file is at the :29 frame.

Any idea how I can convert these files to fit the true 24fps of the Red?

 

[GigaSnow85]

Quick question for the OP, when you say

"the footage now drifts noticeably within about 3 minutes"

do you mean when you're dealing with a 3 minute long continuous take, or 3 minutes in to playing an assembled cut?

Because I've noticed that when I transcode a rather long shot through RedRushes, i.e. a take so long that the .r3d has been partitioned into _001, _002, _003 etc, the sync will drift a frame or two after a couple minutes into this take.

I'm using 48khz/24bit 24fps broadcast .wav on flash card, imported straight into FCP.

I encounter no sync problems when playing back an assembly, or regular takes of ~1 minute long. It's just these extra long takes that seem to drift.

Could it be a problem with transcoding the partitioned .r3d files through RedRushes? Could I be getting drift on every partition that is rejoined?

Or could it be I am encountering that same problem as the OP?

Any help offered would be much appreciated!

Cheers!

 

[rotberg]

New Info regarding BWF's METADATA. 25FPS???

New Info regarding BWF's METADATA. 25FPS???

I'm talking about 3 minute continous take. By the time it reaches 3 min its already about 3-4 frames out of sync. It drifts at a rate of about a frame every minute.

I've actually discovered some new information regarding this problem.

There is no sync drift with the first 4 days of my footage. Even with takes that are 8 minutes long.
There is a difference between those audio files and the rest of my drifting audio when I look at the bwf meta data with a program that can read that info.

The files that work well have this info in the XML data:
<NOTE></NOTE>
<SPEED>
<TIMECODE_FLAG>NDF</TIMECODE_FLAG>
<TIMECODE_RATE>24/1</TIMECODE_RATE>
</SPEED>
<TRACK_LIST>
<TRACK_COUNT>1</TRACK_COUNT>


The files that are problematic have this info in the XML data:
<NOTE> </NOTE>
<MASTER_SPEED>25/1</MASTER_SPEED>
<CURRENT_SPEED>25/1</CURRENT_SPEED>
<TIMECODE_RATE>25/1</TIMECODE_RATE>
<TIMECODE_FLAG>NDF</TIMECODE_FLAG>
</SPEED>
<TRACK_LIST>
<TRACK_COUNT>2</TRACK_COUNT>
<TRACK>

The orginator on the working files is: Sound Dev: 744T S#460305081003
The originator on the problem files is the: Fostex FR-2LE.

So a different sound recorder came on and recorded things differently.
Now is there a way to fix this?? Ive tried slowing down AND speeding up the sound by 4.166% and that doesnt work.

Does anyone know of someone with lots of experience with BWFs and FCP?

thanks all,

jonathan