Audio for Video Issue

[Kent F]

Hey there-
I shot some video where I ran the mics directly into a Tascam DR-70D and took the line out and went into the camera. I was under the false impression that I could avoid sync issues later when I edit the video. More importantly, I wanted to have more control over the record process and then bring the audio into SAW, clean it up, normalize, etc. I've imported the cleaned-up audio into the video editor, placed it on it's own track, then I manually nudge the clip on the timeline to match the camera audio.

So there's noticeable audio drift after about 20 minutes when I compare the camera audio (just for reference) with the Tascam audio. Eventually, it also becomes noticeable with the lip sync. In the video editor I can cut the audio and nudge the clip again in the proper direction, and that works for what I'm doing... but I'm wondering if I can minimize how often I need to do this.

The camera records video at 29.97 fps and audio at 48k. The Tascam is recording at 48k.

I know that SAW gives us different mixdown sample rate options. I'm wondering if there's any value in choosing the 48k pulldown option. Will this track better with the video shot at 29.97? Not sure I'm thinking about this correctly. And, of course, there's always the possibility that I'm totally missing something here and that there's a far better way to deal with this.

Any thoughts? Thanks!

[MMP]

One of your devices either has a bad clock, or the video editing program had a bad import (more likely IMO).

Digital clocks these days are good enough that I have done unsychronized feature length programs with no loss of sync.

I am not sure where the error is creeping in, but I know that Final Cut would sample rate change imports if the project settings were not matched before the first import, causing the original audio not to match. Perhaps your video program is doing something similar.

[Cary B. Cornett]

Kent,
The result you describe is not unexpected. Without the speed (clock) of one device being fully slaved to the other, no matter what the labels on the units say, they will not run at EXACTLY the same rate. When sound and picture are recorded "wild" (not directly locked to each other or to a common standard), they WILL drift apart over time. It isn't that clocks that accurate and stable can't be made, but that they cost way too much to put into any product that can be sold to a mass market. A rubidium time standard, for example, would do the job, but most likely none of us here could afford it, not to mention it wouldn't be easily portable.

This means that, with the setup you have, you will need to re-sync audio and video every few minutes on the timeline.

[cgrafx]

Kent,
The result you describe is not unexpected. Without the speed (clock) of one device being fully slaved to the other, no matter what the labels on the units say, they will not run at EXACTLY the same rate. When sound and picture are recorded "wild" (not directly locked to each other or to a common standard), they WILL drift apart over time. It isn't that clocks that accurate and stable can't be made, but that they cost way too much to put into any product that can be sold to a mass market. A rubidium time standard, for example, would do the job, but most likely none of us here could afford it, not to mention it wouldn't be easily portable.

This means that, with the setup you have, you will need to re-sync audio and video every few minutes on the timeline.

Clocks circuits in most gear these days should be stable enough to free run and not drift more than 1 frame in 8 to 10 hours.

Its extremely common to jam sync camera's and audio recorders at the beginning of the day and then let them all free run.

Its more likely that the timecode settings were not matched between the camera and audio recorder. Things like drop frame or not drop frame.

The two devices have to be running the correct clock rates and unfortunately in some cases the interface doesn't actually tell you what the timecode is actually doing.

For example it can say 30fps but really be 29.97 (or can say 30fps and really be 30fps). Most of the time NTSC 30fps will be 29.97, but not always.

[Kent F]

Thanks for weighing in guys. I'll figure out a path forward.

[Naturally Digital]

So there's noticeable audio drift after about 20 minutes when I compare the camera audio (just for reference) with the Tascam audio. Eventually, it also becomes noticeable with the lip sync. In the video editor I can cut the audio and nudge the clip again in the proper direction, and that works for what I'm doing... but I'm wondering if I can minimize how often I need to do this.

Have you considered time-stretching (maintain pitch) the Tascam audio? It may take a little trial and error to dial it in but should be doable without artifacts at that level of drift...

[Dave Labrecque]

Have you considered time-stretching (maintain pitch) the Tascam audio? It may take a little trial and error to dial it in but should be doable without artifacts at that level of drift...

Might be worth a try. I had a long-form drift issue years ago and wanted to use Saw's pitching feature to sync two tracks, but it wasn't precise enough. Bob added a digit to the speed ratio setting, increasing the available precision by a factor of 10. Worked for me. Could work for you, Kent.

Though I'd really like to figure out where the problem is if I were you.

[Kent F]

Thanks for the help and suggestions. After digging in and asking around, including here... it seems the problem is likely using 2 different recorders (one of them being the camera, the other being the Tascam) without the ability to professionally sync them. In the future, I will work on making sure I have good audio levels from the Tascam into the camera instead of relying on the audio recorder as my primary source. The Tascam will still be the means of controlling the levels to the camera. It will be a help with its limiter, monitoring, slate, and backup recording just in case something bad happens with the camera audio.

In the meantime, I'll try the time-stretching idea. Shouldn't take long to see if it will work.