0

Hi,

A problem has arisen in a couple of our MAC's where the bounced stereo mix is out of sync once it has been inserted into FCP. The mix starts in sync but around halfway it goes out of sync by approximately 5 frames. All my settings seem to be fine and the sample rate is correct for PAL. But when I click on playback engine, a message appears saying "HW device is at a different sample rate from the open session". I checked everything but all seems to be fine.

Can anyone enlighten me on what the issue might be?

Thanks

Improve this question
1
  • What would further help is if there's a tailpop on the print, that way it's known how much drift happens over what exact length of time - that can help narrow down if we're looking at a pulldown issue or some other weirdness. You mention half way through is 5 frames out, but what's the total program runtime? – Stavrosound Nov 19 '12 at 0:30
2

It sounds to me that you're running into a pulldown issue, which WILL cause sync to gradually drift over time. Check your PT session setup and make sure there's no pulldown/up enabled (and subsequently, if there's a way to check this in FCP, it's, worth doing so as well). Framerates and pulldown/up are different animals - you can have two things using the identical frame rate (PAL 25, which may look just fine at first), but if one has a pulldown and the other doesn't (or they both have different pulldowns), it will throw sync regardless.

Also, more clarification would be helpful. Are you running ProTools while running FCP? Is there a reason you need to be if that's the case? Is your computer audio out feeding in the PT hardware so you can audition it on the mains, and that's why you need PT open or use the HW device via CoreAudio?

The only issue I see so far is that when you load in a printed file into FCP and it's causing a sync drift against pix, you have a pulldown/up issue or incorrect framerate at which the original print was made at (like 23.976 or 29.97 which run at 0.1% slower than 24 and 30), and that's causing the discrepancy you see in FCP with the audio print.

As to the secondary issue of the HW device and sample rate, some more clarification as to the circumstances would be helpful. It doesn't seem to figure into the equation of the problem unless I'm missing some key information (as questioned above).

If what your saying is that the HW is serving as your mains even with PT is not running (e.g. using it via CoreAudio), it's possible that by having different sample rate settings it can cause an issue where everything you hear from that device will be out of sync, but normally devices will override with the sample rate they need, unless the HW is still slaved to another device (e.g. trying to run PT while feeding CoreAudio to it at the same time). If that's the case, try setting your computer audio to 48k (which I gather is the regular session sample rates your working at). If this is the case then it's an entirely different issue.

Ultimately, further articulation about the problem would help, it's stil muddy to me what's going on and what the focus of the problem actually is.

Improve this answer
1

your protools session and your FCP project must be at the same Sample rate (i.e. 44.1Khz or 48Khz)

Improve this answer
1
  • This true and yes they are at the same sample rate 48kHz. – oinkaudio Nov 19 '12 at 5:44
1

I'm going to echo Stavrosound here in that a little more detail would be helpful. I will, however, throw out the fact that there is a known issue with FCP (FCP7 in particular, don't know about FCPX if that's what's being used) where it will sometimes misread and rewrite the header information in audio files. This causes them to playback at the incorrect speed against picture, and you'll see in the FCP timeline that it's either shorter or longer than the actualy visual edit.

We run into this all the time where I work. To identify FCP as the problem though, you have to be certain that there aren't any issue in how you're outputting the audio files from Pro Tools...and it sounds like you may possibly have something gummed up on your end there.

Improve this answer
2
  • Interesting, I've worked with a lot of clients who cut with FCP and we've never experienced anything like this with the printmasters not syncing up. Are there any details about this issue? It would be good to keep in mind at least should it ever come up (along with the one where FCP seems to be 'stupid' when it looks at a .L and .R file and tosses them in mono unlinked). – Stavrosound Nov 19 '12 at 0:29
  • @Stavrosound - It tends to happen when the editor has started the new project without changing the preferences/standards based on the project delivery format...i.e. the last project they worked on was PAL, and they just started up a new NTSC project and let FCP change the settings based on the first piece of imported footage (rather than go through and set everything correctly before importing). It also tends to happen with mixed format timelines. The preferences for FCP get all screwy and the header re-write happens. – Shaun Farley Nov 19 '12 at 2:46
1

You've been bitten by THIS:http://duc.avid.com/showthread.php?t=212057

It's a fairly well known issue in FCP... When the Sequence is set to an Integer Frame Rate (i.e. 24, or 25) and the capture settings are set to non-integer rates (23.976, 29.97) FCP "helpfully" tries to correct the audio by doing pull-up/pulldown. The full details can be found in the thread, but the quick and easy solution is to use Sebsky Tools or QT Pro to make the audio into a QT movie with the correct frame rate. This will prevent FCP from attempting to change the audio.

P.S. Just found out the other day that the Sebsky Tools are NOT Intel native, so 10.7 won't run them. 10.6 and under work fine with Rosetta installed.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.