Dual sync sound - proxy

I remember encountering an issue when using dual sync sound with proxies. My normal workflow would be to make proxies first, then sync audio. I use timecode from tentacle sync, where I use "update timecode from audio " .

I think my best action is to first update timecode in resolve from the audio, then make my proxies.

Any insight or better order of procedure for this?

I believe you sync first then make proxies and if memory serves, the proxies then have the sync'd audio burned into them.

Thanks Steve, i vaguely remember this as well. I'm going to test this and I will post my results. Syncing first then making proxies is a very backwards thinking process to me, as having an assistant editor syncing without source files makes so much more sense. Especially with the standalone proxy generator.

Yup. I really dislike the idea that proxies are different depending on at what stage you generate them.

Also I believe the sound is burned into the proxies but not actually used. You still need the original sound files.

If you test I’m curious to hear what you discover.

Also I believe the sound is burned into the proxies but not actually used. You still need the original sound files.

That sounds familiar - quite an odd design decision. I'll have to play with this some day to understand when and why...

I have claimed before and will claim again that proxies should be as faithful as possible to the original media with the sole exception being the amount of resources required to handle them.

This means a proxy can be in a different codec and with lower resolution and/or bitrate. Changing anything more adds a mountain of complexity and opportunities for bugs.

If the proxy does not use the embedded audio in this case, then what happens if you link to external audio after the proxy is made? Does it matter? I'd be interested to understand how the cloud workflow with just proxies functions when the clips in the original project were linked to external audio - you would think that the external audio would also be required by other users of the cloud-based project...

Here are some observations so far:

From my testing the biggest workflow procedure is to first "update timecode from audio track".

1. When creating proxies before updating timecode, when timecode is "update timecode from audio track" Resolve will keep the proxy connected. However, if you unlink that proxy file and try to relink, the timecode now doesn't match and won't reconnect. Highly recommended to not use this method since if for some reason the proxies get unlinked, you can't reconnect them.

2.When first "update timecode from audio track" then create proxies. The proxy does inherit the updated timecode and if the proxy is disconnected, it can be relinked.

3. When "update timecode from audio track" then syncing audio, the proxy does contain the sync'd audio on a file level, not only on a Resolve Database level. (this must have changed since the last time I tested as I don't remember the channels of audio being embedded)

4.When first "update timecode from audio track" then create proxies, then syncing audio, it does work, This workflow would work with an assistant only having access to the proxy media.

This has been discussed here also, just in case it has been missed:

viewtopic.php?f=21&t=176712

I'll bet that the mechanism for creating proxies also factors into things. If you use the external proxy generator then it does not have access to any clip properties you changed in Resolve - it does everything based on the media file properties external to Resolve. That seems to be totally different than if you generate proxies within Resolve. Somehow this duality exists but makes no sense to me and would surely lead to confusion in most cases. Great example is if you change the frame rate within the clip properties of Resolve and then generate external proxies - they probably won't link to the clips in Resolve because the clips have one frame rate while the proxies have another (the original media frame rate).