-
Audio Drift in 23.98 timeline
The setup: shot footage on Panasonic P2 camera 720p 24p Native setting in the camera. Boom mic and lav audio was recorded into a Pro Tools session. Camera Ftg imports fine back into FCP via P2 import. Throwing it into a 23.98 timeline using DVCPRO HD 720p60 codec, 48khz/16 bit. Audio and video both play great with no rendering needed. Here’s the problem. When I import the Pro Tools audio back in to FCP and sync up to the slate clap, the audio drifts. Starts out fine and in sync, but over several minutes it drifts. We’ve tried everything we know to make it right and so far, nothing is working. Please shed some light, Cow Gurus.
Nate Shuppert
MacPro Dual Core Intel Xeon 2.66 GHz
4 GB RAM
BlackMagic Decklink HD Extreme -
9 Replies
-
Try this to find out the difference: Find a long take with a sync point at the beginning and end (say, the slate and a door slam). Put the video in your timeline, and mark an in point at the slate clap and an out point at the door slam.
Put the protools audio in the viewer. Mark in at the sound of the slate, mark out at the sound of the door slam. Now place the audio into your timeline with “Fit to Fill” into the marked area.
Now look at the audio in the timeline, and see what it’s speed adjusted to. That should give you an idea to start with. I’m guessing a 1/10th of 1 percent (.1%) difference in the audio.
My first thought was wondering what the clock was for the protools recording session.
-
set audio speed to 99.92%.
your pro tools guy was editing in 24.0 frames.
-
Did the fit to fill–it comes in at 100.09%. Basically the opposite of 99.91%. The real issue is, however, that once I’ve finished cutting in FCP all audio will have to go back to Pro Tools for a final sweeten. My audio guy is going to time stretch the entire recording in a new session to 100.09%, give me that audio, then he’ll have to macth back to that. A serious thrash, but it might work. Any other ideas?
-
huh… i’m just surmising, but it almost sounds like his Pro Tools brought in your OMF, assumed it was 24.0 and translated it down to 23.98. so it ended up getting 2 speed hits??? wierd.
personally I prefer giver the mixer a downconveted digibeta to mix to. that way he’s working at 29.97 which is a perfect speed match to 23.98. That way your mix stays in sync when you go back to HD land.
-
with all due respect, i think you might be confused on what’s happening here.
i’m dealing with 2 separate audio sources: camera audio, which stays in sync with picture, and audio from a Pro Tools multitrack session which was recorded during the actual shoot (the shoot was at a recording studio) . there aren’t any OMF’s being dealt with here.
my audio guy is bouncing the original session audio(boom on ch1, lav on ch2) out of Pro Tools, giving me 16-bit, 48kHz aiff files.
When I import the Pro Tools session audio back into FCP and sync up to the camera audio using a slate clap, the audio drifts. Starts out fine and in sync, but over several minutes it drifts. The fit to fill workaround works OK for editing in FCP, but ultimately this show will go back to Pro Tools after I’ve edited picture, and we want to match back to the original audio.
We’re still trying to figure out why this is happening, and what to do to make sure it never happens again.
thanks for your help.
-
How did the mixer deliver the audio to you? A while back I had the same problem when our Pro Tools guy gave me .WAV files. It seemed FCP was calculating the length of the audio based on number of samples and was getting the length wrong which caused drift.
Sean
-
the original Pro Tools audio is 24-bit 48k..being bounced as 16-bit 48k AIFF to match my camera audio and sequence settings.
what did you do to get the issue resolved?
-
I keep thinking there’s something with a clock somewhere.
Let’s say you recorded into protools at a rate of 24 frames per second. At 48000 samples per second, that would be 2000 samples played back each frame.
If instead you recorded into protools at rate of 23.976 (23.98), then 48000 samples in a second would work out to 2002 samples per video frame.
If you had to adjust your audio at 100.09 (about 100.1%), then your audio was running too slow, and you had to speed it up. Or another way of looking at it, you weren’t playing enough audio samples per each video frame to stay in sync.
Perhaps something happened to the video during the translation to DVCPRO HD, or something happened to the sound with clocking during recording in protools, or exporting from protools.
When sound is shot against film, sometimes the recordist uses 48,048 samples per second. Then the film is transferred to video (which slows it down by .1% during telecine). A way to slow down the sound is to play it back at 48,000, which slows it down by that same .1%.
However, if you were to take the transferred video, and play it back at 24 frames per seconds (its original speed — instead of 23.97), then playing sound recorded at 48,048, but slowed down by playing back at 48,000, would case the sound to run too slow.
In your case, if you took your 23.97 video, and conformed it to play those same frames at 24, then the separately recorded audio would be too slow, and would have to be sped up by the .1% (100.1% speed adjustment).
Perhaps something of this sort occurred to audio or video. I’m not terribly familiar with protools to tell if there’s setting there that could fix/cause the problem. Perhaps you could check on a protools discussion somewhere if anyone has seen this problem.
-
[nshuppert] “what did you do to get the issue resolved?”
My hypothesis was that because they were wav files, FCP was reclocking them as they were imported. Since you have aif, I highly doubt that’s the problem.
You can use FCP’s modify timecode function on your aiffs to make your TC whatever format the pro tools TC is (like 29.97 non-drop). Then get on the phone your Pro Tools person and compare TC numbers to specific moments in the audio. Then you can at least eliminate user error from either end.
Sean
Reply to this Discussion! Login or Sign Up