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 :)

One second off

C

CaesarC

Member
Joined
Jun 11, 2008
Messages
18
Reaction score
0
Points
0
So, here it goes, my 1st post about timecode... (yikes)

The set up is:

Build 17
4K
29.97 timebase
30 FPS
Redcode 28

Sending timecode out to Mr. Sound Guy and he is always one second behind me, but not at first. At first, it is spot on, then after a minute or so, he is one second off on his slate.

So I get the Build 17 *gasp* manual out, and we both go over the settings together, and still one second off.

Now we try clicking and unclicking every box in the timecode section. Without remembering with was clicked and unclicked the time code would go 4 seconds off then back to 1 second.

So, we just went one second off and crossed our fingers....

Any idea why we were one second off, even after getting out the *gasp* manual?

Thanks,

Caesar
 
"29.97 timebase
30 FPS"

One of these things, as the saying goes, is not like the other.

If you are shooting 29.97, then everything should be on the same timebase (i.e. 29.97), otherwise, the difference between the two rates will cause TC drift. When one thing is set to 29.97, and the other to 30, the .01% difference in TC speed will generally not be noticeable until about a minute has passed.

Every time you jam the two together, they will start off on the same frame count, but will immediately start to drift once they are disconnected.
 
When shooting dual system sound, always use a pulldown frame rate, like 29.97 or 23.976 (aka, 23.98) or an editor will come and haunt you. Like Mike said, they need to be on the same page, most audio gear is set to run at pulldown speeds.
 
I don't see what that has to do with 'pull down' speed....(what is that actually?). The very same thing happens when you jam the camera/recorder with 25. The RED is 95% off one frame. Sometimes not, and there's no rule why...? Maybe it's the lcd that lags, but then sometimes it does sometimes it doesn't. As it is now, I would not use the built-in TC of the RED as it seems to be unstable. Hanging lockits onto a camera should not be the solution.
 
I have to comment on this one. I have yet to experience a TC drift once the both sound and camera matched, including framerates.

The timecode displayed in the LCD and EVF is +/- 1 second usually. The display cannot be relied upon for determining if clocks are in sync. Really, its hard for a human to notice the difference anyways.

However, once timecode is synced take your footage and open it up in quicktime, RedCine or RedAlert. Your timecode slate will be with two frames of the timecode recorded in the R3D file.

The LCD does tend to lag, and Im fine with that as 4k is very taxing to process in real time. But getting accurate timecode is vital, and as long as its accurate in the recorded file, theres not much more to it.

So to the original poster Caesar, verify the timecode drift by checking the recorded files. If your timebase matches, then your TC will too.
 
If I sync my recorder with let's say a sony EX3 and check the lcd display i will have a confirmation that we're actually running now synchronized timecode. This is pretty much frame exact. This even stays like that for many hourse. It even keep sync when powering the camera off/switching batteries. I've tested this extensively by taking photos of the running numbers of both my recorder as well as the camera lcd. No loss of sync after 6 hours.

When I sync my SD recorder with a RED I have to second guess because I do NOT get a confirmation via the lcd, worse than that, the lcd sometimes and out of the blue shows me some fantasy numbers which makes me wonder......if the camera actually just shows that because its computer can't keep up with all that (but nevertheless records the right numbers) or if there's just no sync.

I can't say that every camera does have this bug/feature or just the one I worked with this week (brand new audio board, latest 'build' etc).

I as a need to know that the numbers line up. I can't just pray and hope. It's me who gets the call.
If it is general wisdom though that the numbers shown on the LCD don't really mean what they say then that should be in the manual.
 
Last edited:
Karl Lohninger said:
I don't see what that has to do with 'pull down' speed....(what is that actually?).
Click to expand...

Pulldown speeds are the fractional speeds like 29.976, 23.976. Now I've never shot 25fps with dual system sound, so I can't speak to that, but most audio recorders in the States roll at these fractional pull down speeds, so the camera must also be at the same frame rate. "Pulldown" just means the speed has been pulled down 1/100 sec slower from the whole frame rate, like 30fps pulled down to 29.976.

It's a bit of a throwback term to the advent of telecine when film had to be slowed down (pulled down) from 30fps to 29.976 in order to synchronize to video equipment properly. Not to be confused with "3:2 pulldown" which is describing 2 things, adding a 3:2 cadence to frames to convert from 23.976 to 29.976 and pulldown since the footage shot at 24fps needs to be slowed to 23.976 to work with the video world.
 
Thanks Brandon, I understand. I didn't understand 'pull down' in the context of running 29.976. It's clear of course that both devices to be synced need to be set to the same speed. Then there's DF and NDF......;-)
 
Are you checking the timecode on a recorded clip, or are you counting off the numbers on Red's display and finding them to be a second out of sync? I have found that the TC displayed on the monitor always seems to be about a second behind but is recorded perfectly.
 
Karl, the EX3 isnt trying to do a real time 4k debayer on commodity hardware. As long as the displyed TC on the LCD is within a second, call it good and check your recorded files.

Heres a trick I do on all cameras, Red, Panasonic, Sony, etc...: Set the camera TC to something wildly different, then Jam TC. If it changes, TC is captured. On the ENG cameras its as simple as zeroing out the TC. On the Red I set the internal clock to the wrong time. Then its just a quick check to ensure TC: "It cant possibly be 5 in the morning. Oh - TC isnt set."
 
Conrad, I totally understand that the RED is doing a lot more than running a clock. If I know what the camera actually writes into the files is the right numbers I happily stop worrying. But don't forget, having the camera turned off every possible minute because of some over-heating issues doesn't make it easy or quick to first set TC to some arbitrary number and then jam.
So could anybody married to a RED camera confirm that it actually (always) writes down the correct numbers even if TC shown on the LCD is 'somewhat and that not consistent' off?
 
Karl- Having shot a over a PB of material to date, and doing spot checks of timecode, Ive yet to find a situation where it was more than +/- 1 frame where human error wasnt involved. Thats another good reason to set your Red clock ot something wildly different, as those times when its human error are much more apparent. If your Red clock is close, then you wont be able to as easily tell if it was human error or not.

So, if the TC should be at 12 hours, but I see the recorded TC at 5 hours, I know an AC didnt plug in the TC. When the recorded TC is on hour 12, the frame will be within +/-1 of the timecode slate.

You dont have to ask others opinions for it - if you are using a TC slate on your shoot already, its a 30 second check. Look at the file and look at the displayed and recorded TC.
 
Alright, Conrad, thank you, but: when you mean look at the file....you mean playing back the file via the onboard monitor? Can I step through frames (to see the slate numbers + TC code of the file)?
 
Karl, open up the file in RedAlert, RedCine, or even the quicktime wrappers. You can step frame by frame in there, and all three display the recorded timecode.

That said, if you do a playback in camera I believe it shows the TC at the frame. If the timecode slate is in frame when you pressed record, it should be right there.

BTW, I was searching my emails today for something unrelated, and I did see a email regarding a TC error on a beta build. I dont remember all the details at the moment, but that was on a beta build 16. So I do need to qualify my earlier statement to just release builds that supported TC.
 
Thanks again, Conrad, you've been really helpful. The camera was a build 20, btw.

I see now what you mean. Now this was a shoot without a DIT on the set and I didn't have the chance to get my hands on to the files. Only in camera playback. And also, usually the slate isn't in the frame in all its glory at the very beginning of a take.
So I will have to trust the camera that it writes down the right numbers, but it has more important things to do than to show them correctly in the monitor ;-)

I did try to find enlightenment going though the manual, and it would have helped to find that irregularity mentioned there.
 
Here's what I do to check timecode: Have the AC crack open the slate in front of the lens. That way you can see the digits on the slate AND the digits on your LCD. Both are delayed by a second. It's a simple solution.

What I want to know is how the camera ops deal with the latency when rolling. That 1 second delay from real events to what you see on the monitor is distracting to me. But I am just a lowly Sound Man...
 
tom.boykin said:
Here's what I do to check timecode: Have the AC crack open the slate in front of the lens. That way you can see the digits on the slate AND the digits on your LCD. Both are delayed by a second. It's a simple solution.

What I want to know is how the camera ops deal with the latency when rolling. That 1 second delay from real events to what you see on the monitor is distracting to me. But I am just a lowly Sound Man...
Click to expand...

I keep seeing "off by a second" I hope everyone means off by a FRAME. When the camera is recording, the TC displayed in the viewing systems is accurate, when it is in standby mode it is not directly displaying the clock. I have a Ambient master clock and it can compare incoming TC to out going and it is usually a few tenths of a FRAME difference. There is no way to route TC to 2 different types of devices and always have the latency be the exactly same. Even FCP has a frame offset in the System settings under playback control. Depending on how you route audio through your edit system you can have a few frame audio discrepancy.
 
tom.boykin said:
What I want to know is how the camera ops deal with the latency when rolling. That 1 second delay from real events to what you see on the monitor is distracting to me. But I am just a lowly Sound Man...
Click to expand...

Every camera - no matter who makes it - has a delay between what you see in real life and what is displayed in the EVF. With every camera you can look at real life, then look in the evf and see the same action. Its basic physics that there is no way to get around that delay.

As an operator, it really is not hard to operate with any of the delays in professional cameras by any manufacturer. There are some very cheap palm consumer cameras that have a significant delay, but even those are easily worked around.

But Im deaf, so its all good. :)
 
Even film cameras? It seems like the only latency with those is determined by the speed of light. From what I can tell the light you see in the eyepiece is pretty much happening in real time due to it not running through a computer. But if I'm wrong, I won't complain.
 
You must log in or register to reply here.
Back
Top