Proxy workflow messes with audio tracks

We haven't used a complete proxy workflow before. Imagine my surprise today when I exported the film and it sounded really bad. Apparently, Resolve took the audio from the original files, although many of the audio channels have been linked with separate audio recordings and/or moved to different track. This doesn't make any sense as a lot of work is lost. But more importantly: Does anyone know how to keep the audio tracks exactly as they are at the end of the proxy workflow when switching back to the original files? Thanks a lot!

This might not be related to Proxies.

If you're exporting Individual files, the clip's original audio is used by default. To get the dual-system audio and effects, you have to check the Render Timeline Effects option on the Video tab.

This might not be related to Proxies.

If you're exporting Individual files, the clip's original audio is used by default. To get the dual-system audio and effects, you have to check the Render Timeline Effects option on the Video tab.

Thanks for your answer. Unfortunately we're not talking about individual clips, but an entire timeline that's exported. If you check "use proxy files" everything is fine with the audio.

OK.

What was the sequence of operations? What order were the following performed?

1. Adjust Clip Attributes
2. Sync dual-system audio
3. Create Proxies

This might not be related to Proxies.

If you're exporting Individual files, the clip's original audio is used by default. To get the dual-system audio and effects, you have to check the Render Timeline Effects option on the Video tab.

Thanks for your answer. Unfortunately we're not talking about individual clips, but an entire timeline that's exported. If you check "use proxy files" everything is fine with the audio.

Interesting. One thing I've noticed with Proxies is that, if you create them after syncing audio, the proxy files are created with the synced audio embedded. To me this is a bit of a dangerous design choice as, if your synced audio gets separated somehow from your clips, you won't know it until you try to switch back to the originals.

This shouldn't happen of course - and I don't know how it might have happened in your case - but I'm guessing that's what has occurred. You should be able to check pretty easily by opening Clip Properties on one of the clips and seeing what audio channels are mapped. If they're Embedded channels that's what's going on.

I lost audio information when I created proxy files. The problem turned out to be that I had changed the clip attributes on the original clips and created a Mono audio track with Ch 2 being the source. I needed to remove Ch 1 because it had LTC timecode on it.

The solution was to unlink the proxy files, go to clip attributes and create a Stereo track on the original clips with Ch 2 appearing on both tracks. I created new proxy files from these and the audio is now back in the proxy files.

Just found this in the manual:

NOTE If your source clip has a separate audio file synced to it in the Media Pool, any proxies
generated from that clip will include the synced audio, but that audio will be embedded in
the video clip instead of being created as a separate file.

Yes, that's how it's implemented. As I said I think it's dangerous that way because the farther away the proxies are from the original media the more things may not work correctly when going back to the original media. It's just a more complex problem doing it that way.

Yes, that's how it's implemented. As I said I think it's dangerous that way because the farther away the proxies are from the original media the more things may not work correctly when going back to the original media. It's just a more complex problem doing it that way.

I think it would be very complicated to implement proxies with the same audio track configuration as the originals. The best solution would probably be to only proxy the video, and not the audio. But as the idea of proxies is also to be machine independent, that wouldn't make sense either.

I’m not sure why simple things seem to get convoluted so easily.

The main idea of proxies is to have a video file that’s less resource intensive - processing and/or storage-wise - than the original file. That’s it. So the closer the file is to the original in all other respects the simpler the logic is.

If I switch out a 4K ProRes 4444 file with an HD ProRes 422 Proxy file with exactly the same sound then the logic for what to do with that proxy file is simple. Everything is the same - the sound if synced still comes from the external sound file. If you unsync or want to pull from the internal sound that’s still the same as well.

But if you write different audio tracks into the proxy file that all goes away. You can’t hear the original scratch tracks anymore cause they’ve been overwritten. And if you accidentally unsync your sound you’ll never know it because the internal sound has been changed to that of the synced external audio. This is a recipe for confusion.

Ideally, in the case of raw files one would keep the raw processing but just downres and maybe switch to lossy compression while preserving the ability to faithfully respond to and edit the raw parameters. But that may be technically too difficult a problem. Maintaining the original sound tracks is not.

OK.

What was the sequence of operations? What order were the following performed?

1. Adjust Clip Attributes
2. Sync dual-system audio
3. Create Proxies

Mostly in the order you listed. But this being a real world situation, there are dozens of exceptions in a one hour timeline. You know: The one where were one track in the clip attributes was set to the wrong track first because it didn't sound as expected/was not what it usually is/any number of reasons. The one where one track was not properly synced by the tentacle software and has to be synced late in the process. The one where one Mic on the Set did a better job than the Mic actually installed for the job. And so on. There are a multitude of reasons why attributes and sync are changed after the proxies are made. That's why going back to the original audio makes absolutely no sense in our case. I think we will probably have to render one version for Audio (the Proxy version) and one for Video and then assemble them. Unless someone knows an easier way out?

At this point rendering two versions and marrying them afterwards certainly sounds like the safest course of action.

Thanks a lot guys for pitching in!

Update: With a copy of the project, we tried to assign the correct audio in the original file and make new proxies. My advice: Don't do it. The system was 100% confused after we'd done it. Sometimes it played the correct audio, then it would play back the track from before, sometimes the newly generates proxies didn't play back any sound at all. It was impossible to know what the real deal was.

I’m not sure why simple things seem to get convoluted so easily.

As far as I tested this with my own workflow, video only proxies completely mess up everything if you evoke them through "Relink with proxy media" from the media pool tab.

However, if I only select the video part of the clip on the timeline, and do the same linking in the media pool afterwards, everything seems to work fine, and I can toggle back and froth between originals and proxies.

Complexity Kills.
https://www.google.com/search?q=%22complexity+kills%22

Longstanding quote from software engineering. Make something as complex as it requires and no more.
Resolve and its UI are far more complex than the job requires. It will get less and less reliable and maintainable as its complexity grows. Job 1 should be taming that complexity - both for the users and the developers. Gotta give them enough time to do that rather than adding new features.

Once things are truly clean and stable - and the bug database is "small" - then there's a solid platform for new features. Not before. It's really easy to ruin a codebase by ignoring "technical debt." And like financial debt, interest accrues rapidly and the software can "go bankrupt" - ie it's so dangerous to try and modify it that it just has to be thrown out. Don't want to get there.

However, if I only select the video part of the clip on the timeline, and do the same linking in the media pool afterwards, everything seems to work fine, and I can toggle back and froth between originals and proxies.

As far as I can see, this behaviour is not documented in any way in the manual.

One easy workaround is to bounce the final audio mix onto a new track and use this as solo track when delivering. This allows you to switch off the Proxies without messing with the audio.

Hi guys,

lad to have finally found this thread. I have a similar problem and wonder if anyone could shed some light on it?
we are shooting canon raw and recording sound onto a separate recorder with ultrasync for TC. we sometimes have a top mic going into the canon, sometimes not. we are syncing in resolve using TC, and sometime appending the tracks if we have a top mic. then generating proxies and distributing those proxies to the various editors who are working on the projects. we are using the collaboration feature which seems to work great in most cases.
the issue we are coming across is also related to audio, with the audio switching from linked (the separate recorder) to embedded (the camera) seemingly at random and so we are loosing the synced sound on an almost daily basis.
we have not found any kind of work around yet, but its making editing a nightmare, i dont suppose any of you folks have any suggestions for how we could fix this? id be happy if resolve could just be forced to play the linked files instead of switching back to the embedded files, as the additional issue is that it will do it on every timeline we have, so even switching back in the media pool does not update the various timelines, its a full on nightmare!

thanks,

Chris

It looks like this is still the same mess in 18.5?

I've just come across this whilst making proxies from some FX3 footage. The FX3 came into Resolve with Stereo audio tracks although it was recorded with a camera top mic on Tk1 and Radio mic on Tk2.
I changed the audio of the clips in Clip attributes to dual mono and then made Proxies. This simple process caused all sorts of hell!
Missing audio when playing back. Playing the wrong audio and then when I could hear the audio it would export as silence.

Got rid of the Proxy files and all is back to normal.

I haven't tried making the proxies before changing clip attributes yet, which would seem like a workaround, or using the External Proxy Generator which presumably looks at the source file without changed attributes.
But I am glad I found this thread.

The confusion was compounded in that my Edit Producer had precut some Interviews on FCPX which also picked up the stereo audio clips. At first I figured the imported FCP XML file was causing the problems. What a day!

I changed the audio of the clips in Clip attributes to dual mono and then made Proxies. This simple process caused all sorts of hell!

Proxy workflow is DR is totally buggy.

In my case, it helped changing stereo tracks to 2 channel adaptive, before linking proxies.

Here's a link to my previous comment where I describe what I'm pretty sure is going on:
viewtopic.php?f=21&t=176712#p928045

Ugh - fail! I was disappointed to discover this. Why why why can't proxy files just always have the same audio channel structure as their original counterparts. Joe is right - this seems like really bad design. Proxies by definition should be identical to originals in as many ways as possible, just smaller! Anything applied to the original in the NLE gets applied to the proxy post-creation/non-destructively in the NLE the same way and the output should be identical to the original, excepting any differences due to compression/sizing. If you can't treat it exactly the same as the original in this way, then you shouldn't call it a proxy. You wouldn't burn in audio gain adjustments or image transforms into a proxy (save maybe some specific scenario), so why would you burn in a change to the channel arrangement?

I've started to think nobody gets what a proxy really is. I've seen Premiere screw it up, I've seen cameras screw it up, and now I see resolve screws it up. Too bad because I was actually pretty happy with my proxy experience with Resolve so far.

In my case, all I did was take some 4 audio channel clips down to 2 channels to keep things tidy on a timeline (in Clip Attributes... cause only 2 of the 4 channels had any audio). Now the channels in the proxies are wrong, so when proxies are enabled I hear the wrong channel. Disable proxies and they're correct again.

I understand there are cases where file types do not support more than 2 channels, but this isn't what's going on here.

Anyway, the fix seems simple and I'd love to see it implemented.

Anyway, the fix seems simple and I'd love to see it implemented.

Actually it should be easier to implement it the right way than the wrong way, as it is now. As proxies are central to the Resolve workflow, I wonder why they don't give more attention to it.

I think they recently spent a great deal of time on it. And made it very complex. Was it in v16 perhaps?

It would have been easier and less buggy if they did it the straightforward way. But now that it’s in there the complex way it’ll probably be a big job to extract most of the complexity and make it simple.

Yea you may be right about them "improving" proxies. And I have otherwise found proxies to be fairly solid lately.

But regardless of what they did this is pretty clearly a bug that they need to fix.

I double checked and it is indeed using the modified settings (from clip attributes) and baking them into the proxy file. In my case just not including the channels I removed in clip attributes.

Even if you made the dubious argument that this was appropriate for some odd reason, you should then ensure that clip attribute settings are at least not being applied AGAIN to the proxy, cause that would just be dumb and break things (and again this whole way of doing it seems needlessly complex).

But this is exactly what it is doing: applying channel re-mapping after that channel re-mapping was already baked into the proxy.

Last I heard this is still the best place to file bugs so...

BM DEVS! This is very easy to reproduce:
1) Change the channel arrangements of a clip in Clip Attributes - just make sure it's something different from the original. For example: in a 4ch scenario where only track 3 has audio, eliminate all channels but ch 3.
2) Generate a proxy of that clip.
3) Toggle on/off proxies and you will see that the audio channels change and are incorrect when proxies are on.

Also, if you use the external proxy generator, it does not make use of clip attribute changes you may have made to the clips in the media pool (including linked audio) - how to reconcile?

Steve, can you be more specific about what you mean by "make use of clip attribute changes"? Does this mean the proxy file does not get those attributes baked in? Or... Something else?

I ask because that actually sounds like the behavior we are asking for.Ie make proxy attributes always match original attributes as closely as possible and don't bake in any modified attributes.

Full disclosure I have not used the separate proxy generator app yet - all my post relate to the other way of generating proxies within DR. Should have mentioned that!

The external proxy generator only uses the source files to transcode to proxies. It has no access to clip attributes in the Resolve project.

Ah - good point! Well to me this seems ok, unless you're saying Resolve ignores settings in clip attributes when connected to a proxy generated this way? When I have a moment I may have to test this out and see for myself to understand it.

Ah - good point! Well to me this seems ok, unless you're saying Resolve ignores settings in clip attributes when connected to a proxy generated this way? When I have a moment I may have to test this out and see for myself to understand it.

I suggest trying it. You raise a very good point. What audio source is used by the external proxy? Does it honour the linked audio? I fear not. Back to this being a poor design.

I have to make proxies of some ProRes4444 footage, the camera didn't record audio and there wasn't a timecode. For some takes there are 3 separate audio tracks. I was told to sync first and then do proxies, that way I save a step. When I sync the audio manually and then try to export as INDIVIDUAL CLIPS, the 3 audio tracks become one. This doesn't work for me because we would loose capability to mix the individual tracks forward.

Two questions.

Is it a good idea to sync first and then do proxies?

If so, can I export on INDIVIDUAL CLIPS with multitrack audio files?

It seems like the problem you are having is not really a proxy issue. This is due to the way that the export process works. But I can sorta answer your questions:

It should not matter if you sync before or after you have made proxies. Making proxies should be transparent in this sense. So I'm not sure what step there is to save. But notice that I said *should*!!

I would read this thread to understand the proxy audio design flaws/bugs/edge cases that you might encounter when doing this.

As for exporting individual clips w/ multitrack audio. I have not done this but I don't see why it wouldn't work if you set export audio settings accordingly. But this is really an audio mix/mapping question, as you'll need to pay attention to how timeline tracks are mapped to output tracks. It's not just gonna know that because you have 3 tracks in your clips to put the same 3 tracks in the output files. The default is usually to just mix everything down to 2 (L+R).

It might help if you explained a little more about what you are trying to do since to me this workflow seems a little unusual (but hey, no judgment!). That said I would suggest moving the discussion somewhere else as this thread is about a pretty specific problem of how audio tracks are handled when proxies are created.

I agree that, conceptually, making proxies should be transparent to everything other than the source video and the settings used to create the proxy.

In Resolve at the moment this is not the case.

Proxies in Resolve are a snapshot of the state of the clip at the time the proxy is created. BMD please correct me if anything I say here is mistaken.

For instance, proxies have synced audio baked into them. I don’t agree with this decision but it’s not my call!

Proxies of raw source bake in the raw parameters. Not sure if there’s a way around this but it’s something to know.

I think proxies bake in things like rotation and flipping. I’m not sure if there’s a list of all the things that are baked in/parameters that are ignored when using proxies - but I hope so! And I hope BMD strives to reduce the list as much as possible. In concept it shouldn’t be more than source video and choice of data reduction (codec, resolution).

For instance, proxies have synced audio baked into them. I don’t agree with this decision but it’s not my call!

Did not know this. Good to know, but not happy to hear another way in which they have implemented proxies that I also disagree with.

For instance, proxies have synced audio baked into them. I don’t agree with this decision but it’s not my call!

Did not know this. Good to know, but not happy to hear another way in which they have implemented proxies that I also disagree with.

OK, but with the external proxy generator app, there is no 'sync'd' audio so presumably those proxies behave differently from the ones generated internally to Resolve. How the heck are we supposed to negotiate between these two? I really need to give this more testing to understand what goes where.

Haven’t used the external proxy generator - though perhaps I should since, as you say, it can’t embed synced audio in the proxies. Or put anything else in the proxies that’s been manipulated in the edit. I too wonder how the code disentangles all this.

Just finished quite an extensive documentary project shot in 4k(H264, 400Mb/s, mostly Sony FX 6-9 cameras) with separate audio 4 to 11 tracks (depending on the sound guy).

I had the original video on an external raid. And the original audio on a separate (internal) ssd.

I FIRST generated 1080 p / h264 proxies to another separate (internal) SSD. And after I changed the audio to
adaptive 5- 11 depending on the number of audio tracks.
And THEN synced / replaced the audio. 99 % had embedded timecode, the rest had usually timecode on an audio track and some clips I had to do by hand. (no timecode).

I had no problems/ technical issues with this approach during editing. (100 hours cut to 2, and 200+ timelines)

However, I had some problems when I had to send an AAF file to ProTools. Not all sound guys recorded m/s stereo, they didn't read the production bible about track order etc. But the biggest letdown was that the AAF file lost the metadata (shot and track names) of the audio files. (used Resolve 18.1)

Just found this in the manual:

NOTE If your source clip has a separate audio file synced to it in the Media Pool, any proxies
generated from that clip will include the synced audio, but that audio will be embedded in
the video clip instead of being created as a separate file.

This is pure insanity. Proxy creation has to be done at file level, the idea being to save space on the drives and lighten up the workload on the CPU/GPU. In terms of file size, sound accounts for nothing compared to video so it should be left untouched. Also, there are many cases where you give a low res version to the sound editor to prep the mix. And the sound editor wants to work with the original sound quality, regardless of the picture quality.

Slightly different issue, but when I use the external BMD app for Proxy generation, the sound is out of sync for long clips (more than an hour long, I'd say). So it brings another problem to the equation.

Slightly different issue, but when I use the external BMD app for Proxy generation, the sound is out of sync for long clips (more than an hour long, I'd say). So it brings another problem to the equation.

That's not good.

Separately, I'm curious how Resolve manages other clip attributes when dealing with proxies. It's not uncommon for me to have to manually change the data level from Auto to Full for ProRes HQ recorded on my Ninja V, for example, or to change the pixel aspect ratio for old HDV footage shot at 1440 x 1080. Do these get baked into the proxies and then magically Resolve ignores the clip attributes? What about when those proxies are created outside Resolve? I'm hoping that it does not bake these in and that audio is the outlier here.

I need to test this sort of thing with both internal and external proxies, more out of curiosity since I seldom use proxies, but still - many unanswered questions.

pantau000 wrote:
Just found this in the manual:

NOTE If your source clip has a separate audio file synced to it in the Media Pool, any proxies
generated from that clip will include the synced audio, but that audio will be embedded in
the video clip instead of being created as a separate file.

If you first make your proxies and then sync your files Resolve uses the original sound files.
(according to my Windows TaskManager)
I didn't test any other method.

Right. Not sure if this is the correct workflow for all cases. For example, if I use my TC-1 for timecode generation, it is important that I update my clip timecode before I create proxies, otherwise the proxies will be missing the correct timecode, I believe, and I'm not sure how external proxies behave in this case (another test, I suppose). Of course, I don't have to sync my external audio until after I create the proxies but it shouldn't matter (but it does, as you point out). Sometimes you don't know you need proxies until further into the edit. Using the external generator may be the only option in this case. I just don't understand why BMD made this design choice.

pantau000 wrote:
Just found this in the manual:

NOTE If your source clip has a separate audio file synced to it in the Media Pool, any proxies
generated from that clip will include the synced audio, but that audio will be embedded in
the video clip instead of being created as a separate file.

If you first make your proxies and then sync your files Resolve uses the original sound files.
(according to my Windows TaskManager)
I didn't test any other method.

In a dual audio workflow, I'd say syncing is naturally the first step, as proxies are not always needed.

Right - and as I just discovered, if you use the audio track converted to timecode, you can't use the external proxy generator at all (this is a pretty important revelation for those using a Deity TC-1 or a Tentacle Sync E). Also you must generate your proxies AFTER you update the clip timecode based on audio track.

There's another interesting bit I discovered, but I don't really know what to do with it. It seems that the tagging of the proxies generated within Resolve is based on the current project or timeline output setting but it doesn't appear that Resolve uses this tagging. If you, for example, had log source footage setup correctly for project level RCM with output set to Rec709 gamma 2.4, and you generated the proxies, they would be tagged as 1-2-1, however, the actual data written to the file is not 1-2-1, but is rather still log (at least as far as I can tell).

I didn't look at the tagging of the proxies generated externally but presumably it does not follow this tagging mechanism (I'm guessing tagging in proxies is simply ignored by Resolve but I just haven't done enough testing to know this for certain).

I need to test this sort of thing with both internal and external proxies, more out of curiosity since I seldom use proxies, but still - many unanswered questions.

Just had the issue again. Clips are Canon XF AVC 1080@25fps, so nothing fancy or rare. Clip is 47 minutes long and it goes out of sync after about 30mn. I recreated the proxy from within Resolve and it's in sync. It's not good if you can't trust the software you're using professionally.