Post (Protools and alike) latency question

[Bouke]

For the ones that do / know about audio post:
When I got back a mix from audio post (Few years ago, mixes came from ProTools), sound was always late by some 20 Msecs.
Audio post told me this had to do with latency introduced due to processing.
(I can remember from VERY long ago that a 'render' in PT was in fact a playback trough DSP's with simultaneous recording, can't imagine this is still the case...)
But, fact is (well, was, question follows..) that sound was not proper in sync. (Don't bitch about 20 Msecs being no issue, that's not the point.)

Question, is this still the case nowadays?

Reason, I'm altering my LoudnessChange app. (It nowadays can do way more fun, like altering stems based on the PrintMaster.)
It can also set new TC / timestamps. So it's a breeze to deduct some samples from the timestamp to compensate for latency.

But if it's no issue, why make the interface more complicated with something outdated...

 

And then, what to do when the start TC = 00:00:00:00 / AKA BWF  SAM 1?

Trim the start of the file instead of setting the timestamp X samples lower?

[Philip Perkins]

Current DAWs use latency compensation to account for plugin latency, and usually throw an error or report window if it is unable to compensate enough to maintain sync.

[LDstudios]

 

Yeah, it is still very much a thing today. It is usually the result of cascading recording channels into recording channels. It is an incredibly common thing to do in post for both workflow and QC reasons, with channels feeding print stems, and print stems feeding the print master. The easiest way to fix it in Pro Tools at least, is the turn off delay compensation on the print master by putting the channel into blue mode. It can become a whole lot more involved with more complex bussing structures though. The delay itself only occurs on the recorded audio. 

 

It would be interesting to hear from other people working in post about the subject. I have always been told that the sync pip/two pop is the presiding method of syncing a mix to picture during lay up. A function that could detect the pop, then align TC accordingly could be mighty handy!

 

 

[Bouke]

Oh dear...
Does this mean that if you output stems and print masters, the latency can be different between them?

(That would mean the stems won't add up to the exact same as the PM later on, potentially introduce phasing...)

Next, does this also mean that the latency is 'unknown' until after the QC?

My LoudnessChange app now has a 'latency compensation' build in, but that assumes you know the latency, and it's the same for PM and stems.
(Toy with it: https://www.videotoolshed.com/handcrafted-timecode-tools/loudness-change/ )

 

I could add a routine to find the first sound (Assuming that is pop / beep / whatever you call it), with a routine to round it / decrease to the rounded TC calculated from the BWF timestamp. (Assuming you feed it the video FPS of course...)

Or, add a routine where you can state 'pop is on TC XX:XX:XX:XX, with FPS = xx.xxx'.
Mind you, BWF does NOT carry TC! It uses a frame number, where a frame is a sample. Math is done based on that to calculate TC.

 

Bouke