VirtualDub: Fixing severe A/V async problem

[^rooker]

[PROBLEM]
When recording very long video material from analog source (e.g. VCR), it might happen that audio/video asynchronism are not continuous due to heavy signal distortion (e.g. broken tape, switching channel on VCR, ...).

Here's a "graphical" example of what I mean:

Code: Select all

                                  Part 1                       Part 2
Video                 |---------------V----------X--V------------------|
Audio                 |---------------A----------X-----A---------------|
FrameRate:              24.995 fps                   ??? fps       
Audio Offset:              0 msec                      ??? msec
Duration:                 10,002 min.                  <not important>

"X" ... Distortion
"V" ... video of event used to adjust audio sync. (e.g. lips speaking)
"A" ... audio of event used to adjust audio sync. (e.g. the corresponding utterance)

In this example Part 1 is AV-sync at 24.995 fps and an audio offset of 0 msec, but with those values, Part 2 is not.
In order to synchronise Part 2, a different combination of audio-offset AND framerate is required.

In practice, this is a real hazzle, because without the right starting position (offset) of the audio, you can't even start to find the right framerate.

This means: At an assumed framerate, you could try to adjust the offset to match the video at a certain event (e.g. a speaker utterance) to have a starting point, but if the framerate was not guessed correctly, you will see that the video is either too fast or too slow:

Code: Select all

                                  Part 1                       Part 2
Video                 |---------------V----------X--V------------------|
Audio              |---------------A----------X-----A---------------|

FrameRate:            24.995 fps                   
Audio Offset:         -12000 msec                      
Duration of Part1:    10,002 mins

NOTE: Audio and video of the event in Part 2 are now matching, but Part 1 is now out of sync.

When you try to re-adjust the framerate now, all frames before your sync'ed event will be affected, too - so you've lost your syncing point and can start all over:

Code: Select all

                                  Part 1                       Part 2
Video                 |-----------------V------------X-----V-------------------|
Audio              |---------------A----------X-----A---------------|

FrameRate:                24.3 fps
Audio Offset:         -12000 msec
Duration of Part 1:   10,288 mins

Because Part 1's video duration is now longer, Part 2 is directly affected.

Really great, huh?

[^rooker]

[SOLUTION]
In order to fix this problem in reasonable time, leave the framerate original (e.g. 25) and ONLY adjust the audio offset to have the start of Part 2 in-sync.

You should choose an event as close to "X" as possible.

Code: Select all

                                       Part 1                       Part 2
Video                 |---------------V----------X-V--------------------|
Audio               |---------------A----------X---A------------------|
FrameRate:                25 fps                   
Audio Offset:         -11300 msec                      
Duration of Part1:    10,000 mins       

Now throw away everything before your sync'ed event and export it (direct stream copy of audio and video) to a new file.
Since the resulting file is synchronous at its start, you only have to adjust the framerate properly and you're done.

Code: Select all

                               Part 2
Video                 |X-V--------------------|
Audio                 |--A------------------|
FrameRate:                25 fps
Audio Offset:         -11300 msec

...the drawback of this solution is, that you must process Part 1 and Part 2 separately and merge them back together at the end.

[^rooker]

I ended up in the problematic situation mentioned above, because I was using "virtualVCR" on Windows to capture analog video. Since I'm directly capturing with VirtualDub, I never had to synchronize anything manually again.

*sigh*
If only my coding skills & time would allow me to port VirtualDub to Linux...