Time Code Sync off by 2 frames

[Sean Michael Johnston]

I'll post frame grabs tomorrow to illustrate.

 

[Rocco Schult]

If we offset the timecode to visual, then the TC slate would not match. Currently, if you feed TC from the 744T to both the camera and a TC slate, the TC for the image frame will match the visual on the TC slate and the audio recorded. What I'm trying to determine is if we can isoltate the issue to a specific setup (like yours) or to an offset in one of the devices as we haven't seen this in our tests.

We'll test this again monday and try to recreate it.

If you have a TC slate you can add to your test, that might help also.

Hi there,

no update really, and I have seen this error with 2 different cams and a deva and a sound devices.
One was in January with a deva, the other right now with pretty new cams, beta firmware build and sound devices audio recorder.
No timecode slate yet, which we try to organize.

TC offset in January was 2 frames, the offset right now is 1 frame most of the time and once 2 frames.

Looking forward to your test results.

Cheers, Rocco

 

[Stuart English]

Audio Sync

Audio Sync

If we feed the camera timecode from a slate and clap it, the visual of the timecode on the slate and the timecode recorded on the camera and the audio "clap" are all in sync. So if the slate isn't introducing an offset in its timecode output - or the camera just happens to have an equal but offsetting error - then it would suggest there may be a timecode error coming from the audio recording device.

a) Someone mentioned that some other models of pro cameras have the same symptom as described here - could the audio recorder be "fixing" a problem of another brand's camcorder, and the "fix" is showing up here?

b) Has anyone recently done a self-recorded sound to video to timecode check on the RED-ONE? If so what were your results?

I'll be checking this again today for proto-Build 16, so any feedback is welcomed.

 

[Stephen Pruitt]

This really stinks. . .

Has anyone contacted Sound Devices to get their read on the situation and what can be done about it??? And, most critically, which machine is at fault?

Stephen

 

[Christoph Schilling]

hi everyone
i just have the problems with the 788t with a panasonic camera. And my sound is 4 frames ahead from the audio on the camera. I contacted sounddevices and they never heard about this problem. T try to find some solutions but i think the offset in the final cut session is it. But i won't give up. I 'm wired to the camera and camera is master in auto rec mode.
greetings Chris

 

[Brian J.M. Rytel]

TC

TC

Sounds to me like the TC is set 23.97 on the recorder and 24 on RED. Or FCP is treating one of the two as though it were a different rate than the other.

TC on recorders can get tricky, check and recheck all the settings between the recorder, the camera, and FCP.

 

[ingostar]

Having the same problem, just bought 3 Ambient Lockit and controller. I'm recording the audio on DEVA with Lockit box and when merging clips in FCP it's always off by 0-2 frames. I have both the cameras on build 17. In one test I plugged the controller to the RED and compared it to the controller, and it was off by 0.62 to 0.65 frames even though the Lockit box that gave the camera it's JAM was dead on compared to the controller. Next test I'm trying is to feed the camera with genlock as well and see if that makes any diffrence in post. I'll let you know if it makes any difference. If anyone knows any solution please advice. In all my tests it looks like the camera isn't able to JAM the timecode correctly and according to what I've read the camera JAMS the timecode when you press the rec button and continues the recording on it's own internal timecode.

 

[Serge Arseneault]

Hi, I'm having the save problem with the same camera and recorder (sdx-900, sound devices 744t ) Did you find where the problem is?
Thanks

 

[Shane Betts]

The issue here seems simple, but perhaps difficult to solve. Any electronics path has some amount of built-in latency. What needs to happen is the manufacturers - of all electronic cameras and sound recording devices - need to agree on a testing criteria to establish a base figure for inbuilt latency. That bit is easy. The difficult bit is that, as I assume that electronic cameras will have bigger latency issues than audio recorders - in other words, the pictures will be behind the audio - it will fall to the audio device manufacturers - even though it's not their 'fault' - to provide latency settings to wait for whatever camera is being used. This could be simply provided as a pulldown menu item (I'm shooting on a Red, a Viper, etc) and the latency (both in terms of audio and TC) could be aligned. It will take a level of cooperation between the manufacturers and there's the rub. Given that cooperation, easy problem to solve.

 

[Stuart English]

Timecode

Timecode

We check often, and there is nothing in our tests that suggest we have a timecode to audio sync issue.

But as the camera has Timecode Out, try locking the audio recorder to that and see if you still have an error.

 

[Seth Larney]

We check often, and there is nothing in our tests that suggest we have a timecode to audio sync issue.

But as the camera has Timecode Out, try locking the audio recorder to that and see if you still have an error.

This would be a good test..

As Stuart mentions, if you feed a timecode signal to the camera from a slate, then the timecodes are in sync across the clap, audio and video on those devices, so it would seem that there is not a latency issue with the camera?

I can't see how that assuming the above is correct the issue is coming anywhere other than the Sound Devices unit?

 

[Shane Betts]

If everyone agrees that no audio to timecode sync issues exist, scratch my suggestions altogether and I'm not pointing any fingers here, but I'm assuming latency exists in all electronic devices and simply saying that, if accurate numbers can be gained, the solution is "device A latency plus/minus device B latency equals sync".

Audio devices don't record in frames so, if latency is subframe (assuming there is some inherent in any electronic device) then timecode sync has only a limited degree of accuracy when it comes down to synching picture and sound recorded double system. Correctly synching timecode would not seem to be a great issue, but if users are finding subframe rubberyness, then it must come down to latency. Milliseconds could make a visible difference and my suggestion is that, if every device in the chain is measured to within milliseconds instead of frames, then any latency issues can be resolved with cooperation.

 

[Rocco Schult]

This would be a good test..

As Stuart mentions, if you feed a timecode signal to the camera from a slate, then the timecodes are in sync across the clap, audio and video on those devices, so it would seem that there is not a latency issue with the camera?

I can't see how that assuming the above is correct the issue is coming anywhere other than the Sound Devices unit?

I'd like to show, but just haven't the picture handy.
Situation is this:

TC slate with Clockit timing unit, freshly synced, TC out fed directly into camera and TC is off by 2 frames.
No audio at all, no Sound Devices either.

Verified with 2 different REDs, two different TC slates, two different soundmen, cables etc. and 1000km distance between the locations.
Only similarities me, RED and the recording format.
Ah, I forgot to mention, only checked with my least favorite editing app: Final Cut Pro.
Didn't cross check with MC, sorry.

 

[Stuart English]

Timecode

Timecode

I'd like to show, but just haven't the picture handy.
Situation is this:

TC slate with Clockit timing unit, freshly synced, TC out fed directly into camera and TC is off by 2 frames.
No audio at all, no Sound Devices either.

Verified with 2 different REDs, two different TC slates, two different soundmen, cables etc. and 1000km distance between the locations.
Only similarities me, RED and the recording format.
Ah, I forgot to mention, only checked with my least favorite editing app: Final Cut Pro.
Didn't cross check with MC, sorry.

Well we are seeing very different things then. How are you judging that the timecode is out of sync ?

(Hint - don't record and inspect the camera preview output for that as it does lag; inspect the recorded file)

 

[Tom Visser]

It is quite normal for there to be a frame offset between devices. It is simply a reality of the situation. When speaking timecode, the frame is not the base unit of measure, there are also "bits". Unless you get 100% bit to bit lock, you will always have some offset. The best way is to test the workflow in advance. I use Sound Device Wave agent to show the timecode of a file I record with my workflow. If you want to address offset in advance, one should do a test shoot, send the audio and video to the editor, simulating the final workflow, and then calculate the offset. I have an Ambient ACD301RF wireless slate. It can accommodate up to 7 frames of offset simply by setting a few dip switches. I haven't seen the need to do any more than that in the past. My Nagra VI shows a 2 frame offset from the TC on Wave Agent versus its internal clock, +/- a few bits.

Otherwise you simply note the TC offset if it is known or the editor can figure it out on his own, a little difficult to do if a TC slate was not used, but not impossible. This is completely normal and within the realm of responsibility of an editor to deal with. In my opinion, there is nothing "wrong", it is just the way it is.

 

[Rocco Schult]

Well we are seeing very different things then. How are you judging that the timecode is out of sync ?

As said, I use FCP to inspect the TC and original proxies were used, no converted files.
The TC shown by FCP and that on the TC slate have been off by 2 frames.

It is quite normal for there to be a frame offset between devices. It is simply a reality of the situation. When speaking timecode, the frame is not the base unit of measure, there are also "bits"...

Well, I disagree completely here.
Assuming FCP shows the right TC and I have a slate which can clock to frames only and a camera which can do the same, an "image" can be on that frame or the other, no bits here or there. Of course it can be off theoretically by milliseconds, but that is just time and has nothing to do with audio or digital in general, resulting in an unsharp image, basically a special kind of motion blur.
If you read my post, there was no audio involved at all, just TC out of slate (TC generator/source) fed into the camera.
And while reality proves me wrong, there shouldn't be any delay at all in that moment, however that is achieved in the system. Of course I can think of reasons why my image lagged behind, but it could be corrected within the system.
I agree with your statement regarding audio, but assume this is a system inherent "feature".
Admitted, it was a build ago and I didn't test that specifically since then. Look at the original thread start, it might have gone already without me taking notice.
Lucky me I do mostly commercials which are dubbed anyway.