Continuing the investigation, I looked at possible jitter in the rendered output over a period of ~1:30 (M:SS). I set a marker at the first positive rise from the zero-crossing on the left track of the sound in the source project. Adjusted the zoom to a constant and took a screenshot of the result. The animation from the still image sequence:

Interesting testing. Curious if the sync drift of MainConcept AVC and Vegas2Handbrake is caused by the encoding or by the decoding process.

Hmmm

In Handbrake it's the decoder. No other common input format i tested causes the audio to lead the video.

In a minute and a half, I don't see it as "drift" as much as a relatively consistent displacement from the source timing. 

Musicvid said:

"In Handbrake it's the decoder. No other common input format i tested causes the audio to lead the video."

I rendered the whole camera source file in Handbrake and observed the rendered audio output from Handbrake lead the source file by 44 ms when both files are compared in a new Vegas project. 

2018-04-25 Made changes to the text (underlined) so that I don't run afoul of conventions for +/- ms described in this article on lip sync. 

Hmmm^2

Was the audio fed to Handbrake PCM or compressed?

Here's the one surviving test I was able to find from 2012. I believe it's mov/pcm.to HB and avc/aac from HB. This is probably where I got my 40-something-milliseconds audio lead.in 2012. I remember being so exasperated at the copyright hijack that I never uploaded the compressed audio version, which was a lot closer.

(Ignore my missive to the copyroaches. I left it up because it "did" scare the pests off...)

"Was the audio fed to Handbrake PCM or compressed?"

PCM

I remember your video from the time but I don't remember having anything else about the issue at the time.

I did a comparison of PCM audio in an MP4 wrapper from the Sony RX10-III camera. I encoded the camera audio directly in Handbrake 1.1.0 64 Bit (the Latest release as of this date) with the following result:

With an older version of Handbrake 0.9.9-5330, the audio lead was less (~23 ms):

Me either, John, just piecing it back together after seeing your post.

Then, there appears to be no shift at all when Handbrake 1.1.0 64 bit encodes video from a Canon 80D (AVC+AAC in MP4 wrapper):

The PCM line of investigation seems indicated.  

I will link to this thread on the Handbrake forum.

I will go drink something.

Can you post the Handbrake encode logs for a desynced render?

They are required for support at Handbrake.

;?)

Sent you a PM.

I created a Vegas 10.0e project file that's available here, if anyone else cares to test their round-trip experience with audio sync through the various render options and applications. This test flashes two white frames with timecode that is frame-aligned with an audio pulse.

I gave up on using the Vegas2Handbrake script specifically for this reason - The audio drift was noticeable and the client for the current project I"m editing noticed it. Once I rendered directly in Vegas using the SONY MP4 option using CUDA not only did it render faster, there appears to be no audio drift - of course I'm rendering for Vimeo and set the encode rate fairly high - VBR min set to 12mbps and max set at 24mbps and let Vimeo take care of encoding for their platform on their end. I'm hesitant to give the script another shot due to the audio drift issues. Rather play it safe and let Vegas handle the encode directly.

I've been using this script for a while, and I don't notice any audio drift in the finished encode. Maybe 42ms is not enough time to visibly notice something is off? Of course now that you mention this, it's going to be in my head.

Yes, there is a 44 msec delay in most external aac encoders such as Nero or Frauenhofer. For an explanation, read the first post in this thread. https://github.com/mbunkus/mkvtoolnix/issues/715

AFAIK, there is no option for adjusting delay in Handbrake.

Yes wwag, that is an internal delay that vbr (non-interleaved) material always needs, and it is invoked in the file headers, even old-school mpeg-2,

It is rarely exposed, but drifts a little, and can be tweaked in yamb/mp4box if you are a perfectionist who also is compelled to drive himself batty.

The bug reported now twice to Handbrake only affects interleaved, cbr audio (often PCM) with the libav decoder. Why the audio leads by the same amount may be a coincidence, but it is a bug when using pcm source which I guess doesn't specify annoffset in the file headers.

Now, as then, the new bug report, motivated by j_d, met with a response from Handbrake...

https://forum.handbrake.fr/viewtopic.php?f=11&t=37672

I'm still starting my projects in Vegas 13-453 and have more or less ignored Vegas Pro 14. Today, I happened to render using Vegas 14-270 using the Intel HEVC render template, modified to fit the 1280x720-59.94p project properties. The output wins the audio lead prize with ~67ms. 

Peer review is important.