Camera drift: audio goes out of sync...

[imagetemps]

Yes it is like that... Thanks for the video.

[George A.]

Totally not cool.

[Calomile]

Does this imply that the footage isn't actually in the timebase it says it is, when compared to real time?

[imagetemps]

Yes. Exactly.
In the real world, a second is a second. In the digital audio world a sample is a 48000th of a second. In the digital camera world a second is 23.98, 24th or ... 30th of a second. In the real world a second is always a second but if your filming speed drift, when you play back your frames one after the other at 24 FPS, a second is no more the second of the real world. The fact is that in the camera, a second of the "Image block" is slower than a second of the "audio bloc". It sounds unreal to make a camera that don't record at the exact same speed sound and image!
By the way, don't forget that timecode is camera speed when timecode on an audio recorder is only a stamped reference. The audio speed is always is sample rate.
The precision of a sound recorder should guarantee that they can play 48000 samples every second while they should basically be able to read 25 or 24 frames in a second. In terms of milliseconds the drift allowed by audio is more critical than for images. That's why sound recorded by Kinemini remains in sync with an external recorder.
Let's say that we are speaking of 5, 10 or 22min shooting tests. When you record interviews, in the last ten years (how many cameras?) we recorded full flash cards, P2 cards, HD etc... of one or two hours non-stop interviews.
I have filmed gently first footage for my documentary. On the NLE it is umbearable!!!
You can't — as they recommend to us — resample the sound, and you can't slice audio like a sausage every minute to keep your audio in sync!
Let's hope they'll find a solution.
All the best
I AM CHARLIE TOO!!!!!!!
Erwan Kerzanet (from France)

[Calomile]

The only saving grace I have in all of this is that my camera is being predominantly used on a drone so therefore audio isn't as big of a deal, but I do also use it for corporates, which can have up to 20 minute takes while people work on the delivery of their lines. I seriously hope kinefinity sort this out as the more work I get with this camera on the ground the more it's going to make me resent it.

[George A.]

Hi,

I emailed the guys at the team and they helped me out for a job I have coming. This is their answer:

Hi George,

The new firmware download link:
Link: (sorry can't reveal this yet as it is not public)

It fixes stutter of 4K KRW liveview, smooth as 2K liveview. And it launches compensation of Audio sync issue.

How to compensate the Audio sync issue:
• Update firmware to KineOS3.2(4);
• Power on KineMINI 4K, and set resolution as 2048x1080, fps as 25fps, S35mm mode;
• Leave it, and wait around 10 minutes;
• Enter playback mode, and then switch back to liveview;
• Leave it, and wait around 60 minutes;
• CONFIG—>SYSTEM—>ABOUT. Use your phone to take a phone of the ABOUT window;
• Send the photo back to support@kinefinity.com and sales@kinefintiy.com;
• Kinefinity will send one software patch to you, like option file;
• Upgrade camera with patch file, and firmware 3.204.

It is a little bit long, but it will fix the camera sync issue in software way, once for all.

It will take me few days to get my hands on this but I will report in the form of another test. Hope this works.

[Calomile]

Is this what they propose to do for all the owners of the camera? Is this going to end up breaking after every firmware update? This shouldn't even be an issue and their proposed way of fixing it doesn't seem very practical.

[imagetemps]

The problem is probably not coming from the hardware.
Let's see...
E

[George A.]

Hi,

I got the patch and the firmware but still no avail. They'll try to do it again. The patch is only for me (will cripple other cameras) so I can not share it. It seems to be a matter of calibration. Meaning it only needs to be done once. No idea what the real problem really is?

But it could be that... I think they just don't have a hardware timecode generator on the computer. Maybe the chip that they are using is a crippled consumer chip and by default is connected to a time server because the camera really isn't it's internal time frame get's messed up. Raspberry Pi's tend to have "being on time" problems when not connected to NTPs. Of course this is all an assumption and I might be totally off.

[SaxRix]

It's interesting to watch this develop. Thanks for keeping us all in the loop George!