MASSIVE drift issue with my mixpre3 and GH4

[SDub]

I've never had a drift issue with my GH4 and sound devices mix pre3 until a week ago. In a 20 minute recording, the drift will be 4-5 seconds which is insane. I reset my mix pre3 to factory defaults and am still having the same issue. Any idea what might be causing such a severe drift?

Scott

 

[patrickbaldwin]

Wrong audio frequency? 44Khz instead of 48Khz?

 

[Alex H.]

Is the MixPre’s time code function on?

If the TC is on, but there’s no external source to feed it, it defaults to 30fps. And if that’s the case, and you’re dropping the sound files into a project with any other time base, you’re gonna see drift.

Easy fix, if this is what’s going on: pull the files into Wave Agent (free download from Sound Devices) and change the time base to match your project.

 

[Noiz2]

When you say "drift" what exactly are you talking about?

Is it the TC numbers are drifting apart, or if you start them at the same time in sync they actually drift out of sync (sound wise)?

In the "good old days" drift was usually a clocking thing, but now the clocks on boxes are extremely good so it's really rare to see a drift of more than a frame in an hour.

With digital it is usually a TC setting or a sample rate setting. You are in the range of a 44.1 VS 48 sample error, but the pitch ought to sound off.

Depending on your editing software it will either assume the same sample rate and "convert" on the fly, or it won't convert and just read it sample for sample, or it will just puke at the wrong sample rate.

In the name of "user friendly" a lot of NLE's don't tell you what they are doing or give you any options, so it's kind of up to you to find out how they handle mismatches so you can correct them.

 

[SDub]

Wrong audio frequency? 44Khz instead of 48Khz?

I feel dumb. It was this. For some reason, I didn't think the sample rate should effect the duration of the track. Increasing the sample rate just means you take more samples in a given time frame, not that the time frame changes. What's the error in my logic here?

 

[Alex H.]

For some reason, I didn't think the sample rate should effect the duration of the track. Increasing the sample rate just means you take more samples in a given time frame, not that the time frame changes. What's the error in my logic here?

If the recorder takes 44,100 samples per second (44.1kHz), but the file is then played back on a system set for 48kHz, it’s going to play 48,000 of those samples per second. In other words, more samples than were originally recorded per second.

This should, as Scott mentioned, affect the pitch as well. 48kHz material played back at 44.1kHz will sound like the pitch has been dropped. 44.1kHz material played back at 48kHz will sound “chipmunky”, like the pitch has been raised.

 

[Paul Isaacs]

If you use the GH4 HDMI out to MixPre-3 HDMI TC in, you can guarantee absolute zero drift since the MixPre derives it's clock and timecode from the HDMI. You need to set your GH4 to output TC over HDMI and the MixPre to receive timecode over HDMI from its Timecode menu. You can also get the GH4 to record trigger the MixPre-3 automatically.

Paul

 

[Noiz2]

If you use the GH4 HDMI out to MixPre-3 HDMI TC in, you can guarantee absolute zero drift since the MixPre derives it's clock and timecode from the HDMI. You need to set your GH4 to output TC over HDMI and the MixPre to receive timecode over HDMI from its Timecode menu. You can also get the GH4 to record trigger the MixPre-3 automatically.

Paul

I'm not sure this is 100% true in this case. It is certainly possible but I doubt that the MixPre will change sample rates based on HDMI input. I would suspect that they are syncing the TC clock, but that is quite different from the sample rate and the digital word clock.

His issue is that his editing software is ignoring the meta data and playing his audio back at the normal digital video rate of 48K.

Most NLE's will do one of two things with miss matched sample rates. Either they will sample rate convert on the fly (or convert on import and point to the new files) or they will balk and tell you you need to convert the sample rate. Whatever he is using is the worst case alternative and it just plays at what it wants to and doesn't bother to throw up a flag that there was a mismatch.

 

[Jim Feeley]

I'm not sure this is 100% true in this case. It is certainly possible but I doubt that the MixPre will change sample rates based on HDMI input. I would suspect that they are syncing the TC clock, but that is quite different from the sample rate and the digital word clock.

I think I'm going to go with Paul's opinion on this...

Paul Isaacs
Director of Product Management and Design at Sound Devices, LLC
https://www.linkedin.com/in/paulisaacs/

 

[Noiz2]

I think I'm going to go with Paul's opinion on this...

Paul Isaacs
Director of Product Management and Design at Sound Devices, LLC
https://www.linkedin.com/in/paulisaacs/

I am also but he doesn't say that the MixPre will change sample rates only that it will sync TC and the TC clock. Unlike linear systems (like tape and film) TC on files is only a time stamp in the metadata. With tape you could use TC to control the speed of the deck with a synchronizer, you can't do that with digital files.

In this thread the problem was not with the recording but with the NLE's processing (or not) of the file. It's a sample rate issue not a "sync" issue.

 

[Paul Isaacs]

MixPre's sample rate clock is locked to the incoming HDMI clock.

Paul

 

[Noiz2]

MixPre's sample rate clock is locked to the incoming HDMI clock.

Paul

I stand corrected.

Thanks Paul for correcting me.

 

[IronFilm]

If you use the GH4 HDMI out to MixPre-3 HDMI TC in, you can guarantee absolute zero drift since the MixPre derives it's clock and timecode from the HDMI. You need to set your GH4 to output TC over HDMI and the MixPre to receive timecode over HDMI from its Timecode menu. You can also get the GH4 to record trigger the MixPre-3 automatically.

Paul

Genlock and timecode are totally different things.

Timecode merely means the *START* of the file for everything is 100% accurate the time. But after that start?? Who knows! How good/bad it drifts away depends on how good/bad the camera itself is.

For keeping frame accuracy all the time from start to end, then you need genlock as well.

Now does the GH4 / MixPre3 keep time accurately enough not to drift over a 20 minute take? I dunno. I'd need to test it. (but 5 seconds sounds surprisingly long, it makes me suspect there is a user error at play here)

But this is why you should lean towards your takes being 10 minutes rather than 2 hours.

So if you have an interview rolling on and on and on for a very low time, then if there is a natural pause then just take a breather and stop/start the recording! Also a good habit just in case a recording is ever corrupted, then at least you won't lose the whole entire day but just that one segment.

Edit: just read Paul's response at the end of the thread! Welll... that is an interesting little surprise feature I wasn't expecting. What happens if the camera changes its timecode sent out mid recording on the MixPre3?!?!

 

[Alex H.]

Genlock and timecode are totally different things.

Timecode merely means the *START* of the file for everything is 100% accurate the time. But after that start?? Who knows! How good/bad it drifts away depends on how good/bad the camera itself is.

For keeping frame accuracy all the time from start to end, then you need genlock as well.

We’re not talking about frame-accuracte TC: that’s just a metadata stamp at the file header.

We’re not talking about genlock: that’s a reference signal used to keep video signals from glitching when switching/mixing multiple cameras and other video sources. This is very different from time code sync.

Audio relies on word clock to keep its sample rate accurate to another device. As Paul said:

MixPre's sample rate clock is locked to the incoming HDMI clock.

And drift in non-sync situations isn’t just about “how good/bad the camera itself is”. It’s actually the result of imperfect sample rates in cheap audio recorders, and perhaps the same issue in some camcorders/DSLRs.

But this is why you should lean towards your takes being 10 minutes rather than 2 hours.

Some of the earlier models of low-cost, digital recorders had chintzy clocks in them and the 10-minute drift was common. I recall one event I covered with a Fostex FR-2LE recording an AUX mix from the house, and a Tascam DR-40 in the back of the auditorium to catch the room. The Fostex was rock-solid across two hours when dropped in alongside the camera footage. The Tascam, not so much.

But that’s happening less and less with newer recorders.

So if you have an interview rolling on and on and on for a very low time, then if there is a natural pause then just take a breather and stop/start the recording! Also a good habit just in case a recording is ever corrupted, then at least you won't lose the whole entire day but just that one segment.

Except for interviews on some earlier DSLRs, where the file size limitation and lack of file bridging meant stopping and starting every 12 minutes, I’ve never seen this. It’s terribly annoying and makes interviews run longer as the interviewees keep having to backtrack. “Okay, where were we?”

What happens if the camera changes its timecode sent out mid recording on the MixPre3?!?!

Something else I’ve never experienced in nearly 25 years of production. I’d say if your camera is changing TC mid-take, you have much bigger problems.

 

[Noiz2]

This thread has drifted quite a bit. Since some don't seem to have read all of it and are just commenting on a couple of later posts let me summarize.

Not that the talk about sync isn't full of good points but the "problem" the OP had was solved quite a few posts ago. He recorded at 44.1K and his NLE played it back at 48K without doing a SR conversion so it went wildly out of sync. A number of people suggested that might be the problem and the OP confirmed it was.

So in terms of this thread most of the discussion about sync while recording is irrelevant. The exception being Paul from SD who pointed out a feature with the MixPre 3 (and I assume the rest of the new MixPre's) that when HDMI is sent to the MixPre it can switch it's sample rate automatically to match the video signal. In this case that would have prevented the issue.

The take away is that you should have everything on your shoot set to the same sample rate, TC format etc. It's kind of basic but so much stuff just works (most of the time) that people forget.


To the last tangent on this thread, todays devices, even the prosumer ones, are generally good to a frame or so over an hour. Old "rules" about take lengths had to do with much less stable equipment and with the limitations of shooting actual film. Shooting film you basically could not shoot much over 10 min. Cameras didn't hold more than about 10 of film and Reel to Reel recorders only had about 15 min of run time on a 7" reel. Narrative films rarely have a shot run as long as 3 min. so generally not an issue. ENG and documentaries are a different game. Shooting video I have seen "takes" in excess of an hour. Practically it doesn't matter that much since you are going to edit that take down and with drift under a couple of frames an hour it will be unnoticable in any given clip. A little extra work for sound post but not a lot.

I think the confusion about various forms of sync have to do with a lot of old info out there, and a lot of younger people never having dealt with analog equipment.

On the audio side of things Genlocking and Black Burst, etc. are from the analog days when analog decks were using TC to stay in sync to an analog video tape. They are not used in digital audio. For one thing they are much too crude for digital timing.

 

[Razz16mm]

I recently ran into a sync issue on an event recording with my Bolex. I didn't check the camera settings thoroughly before the event and recorded picture at 24fps while sound was recorded to a BWF file at 23.98 fps NTSC offset (internal double system). In the NLE (Lightworks and Resolve) sound drifted about 5 seconds over a 1 hour plus recording.
Imported the audio file into Mixbus DAW for some sweetening and exported it clocked to true 24fps.
Sync problem solved.
Timecode in recordings is not just a sequence of numbers for editorial reference. Depending on hardware and software, settings can affect sync too.

 

[Noiz2]

Kind of. Frame rate has nothing to do with digital sound directly, it's just a time stamp. BUT software can do "conversions" in the background with out mentioning it to the user based on what it sees as a conflict in frame rate. This last is a real PITA if you can't turn it off with a preference.

Your drift was actually 3 sec. per hr (0.01%). This used to be a constant pain for sound post for film. Everything was shot at 24 but (in the US) the edit was in video at 29.97. To get there you duplicate frames every so often (the infamous 3-2 pull down you may have heard of). That gets you to 30fps, so you slow it all down by 0.01% and end up at 29.97. What you experienced was that issue, without the 3-2 pull down part.

This BTW is what those weird sample rates (the ones just over and under 48k) on some recorders are for. You would record at a slightly higher SR if shooting film destined for video so that when picture was slowed down in the video transfer the sound would be in sync.

I'm actually surprised that Lightworks or Resolve would do this with out a warning, but it is probably something you can change in preferences. The other "fix" is to use an app that can edit the meta data of the file to rebrand the audio file with the FR you need. Which is essentially what you did. For digital files TC is a locational reference not a clocking one.

Your core point though is spot on. It is really important to keep everything coordinated, Frame Rate, format, sample rate, etc.

 

[Razz16mm]

You can set project frame rates in Lightworks and Resolve. But that has no effect on imported audio file sample rates.
With Lightworks there are tools one can use to correct drift. I have used fit to fill, which changes the timeline length of an audio or video track to exactly fit a marked segment when inserted. Video and audio tracks can be sped up or slowed down by percentages to alter timing too, but one then has to adjust in/out points of clips to match across tracks. It can be hit or miss for accurate sync.
However drift is going to exist on long shots between any camera and any double system sound recorder unless both are externally locked to the same master clock, no matter how seemingly precise the individual device clocks are.
The timecode referenced solution produces absolute frame lock between picture and sound as well as providing time stamps for editing reference. However that is actually accomplished, time code is still a valuable production tool that saves a lot of headaches in post.
Lightworks makes no assumptions about the correctness of imported material, sound or video, as long as it fits the basic parameters of the assigned project frame rate and other settings. Sequence timing follows the selected project video frame rate and timecode is written to the sequence based on video time code if it conforms to SMPTE standards, or to assigned time code value and format for the project if not.

 

[Noiz2]

You can set project frame rates in Lightworks and Resolve. But that has no effect on imported audio file sample rates.

And yet it apparently did? I will have to do some tests with Resolve. Traditionally NLE's just played samples at whatever rate the project was set to which was why the odd sample rates were used. FCP at one point stopped doing that and would SR convert on import which drove some people nuts.

However drift is going to exist on long shots between any camera and any double system sound recorder unless both are externally locked to the same master clock, no matter how seemingly precise the individual device clocks are.

Completely true. For modern machines though that drift should be extremely small. I was on a shoot with three high end cameras a bunch of years ago and we just din't have enough came to run sync likes to everybody. The max drift between the cameras and sound (recorded free run in Boom Recorder) was less than a frame over a two hour roll.

The timecode referenced solution produces absolute frame lock between picture and sound as well as providing time stamps for editing reference. However that is actually accomplished, time code is still a valuable production tool that saves a lot of headaches in post.

The first part is not correct. It used to be with analog gear but not digital. The only way you get dead sync is with distributed word clock. TC is a positional reference only. It will start you at the same place but unless you have word clock to everybody the clocks are not locked and you will get drift. The reason is pretty simple math A subframe of TC is .24 seconds, digital audio needs a clock reference 48,000 times a second (0.0000208 seconds). TC is simply not high enough resolution to be used as a digital clock reference.

On the second part:
I have been told that it is a biggie for picture post, and I'm sure for multi camera shoots it is, but it's not used much in narrative sound post. At least not the way you are talking about, syncing production sound with picture. It is used extensively to track stuff, though F+F was actually used more for that, and it was used to get the video deck to sync to the DAW (again only as a positional reference, black burst and word clock were used for sync). The Saul Zaentz Film Center (Amadeus, The English Patient, etc.) didn't own a TC DAT machine (dates me but production was coming in on DAT then). The Ranch however did so its not like TC was never used for production but even then it was still "phased" in by hand.

Don't get me wrong, I love TC and grew up with it but how big a deal it is in filmmaking is very project dependant. If you got it use it, if you don't really look at the project and see if it's worth the cost in time and $, because it might not be.