PDA

View Full Version : Time Code Sync off by 2 frames



JFirestone
01-26-2008, 01:32 PM
I just did some more tests using a Sound Devices 744T audio recorder Jam synced with a lemo 5 cable to the camera. When merging the clips in FCP, the audio is out of sync by 2 frames.

Kevin Halverson
01-26-2008, 02:13 PM
I just did some more tests using a Sound Devices 744T audio recorder Jam synced with a lemo 5 cable to the camera. When merging the clips in FCP, the audio is out of sync by 2 frames.

In which direction? Is audio leading or lagging in your test?

Anders Holck
01-26-2008, 02:23 PM
I have seen this before when using the 744T with FCP.
I was shooting on the SDX-900 and the TC in the BWF (Or the P2 MXF) was 2 frames off.

Peter Reventlow, the creator of Dharma Tools made a special version of his BWF2Wav converter with an offset slider in the batch window.

Dont know if this is the same...

JFirestone
01-26-2008, 03:11 PM
In which direction? Is audio leading or lagging in your test?

The audio was lagging by 2 frames. I had to unlink the audio track and drag it to the right by +2.

JFirestone
01-26-2008, 03:13 PM
I have seen this before when using the 744T with FCP.
I was shooting on the SDX-900 and the TC in the BWF (Or the P2 MXF) was 2 frames off.

Peter Reventlow, the creator of Dharma Tools made a special version of his BWF2Wav converter with an offset slider in the batch window.

Dont know if this is the same...

Time to call Sound Devices I guess.

Anders Holck
01-26-2008, 03:23 PM
Maybe shoot a wireless TC slate. Could be an easy test to do.

JFirestone
01-26-2008, 03:57 PM
Maybe shoot a wireless TC slate. Could be an easy test to do.

I don't have access to one, but if someone else can that would be great.

Deanan
01-26-2008, 03:59 PM
I've come across numerous slates that have been of my as much as 2-3 frames. Especially older ones. Did you test with only the sound devices or with a slate also?

JFirestone
01-26-2008, 04:12 PM
I've come across numerous slates that have been of my as much as 2-3 frames. Especially older ones. Did you test with only the sound devices or with a slate also?

Only with the Sound Devices 744T. That is the only time code capable product I have access to. I ran across this message in another thread, which also confirms the issue with a 744T.


hi all

also did a test with the new red camera for a tv series, especially to test
timecode ability and analog inputs. the setup was:
red camera (software build 13)
sd744T (latest software version)
ambient clock it
25fps pal, 4k recording on the camera
camera jam synced with 5pin lemo
audio was sent to input 1 on the red camera, directly from sound
devices

then the whole tests were imported into final cut studio (fcp6), and
synced

RESULT was about 2 frames difference between audio directly sent to
the camera and the audio from the sd744t, delay seemed to be constant.

has anybody had similar experiences, does the camera have a delay on
the incoming audio?


thomas

Sean Michael Johnston
01-26-2008, 09:23 PM
We just finished a 2 camera shoot last week and had the same issue. We jam synced the cameras to a Deva audio system with a timecode slate for visual reference. The Deva's audio was 2 frames off (ahead) from the RED audio/picture. We assumed that the processing overhead of the camera was causing the lag. In post, we just bumped the audio 2 frames on most edits. Sometimes it was more like 1.5 or 1 frame off. The jam sync wasn't always perfect. The sync didn't slip, but they would be fractions of a frame off from each other in either direction. After every power change we would resync, so there were a lot of chances for the offset between the 2 cameras and the Deva's audio.

JFirestone
01-27-2008, 01:16 AM
We just finished a 2 camera shoot last week and had the same issue. We jam synced the cameras to a Deva audio system with a timecode slate for visual reference. The Deva's audio was 2 frames off (ahead) from the RED audio/picture. We assumed that the processing overhead of the camera was causing the lag. In post, we just bumped the audio 2 frames on most edits. Sometimes it was more like 1.5 or 1 frame off. The jam sync wasn't always perfect. The sync didn't slip, but they would be fractions of a frame off from each other in either direction. After every power change we would resync, so there were a lot of chances for the offset between the 2 cameras and the Deva's audio.

I'm pretty sure our sync is not exactly 2 frames as well. It lines up pretty well, but when playing the camera audio and the mixer audio at the same time, there is a very slight chorus type effect, indicating to me that the audio is just barely off.

Deanan
01-27-2008, 02:13 AM
Just so I'm understanding the problem correctly... is the camera audio out of sync with the 744T or Deva? or is the timecode out of sync?
or both?

JFirestone
01-27-2008, 03:29 AM
Just so I'm understanding the problem correctly... is the camera audio out of sync with the 744T or Deva? or is the timecode out of sync?
or both?

I am having the problem with the 744T as is Thomas. It appears that others are having the same problem with the Deva. When the timecodes are matched in post, the audio from the recorders is out of sync with the audio from the camera.

Harry Clark
01-27-2008, 04:54 AM
I'm a cinematographer, not an audio engineer, and I'll use my stock line: "what I know about sound could fit in a thimble"
But...
When we talk about lip sync, isn't there a bit of wiggle room? Meaning, isn't one frame off fairly invisible? And without Word Clock, isn't there always going to be half a frame here and there? I mean a 48th of a second is a loooong time when you're sampling 48,000 times a second. I can remember being in film school and lining up slates on a KEM flatbed and having to "choose" between 2 frames, either one of which could have been acceptably in sync.
Of course we should get with Sound Devices and Red and try to resolve it, but isn't there always going to be a small difference in sampling without Word Clock?
Again; not a sound guy...
Cheers,
Harry

JFirestone
01-27-2008, 05:03 AM
There is a little wiggle room on audio sync. In the case of my tests the audio sync is very obvious because We recorded the audio to both the camera and the recorder. When I merged the clips using timecode and dropped them into the into the timeline, it is very obvious that they are out of sync. When I playback, it plays back both the camera audio and the 744t audio, and everything has an echo. By shifting the audio from the 744t to the right by two frames, the audio from both synchronise pretty well.

Sean Michael Johnston
01-27-2008, 10:18 AM
We used a timecode slate and matched both timecode and the slate clap. The audio was consistently 2 frames delayed, however the jamming was always off between cameras by + or - a few 10ths of a frame.

Deanan
01-27-2008, 11:14 AM
Still not quite clear as there are references to 'audio' being out of sync but not specifically recorder or camera audio. Assuming TC matches
on camera and external audio (and slate if present), does the audio
match on either the recorder or the camera (and which one is on and which one is out of sync)?

philper
01-27-2008, 11:42 AM
We often have sync differences between audio devices and video cameras, in part because each device takes a certain amount of time to process its signal prior to recording. The Sound Devices recorders have been in constant use all over the world for several years now, and most of the bugs have been worked out. What we might be seeing is simply the relationship of recorded signal to TC frame being different on the two devices. Usually audio is ahead, since it takes much less time for an audio recorder to process its signal than a digital video camera (this is particularly true of the Panasonic SDX/HDX/Varicam cameras). We know what the offset is and compensate in post. After some tests are done w/ the Red @ its various settings then we'll know its offsets too.
This testing would be made a lot easier if they would get the Red's TC output working.

Philip Perkins

JFirestone
01-27-2008, 01:13 PM
Still not quite clear as there are references to 'audio' being out of sync but not specifically recorder or camera audio. Assuming TC matches
on camera and external audio (and slate if present), does the audio
match on either the recorder or the camera (and which one is on and which one is out of sync)?

It depends on which device you would consider to have the correct sync. In this case the 744T provided the sync signal to the camera when it was jam synced. So lets assume that the 744T was has the proper sync, since it is the reference. The camera's onboard audio is obviously syncronized with the picture. However when matching timecode in post there is roughly a 2 frame offset between the recorder's audio and the camera's audio and video. The 744T's audio is not syncronized with the picture when it's timecode is. Since this occurs not only on the 744T but with other recoders as well, then it sounds like the camera might need an offset to match the timecode of the external recoders. Since the camera is recieving it's timecode from the recorder it seems to me that the offset would have to happen on the camera's side.

Deanan
01-27-2008, 02:04 PM
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.

Sean Michael Johnston
01-27-2008, 03:18 PM
I'll post frame grabs tomorrow to illustrate.

Rocco Schult
04-09-2008, 06:15 AM
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
04-09-2008, 06:50 AM
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
04-09-2008, 12:10 PM
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
11-19-2008, 03:04 AM
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
11-21-2008, 02:37 PM
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
11-27-2008, 09:03 AM
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
05-28-2009, 10:45 AM
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
05-28-2009, 06:04 PM
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
05-28-2009, 06:33 PM
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
05-28-2009, 07:18 PM
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
05-28-2009, 08:26 PM
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
05-29-2009, 02:18 AM
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
05-29-2009, 09:28 AM
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
05-29-2009, 09:42 AM
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
05-29-2009, 10:45 AM
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.