fcp 7 audio/video drift/sync

[Bouke Vahl]

NTSC based framerates are 30 * 1000 / 1001, or 24 * 1000 / 1001
So to be correct, it’s 29,97002997002997 and 23,97602397602398

For normal math, to calculate sync stuff for normal content (let’s say up to 2 hours), 29.97 is accurate enough, but the rounded 23.98 is not. 23.976 however is way better.
The difference between 23.98 and 23.976 makes for 0.6 seconds over an hour. And 0.6 seconds off, well, that is not accurate enough for us.

hth

Bouke
http://www.videotoolshed.com

[Michael Gissing]

Yes Bouke. I used to have the 23.976 formula written down to the extra decimals to do an audio file conversion for feature length programs for that very reason. It did matter

[Michael Gissing]

[Mark Suszko]”In all the banter about frame rate, anybody check and match the audio SAMPLE rates?”

The problem was the incorrect frame rate metadata causing FCP to think the audio was not 48khz @ 29.97, even though it was. Over the years the single biggest cause of audio drift in FCP has not been sample rates but the way FCP applied a frame rate to audio files and then would in the background, varispeed them to correct their frame rate against the sequence frame rate.

In this case the audio sample rate was absolutely correct but the frame rate had been stamped as 29.975. All FCP could do was to drift the audio. I wish FCP had never included in its software this ‘feature’ of affecting audio speed based on a frame rate metadata stamp. It has been the culprit in most of these sync problems. Sample rate has almost never been the culprit.

Once again in this case the problem was solved when I realised the frame rate metadata was incorrect. When that was fixed using Cinema Tools, the audio drift didn’t happen. So no need to check sample rate as it was always correct in this case. I wish a permanent sticky thread outlining FCPs audio behaviour could be applied to this forum.

[Ted Coakley]

Sorry, Michael, I don’t understand this.

You said, “The problem was the incorrect frame rate metadata causing FCP to think the audio was not 48khz @ 29.97, even though it was.”
* Do you mean that my FCP7 Viewer could only playback my 29.975 metadata Clip as a 29.970 Clip, and thus the A/V drift?
* And do you mean that my FCP7 Viewer could not see my 48khz clip as 48khz for some reason, and thus the A/V drift?

You also said, “In this case the audio sample rate was absolutely correct but the frame rate had been stamped as 29.975. All FCP could do was to drift the audio.”
* Do you mean that my video Clip’s ACTUAL fps is 29.970, and its ACTUAL audio is 48khz, but because the Clip’s metadata was stamped 29.975, that that causes FCP7 to think, “Oh, since this Clip is 29.975, it must NOT be 48khz, so I’ll play it back at a different khz.”?
* If so, then at what khz DID my FCP7 choose to playback my 48khz ?
* If not, then what did you mean?

You also, that FCP would “…… varispeed them to correct their frame rate against the sequence frame rate”, but keep in mind, this is an issue in FCP7’s VIEWER – NOT anything related to FCP7’s Sequence, Sequence frame rate, or any other Sequence settings.
* With that in mind, that there’s no sequence frame rate against which FCP7 would varispeed, what’s your thoughts on the matter?

I’m just trying to get everything totally dialed, understood and setup right, before I dive into a couple hundred hours of archival miniDV transfers (and before I get more of those tapes transferred).
Thanks!