Timecode Drift in GUI

[dev.doyle]

Hey guys - thought I would post a note as a general heads up in case anyone else comes upon this issue.

On a shoot today with 2 REDs and I'm jamming timecode between them with 2 Denecke Dcode SB-Ts. I took the timecode from the A camera in to the master SB-T, then jammed both the A camera from it, as well as the B camera SB-T and sound dept. SB-T. Everyone was jammed together and the slates all matched (timecode was set to output and jam sync to accept incoming timecode)

As the shoot progressed the sound mixer called me over and mentioned that the timecode at times would be spot on in the HUD coming out of the camera, but would then drift forward by a second, and then backwards at others!

I brought up footage in REDAlert and verified timecode at the head of random takes throughout the day and it was always dead on to the timecode running on the slate.

It looks like timecode display off the body is rather buggy, or at least slows down when other processes take priority. Anyone else seen this issue?

 

[Stuart English]

Timecode

Timecode

Correct, the timecode value displayed in the camera GUI is rendered by the CPU, and its not guaranteed to be frame accurate.

This is because the CPU has a task priority list and timecode render for any specific frame may be interrupted by more a critical task.

The 100% reliable, frame accurate sources of timecode are the embedded HD-SDI and analog Time Code Out ports (and what's in the .R3D file)

 

[dev.doyle]

Thanks for confirming my hypothesis Stuart - makes total sense!

 

[Dennis Salcedo]

Recently did my first Red Feature “A Marine Story” I read as much Red camera documentation as I could get my hands on. As suggested by their downloadable manual. I used a Ambient Clockit box which was Jamed from my DEVA IV and it locked up fine and held through battery changes and all. If there every seemed to be a drift in time code (rarely) I simply rejamed the Clockit box and it was good to go.

I used the dip switch setting that are recommended in the Red Manual and it was all good. I used my trusty Denecke TS2 slate which is has a sync box and separate reader unit. And it was off a fame but the editor cutting on Final Cut Pro said it was a normal offset to deal with and the shoot went along fine. I built all my own audio and Time code input cables fallowing the Red Manuals diagrams (pin layouts) and now I have them for the next shoot. It is all good. I must say that the smart Red camera shoot sound man will always be running a double system, sound recording Just like the old days bang the slate and all. In fact the Red Manual says for best audio results run a double system. That’s my story.