[Matt Lyon]

Are you using colormunki? There was a thread about this recently:

https://forums.creativecow.net/thread/8/1154749#1155573

Matt Lyon
Editor
Toronto

[Matt Lyon]

hmm … I’m not enough of a ProTools guy to be able to explain how to do that of the top of my head, but I’m pretty sure there must be a way.

If you are still getting the green bars, there could be a number of things going on. Make sure ProTools is actually rendering a new file at 48000 hz, rather then just changing the sample rate to 47952, which is one way of applying pulldown, but not really FCP friendly.

[Boris Riabov] “I see that when I’m cutting my 23.98 picture-lock time line based off my 23.97 timeline,”

I assume you mean 29.97 timeline?

as for the clip lengths: are you sure they are actually shorter? remember that the timebase is different. So frame number 12@24fps is equivalent to frame 15@30 fps

Matt Lyon
Editor
Toronto

[Matt Lyon]

Great sleuthing Joshua, and thanks for posting a follow up. I’m sure many people will find this thread helpful.

[joshua sandler] “But i must say I am still a little confused about this 1.8/2.2 Gamma issue. As I am running Lion, should my display always be set at 1.8? Should it be set at 2.2?”

I don’t mind posting about this again 🙂 It’s probably faster for me then searching for my old posts. I guess the answer is “it depends.” I’ve profiled my displays with a Spyder, and have made setting for 1.8 6500k (for FCP video), 2.2 6500k (for sRGB standard) and 1.8 5000k, for working with the photo lab I sometimes use (as per their spec).

So I guess it depends on what else you are doing on your machine? And how much of your time is it worth it to sweat about?

Honestly I find it more often then not a PITA to keep switching profiles all the time, so I generally stay w/ my FCP preset all the time.

Of course, my preferred way to work is always with a video break-out-box and a calibrated broadcast monitor; in that case I would leave my computer monitors at 2.2, and judge everything video related on the broadcast monitor.

hth,

Matt Lyon
Editor
Toronto

[Matt Lyon]

sorry, been crunching at work today so I couldn’t write sooner…

1. You may need to play around with the reverse telecine settings in Cinema Tools to find the combo that works, but start with:

Capture mode: Field 1 – Field 2
Fields: Style 1:AA
conform to 23.98 (don’t ever change this)
standard upper/lower: ON (unless nothing else works)

Usually, a telecine session will export an ALE file where every clip starts on a 00 frame, and every 00 frame is an “A” frame.

2. correct. when you read proper A/B/C/D letters, you’re reverse telecine worked

3. The pulldown doesn’t change the timebase of the audio, it just makes the audio play slower (since your video footage has been slowed down from 24.00 to 23.976 fps during the telecine). So the speed change should be 23.976/24.00 (aka 0.999%)

4. You only need to apply the pulldown to sound that was recorded while cameras were rolling.

5. Your sound guy should work at 23.976. It sounds like you are finishing on HD, which will be at 23.976 … so everything will stay in sync. If you finish on film at 24.00, then you need to apply a pullup to the final mix to maintain sync.

6. By “bake in,” I mean to say that the audio tracks are processed and re-exported with the speed change applied so they are permanently altered, as opposed to having FCP do the speed change “on the fly.” (in a sense, the opposite of a “non-destructive” effect)

Matt Lyon
Editor
Toronto

[Matt Lyon]

[Matt Lyon] “sync a long clip, make a merged clip, and very there is no drift”

sorry that should read: VERIFY there is no drift…

Matt Lyon
Editor
Toronto

[Matt Lyon]

Hey Boris, there’s a lot of information here so I hope I’m getting everything straight 🙂

First off, based on you other post, if you are still seeing interlaced fields in your footage after you ran the reverse telecine, that means it didn’t work properly. You need to run the batch again, and find the correct settings that work with your material.

FCP is actually designed to automatically apply audio pulldown in certain situations (you can read about it in the Cinema Tools manual. In fact, I highly recommend reading the whole thing if you haven’t already).
So it actually sounds like this worked in your favor, since that is what is likely kept your audio and video in sync during your first go around.

I don’t like working that way. My preference is to bake the speed change in. I’m not aware of any specific tutorials for doing this in protools, but I’m sure they are out there.

So I’m still not sure why you need the xml route? My way of going about this would be:

reverse telecine the footage
apply pulldown to the audio
start a new FCP project
import all audio and video
sync a long clip, make a merged clip, and very there is no drift
throw a few clips on the timeline and very you can export a valid pull list with keycode via Cinema Tools (I assume that is what you’ll be giving to the lab to recapture you’re selects?)
rebuild your edit, picture and camera sound
rebuild your temp score and sfx
export deliverables for sound folks and the online folks

hth,

Matt Lyon
Editor
Toronto

[Matt Lyon]

Hi Boris, I understand more now… you basically are re-conforming your project from 29.97 to 23.976?

But that raises a larger question. Did your audio stay in sync with picture during the first edit? Theoretically, if you didn’t do the audio pull down at that point, then the clips would have been drifting out of sync. It is possible your sound recordist was already applying the pulldown, so there is no need to do it again.

Also, you don’t HAVE to change the audio TC to 24 in order for things to stay in sync. In fact, your audio should absolutely maintain the timecode of the original recordings. This is important if your mixer has to reconform from the the original files.

FCP can mix 23.976 video with timebase 30 audio, you just have to make sure your settings are correct when you import the files (which is what the second half of my guide is all about).

Are you rebuilding your timeline from scratch? Or are you hoping to conform the video and marry the old sound to it?

Matt Lyon
Editor
Toronto

[Matt Lyon]

Hi Boris,

Is this the same project as your earlier post? The super16 shoot?

If you ran your camera at 24.00 fps, then you need to apply a speed change to your audio before you start synching. You can do this in “realtime” in FCP, but without sample-level accuracy, so I prefer to run all my sound through ProTools or Audacity and “bake in” the speed change (aka pulldown).

You should definitely reverse telecine your video FIRST. Then import into FCP. Then import your processed sound, then do the sync and clip merge.

But follow my advice in the second half of my tutorial (about setting your sequence presets) so FCP interprets your sound files properly when you import them.

hth,

Matt Lyon
Editor
Toronto

[Matt Lyon]

hmm, that does sound like a different issue then I’m describing. There’s a lot of moving parts when it comes to display gamma so it makes sense that a software update could have changed something.

But did you try my solution? I’m curious if it made any difference at all.

FCP will do the gamma correction in hardware or in software, depending on the graphics card you have installed. So maybe an update to a display driver might have “broken something.”

I’m not using Lion, and haven’t seen this issue, but I know that in Snow Leopard, you can open the “software update” control panel and open the “installed software” tab and look back at your update history. You can reference the dates and hopefully figure out which installer might have caused the problem. I think you are right that an FCP re-install won’t fix this issue, but if you can revert the OS to before the patch was installed, that might do the trick. I’m not sure if you’ll be able to “un-install” whatever patch caused the problem, or if you’ll have to re-install the OS from scratch.
But I don’t have direct experience with this bug, so consider my advice to be speculation 🙂

Matt Lyon
Editor
Toronto

[Matt Lyon]

Hi guys,

I’ve posted about this issue in other threads, but basically FCP 1 thru 7 darkens the gamma of the viewer windows because it assumes a system gamma of 1.8, and is trying to achieve a net gamma close to 2.2 (which would be roughly equal to a broadcast monitor). This is mentioned briefly in the manual:

https://documentation.apple.com/en/finalcutpro/usermanual/index.html#chapter=85%26section=8%26hash=apple_ref:doc:uid:TempBookID-ReplacedWhenAssociatingWithMessierRevision-44034RND-1019474

In Leopard OS, most people didn’t notice, since the default system gamma was 1.8. But in every OS since Snow Leopard, the system gamma is now 2.2 by default, so the viewer windows end up being way too dark (since the gamma multiplier is still being applied).

So on any system I run FCP on, I switch the display gamma (in system preferences>Displays) to 1.8. I also keep a 2.2 gamma setting, when I need to work in other programs that expect 2.2 gamma.

hth,

Matt Lyon
Editor
Toronto