If so, then I’ve got a little tidbit that you may want to keep locked away somewhere easily accessible in your mind…particularly if you’ve ever been on the receiving end of this statement, “The audio file(s) you sent me doesn’t sync up to the picture.”
This conversation usually starts with a passive aggressive attempt to blame me for the issue. While that’s certainly a possibility, I’ve found that, more often than not, it’s an issue with Final Cut. Obviously, due dilligence requires that we apply “Occam’s Razor.” From the editor’s perspective, the simplest answer is that I am at fault. Here are the conditions you have to clear before you blame it on Final Cut…and, ultimately, the editor:
- Is the audio drifting consistently out of sync, or only out in certain scenes? [If it's drifting...that's a check mark.]
- Were you and the editor using the same frame rate? [Yes? ...check]
- If you are using an external sync source, were you locked to the correct reference type? [Yes? ...check]
- Did you have pull-up/pull-down enabled; either for the session or for the bounce? [No? ...check]
If you’re confident you did everything right on your end, and that there aren’t any other factors that could be contributing (sample rate a possibility?), then it probably is Final Cut. I should clarify that this is an issue with version 7 (maybe 6 too, I can’t remember…it’s been a while). I have no idea if the problem occurs with FCPX. I haven’t worked with anyone using that version yet; and likely never will.
The problem is typically drifting sync. A very early indicator is if you’ve been working with a session that is the same exact length as the Final Cut Sequence; the audio will be either shorter or longer than the full sequence upon import after it’s gone back to the editor. The program begins in sync and slowly drifts, as if it were a sample rate or frame rate issue. In truth, it is. What commonly causes this, is a mismatch of system settings in Final Cut. The sequence is set to one frame rate, while the overall Final Cut default frame rate is set to another. Let’s use 23.976 (sequence) and 29.97 (Final Cut default) as an example. Guess which setting Final Cut uses when it imports media?
If you guessed the “default” setting, congratulations. You’re correct. One would think that an audio file that is exactly 30 “real” minutes long is 30 minutes no matter what, but that’s not the case. Final Cut appears to try and compensate for frame rate discrepancies on the timeline (because there can be frame rate information in the metadata header). Final Cut can, after all, have mixed format media on a timeline. [Which is a horrible way to work, for many reason...but beyond the scope of this article.]
The way to correct the problem that occurs on import is to set the Final Cut default settings to match the frame rate of the sequence the media will be imported to. The real problem is that when Final Cut imports a piece of media, it re-writes the metadata in the header file! [...at least, it does with audio files...]
Whoever thought that was a good idea needs a firm, “boot to the head!” If the settings aren’t matched prior to file import, the possibility exists that Final Cut will completely garble the metadata in the header section…because any subsequent attempt to use that file, even if it is removed from the project and re-imported from its existing hard drive location, gives the same result…drifting sync. That file has been permanently corrupted! The editor needs a fresh copy.
The file the editor originally imported needs to be deleted from his or her system. Load a fresh copy from your workstation. If you’re using a shared server, then hopefully the editor copied it to a second location before importing it. If they didn’t create a second copy, hopefully you didn’t bounce directly to that shared server (meaning, you still have an uncorrupted file on your system somewhere). If you did bounce to the server, then you need to create a brand new file…enjoy that extra bounce time.
Once the editor has made the frame rate change in the settings of Final Cut, importing the new uncorrupted audio should solve the issue. I’ve run into this so many times where I work that I stopped counting months ago. We’ve had one editor who has consistently been able to correct the issue. [I should note that it never occurs in her projects.] This is the solution we’ve narrowed it down to. It works almost every time.
There’s been a small number of occassions when the offending Final Cut sequence has to be moved to an entirely different system; in fact, it’s only happened twice. Both times, the frame rate setting and a fresh file solved the problem once on the new system.
I’ve seen other people mention this problem online in the past. This problem could also pop up when importing original production files. So, keep an eye out for that too. I’d have posted the solution earlier, but I only confirmed it this week. Hope it keeps you from pulling your hair out in the future.
Apparently, there’s another way to deal with this issue. According to Charles Dayton, supplying the audio as a Quicktime file can eliminate the issue entirely. Thanks for the infor Charles!
Yeah, I know. It’s only a matter of time before people stop using FCP7 entirely. To be honest…I can’t wait ’til it happens.