-
Audio Drift Dilemma — Makes no sense, but VERY serious nonetheless
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–we find a drift of approximately one tenth of one percent (.1 %). Therefore, at the end of 22000 frames (approx 12 minutes) of footage, our audio is out of sync by 22 frames–more than enough to sound like a gigantic out-of-sync issue. 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.
We’re editing non-drop because this film is being generated a for a very unusual, fully digital theater projection system that ONLY plays in 30 fps. Pure 30fps; no drop frames. (Go figure.)
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.)
–MichaelMichael Starobin
Founder, Creative Director
1AU Global Media, LLC
Olney, Maryland -
15 Replies
-
Michael, you seem to be somewhat confused about timecode and framerate, and you essentially use them interchageably in your post.
Timecode does not affect framerate. Drop and non-drop timecode are just two different methods of accounting for the running-length of video, with drop frame displaying accurate running times. Changing from drop to non-drop or vise versa has no impact whatsoever upon the actual framerate of te underlying video or audio.
Meanwhile, with regard to exporting at 30fps. That also seems to me to be a case of mistaken terminology on your part. Exactly where did you come up with the idea of a projector requiring “true 30fps” video? That seems entirely nonsensical.
People often (incorrectly) refer to NTSC video running at 29.97 as 30fps. If indeed you’re forcing an export to true 30fps and then bringing that back into FCP, which is running at 29.97, you will encounter drift.
David Roth Weiss
Director/Editor
David Weiss Productions, Inc.
Los AngelesPOST-PRODUCTION WITHOUT THE USUAL INSANITY ™
A forum host of Creative COW’s Apple Final Cut Pro, Business & Marketing, and Indie Film & Documentary forums.
-
[Dave LaRonde] “So how do your get your epic to play back on this 30fps-only system? Finish your edit, export a quicktime movie, and use Cinema Tools to conform it to 30.”
Dave,
You beat to the punch… Do you really think ther 30fps projection thing is for real, or just another another misunderstanding???
David Roth Weiss
Director/Editor
David Weiss Productions, Inc.
Los AngelesPOST-PRODUCTION WITHOUT THE USUAL INSANITY ™
A forum host of Creative COW’s Apple Final Cut Pro, Business & Marketing, and Indie Film & Documentary forums.
-
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.
Michael Starobin
Founder, Creative Director
1AU Global Media, LLC
Olney, Maryland -
Sample rate is what determines audio speed.
If you have 48,000 samples per second, and that is in your 30 fps timeline, you have 48,000 / 30 samples per frame of video, or 1600 samples per frame.
If you take that audio to another program, that runs at 29.97 (the program might call this 30, causing confusion) then you have 48,000 samples per second, in a 29.97 fps timeline, and since 48,000 samples still occupies 1 second, there are 48,000 / 29.97 samples per frame of video, or 1601.6 samples per frame of video.
Placed back in a 30 fps sequence, the 1.6 sample difference per frame would be 1.6 sample difference * 30 fps * 60 second * 12 minutes, or 34560 samples played sooner in your 30fps sequence after being reference to 29.97 in another program.
34560 samples, at 48,000 samples per second, is 72% of 1 second. 72% of 30 frames per second is 21.6 frames. There’s your 22 frame difference.
By taking your sound to another program, you’re referencing it to 29.97. By conforming it and some connected video in compressor, you are re-referencing it to 30.
-
Excellent post, Steven.
Also for Michael, I am not sure what your FCP easy setup is set to, but I have seen and heard similar issues when importing audio for PAL when your project is set up for NTSC. The audio will be sampled @ 29.97 fps instead of the 25 you’d expect, causing an apparent drift. I would think that since it works when you have married 30.0 fps video to your audio that FCP simply brings in the file at whatever fps the movie is (it won’t conform the fps of imported movies to your project) and of course the audio will follow suit. When you import audio without video it assumes a frame rate that is somehow attached to an easy setup or video setting internal to FCP. I have not been able to track down where exactly that would be, but I am sure with some tinkering, we could find it.
Jeremy
-
…and from a few posts down. Talk about synchronicity.
https://forums.creativecow.net/readpost/8/1006953
Jeremy
-
I feel your pain. Thanks soooo much for the post regarding embedding the audio in a video.
I am editing a feature @ true 24 / 48hz 24bit and ran into this same problem, just at 24fps.
In fact – If I export/AIFF mixdown out of FCP and re-import that exact file back into the sequence, it is out of sync and the file is short.
It does not matter the method used to get out audio only, export AIFF, QT conv etc, it always reimports with drift.The only way to get matching is to export a QT with audio or OMF.
When reimporting a mix/sound design session from Cubase/PT/Logic without replacing the audio the reference video, guess what… out of sync.
All parameters set to true 24FPS with audio @ 48/24. All Audio matches in sync in every program upon import EXCEPT FCP 6.3 when imported.
Be it confusion about frame rates, timecodes, magical internal working gnomes… I find it odd that all other programs are in sync.
This problem is extremely annoying. FCP cant seem to output a simple 8 track mixdown to stereo and reimport in sync?
-
[Je Moore] “All parameters set to true 24FPS with audio @ 48/24. All Audio matches in sync in every program upon import EXCEPT FCP 6.3 when imported. “
When you say all parameters, meaning you have created an easy setup that points to everything being 24.0 fps? Are you sure about that?
Jeremy
-
this is the most time consuming bug I have yet to personally encounter and it is a bug
I have encountered the same behaviour in Europe at 25fps and I am old enough and wise enough not to mismatch frame rates or audio sample rates
it is a pure bug and apple had better fix it
cos it has sucked so many hours away from my workflow
right when you are trying to render out the final master of your project, with all edits finished and audio mixed
you get a phantom sync problem
its ridiculous
-
I am having exactly the same issue. Sequence setting: ProResHQ 1920×1080 30 non-drop 48khz 16bit audio. My sequence is 4:30. Settings in Soundtrack Pro are the same. After sending to Soundtrack Pro, duration of the sequence in STP matches sequence in FCP. But after exporting and either having STP send it to FCP or importing the audio myself, the exported tracks are now 8 frames shorter. It is definitely a progressive sync drift. This is driving me crazy.
Reply to this Discussion! Login or Sign Up