Audio Drift Dilemma -- Makes no sense, but VERY serious nonetheless

Question

Hello everyone,
This is the SECOND time in 4 months I've encountered this problem, and it's serious. I'm using FCP 6.0.4 in a sequence that's 30 fps (NON-drop), 48kz, ProRes. Here's what happens: I take a VO track from my main edit and export it for use in an audio authoring program. But when I REIMPORT that audio back into FCP--taking it from an audio program back into FCP-- the audio drifts approx .001 per 10 minutes of footage. And let me be clear: we have rigorously determined that all the project and sequence and timecode settings are precisely conformed, at least as far as the software allows us to set them or double check them.
This problem ONLY seems to happens on import. Audio created in FCP is not drifting. Audio created OUTSIDE FCP is the problem. We have also tested multiple applications, including Soundtrack Pro and Digital Performer (something outside the FCP Studio realm). If we send a QT outside to another application, build tightly integrated audio, then bring that audio file back into FCP, the AUDIO DRIFTS.
Egad. This is a big problem, and it has now happened more than once, and the way we worked around the problem before was far from elegant or acceptable.
Anyone else experience this? Anyone have a suggestion?
(Naturally, I'm racing the clock for deadline.)
--Michael

Answer 1

Ah-ha. I think we have a solution. Plus, I think I can also put to rest some of the logical, yet erroneous suppositions of previous posts. One thing's for sure: I confused matters by conflating the terms "frame rate" and "time code" in my initial post. I realize the difference--it was simply a matter of imprecise writing and I think it sent people astray.
Here's the deal: we are NOT producing for an NTSC system. The projector system IS in fact 30fps playback. It IS like nothing else you'll find anywhere through traditional vendors. There are only 30 of these systems currently in existence (although more are coming online every month) and they are rather exotic and spectacular.
It's important to say also that our source media is also NEITHER NTSC NOR HDTV. Our source media is completely CG. Our frame size is 4000 x 2000.
Now: our discovery. It turns out that FCP 6.x requires a video source married to an audio source for preserving a reliable frame rate if you're editing at PURE 30fps.
What we did was export an H264 QT from FCP with embedded sound at a frame rate of 30fps. (It was ACTUALLY 30fps, non-drop. Really.) We then took that QT and brought it into Digital Performer where our composer authored the music and sound. His project settings were 30fps, non-drop. When complete, he exported an AIFF file (48khz, 24-bit, just like our FCP settings). But when we imported it into FCP 6.0.4 (30 fps, non-drop sequence settings) we discovered the AIFF which had matched perfectly in Digital Performer was now visibly shorter in the FCP sequence. On inspection, it was 22 frames shorter. Our original video timeline is 21,346 frames. The newly applied AIFF came in only at 21,324 frames.
When we imported that SAME AIFF into Soundtrack Pro (simply to double check ourselves) the duration showed itself to be precisely the same as the original source FCP sequence. And when we export that file from Soundtrack Pro, there's no problem with the AIFF file either. It comes out, just like the Digital Performer file, the proper frame count: 21,346. But when we IMPORT that AIFF file into the FCP sequence, the problem crops up. It imports SHORT. It doesn't matter the source audio application: the audio comes up short when it's IMPORTED BACK INTO 30fps FCP sequence.
It turns out that a 30fps FCP sequence needs to see the audio within a QT that has video at a pure 30fps. This is NOT the case for other frame rates, but it IS the case for this specific, precise scenario. To import audio into a 30fps FCP sequence requires a QT with video, essentially turning that embedded video signal into a veritable timekeeper.
Here's our workaround: what we did is take the audio originally authored in Digital Performer and brought it into Soundtrack Pro. We then forced an export of that audio with the video and told Compressor to force that video and audio to conform to 30fps. Suddenly, the audio no longer drifts in the FCP sequence at all: instant audio/video conformation.
We came to this conclusion after it occurred to us that no, we were NOT using media captured through a camera or other time code generating device. All our media is computer generated, and thus it is not embedded with time code. It is pure 30fps.
It is our belief that this is, in fact, a genuine bug in FCP 6.x. Further proof appears when we zoom way, way down into the audio waveform. The files appear to be perfectly matched when we compare the source file with a re-imported version (having undergone a round trip out to an audio application and then sent back into the FCP sequence). The waveforms are matched but THE AUDIO PLAYBACK IS NOT. By the end of our 12 minute video the sound in these two lines has diverged by 22 frames.
When we used the exact same pipeline in FCP 5.x we edited at a pure 30fps and did not encounter this problem. But since almost no one actually cuts in a pure 30fps, it's possible that some minor details in the new FCP code are now slightly askew for that particular parameter, hence the slight variability in how audio and video both play at 30fps. We don't know the cause; we're just guessing.
Finally, credit where credit is due. After many, many mental and real-world experiments, hair-pulls, and hard stare-downs, my extraordinary editor and close associate Victoria Weeks solved this conundrum. She's whip smart and tenacious like you've never seen...and I do believe that in the great galactic encyclopedia she's just earned herself a major footnote in editing history.