So the Zoom F8n Sound mixer has a pretty precise internal clock even when powered off and all batteries and external power are removed. The internal clock battery will keep the clock precise. If you are shooting in exact 24ND (Non Drop frames). The moment you switch to 23.976 or 29.976… all accuracy goes out the window though.
It really is important to test the equipment that you will be using… perhaps even become a member of online user groups. I wasn’t even aware that it had an internal small battery to keep the clock accurate. This comes in handy when you have to power down the mixer to save energy, switch batteries or whatever. Because the time will still be accurate (in exact frame rate modes like 24/25/30) you won’t have to rejam everything on powerup.
I’m wondering why it becomes inaccurate in 23.976 modes though… the clock will start veering off by many seconds and you can bet audio and camera(s) won’t be synced anymore. Since we mostly shoot at 23.976 for on air broadcast… would still have to rejam the device on powerup. I’m now researching any benefits of shooting exact 24 fps instead of 23.976 FPS.
Below is a picture of the timecode drifting when powered down and then powered back up after about a minute. The longer it’s powered down the more of a drift happens.
Unfortunately in the manual for the Zoom it doesn’t go into all this geeky stuff. I’ve seen on the JW Sound Group that some sound recordist were unaware of this issue. They would power down the mixer and expect it to still keep accurate time. Finally by the time the project is finished and sent to editors… the audio and video are way out of sync… ouch… this can be an expensive problem for post. Also as a sound recordist it can make you lose clients. Yes this little frame issue difference is actually a big deal.
I think it’s good to have practices like the AC and Sound Recordist verbally out loud calling out the timecode every now and then to double check that everything is still in sync between audio and video. I usually take a picture with my phone to see if there is any unacceptable drift happening. There should not be drifting beyond a few frames. I like to see exact frame matches but display latency between say a LCD and LED usually make this not practical. For example my Denecke TS-C slate is LED but my Zoom F8n display is LCD… LCD’s are slower than LED’s. So if you snap a picture you’ll notice usually a 1-3 frame lag in the display times. Not a big deal don’t think the real time code is being affected.