There's a post in another forum by someone who tested the H2's 48/16 PCM recording against a video that was recorded simultaneously. The H2 file was about ten frames slow after 45 minutes.

Can anyone confirm or contradict? My H2 is still in the box, and tomorrow is the last day to call for an RMA. Yes, I suppose I could plan on stretching it for every project, but my HiMD recorder had led me to expect perfection even after 90 minutes.

Yes, I suppose I could plan on stretching it for every project, but my HiMD recorder had led me to expect perfection even after 90 minutes.

I don't care what gear you have, unless the same PLL (clock) providing the clock, there will be some drift. Now, the H2 seems a bit high, but you will see some drift. As you get further away from the consumer marketspace, the equipment has tighter tolerances and thus less drift. No two clocks are perfectly in sync with each other.

Wayne

Ancient proverb says: Man with a watch always knows exact time but man with two watches is never really sure.

For what it's worth, I have a H4, and it definitely drifts. I need to adjust speed to 100.5% and adjust by a couple of frames every 20 minutes on FCP to synch with audio from my Panasonic HVX200. It's a pain in the ass at first, but once you know what to do it's a two minute exercise.

The H4 has amazing sound quality for the price - and on that basis I'm going to buy another couple of the cheaper H2's for work, they'll be invaluable, even a little disposable if an elephant eats one.

So, if you have more time than spare cash, I say keep your H2 - but if you need to get the job done without fuss, and don't mind spending the extra few bucks, aim for maybe a Marantz or similar.

Thanks guys.

Wayne and Steve, my point was that my Sony HiMD and all my camcorders recording the same event show NO relative drift after 90 minutes of continuous recording, so I can't quite agree based on my experience. This man with "four watches was still sure of the time."

Sean, apparently the H2 is greatly improved over the H4 in this regard. 10 frames in 45 minutes is on the order of 0.01%. And, in fairness their primary target market was not videography. Thanks for your comments. If it sounds good along with the convenience and economy I'll keep it, make the adjustments and call it all good.

Wayne and Steve, my point was that my Sony HiMD and all my camcorders recording the same event show NO relative drift after 90 minutes of continuous recording, so I can't quite agree based on my experience. This man with "four watches was still sure of the time."


David:

Unless you have the exact same circuit providing the clocking there will be drift. You have the best situation however in that you found two devices which are nearly identical. If you take two or three recording devices, record 90 minutes worth of audio onto them, then place them all into a DAW, you'll start seeing the drift. It's there and it can become very apparent depending on the device. That's why when you record with multiple devices you have a master clock that drives all the devices. This input clock is usually only seen on professional audio gear however, and consumer devices tend not to have a way to externally clock them.

Regardless, I'm not doubting that you aren't seeing this with the Sony MD, but realize you simply have some devices that have better tolerances with their internal PLL circuits than most.

Wayne

Wayne, I'm talking about four devices, not two--a Pany GS200, a Sony VX2100, a Canon GL2 and My HiMd recorded from the board at the event all showing perfect synch at frame level with the video. If it's chance, that's a lot of luck.

One time I taped a school event with seven cameras, adding our video club's four Sony TRV22's to the above. Same result. No adjustments necessary.

Is there a finite drift in the audio? Of course. But not any of a magnitude that matters in terms of synching with any of the video tracks or each other. So my experience makes 10 frames after 45 minutes seem monstorous.

David, something I'm not clear about then. Since you have one (in the box), have you confirmed the 10-frame drift after 45 minutes you mention at the top of this thread, as reported by someone else? Or would that disqualify you from exercising the RMA option?

All it should take is setting up the H2 and a camera, set the audio sample rates to be identical (i.e. 48 kHz), hit record on both. Clap once at the start, let them record for 30+ minutes, clap again at the end and measure the time between claps.

Andrew,
No I haven't confirmed it with my own unit. The poster I referred to had done exactly as you said and posted screen shots of the audio tracks. It was plausible because of previous reports about the H4. It seemed unlikely that he had a defective or nonrepresentative unit. As you probably know, B&H will take a return as long as the piece is pristine and the packaging materials are all there and in good shape so I wasn't worried about that. Plus, I've pretty much decided to keep it anyway. So I will test mine.

Looking forward to seeing how it goes.

Make sure you do explicitly set the audio sample rates to the same thing. Many recording devices targeted at musicians default to 44.1kHz to match CD standards, not the 48kHz rate (or some multiple like 96kHz/192kHz) to match DVD standards.

Well, I just ran the test and got basically the same results as the other guy.

Sony VX2100 aimed at the TV (so I could look at lip synch as well measure events on the audio timelines. Zoom H2 a few feet to the cam's right. I set the H2 to 48Khz, 16 bits. I aligned the first hand clap in Vegas and measured the Zoom's delay on the second clap 33 minutes later to be 8 frames (I didn't try to get any more precise). My unit is apparently a little worse than the other guy's.

As some of the posters have noted, if you have two clocks involved, and no time code to sync to, all remote audio recorders are likely to show some 'drift' - especially noticeable on longer takes.
I posted a possible solution here: http://www.mfbb.net/myvideoproblems/viewtopic.php?t=25&mforum=myvideoproblems
which I found useful.

But it does depend on the remote clock being just a slightly different frequency, rather than 'drifting'. Should be OK for most crystal clocks though!

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.

Short of that, it sounds like the H4 and H2 play back at different rates than they record. That's a separate issue. And it should be easy enough to test. Record a track from WWV, for example. Then play it back against WWV. Or any other stable clock.

It has been noted that the H4 has a low level click or pop when running from batteries that is absent when running from the power supply. Has anyone checked the H2 to see if it has a similar issue?

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.

Typically though the H2 & H4 don't play back the recording. Instead it is transferred digitally (file copy from SD card or via USB port) to a multi-track editor in the computer. So you end up syncing the DV cam's digitally-transferred (via firewire) "48Khz" datastream with the H2/H4s "48Khz" datastream. And that's where any difference between the actual freq of each device's "48Khz" sampling rate becomes significant.

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.

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.

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

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.

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.

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.

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.

Most likely the latter, really cheap parts (http://mclements.net/Mike/H4/H4-mod.html).

...Or it could be another symptom of the power-glitching issues people have been noticing (http://createdigitalmusic.com/2007/08/17/fix-for-zoom-h4-mobile-recording-use-a-mobile-battery-pack/). 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.

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.

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?

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...

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?

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.

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.

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.

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?
Sorry, did I mis-type in my last post? I don't have an H2. I can confirm that in the studio I can find audible beeps down in the noise floor of the H4 that correspond with the record light blinking, but in practical recording applications I've never heard it.

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?
Luck. Gotta' be luck.

...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.
If you're working on hundreds of shots then most likely they'll be short shots in which time-base errors won't be noticed or correctable. But it will be a ginormous synching job for hundreds of shots even if you have full genlock and TC lock. That's a couple dialog editors working full time for a week or more.

Some definitions:
Offset - an interval by which two timecode values differ (like Steve said), you plug in the offset and the two sources should now sync.
Drift - non-linear errors, the clock doesn't maintain constant intervals (we don't see this much in the digital world).
Genlock - the capability of a clock to be slaved to another. In theory and large studios, all clocks would slave to a house clock. In practice, feed composite video out of the camera to the genlock input of your audio recorder.
Jam-sync, jammable code - the capability of a TC generator to slave to another TC gen.
Timebase error - two or more clocks run at slightly different rates. This is what most of this thread is concerned with.
Timecode generator - a circuit that turns clock into individual frame addresses and embeds that info in a video frame. For an analog or DAT audio recorder, lays down timecode info in a separate stripe on the tape. For a digital audio recorder, typically embeds (stamps) starting timecode in the file header.

Okay, I understand what you meant now.

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.

This shouldn't be necessary is my point. The clips go out of sync so slowly, that any particular shot of a few seconds up to a minute or more will be in snyc. It's only very long shots that would be a problem.

For example, the H2 in the original post goes out only 10 frames in 45 minutes. A ten second shot with the head in sync will certainly be in sync for that ten seconds.

Okay, I understand what you meant now.



This shouldn't be necessary is my point. The clips go out of sync so slowly, that any particular shot of a few seconds up to a minute or more will be in snyc. It's only very long shots that would be a problem.

For example, the H2 in the original post goes out only 10 frames in 45 minutes. A ten second shot with the head in sync will certainly be in sync for that ten seconds.

Right, but .... you're shooting a scene that plays for 5 minutes and doing it right and going for coverage. That means you're going to shoot the same scene in its entirety over and over again from different setups. Shoot once in a long shot, shoot again in a MS, shoot again over the shoulder of A seeing B, shoot again over the shoulder of B seeing A, shoot again A in ECU, no B visible, shoot again ECU B without A. Now pick 2, 3, 4, 10 second clips from out of all that and cut it together into a cohesive scene.

What I'm getting at is that (in my example) you have 6 or more 5 minute scenes, each of which must be adjusted into sync throughout their entire length. THEN you can slice and dice 'em up into clips of the desired length. So I'm not talking about holding sync over a series of short clips - I'm thinking about about achieving and maintaining sync throughout a set of relatively long source materials so you can then pull out pieces of sync'ed audio and video and cut them into your final edit.

Now obviously this method of multiple coverage of the same scene from different setups wouldn't be used in wedding/event video or ENG. But for indy film, documentary, dramatic narrative, theatrical film, and even corporate training etc, it may very well be used to a greater or lesser degree. Even concert footage is often done this way - have a Talking Heads DVD on my shelf that appears to be a single performance start to finish but in fact has been assembled from footage obtained over three or four different performances.

I'm thinking about about achieving and maintaining sync throughout a set of relatively long source materials so you can then pull out pieces of sync'ed audio and video and cut them into your final edit.


Absolutely, I see your point. But (there's always a but), even if you grabbed a shot say five minutes into a long clip, it might only be 1 frame out of sync by then. So you slip it one frame, and you're good. You don't have to do any time remapping/stretching in order to have the tail in sync as well.

Unless I'm just too dense to understand what you're getting at? Which is not far fetched by any means.

Thanks for the replies. An interesting discussion for me...

Absolutely, I see your point. But (there's always a but), even if you grabbed a shot say five minutes into a long clip, it might only be 1 frame out of sync by then. So you slip it one frame, and you're good. You don't have to do any time remapping/stretching in order to have the tail in sync as well.

Unless I'm just too dense to understand what you're getting at? Which is not far fetched by any means.

Thanks for the replies. An interesting discussion for me...

You're right ... but doing it for every cut will be time consuming and error prone. And many productions have a LOT of cuts - look at a typical TV commerical, there's a cut on average every three seconds in many of them! Let's say audio has drifted to be a little late in that shot you're extracting from the longer take - now you cut it but you need to remember to leave it longer than you actually need. You're going to slip the audio toward the head to bring it back into line. But wait! Your slate is 5 minutes back at the start of the take so what are you going to use as a reference to line up the audio properly to the video in the shot at hand? You can't look back in the timeline because although the slates already line up at the start of the take sync has drifted apart by the time we get to the part of the shot we're cutting due to the clock issues we're discussing - and after we cut out the part we want to use we lose the slates for reference anyway. So we have to do it the old fashioned way, by trial and error, sliding the audio back and forth until it appears to match picture. Okay, now we've got 'em aligned but there are extra frames of audio before the start of picture and also extra frames of picture after the end of audio. So now we have to trim again to get the sync-repaired shot to its final length. If the entire take was in proper sync from start to finish so that aligning the slates at the head before you started cutting was all you had to do to guarantee the entire shot would be locked in perfect sync all the way through to the end regardless of its length, your job would have been much easier and you could focus on the narrative and creative/expressive decisions in the editing process without getting distracted constantly fixing technical hitches along the way.

I hear you. You are right on all counts.

But really, I don't think productions such as the ones you describe will be using any H2s or the like. You would hope they wouldn't, and thus would avoid these problems.

For an event videographer such as myself, the problem is much less severe. I take an audio file, which is often a complete ceremony with no cuts, lay it under the complete video take, also no cuts, and sync them up. Then I start cutting.

Eventually, as the cuts progress, I may notice that the audio is a frame out now. So I slip it (the uncut remainder) a frame to correct, and all the uncut material is back in sync. I can continue to cut until the drift takes me out another frame. In an hour's material, I may have to slip the audio perhaps twice. And correct the mismatched head and tail as you mention. But this two times is hardly a problem.

Your description, however, reminds me that most productions are not so simple, and thus are not so forgiving of non-pro equipment.

Thanks, Steve, for your explanations. I've always enjoyed, and learned from, your posts.

Would stretching or shrinking an audio track which was 10 or so frames out over 45 minutes (< half a second), really change the pitch so much it was noticable?

If not, wouldn't stretching or shrinking the track before any work was done on it, be the easiest way to go?

Would stretching or shrinking an audio track which was 10 or so frames out over 45 minutes (< half a second), really change the pitch so much it was noticable?

If not, wouldn't stretching or shrinking the track before any work was done on it, be the easiest way to go?

This is exactly how a lot of people I know handle it. In fact some software will take the pitch into consideration when you "stretch" the audio on the timeline.

Wayne

I don't understand why you're going to alter the pitch?

The situation as I see it from the posts above:

Import the camera video and audio to your NLE. Even if the NLE 'clock' (i.e. the computer clock) is different from the camera clock, you leave this as it is - with the camera audio in sync with the video -the reference file, in other words.

Now importing the remotely recorded audio to the NLE may result in a different length audio file, because the audio recorder clock may be different from the NLE clock, by a different factor.

Once you know the correction factor to make this audio file 'sync' with the camera audio (and thus video), you apply it to the whole of the remote audio file, before any editing.

This will restore the pitch to match the camera's audio anyway - so no 'change' in pitch from the original (assuming the NLE clock is not too far removed from the camera clock!!), plus the fact that the corrected audio file will now 'fit' the whole take.
It also follows that any segment of the file will now 'fit' as well - so adding the external audio to any segment will only require an initial 'clapper' reference - no additional stretching of each indidvidual sequence.

On the other hand, if you don't add the correction factor to the whole audio file, but try to stretch each sequence separately, that's going to take forever....