Welcome to our community

Be a part of something great, join today!

  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

FCP Log and Transfer tool DOESN'T see edgecode?

Scott Simmons

Well-known member
Joined
Sep 1, 2007
Messages
243
Reaction score
0
Points
0
Website
www.scottsimmons.tv
I noticed a strange thing with the FCP - RED log and transfer tool today .....

it seems to be looking at the Time of Day timecode recorded with the .R3D file.
Everything else (the QT ref files through Quicktime player, Compressor, dragging the ref into FCP) all look at the Edgecode ... which seems the proper code in which to display.

Anyone?
 
Personally I rely utterly on the EXT (Time of Day) T/C - the hour number often refers to something critical production wise, think new camera roll for each incremented hour - and it confuses me when everything starts at 01h... Then again as you note on your blog L&T is very much in early days (daze?).
 
Personally I rely utterly on the EXT (Time of Day) T/C - the hour number often refers to something critical production wise, think new camera roll for each incremented hour - and it confuses me when everything starts at 01h... Then again as you note on your blog L&T is very much in early days (daze?).

I don't disagree that the TOD is more useful that the other. It's just that when the FCP Log and Transfer tools uses that code and nothing else does then it kind of make conforming difficult, if not impossible on some systems. I still feel like I might just be missing something but I sure can't figure out what it is!
 
I'm honestly having a hard time finding much value in the L&T plugin, other than for mass application of a preset look (though I haven't figured out how to tell it to use one-light settings/.RSX info created out of REDALERT for this). Not reading the edgecode kinda sends it deeper into my hate pit :P

Transcoding with Compressor is rock solid and I would hazard to guess faster than the L&T tool. I make a droplet for conforming all footage in an .RDM to 720p, fit width for offlining. I can drop the whole folder onto the droplet, then go home. If anything goes wrong with the transcode, Compressor will immediately send me an email or SMS message, telling me that the job failed.

The Kona 6.0 driver update cant come soon enough for me. Mass transcoding to ProRes for offlining is just stupid, at least in my production world (TV commercials/broadcast)
 
Transcoding with Compressor is rock solid and I would hazard to guess faster than the L&T tool. I make a droplet for conforming all footage in an .RDM to 720p, fit width for offlining. I can drop the whole folder onto the droplet, then go home. If anything goes wrong with the transcode, Compressor will immediately send me an email or SMS message, telling me that the job failed.

This does seem to be the best and easiest way to do things but with the odd RED frame size things are stretched to a normal size. You mention the droplet for conforming where you do FIT WIDTH but there isn't anywhere in Compressor to tell it to fit width is it???? I can't find it...
 
This does seem to be the best and easiest way to do things but with the odd RED frame size things are stretched to a normal size. You mention the droplet for conforming where you do FIT WIDTH but there isn't anywhere in Compressor to tell it to fit width is it???? I can't find it...

You have to use the Geometry tab in the preset you're using to make the droplet in order to fit the width while preserving the original aspect ratio. I'm sure there's some simple mathematical formula for figuring this out (the formula table in the otherwise awesome "Compressor Quick Reference" book made my head spin, and I couldn't make any sense out of it), but I ended up doing it the "dumb guy" way: Bringing the proxy file into After Effects, dropping it into a 720p comp, then scaling it down to fit width...then dragging out a horizontal guide, down to where the black bar meets picture, and then counting the number of vertical pixels the black bars.

I used that information to fill in the "Source Inset" and/or Output Image Padding parameters in the Compressor Geometry tab. I cant remember off the top of my head which setting it was, but when I get into the office, I'll check out the settings and post back here.

The lovely thihg about doing it this way is that the same droplet will conform all proxy sizes to a uniform 720p, so if you've got a lot of overcranked 3k or 2k proxies you can edit them all in a single 720p timeline without any headaches.
 
If you use the Geometry tab and set frame size to 1920 x 1080,


Then go to Filters tab and use the letterbox filter, This will scale the clip.


Set the settings to:

Type: Scale

Position : Center

Output: Manual

Manual Setting : 89.1

Background : Black (White if you like)

Then save your Pro Res Preset, by hitting Save as... in the INspector window of Compressor.

The clips match pretty close, to ones scaled in RedCine.
 
I don't disagree that the TOD is more useful that the other. It's just that when the FCP Log and Transfer tools uses that code and nothing else does then it kind of make conforming difficult

"Everything else" is probably using whatever the camera was set to display, which is what the proxies are generated with, however both TC tracks are in the R3D.
 
Hey Mel, I'm getting a timeout on that zip file with the droplet. Is it still up?
 
Our web hosting provider, Dreamhost (which should rename itself to "DreamHosed") was apparantly having it's irregularly scheduled downtime. Everything should be working fine now.

Thanks Mel, works like a charm
 
I neglected to mention something that I assumed would be obvious, but before using the droplet, you should do a search for the "_H" proxies in whatever folder your R3D files are, then drag the search results over to the droplet.
 
The QT proxies actually have both timecode tracks in them (at least the footage I have does) But FCP only looks at the first track, which I guess is determined by the camera display settings. I've made an applescript that will remove the first TC track if you want to work with the proxy files and use TOD if your camera was set to Edge Code. I haven't done a lot of testing and IT IS DESTRUCTIVE. The TC track is permanently deleted. So use with lots of caution. The script is at http://www.kylegilman.net/2008/06/04/red-tc-fixer/
 
The QT proxies actually have both timecode tracks in them (at least the footage I have does) But FCP only looks at the first track, which I guess is determined by the camera display settings. I've made an applescript that will remove the first TC track if you want to work with the proxy files and use TOD if your camera was set to Edge Code. I haven't done a lot of testing and IT IS DESTRUCTIVE. The TC track is permanently deleted. So use with lots of caution. The script is at http://www.kylegilman.net/2008/06/04/red-tc-fixer/

Thanks Kyle. I'll try and give that a look when I'm back in RED land next week. I don't use the proxies so it might not apply... It really seems that this is an issue that has been missed. I did more testing and it seems that both the FCP log and xfer tool and REDline will only see the one track regardless of what was set-up in the camera. I wrote a piece about it as it seems that this is good info to know before a shoot!
 
i think the final cut log and transfer tool does use the proxies, or does it deal with the .r3ds?

My understanding is that it looks at the R3D files. Maybe that's just from using it that it "feels" like it is looking at them from the way your load and such...
 
I don't use the proxies either, but I thought it might be useful for someone. At this point using the edge code seems like a dangerous workflow since some tools are ignoring it.

The Log & Transfer tool doesn't use the proxies, only the r3ds.
 
Back
Top