The Editblog

So I’m still obsessing over the two different timecode tracks that are recorded to RED camera footage and what application see which timecode track. The whole thing came up when I noticed that the RED Log and Transfer plug-in for Final Cut Pro only seems to see Time of Day code. I posted this as a question on reduser.net and one of the responses was this from the RED camera #242:

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

That seems very interesting and is something I had never heard, of course I don’t have a RED camera of my own but as a post production professional I think it’s important to understand what kind of timecode I will be seeing in RED footage that might come my way. Armed with that knowledge I went to DR&A, a local RED camera rental house, and we did a quick test. 2 short test shots, each one with a different timecode set on the display screen on the back of the camera.

Here are the two shots:

Shot 001 was set up to display the edge timecode on the camera.

Shot 002 was set up to display the time of day timecode.

With the shots done I grabbed the _M resolution Quicktime reference files generated by the camera and dropped them into Final Cut Pro:

This jives with what was said in the reduser.net post: “whatever the camera was set to display, which is what the proxies are generated with.” To make sure I then dropped the _H QT reference files into Compressor since this is a common was to generate ProRes files to edit with. Same result:

One file shows edge timecode and one time of day.

But bring the files into the FCP Log and Transfer window and the result is the same as the earlier post:

So again, this seems to not be the way that the Log and Transfer tools should behave. Maybe there is some unknown reason for this or maybe we need to remember that the plug-in is still beta … like most RED post-production tools.

But this problem still shows when using other RED tools to pull DPX files.

Using RedCine to pull ProRes Quicktimes and DPX files, the timecode that was selected in the camera display is the timecode that is used for the generated files, as expected:

I then used Crimson to generate the same clips. Crimson uses Redline, the RED command line utility, to pull files. These both came out with the Time of Day timecode:

This has also been noted on the Crimson forums. I see this as a problem. If you’ve edited your footage with the edge timecode that was used with the Quicktime proxies and then use Crimson to pull DPXs for conform elsewhere … the timecode isn’t going to match. I looked at these DPXs on a Quantel eQ and could only see the Time of Day code. Someone please chime in if there’s more than one timecode track in a DPX sequence that might see the other code but I couldn’t find it. With this knowledge I think it’s important for post to be in communication with a production to know what timecode to use in-camera in conjunction with how the RED post will be handled.

But what I really want to say is … What gives RED? Why does one post production tool that you provide seem to use one particular timecode track while another one uses another?  These tools aren’t particularly well documented so maybe there is just something that I am missing in the set-up or file generation. But I really think this “beta” excuse is only going to go so far. This camera is revolutionary but with the post being such an afterthought one has to question RED’s real commitment to getting post production just right.

This entry was posted on Wednesday, June 4th, 2008 at 10:42 am and is filed under Editing, RED. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.