-
Sync Issues with FCP and ProTools
Hey there everyone. I’m having a rather strange issue with Final Cut and ProTools. I’m hoping someone has come across this problem before and might have a solution.
We recently posted a feature length film in Final Cut and ProTools. We opted to post in True 24p for the entire project with the intent to output directly to 35mm film at the end of the process. Here was our workflow:
All of the footage was brought into Final Cut as 24p Quicktime movies. Audio was brought in at 48k 24bit. The film was edited and everything was in sync and working perfectly.
We then created a quicktime movie of the entire film at 24p along with audio and send that file over to our ProTools studio. The quicktime movie was opened in ProTools and the audio was imported from the same quicktime file. We placed the audio on a track and everything synched perfectly. The ProTools session was set for 24 FPS Time Code as well. We then performed ADR, Foley, added Music, etc. in our ProTools session and still everything is in sync. No problems so far.
Here’s where we’re running into trouble.
We performed a bounce to disc of the entire session in mono (roughly 90 minutes) and sent the resulting mono AIF file back to our Final Cut station for use as a reference audio track. We imported the resulting mono 48k 24bit AIF into Final Cut and dropped it on the timeline, and now, nothing syncs up correctly. The strange part is, we have the standard 8 second leader with beep at no. 2 at the head of the film, and when we import the reference audio back into final cut, the tone (which is only 6 seconds in) is late. To make matters worse, the audio at the end of the 90 minute film is EARLY. It’s almost as if the entire audio file was time compressed, despite the fact that the audio clip is showing as the proper length on the time line.
All settings matched throughout the entire workflow (48khz 24bit audio) so I thought maybe it was a problem with AIF? I rebounced the entire audio session from ProTools as a Broadcast WAV (BWF) thinking the additional Meta data might give FCP the extra info it needed to sync the audio, but the exact same issue resulted. No sync.
I’ve never had this problem before, but then again, I’ve never worked at true 24fps, or worked on a 90 minute long project. Has anyone encountered this problem before or know of a solution? Any help would be appreciated.
Greg Steiner
Q Station
gs******@*******on.com -
10 Replies
-
can you verify if it was drop or non-drop working in fcp and pro tools? Thats the usual suspect.
-
As far as I know it’s 24 fps non-drop. I’m not personally familiar with 24 fps drop-frame, unless you were referring to 23.976?
The sequence settings in FCP are listed as 24 fps and the time code “appears” to confirm this. Same in ProTools. Is there any particular place I should look in FCP and PT to verify that it’s not using some form of drop frame other than the sequence settings in FCP and the session setup in PT?
Thanks!
-
Ok folks… additional information for you all on this topic. I’ve done some extensive testing to try and track down the problem and here’s what I’ve found.
If I “bounce” a QUICKTIME movie from ProTools (which is aparently an option I never noticed before) it Re-exports the imported reference movie with the audio included (these are obviously in sync).
When I import the QUICKTIME movie into FCP, I can lay the audio track on the timeline and it is perfectly in sync. SO…. AIFF, WAV files created from ProTools = out of sync audio. QUICKTIME movie created from ProTools = Audio is in sync.
A little further investigation revealed that the Quicktime movie is a 24 fps movie (as expected), however, the audio AIF and WAV files are being interpreted by FCP as 30 fps… even though I’m exporting them from a 24fps timeline in ProTools. There is aparently no way to manually change this in FCP as it ‘interprets’ the frame rate from the audio file.
It appears that FCP always assumes that audio files are at 30fps. I suspect that herein lies the problem I’m having with the audio.
Is there any way to let FCP know that the audio file I’m importing should be interpreted as 24fps and NOT 30fps? Perhaps this will solve the problem?
All help is appreciated!
-
the drop, non-drop i refer to has nothing to do with the frame rate, its the setting for the project itself.
both fcp and protools have these settings, if they don’t match your audio is out of whack for sure. also look at the pulldown setting.
Audio itself doesn’t really conform to a frame rate based on video. Audio “frames” are much different in that regard.
-
Both Final Cut and Pro Tools are set to straight 24 fps (no drop frame set in either case that I can find in the settings). No pulldown is being used either since I’ve kept the entire workflow at 24 fps and 48 kHz audio.
I even experimented with a few pullups and pulldowns to confirm. If I reduce the duration of the AIF to 99.9% it getes much closer, but it still is not in sync.
I’ve also tried doing some frame rate conversions going from 48kHz to 47.xxxx (can’t remember the exact ratio but you get the idea) and that didn’t work either. So far the only way to get it to sync exactly is to send the audio out of protools embedded in a 24fps quicktime movie.
I’m at a loss here.
-
thanks for the effort, I’m going to put that in my list of work arounds.
-
While I’ve never done this, Pro Tools has pull up/pull down settings to do what I think you need. They’re in the Time Code Settings/Pull Up/Down panel.
John
Dual 2.5 G5 4 gigs RAM OS 10.4.8 QT7.1.3
Dual Cinema 23 Radeon 9800
FCP Studio 5 (FCP5.1.2, DVDSP4.1.1, Comp2.3, STP1.1, Motion 2.1.2)
Huge U-320R 1TB Raid 3 firmware ENG15.BIN
ATTO UL4D driver 3.50
AJA IO driver 2.1 firmware v23-28
Pro Tools HD w SYNC IO, Yamaha DM1000, Millennia Media HV-3C, Neuman U87s, Genelec Monitors, PrimaLT ISDN -
I did see the pulldown/pullup settings, but I believe you need to have certain external hardware to use it (if I’m interpreting the manual correctly).
Either way, I shouldn’t have to perform a pullup or pulldown since everything was done as straight 24fps. This is evident since I can export from ProTools as a quicktime movie and everything syncs correctly. The only difference I can tell is that when it’s packaged as a quicktime movie it is “synced” with a 24fps video track.
It seems as if final cut interprets all imported AIF files as 30 fps. I’m beginning to suspect that this is the problem (even though technically, audio files don’t have a frame rate, only a sample rate)… maybe a glitch in the program design?
-
Interesting that it’s a drop frame issue – I always assumed it was a 24 v 23.976 thing but this makes sense. I’ve often noticed drift on PAL projects that adds up to about 4 secs every 45 mins, which seems about right… oddly the waveforms in FCP’s timeline sit against existing audio as expected, but don’t reflect the sound played back.
I’ve remedied this by throwing the wav or aif into an NTSC or 23.98 timeline ( (and I now realise, drop-frame) and re-exporting the aiff from FCP, which then imports correctly, as it’s now presumably drop-frame-flag agnostic.
Quad G5/NVidia Quadro/Kona LHe/Infortrend RAID/Final Touch HD 2.6.1/FCP 5.1.2/OS X 10.4.8
-
Couple of clarifications here… Digital audio does in fact have a frame rate in the sense that the sample rate is divisable by the frame rate. In other words, there is a relationship between your sample rate and your frame rate… change one and you change the other.
As far as Drop vrs Non-drop goes… this should only effect the placement or offset of the audio to the picture. It should not cause drift because both NDF and DF have the same frame rate 29.97 for NTSC video.
I suspect the problem lies with the bounce in ProTools. If you just bounce to disk with your system running on internal sync you are no longer synchronizing to the rate established by the picture… in effect, you are pulling up. Even if you set PT for pull down. You must use a Sync I/O clocking to an appropriate external source to force PT to clock to that rate all the time… even when bouncing to disk. When you bounce to QTM, PT clocks to the rate of the QTM file… which would explain why QTM audio tracks are working.
Reply to this Discussion! Login or Sign Up