Welcome to our community

Be a part of something great, join today!

Log in
  • 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 :)

1 frame offset between slate and cam TC

S

Sean Sweeney

Well-known member
Joined
Jun 1, 2008
Messages
189
Reaction score
0
Points
0
Hey guys,

Wondering if this is a common issue (I've seen it more than once with different hardware).

Was on a shoot using 2 Epics with Denecke SB-3's. No problem syncing up the cams and boxes at 23.976, but occasionally we were getting a 1 frame offset between the TC slate and the in-cam TC (generated from the Denecke). It wasn't consistent either - it seemed to happen randomly throughout a mag.

We did a hardware swap (cables, boxes, etc) and reset and the issue persisted. Our 1st AC had mentioned they had similar issues on a pilot shoot a few weeks before. Is this a known issue, or the result of some kind of incompatibility? Curious to know if anyone else has seen this.

Thanks in advance.
 
This is an ongoing and known issue.

I too have never had consistency when recording to our pix 240's - Same principle different kit. Indeed, today I went through as many different options as I could think of with my kit but still get the random 1 frame offset. This is a Red issue with the SDI out not being consistent with the generated timecode regardless of how timecode is generated.

I know this doesn't help, but it should save you wasted time & effort trying to find a solution.
 
Thanks for the reply Simon. Do you know if anyone from Red officially commented on this issue?
 
No Not really. Going back 12 months and beyond there were various problems with the SDI out, for example there were black bars top & bottom of frame. This was fixed with a release build (3.0.7 I think?). Recently I noticed that there was a black line across the bottom of the frame about 6 pixels high. After a lot of unsuccessful calls to support I was told that it was a known issue, "It is on the list" but they then told me they had more important things.

It seems to me that the SDI output on the camera is buggy in all sorts of circumstances. Your timecode issue though doesn't *Shouldn't* cause any issues with syncing the actual R3D's & sound rushes though - that at least does seem to be solid.
 
I don't follow you - our issue didn't have anything to do with the SDI on our camera - we were connecting the SB-3 into the sync port on the Epic using a BNC to mini 4-pin male lemo cable. The issue was directly between the timecode displayed on the timecode slate and the internet timecode in the epic itself.
 
Sorry, I went off at a tangent slightly - our issues manifested themselves via the SDI feed to the pix. We tested with the timecode slate as well and got similar results to you albeit we were looking more at the pix issue. There is something amiss with how the Epic is generating its timecode but nobody has ever elaborated.
 
As long as there's a consistent 1-frame offset throughout the project, the assistant editor (or whoever is syncing up the dailies) can compensate for this manually. It's not a big deal, and in fact is very typical.

Where it becomes a problem is when each camera is off from the other by a frame or more in different directions, or when it's inconsistent. I find there's generally no problem when the cameras are fed both external timecode and external genlock, and the audio department is responsible for master timecode at the sound recorder.
 
I'm on a shoot now with two Epics, both running firmware 4.0.10, and both connected to Lockit boxes. Master clock is a SD-744T, which they re-jam twice a day. When I auto-sync shots in Resolve, they are sometimes 1, sometimes 2 frames off, and sometimes perfect. Not a consistent offset. Is this a known problem, or should I be contacting RED? Our sound mixer tells me 1 frame isn't noticeable, but I'd like to get things right, just for the sake of my own obsession.
 
I've found the TC lock on Red is more art than science. Same experience as Elliott. +/- a frame or two and varrying from shot to shot. Have used just TC and the TC+Genlock without luck. Just have to fix it later or do what I am doing, run sync sound into the Pro I/O.
 
Sean, the SB-3 only supplies timecode, correct? The Epic does not derive sensor timing from timecode. So the sensor timing is asynchronous to the update of your slate's display. If you were to use a sync source that supplied genlock and then used the sensor sync->genlock selection you would see the TC in R3D match the slate all the time.
 
Simon N said:
Sorry, I went off at a tangent slightly - our issues manifested themselves via the SDI feed to the pix. We tested with the timecode slate as well and got similar results to you albeit we were looking more at the pix issue. There is something amiss with how the Epic is generating its timecode but nobody has ever elaborated.
Click to expand...

I think there are two issues.

TC is a sound signal that counts frames.
Genlock synch is the pace that keeps the recording at the same beat as other devices.

This doesn't mean that TC (frame count) and Genlock (pace) are accurate to other devices. Especially when SDI from the Epic is recorded (with Pix or other) where you have 1 (or more) frame delay due to signal processing.

TC is a strange thing, invented by Aaton long long time ago. I think there should be one unique Synch/TC/Genlock... protocole developed to get real shutter/subsample universal synch.

Pat
 
Dave Winder said:
Sean, the SB-3 only supplies timecode, correct? The Epic does not derive sensor timing from timecode. So the sensor timing is asynchronous to the update of your slate's display. If you were to use a sync source that supplied genlock and then used the sensor sync->genlock selection you would see the TC in R3D match the slate all the time.
Click to expand...

Which sync boxes would you recommend? The SB-3 is the defacto standard in this market.
 
if you are running at a base rate (24 not 48), feeding TC and Genlock and syncing the sensor to Genlock and getting green TC ,GEN, SYNC icons, then no, this is not normal. If you are not genlock sensor syncing, then yes I would expect it. IF you are running sensor at say 48 or 72 and genlocking with 24, then you will see this as well, because you basically have multiple frames with the same timecode and post sw cant distinguish that. Hope that helps.
 
I'm running at 23.98 with TC, without genlock, and the TC icon is green. I don't need the shutters to be synchronized, I just want the camera's timecode to match that of the sound recorder. I was under the impression that LTC timecode is all you need to accomplish this. And I believe that's how all other cameras work, no? So this means RED is aware of the problem... are you working on fixing it?
 
ok, so what exactly are you saying is 'off' and how do you judge it? Scratch audio versus recorder? Image of slate versus clap on recorder? We did tests where Zaxcom Deva caused this issue between scratch audio in camera and sound cart. Deva ran asynchronous to timing. Scratch audio in camera was always dead on, deva almost always off. TC will not drive the timing. So sensor is running asynchronously to the TC if you not synching to the genlock. Your sound cart will be running asynchronously to the camera as well.
 
I expect the timecode in the R3D's to match the timecode on the WAV files from the SD-744T. But when I autosync picture and sound, the visual slate clap does not match the sound from the recorder. I don't have any scratch audio on camera for this shoot.
 
Without syncing the sensor to the timebase as the time code, you will see +/-1 frame offset. The sensor is recording a 1/23.98 sec slice of time as a frame. the time stamp of that frames is latched at the start of the frame. Timecode is also a single number tagging a 1/23.98 sec piece of time. Without syncing those two, you are not getting the same 1/23.98 sec chunk in both. This causes the difference you see.
 
You must log in or register to reply here.
Back
Top