[Matt Riley]

Indeed, you are not alone.

I’ve posted about this problem/bug here (somewhere on the Cow, anyway) and in Apple’s forums and have never found a solution outside of modifying the TC after the encode, which sucks.

You can either do the QT Player method like you mentioned or you can use FCP to manually change the TC on a per-clip basis (it’s under the Modify menu).

If anyone has a solution to this, I’d love to know about it.

-Matt

[Matt Riley]

If it happens repeatedly, call AJA. I had a Kona LHe cause me all sorts of grief after less than a month of use. The first time the problem appeared was after a (planned!) system shutdown for some maintenance. Then, every time after that, the machine would panic on boot. Uninstalling the drivers would let it boot normally, which was the smoking gun that it was the Kona card that was causing problems.

A call to AJA allowed them to verify over the phone that the card was being problematic and they shipped me a new card pronto, at no charge for the exchange. Put the new card in, installed the drivers again and it’s been good since. That was about five months ago. 🙂

So, yeah, call AJA if the standard troubleshooting stuff doesn’t pan out.

-Matt

[Matt Riley]

I don’t think I have any keycodes. If I do, I don’t know how to find them (I’ve been dealing with film for quite some time so I feel a bit stupid asking these things!).

I don’t want to have to do any post processing to remove the pull-down; my schedule doesn’t really allow for it and I don’t want the added step or multiple files scattered about. I just want to remove it during capture like I hear about in the product specs and on these forums. 🙂

I’ll give the FCP manual a read and make sure everything is up-to-snuff there. Thanks for the pointer.

I wish AJA had this documented somewhere on their site, in a support document or something. It seems like something more than a few people would want to do and there is pretty much zero documentation for it (that I’ve found, anyway).

I’ll keep trying.

-Matt

[Matt Riley]

I’m not alone:

https://discussions.apple.com/thread.jspa?threadID=1725001&tstart=0

Here’s a link to submit feedback to Apple about Compressor. I’ve just sent them a link to this thread in the hopes that they can fix the problem or at least slap me around and tell me I’m doing something wrong.

https://www.apple.com/feedback/compressor.html

[Matt Riley]

While the copying TC track in QT player might work just fine, it’s really not any better than having to use FCP’s modify TC function to change things. Either way, it’s still a manual process to fix something that should be handled by a program intended for automation with a batch-driven interface.

I wonder how hard it would be to write a nifty little AppleScript to do the dirty work for me? Something like copy the TC track from each clip in folder A (source folder) and replace the TC track of each clip in folder B (record folder), in order, of course.

I might look into this, although counting files and applying things in order is beyond my limited scripting capabilities at the moment. 🙁

-Matt

[Matt Riley]

Okay, here is a quick test I just did to confirm the problem (for me, at least) still exists even with the absolute latest versions of everything installed.

I took three clips at random from a current project for analysis. These clips are from a telecine session at a high-end transfer house; they were captured from a D5 intermediate with a Black Magic card in a FCP system. When I import the clips into FCP here, I get the TC I’m expecting (so that my EDL conforms properly). Here are the starting TCs for each clip as FCP shows me:

Clip 1 — 01:02:32:00
Clip 2 — 01:03:19:00
Clip 3 — 01:04:00:00

Now, if I open each one of those clips in QuickTime Player and set the display to show the TC, it shows these same values. This seems like new behavior to me. QuickTime Player says “Timecode: Non-Drop-Frame” from the pop-up menu in the lower left of the window where you can change the display options.

However, when I drop these clips into Compressor, here are the TCs Compressor shows me:

Clip 1 — 01:02:28:06
Clip 2 — 01:03:15:05
Clip 3 — 01:03:56:04

Obviously, these aren’t correct and represent a fairly significant workflow problem. 🙁

What’s Compressor doing? Does it think the clips have Drop-Frame TC instead of Non-Drop? I don’t see any way to change this behavior in Compressor so I don’t know if there is anything I can do about it. I don’t deal with DF TC ever, so I don’t know much about it.

Ideas?

-Matt

[Matt Riley]

QuickTime 7.5.5 (just did the 7.5.5 update a few minutes ago)
FCP 6.0.4
Compressor 3.0.4 (just did the application support 2008-003 update a few minutes ago)

As you can see, I did some updating all around this evening and will hopefully have time to test this yet again tonight. I’ll let you know what I find.

-Matt

[Matt Riley]

QuickTime seems quite capable of displaying 23.98 TC…

I still see my original issue, though. Here’s exactly what happens:

I get files from telecine or P2, import them into FCP. No problem. TC looks fine (this is, of course, a rather important thing when conforming from an offline edit and receiving files back from telecine to create the online version of the spot).

If I want to make proxies of this media using Compressor – so that I don’t have to have 50 GB of uncompressed HD files sitting on my SAN all the time – I drop the files into Compressor and setup the settings I want (photo jpeg, smaller size, etc.). However, if I look at the time code Compressor is displaying it does not match what is in the QuickTime file.

Just to prove myself right, I import the same source file into a new FCP project and the TC reads how I expect it to. Drop the same file into Compressor again and verify that Compressor is indeed displaying the TC incorrectly. Sometimes by a handful of frames, sometimes by a few seconds or more.

The only decent workaround I’ve found so far is to go ahead and do the encoding with Compressor with the incorrect TC. When Compressor is done, I take the new proxy files and drop them back into FCP. From there, I can see that indeed, the incorrect TC that Compressor was displaying has now been embedded into the files. Ugh. So, I import the original files into FCP for reference and modify the TC on each of the proxy files, one at a time, so that they match the original files’ TC.

It works, as the modify TC tool in FCP instantly changes the TC embedded in the files. But, it is a tedious, manual process requiring me to type out the TC for each clip while looking at the TC from the original files. Very prone to errors if you aren’t paying attention. However, I feel that having good proxy files that I can keep around without using much disk space (or overhead to playback from the SAN) is worth the extra effort.

It’s really a shame this doesn’t work like it should. I suppose I should file a bug report or something with Apple but it is hard to find the time some days, especially when I’m spending time correcting TC errors. 😉

-Matt

PS–I see Compressor 3.0.4 is out now. I might give that a whirl and see if I have any better luck with that version. I’m not hopeful but it doesn’t hurt to try.

[Matt Riley]

Who are you and what have you done with Zelin? 😉

-Matt

[Matt Riley]

If they all have the same pulldown cadence, then yes!

Pick your first file and interpret the footage to taste. Then control- or right-click on that footage item after closing the interpret footage dialog and select “remember interpretation.”

Select the rest of your footage items and control- or right-click and select “apply interpretation.”

Enjoy.

Matt