Zoom F4 Firmware update

Yeah David, the F4 for the price is a really good deal! Still curious what preamps they use... I still prefer the AKM ADC's of the SDs (on high quality speakers, headphones). Probably true most people won't notice a difference, especially on typical playback devices.

That's true, Scott: 1ms = 48 samples at 48kHz- not a big deal and can be fixed if desired in PP CC when using Audio Time Units to slide the audio track precisely. Today talent averaged around -12dB and still managed to get loud and get close to the limit briefly on one take (just touched it). They didn't notice the distortion, so all good, but I did. Will test the Advanced Limiter and see it how compares to SD's analog limiter (painless & no delay- if you just kiss the limiter- not even audible- guess that's why analog limiters are popular on the higher end).
 
well even analog systems have some delay, and the Sound Devices all now have digital sections so there is going to be some latency. I actually went down the rabbit hole and tried to find total latency figures and even SD doesn't tell you other than "we worked very hard to have low latency monitoring".

The other thing is that all of the latency anybody talks about is monitoring latency. It's entirely possible that the recording has effectively zero latency. If for instance you sync on the slate any latency will be gone. With TC it would be very simple to shift the code enough to compensate for whatever latency was there. So I think they talk about monitoring latency because that is what will throw off musicians and can get really weird if it's noticeable. Nobody used the safety monitoring mode on DAT machines because it was very disorienting (but it was a second or more). If having a 48 sample lag into your headphones while recording isn't a problem, and in 99.999% of the cases it won't be on a film shoot, you should be good.
 
When writing code to capture real-time audio-video, I spent a lot of time making sure lip-sync was right on. For example, some cameras reported invalid timestamps! So I had an option to ignore camera timestamps and use the real-time-of-arrival of the video frames based on the audio sample clock (where each audio sample represents the finest grain time value). It's been a while, though this seems about right https://en.wikipedia.org/wiki/Audio-to-video_synchronization:

For television applications, the Advanced Television Systems Committee recommends that audio should lead video by no more than 15 milliseconds and audio should lag video by no more than 45 milliseconds.[4] However, the ITU performed strictly controlled tests with expert viewers and found that the threshold for detectability is -125ms to +45ms.[1] For film, acceptable lip sync is considered to be no more than 22 milliseconds in either direction.

Again, 1ms or 48 samples at 48kHz really isn't a big deal, and as you noted can be made perfect (as possible) by using a clapper board. Since 24fps video is 1/24s per frame, we've got 1/24 = x/48000, x = 2000 audio samples per frame at 48kHz. To really get it perfect we'd need to sync on many frames (perhaps with an iPad/iPhone strobing along with tones), related to Nyquist sampling theory, so strobing at 48Hz for at least one full wave + double that (just needs to be > but double is pretty safe in practice), so 2/24s = 1/12s with 48Hz pulses (light + sound), where the light pulse varies in intensity as a sinusoid, then software finds the exact audio and video peaks. Doing pattern recognition on an analog clock second hand could also perhaps work). Never really thought about this before for film; curious if anyone's ever bothered to make sync accurate to this level haha?

Given how often we see sync errors, it's kind of remarkable it still hasn't been reliably solved after all these years!
 
Sync is a strange beast. Perceptibility depends a lot on reference. If a clip is out of sync relative to other clips it will be very detectable, but if everything is out by the same amount not so much. TV/ video is actually trickier because you have real world references so dead sync is actually more important. In a large film theatre the sync difference from the front to the back can be over 3 frames (~125ms) which is huge, but the audience is in a dark room with no realtime references and the brain quickly adjusts and nobody notices. In that same theatre have one clip 1/4 frame out and most people will notice, 1/2 frame out and everyone will notice.

When you are comparing two files at the same time you can hear the phase difference down to pretty much the sample rate.

But to get back to the original point there should be no "lag" if you are doing two system audio. Your live monitoring will have a slight lag but the file should have none. Where you could have a hitch is if you send your monitor feed to the camera as a reference track. Then when you post sync you are syncing to a track that has a lag.

But if you are just syncing either by guide track or by TC there should be no lag at all. Kind of the sound equivalent of general relativity...
 
What many companies have been learning over the past few years is that they simply cannot sell their 'higher-end' products anymore to 99% of those potentially interested based on a few better features. For the pros-pros whom will absolutely need it, sure. But the rest are simply not going to pay twice the amount for the "better" option since they will be able to use the 'lower-end' version as is.
So it's a smart move to see a sought-after feature added (without any additional work on their end) to continue to move/push sales of the F4.


I think it is a case of those who have an F4 (or F8) are very unlikely to buy an F8n just because it is an n version. Unless they were looking at an F8 anyway. Zoom know this. There is nothing worse than buying kit that will last a long time and is an investment just before a new version comes out. So Zoom don't loose sales BUT do gain customer loyalty by patching the F4. Win-win.

The only thing that annoys me is that the firmware upgrade instructions are hidden away somewhere in the manual. they should put them on the bottom of the Firmware Revision notes in the firmware package.
 
Back
Top