Audio cutting out, but only when Proxies are on

[Roo Vandegrift]

Hey everyone, I'm having the strangest issue, and I'm hoping someone can help me out here. Basically, the issue is that the audio cuts out during playback randomly, but only when proxies are toggled on.

I've been all over the forums (and all over the internet!), and certainly other people have had similar issues with Premiere and audio cut outs, but I can't find any particular post that relates those audio cut outs to proxies. It took us a long time to figure out that it was related to the proxies, too, since it's so counterintuitive: maybe some of these other audio cut out issues were also related to proxies, and they just never knew? 

The other aspect to the problem is that it's worse the bigger and more complex the project is: with a small project, it's not really an impediment, but we're starting to work on the initial edit for a feature-length documentary, and it's just killing me! The sequence will play for 10 sec or so, and then the audio cuts out; the video will keep going, and the audio will come back randomly. The distribution and timing of the dropouts seems to be completely random, and unrelated to any properties of the source footage (encoding, frame rate, etc.). And, importantly, it's not just the audio linked to the proxied video that's dropping out: it's all of the audio, no matter the source or file type or bit rate. If the proxies are toggled off, the issue dissapears (but then, of course, the video is choppy as hell, since all of our footage is 4K).

The Audio Clip Mixer display drops to infinity when it happens, for all clips in the timeline. So, that means that having proxies toggled on somehow triggers stochastic disruption between Premiere and the audio output device, I think. 

Here's my system specs: 

Powermac, 2.5 GHz i7, 16 GB RAM, NVIDIA GeForce GT 750M 2 GB 

Running macOS Catalina, v10.15.7

Premiere Pro, version 13.1.5

The project is mostly using footage recorded from a Panasonic GH5 in 4K at 23.97fps, using the standard H.264 codec, but there's a mix of other things in there; source or encoding doesn't affect the issue. The proxies are generally Apple ProRes using the CFHD codec, but we've tried changing the proxy ingest settings to pretty much everything, and it doesn't affect the issue either. 

We've tried clearing all of our caches, resetting all of our preferences, re-proxying clips using different settings, we've changed the Audio Hardware and Playback preference settings in every way we can think of that might make a difference... We're just stumped, and the issue is so severe as to complety stop us from being able to move forward with the project.

Please, can anyone help? 

[Kevin-Monahan]

Hi Roo,

Are you sure you have your proxies enabled? It sounds like the full raster video might still be playing back. Can you check to see that proxies are attached and that the UI is enabled for proxy playback?

Your footage might be the 10 bit variant of H.264, and with your somewhat underpowered computer operating on a recent version of macOS might create the perfect storm of performance problems.

If you are indeed playing back proxies, you might try smaller sized proxies. You can also render your audio before playback. That can help a lot of folks that have underpwered systems.

Let us know more details and hope we can help.

Thanks,
Kevin

[Roo Vandegrift]

Hey Kevin,

Thanks for the rapid reply! I'm going to reply to your questions/points first, and describe the tiny bit of progress we've made since I posted after.

You're right, it does sound like the sort of problem you'd get trying to play back the full raster videos instead of the smaller proxies. Sadly, that's not the case: that was the very first thing we checked. It's definitely the proxies playing. That's part of what's so frustrating and mystifying about it! Like I said in the OP, the random audio cut-outs only happen when the proxies are toggled ON. And yes, they're definitely attached, we checked that right at the outset too. 

Most of the footage is actually 8-bit H.264, but there are a few 10-bit clips in there too. But there's also HD archival footage and a number other things (lots of secondary video sources for this documentary film project). None of that makes a difference — audio is fine with the proxies off, and has random drop-outs when using the proxies. And the proxies are as small as we could make them, only 720p, with filesizes typically less than a full gig. 

About rendering the audio before playback: that was an interesting suggestion, and something we hadn't tried. It's not the solution-solution, but it did sort of fix the problem! Unlinking the audio from the video and then "Render and Replace"ing the audio did stop the audio cut-outs — very strange, given that the audio cut-outs affected all audio tracks, not just the one that was linked to the poxy video. But sadly, it's not a practical solution for the whole project, because rendering all of the audio means ripping the audio for each and every video file and generating a new .WAV file that didn't exist before. Aside from the time component (OMG, just thinking about doing that for each source video... it's worse than proxying it all over again!), we're utilizing a co-editing workflow that relies on cloned external drives with all the footage+proxies, and passing just the project file back and forth. I suppose we could unlink all the video files, create the new .WAV files, and then re-clone the edit drives, but that's a pretty drastic step — I'd like to avoid such a bruteforce workaround if we can. 

But the realization that removing the audio from the proxy file did stop the audio cut-outs pointed us in the direction of a little more understanding. Here's what we learned from that: 

For some reason, no one had noticed that the proxy videos were also much more stuttery than they should've been — like you said, it's a rather underpowered machine, so I guess everyone was just going with it. Well, after a lot of trial and error, we've figured out that we're having trouble specifically with videos using the CineForm or Apple ProRes codecs: codecs that are suppose to be uncompressed and have faster playback in previews just like this. All our proxies used the CineForm codec specifically for that reason. Rendering and replacing the audio fixed the issue because it stopped using the audio from within the CineForm wrapper! 

It turns out, when we re-proxy select clips and use H.264 (which, I know, you're not suppose to!), everything works great. And if you just drag one of these CineForm videos straight into the timeline, unproxied, you get the same audio cut-out issue. So that's fascinating.

So, it seems like the problem is with Premiere's ability to playback videos (both the video and the audio) that use the CineForm and Apple ProRes codecs. And knowing that, I'm still stuck — nothing on the forums or the intertubes seems to address problems with playback/audio for videos using particular codecs, other than than to tell me that CineForm ought to improve playback (not make it worse!). 

So... any ideas? (Other than re-proxying everything — I'd like to preserve the investment in time we've already made to create the existing set of proxies if we can, since there's a lot of source material here. And, I'd love for Premiere to be able to deal with CineForm and ProRes video files, you know.) 

[Roo Vandegrift · Accepted solution]

Well, we figured it out, and boy do I feel silly. 

All of the problems we identified (first, that the audio cut-outs were only happening when the proxies were toggled on, and then that the issue was only with CineForm or similarly encoded files) were merely symptomes of the real problem. 

Turns out the issue wasn't with Premiere at all: the dedicated high-speed drive used for the proxies was slowly dying. As the transfer speed from that drive decreased, any video playing from it got glitchy and suffered audio drop outs. The apparent issue with CineForm was just because we were keeping all of our proxies on the failing drive, and those were the only files using that codec. So testing different codecs really amounted to a systematic error, and the test was also testing the different drives (the raw footage drive vs. the proxy drive). 

Thanks @Kevin-Monahan for the intellegent chime-in, and everyone for bearing with me while we knocked our heads against this stupid wall! Advice for everyone else: pay attention to when your hardware is conflated with other aspects of whatever problem you're investigating, because hardware failure does happen, even when it's not expected (like here: that drive was less than a year old).