Determing the sync offset of Zoom H4 & H2
 

There is a report going around about an excessive sync delay when using a Zoom H4 Handy Recorder with a DV camera. The figures from this report (more than one second difference after 39 minutes) has been mentioned in a few other places.

I was alarmed by such a large reported sync offset so I decided to test my H4 and a couple of Panasonic GS400s cams to see how much they varied.

My SW radio is not working so I could not use a broadcast time standard. Instead I installed a trial version of One Clock http://www.directlogic.com/oneclock.htm and had it speak the computer time every 15 mins. For sync purposes, I found the ticking sound was better than the chime.

So I set up the two GS400s and the Zoom H4 (recording 48KHz WAV since this suits DV work practice) in front of the computer speaker, waited until just before the next 1/4 hr announcement was due and then started them all recording. I left the room and came back an hour later.

Here are my findings:

1. The two cams were different from each other by 5ms after 1 hr. This is a negligible difference.

2. The H4 was slower in my case by 300ms after an hour. The quarter-hour offsets were linearly increasing: -77ms, -153ms, -224ms, -300ms. So this indicates it should be a straightforward matter to adjust for this offset. The start of 4th quarter (1 hr = 3600s) was 3600.300s from the first quarter's starter so the H4 needs to be sped up. The time stretch speedup percentage (3600.3/3600) = 100.0083%. You can easily do this in Adobe Audition or in your NLE (it is easy to do this visually in Vegas).

So I did not find a ridiculous offset as was reported in the user review. The offset I measured is similar to what I've experienced with Sharp MD-SR50 & MD-SR60 minidisk recorders. And as long as it's consistent, once you adjust the end of a long take, the midpoint should be OK as well. Camera dropouts might change the sync delay. Only more experience will tell.

If you own a H4, H2 or some other solid-state recorder that you are using for film work I suggest you carry out your own test as there may be some variation between different examples of each model.

Dan - an excellent way to illlustrate just how variable the various 'clocks' in our editing chain can affect the results for audio sync.
What is intriguing is just how much we expect these days from 'consumer' equipment. It wasn't that many years ago when crystals were generally too costly for inclusion in most consumer equipment.
I believe that the electronics for deriving telephone 'touch tones', for example, utilised 3.58MHz crystals initially, because they were the only ones available at a reasonable cost, as they were used in TV sets, and therefore made in quantity!
Today we take crystal oscillator standards pretty much for granted, but they are only reasonably accurate. For real accuracy, you have not only to use specially selected crystals, but to maintain them at a constant temperature in 'crystal ovens'.

No wonder the 'pros' use timecode, where the whole chain can be controlled from a single reference.

Following on from your experiments, I did a similar exercise, using our telephone 'speaking clock' here in the UK as a source. It is based on an atomic clock reference, and so should be pretty accurate!

I simultaneously recorded two references from the clock, some 15 minutes apart, onto my DV camera, my minidisc recorder, and my Olympus digital voice recorder. (you will appreciate I am somewhat lower down the food chain than you, equipment wise!!).
I was able to edit the resultant files down to an accuracy of about 1mS, by picking out the first zero crossing of each appropriate tone burst.

Intriguing results. After 15 minutes, the camera was out by some 10mS, the minidisc by about 65mS, and the 'cheapo' Olympus recorder by 700mS.

Applying correction factors as you descibe, using Cool Edit (Audition), I was able to mix down the three sources so that they could not be separated at any point in their entire length. Mixing the three original files produced a totally unacceptable result, of course.

So it would seem that even though we cannot expect miracles from our 'consumer' remote audio devices, a relatively simple correction procedure can produce very satisfactory results.

At least until we can afford to splash out on timecode linked equipment!!

Roger, for the prosumer user, knowing the absolute time accuracy isn't necessary. What's important is the relative offset(s) between the cam(s) and the ext. audio recording device(s) because your cam is the master timetrack device. In your case the offset between the MD & the cam is:

55ms/15mins

220ms/hr

8.8f/hr (PAL) or 7.4f/hr (NTSC)

3600.22/3600 (assuming the MD's soundtrack end sync point was lagging to the right of the same sync point from the cam's soundtrack when both are loaded in an NLE and synced up near their beginning) = 100.0061% correction percentage

(48000*1.000061) - 48000 = 2.93 Hz actual clock difference between the MD & the cam. So a one hour audio recording from an device operating with a relative sampling rate difference of 2.93Hz higher than the cam will be 180ms longer than the cam recording when matched against the cam's "master" soundtrack, or visa versa if the audio device clock rate is 2.93Hz lower than the cam's.

In my case, the H4 to cam difference is +4Hz at 48KHz sampling rate.

Dan the 300ms accumulated lag per hour for the H4 roughly equates to 9 frames, which is fairly consistent with what we are finding for the H2. Has anyone reported an H4 or H2 with a clock that's running slow rather than fast? If not, then I submit that the timebase errors we have to live with in these particular pieces of consumer equipment are not due to uncontrollable random variation in crystal frequencies coming out of the manufacturing process.

Rather, we are either seeing the result of a set point for a crystal manufacturing process that is higher than 48khz, or we are seeing the result of Samson buying cheap crystals from a manufacturer who has sorted them by accuracy. Either way, it's a quality issue where deliberate decisions are being made by people who know exactly what the numbers are. I wonder what the additional cost of better crystals would be.

David, I bet the H2 & H4 both use the same x'tal. Zoom would use the same type where possible to reduce their inventory.

And if they're buying sorted crystals, they'd buy ones with error to the same side, to minimize the timebase error between their own products in the field.

This is probably better explained by drop-frame time codes and 1hr of DV is about 3 seconds off in time. As you see, you compensate for it linearly.

As I understand it, this has nothing to do with timecode, df or otherwise. Why?

First of all, timecode is merely a handful of standards to describe the address of a particular frame in a time format.

Of course an audio recorder doesn't have frames, the way a video recording does. In olden times (pre-digital), pro audio timecode consisted of a stripe of timecode info on a tape, which originated with a TC generator. Preferably, this TC gen was extremely accurate (not all were), and if synced a couple of times with the clock/gen on the video or film device, would stay in sync. (hah!) Timecode errors were common, and workflows were tightly controlled to minimize them.

Then, during editing, a timecode synchronizer was used with servo controlled playback devices to make the audio recorder chase the picture timecode. (and corrections frequently applied!)

Digital first came in the form of the DAT standards, and pro manufacturers added a linear timecode stripe to DAT to continue roughly the same workflow.

Now, we have the H4 and many other prosumer recorders. What Dan originally posted on was what we used to call timebase errors, the sample clocks running at slightly different speeds. These recorders do not have a timecode generator. As you step up to recorders like the Tascam HD-P2, the Edirol R4Pro, and Sound Devices 702T and 704 you get a timecode generator that is syncable to other timecode sources. Then, the issues of drop frame and non-drop frame (DF, NDF) settings become important, but that's another thread. They stamp the beginning timecode in the file header - no timecode recording for the duration of the audio clip/file.

Back on the H4 & similar, the timebase errors just mean that instead of 48,000 samples being recorded in one second, 48,002.93 (or is it 47,997.07?)are recorded instead, if you assume that his Pana GS400 is recording precisely 48K. So, to resync, a .0083% correction is applied.

Nothing to do with timecode, but, everything to do with the clock that does rule the recording, the sample clock.