Hopefully, they will fix it in firmware...

The problem: Files recorded in .WAV format are NOT Broadcast Wave Format compatible, eg. the H1 does NOT correctly timestamp the audio files with the proper timecode, even though in the Zoom literature it says it does. This would be incorrect. Without the timestamps, you will not be able to find the right sync points in your editor. The only reference is looking at the "Modified Date", but this can be altered depending if you just open these files in certain audio editing programs, like Soundbooth CS5.

I've found a workaround on Mac/FCP.

Import your audio files into FCP. Select an audio clip (ie. ZOOM0001.WAV) in the bin, and go to Modify > Timecode. Frame to Set should be set to First. Enter the proper timecode. You'll need to refer to the Modified Date that's displayed in the Finder Info. Unfortunately, Finder only displays the Hour and Minutes, but not the seconds. Without the seconds, your timecode would be just an approximation.

To find the seconds, I found an AppleScript that does this very thing.

In Applescript Editor, copy this code:

--------------------------------
tell application "Finder" to repeat with MyItem in (get selection)
do shell script "mdls " & quoted form of POSIX path of (MyItem as text) & " | grep 'kMDItemContentModificationDate' | awk '/ = / {print $3,$4}'"

tell the result to set ModDate to text 3 thru 4 & text 6 thru 7 & text 9 thru 10 & "_" & text 12 thru 13 & "-" & text 15 thru 16 & "-" & text 18 thru 19

display dialog "Modification date: " & ModDate with title (get name of MyItem)
end repeat
--------------------------------

Select your audio file in the Finder, run the AppleScript, and it will show you the Finder info in HH:MM:SS format (there is no display for frames, unfortunately, but it is close enough).

Enter this time into FCP's modify timecode dialog box and you should have a very close by the second TC of your audio clips.

Hope that helps anyone else experiencing this issue.

Even with a 'working' Zoom's internal BWF TC stamp, it's an approximation. It would almost never be frame accurate. 'Plural Eyes' would be easier and faster however it will cost ya' $150usd.
WaveAgent may also be of help.. if only the TC stamp is missing from the BWF.

Wow, I would expend more in labor to implement this fix than I would on buying the H1 itself, seems kind of like cutting off your nose to spite your face. I agree with Rick, Pluraleyes is the best solution for anyone doing any kind of double system sound. Quick and easy.

Dan

PluralEyes rocks, huge time saver.

The time code on any recorder that doesn't have a timecode input will always be an approximation, solely dependent on how accurate the user is when they set the internal clock of the device, plus whatever drift occurs after that.

Has anyone looked at the wav files from an H1 using a PC instead of a Mac to see what info shows up by default? With wav files from the H4n the timestamp is also shown as "date modified", with the date, hours and minutes of the time the file ENDED.

While having an internal clock can be very beneficial for organization of files and getting your workflow started, it would never be accurate enough to get you any closer than a second or two at best and generally a minute or two under normal conditions.

At least this is an improvement over my original H4, with no clock and the generic time of 9/16/2005 12:00 AM for every file it ever recorded.

Ian,

Do you mean the actual date and time on the physical WAV file? My Zoom H4 had the same thing, every file was dated 1/1/2000 at 00:00:00 (or something like that).

If so, then it's nothing new... and was a wee bit annoying. If I went on a field trip and took recordings all day long, it was pretty tricky to even work out which one came from which time of the day when they were all at 00:00:00. Totally different from the problem of synching with an individual clip.

If the Zoom had a concept of time, you could tie the time in the .MTS file with the time on the Zoom... but the Zoom doesn't even have a clock (or at least my H4 doesn't).

You can set the time on both the H4n and H1, and that helps a bit in determining the time and date a recording took place. On the Zoom H4n for example, the recorder has three ways to tag the date of the audio files:

1) It will name Stereo files with the DATE (ie. 100901-000.wav, for 2010-Sept-01) This doesn't work for 4CH recordings.

2) It will show the last modified time (I'm in Finder), which is helpful in knowing the time of day the recording happened, and,

3) It will embed timecode into the .WAV file so when you import the audio into FCP for instance, FCP will display the timecode in the TC column. Helpful when you need to do a rough sync with lots of clips. You can then of course offset the timecode to match with the video.

On the Zoom H1, it only does number 2. But again, this modified date can change easily even if certain programs open these files but do not write out to it. It's very easy to lose the dates this way and there is no undo. If you bring H1 files into FCP, the files show up with :23 or :29 as the starting timecode, depending on whether the FCP sequence is set up in a 23.976 or 29.97 timeline. Strange.

Ian,

Do you mean the actual date and time on the physical WAV file? My Zoom H4 had the same thing, every file was dated 1/1/2000 at 00:00:00 (or something like that).