Synch Drift in Zoom H2 PCM file?

[Steve House]

Originally Posted by Bob Huenemann

I have been following this issue since it showed up in H4 threads.

It doesn't matter if the clocks in the two devices are correct or not!

Think about it. All that matters is that they both play back at exactly the same rate at which they recorded.

If the two inputs are being fed to some DVD creation software that makes assumptions about the clocks, I suppose drift could be introduced.

...

And that's exactly the situation that causes the drift. Video from the camera is captured as a file and imported into the NLE. Audio from the recorder is transferred to the computer as a BWF/WAV file and imported into the NLE. Now for both of them it's the editing workstation's clock that becomes the standard time reference. Assume for discussion that it's on the money at 48kHz. If one or the other of the imported files was recorded with a clock that is a little faster than 48kHz, it'll playback slower than recorded. If the recording clock was a little slow, the file will playback in the NLE a little faster than recorded. Now if the clock in the camera and the clock in the audio recorder were locked together, the slight speed up or slow down would be identical to both and they'd stay in sync. But if they differ, the slight speed difference between them after they both get into the NLE timeline will cause the recordings to diverge from one another and you'll find that if you align the start of each, they'll be out of alignment by the time they play through to the end.

[Bob Huenemann]

Thanks for the clarification. I said "DVD creation software". I should have said any editing software, of course.

You are correct. To work perfectly in editing software, the clock crystals in the H2 and H4 would have to put the sampling frequency at exactly 48 kHz, or whatever. That seems a bit much to ask of a $200 device.

[Roger Shore]

I suppose that, in this situation, the word 'drift' is not really entirely appropriate.
Although that is the apparent effect, the cause is not from any of the clocks involved actually 'drifting', but is because the sequence described by Steve in the above post actually causes an 'offset' which can be measured and corrected.
As the camera audio needs to act as the reference (to stay in sync with it's own video!), the offset needs to be calculated against this reference, which might itself not be accurate.
So you could have the situation where the externally recorded audio is is fact pretty accurate, but needs to be offset to compensate for a more inaccurate camera clock.
Not that it matters, as long as you can correct one to match the other!


I

[Bob Huenemann]

The Sampson web page for the H2 states the following:

"Time Stamp and Track Marker functions in Broadcast WAV Format (BWF)"

Anyone care to interpret this?

The H4 page contains no such statement. The H4 page states that a software upgrade is available for the H4.

[Seth Bloombaum]

Typically, a timestamp in a BWF file would be from an internal timecode generator, the BWF format allows a record start time to be embedded in the file header. This can later be accessed in some NLEs and used in various ways to achieve sync.

*Several* caveats:
*I don't have an H2, but it's hard to imagine a full featured TC generator in this tiny inexpensive box. I'd guess it's a time-of-day clock similar to the time/date clock in a computer. Someone else can be more specific, but, even at that it would be very useful for achieving rough sync. Search for posts by me that include the term "timecode", you'll find lots of discussion on the benefits and limitations of this kind of rough sync. Likely, without full TC gen, sync will be rougher than described in those posts.

*I do have an H4. The dang thing has no time functions at all, not even a date stamp for the file creation date. I have a (probably) forlorn hope that Zoom will develop a software clock and include it in a future firmware update.

*There is so much discussion about clock errors, clock stability, something "wrong" with the prosumer flash recorders (including the H4 and many others). These boxes are working as designed. They are not designed for video sync, but, with a little investment of time and trouble can be useful for video sync, especially on longer takes, as in events.

*To get exact sync and a real TC generator, you need to step up to at least the Tascam HD-P2 (about $1000 US street price). Going up in price, the Edirol R4Pro, various decks from Fostex and Sound Devices.

Even with TC and sync capable decks, there can be differences in clock. These recorders allow locking the clock to an external video source (genlock), which results in clock sync over hours-long takes. A good TC generator can by jammed to a camera or another device that has TC out. But again, we're getting out of the current prosumer range, you'd need at least a Canon XL-H1 (about $8000 US) to get TC out.

[Mike Peter Reed]

Arris and Nagras would sync to parts in a million using nothing more than individual crystal sync. I have a hard time believing that the sync in modern A/D convertors are so skewed as to give 10 frames out over 45 minutes unless there's been a really really serious quality control issue. A lot of problems are caused in NTSC land and the confusion between 30fps and 29.97fps on the timeline. But even that is frames per second and should match within parts of million with an actual second of your audio. Well, in theory. Unless there's been a really really serious quality control issue .... or just really really cheap parts perhaps.

[Vito DeFilippo]

My two irivers stay in perfect sync for at least an hour, as I have noticed with many wedding ceremonies. No one's going to mistake them for expensive pro recorders, but they have no obvious drift that I see.

[Andrew Plumb]

Most likely the latter, really cheap parts.

...Or it could be another symptom of the power-glitching issues people have been noticing. Mess with the power and the clock circuit will react, skewing everything slightly, more noticeably over long periods of time.

One possible fix, and it would be a long-shot, is that if the ADCs get their clock from a programmable PLL or counter-generated signal off the main CPU clock, you could compensate in firmware. But then you may run into the opposite problem if it's being caused by the power supply. It will track well on battery, but be skewed again on an external supply.

[Steve House]

Originally Posted by Roger Shore

I suppose that, in this situation, the word 'drift' is not really entirely appropriate.
Although that is the apparent effect, the cause is not from any of the clocks involved actually 'drifting', but is because the sequence described by Steve in the above post actually causes an 'offset' which can be measured and corrected.
As the camera audio needs to act as the reference (to stay in sync with it's own video!), the offset needs to be calculated against this reference, which might itself not be accurate.
So you could have the situation where the externally recorded audio is is fact pretty accurate, but needs to be offset to compensate for a more inaccurate camera clock.
Not that it matters, as long as you can correct one to match the other!


I

I think of an "offset" as a constant amount. If the image and the clap of a slate are 5 frames offset from each other at start of picture, it'll be 5 frames off at 1 monute, 5 minutes, 10 minutes or whatever and of course such a thing would be very easy to correct just by slipping the tracks with respect to each other. But sync drift is more variable...if one lines up the slate exactly at start, after 1 minute it might be 1 frame off, after 5 minutes 5 frames out, after 10 minutes 10 frames out, etc. That means rather than just slipping it back and forth you need to expand or contract the length of the audio track with respect to the length of the video track yet the exact amount you need to change it depends on the precise length of the video clip you're matching to. Not impossible, but more of a PITA and you need to watch out for pitch changes due to the slightly varying speed from clip to clip.

[Bob Huenemann]

The cheapest available crystals used to be the ones used for color sync in TV sets. My recollection is that they were used to establish the approximate frequency for the color subcarrier, so that the PLL could find it. These cheap crystals have been used in various other consumer devices.

Seth, since you have an H2 and an H4, can you investigate the power glitch issue and tell us if the H2 has it also?

[Vito DeFilippo]

Originally Posted by Steve House

Not impossible, but more of a PITA

Actually, not much trouble at all with most video work. The clips tend to go out of sync very slowly, and we make many cuts on the timeline, so it's a matter of slipping the audio a few frames here and there once in a while. If you are trying to keep long clips in sync, however, that's a different story.

and you need to watch out for pitch changes due to the slightly varying speed from clip to clip.

Steve, in your experience, is this actually an audible issue with such minor differences in speed over long periods? Or do you mean the speed change happens quickly, and you hear the shift?

Thanks...

[David Ennis]

For anyone curious about the answer to the simple question I began this thread with, [has anyone else had significantly different results with the H2 than the guy who found it to be 10 frames off after 45 minutes?] No one answered, so I tested it myself and got virtually the same results.

No disrespect intended to the philosophers and engineers who couldn't answer the question directly, but who have made it a fun read anyway ;>]

Chew on this one, though: Why does the 44.1/16 file from my $300 HiMD recorder align perfectly (within detectability in Vegas) with my camera's 48/16 tracks for a full 90 minutes?

[Andrew Plumb]

Originally Posted by David Ennis

For anyone curious about the answer to the simple question I began this thread with, [has anyone else had significantly different results with the H2 than the guy who found it to be 10 frames off after 45 minutes?] No one answered, so I tested it myself and got virtually the same results.

No disrespect intended to the philosophers and engineers who couldn't answer the question directly, but who have made it a fun read anyway ;>]

Chew on this one, though: Why does the 44.1/16 file from my $300 HiMD recorder align perfectly (within detectability in Vegas) with my camera's 48/16 tracks for a full 90 minutes?

That's probably the easiest one to answer: HiMD=Sony, Camera (at least one)=Sony, and Vegas=Sony.

On the hardware side, there's a strong chance that the chips and sub-circuits used for the audio blocks across all their devices share common design "ancestry". Design re-use is quite common, particularly when you either own the patents and/or license a chunk of the underlying tech. They also have the in-house experience designing for the broad range of applications (audio and video, consumer and pro), so there's usually some implicit consistency across all that they know.

Ultimately, you get what you pay for. ;-)

Thanks for confirming skewed timing. I've been pondering whether to get an H4 or go for something like a Korg MR-1(000) instead. I'm leaning toward the Korg because I'm more concerned with my audio quality than multi-input and built-in mics at that approximate price-point.

[David Ennis]

Originally Posted by Mike Peter Reed

Arris and Nagras would sync to parts in a million using nothing more than individual crystal sync. I have a hard time believing that the sync in modern A/D convertors are so skewed as to give 10 frames out over 45 minutes unless there's been a really really serious quality control issue ...

Even I, who started the thread by complaining about this error have to acknowledge that 10 frames in 45 minutes is parts per million (124 ppm). I poked around and found that 100ppm is a common spec for crystal oscillators. So I concede that the H2 isn't too bad by those standards.

I just can't understand why my HiMD, and one of a different model belonging to an experienced and responsible poster I've read, synch so well with so many cams.

In other words, the limited data points that I have so far (and a third poster has now confirmed the 100+ppm H2 lag) support the hypothesis that the H2 consistently lags by over 100ppm and Sony HiMDs have no error detectable in Vegas.

[Steve House]

Originally Posted by Vito DeFilippo

Actually, not much trouble at all with most video work. The clips tend to go out of sync very slowly, and we make many cuts on the timeline, so it's a matter of slipping the audio a few frames here and there once in a while. If you are trying to keep long clips in sync, however, that's a different story.



Steve, in your experience, is this actually an audible issue with such minor differences in speed over long periods? Or do you mean the speed change happens quickly, and you hear the shift?

Thanks...

I was thinking of two clips that required differing amounts of correction and then ended up being cut together, say a cut from a medium shot to a closeup of an actor, so that the same voice on both sides of the edit would have noticably different timbre. Of course some NLEs will automatically pitch correct when stretching or compressing a track so it wouldn't always be so much of an issue but it's still going to be a PITA to align the heads of video and audio for every one of hundreds of shots and then stretch or squeeze the audio so that the tails line up properly as well.