Black Magic RGB to AJA RGB

[Scott Compton]

Thanks Jerry.

Scott

[Jeremy Garchow]

[scott compton] “Thanks Jerry.

Scott”

Sure Scoot,

Jeremy

[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.

[Jeremy Garchow]

[Matt Riley] “QuickTime seems quite capable of displaying 23.98 TC… “

What version are you on?

[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]

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

[Jeremy Garchow]

[Matt Riley] “Does it think the clips have Drop-Frame TC instead of Non-Drop?”

It can’t discern the difference and Quicktime used to be the same way, but that seems to have changed now.

Jeremy

[Del Chapple]

A bug in compressor, whoda thought… Compressor (i bet) just cant discern 24f tc so maybe its assuming its DFTC bt from the 00:00:00:00 code. the diff between DF and NDF over an hour is 3 sec and 18 frames, which roughly seems to be what compressor is doing. as i said before if you need the TC track you can just copy it from the original and paste it into the proxy. theoretically it will work.

d

you cant hear my inner voice scream… can you..?

[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]

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