Audio drift in 23.98 timeline REDUX

[Nathan Shuppert]

I’ve already done the speed adjust in FCP–and it works more or less.
This does not help me however as this project will go back to Pro Tools to match back to several pieces of what will become 5.1 audio.
We need to figure out what to to within Pro Tools so we can match back to it for final sweetening.

What we don’t know if it’s a speed adjustment, a sample rate adjustment, a pullup or pulldown adjustment….???

So far nothing has worked.

[The Edit doctor]

They probably removed pulldown on output the first time making it a 24fps audio. Was the audio too fast for picture or too slow? They tricked you, Shane.

[The Edit doctor]

you didn’t answer the question. is the audio FASTER in your FCP timeline than the picture…or slower?

[Nathan Shuppert]

it drifts slower. adjusting the speed in FCP to 100.08 % gets it very very close.
If we can’t figure out the correct fix in Pro Tools, I may have to use this method at least to get a cut going, then figure out the drift issue on the back end.
It would be great to figure it out now though.

[Nathan Shuppert]

it drifts slower. adjusting the speed in FCP to 100.08 % gets it very very close.
If we can’t figure out the correct fix in Pro Tools, I may have to use this method at least to get a cut going, then figure out the drift issue on the back end.
It would be great to figure it out now though.

[The Edit doctor]

Nathan,

It seems there are many things incorrect with this. I hope a lesson gets learned.

In the future… don’t go directly to Protools. Use a dedicated recording device.

Now, your picture is 23.98 – and you are sure of this?! Take a quicktime of one long shot. Leave the audio tied to it.

create a 29.97 timeline and drop the 23.98 picture into the 29.97 timeline. Render it and output a 29.97 quicktime movie. You could put a timecode burn in on it for reference too using FCP TC filter as well.

now you have a 29.97 movie with camera audio on it.

Have the PROTOOLS import the 29.97 move (which now has pulldown on it) into their PROTOOLS. Have him to the same thing…sync up the clap to picture. Is it faster or slower. This will determine you speed/sample issue.

[Nathan Shuppert]

absolutely picture is 23.98.

i will try this tomorrow. thank you.
but to say don’t use PT is a little strange to me.
what would you use instead if you need to multitrack?

thanks for your help.

[Aaron Neitz]

This thread has hurt my brain.

It totally sounds like the PT computer is re-adding a pulldown when he’s bouncing you AIFF files. PT took real-time audio in, but it was marked for 29.97, so subsequent playback in the studio will be slower than real-time. And when he bounces that audio out it’s miscoding as if it were 24.0 frames audio… so it’s getting double slowed down. 100.08% falls perfectly into the math if real-time audio is slowed down to 23.976 TWICE. Dig?

It would have been better for him to record at true 30fps timecode 48.0khz audio. And then you could have 99.92% that stuff in FCP for editing. it sounds like you were shooting a band in their studio? that’s why you need to get back to the PT for a 5.1?

Edit Doctor gave you super suggestions. You might also want to try: get some WAV or SD2 from the PT guy. FCP can read them fine. Maybe it’s the transcode to AIFF? Have the PT guy re-conform all the multitrack the audio to 24.0 fps/48.048 khz and THEN give you aiff files.