Timing change between raw capture and final encode?
 

I'm trying to figure out why a compressed mp4 has audio sync issues not present in the original capture avi.

I finally found the spot 3.5 hours into a 6 hour compressed mp4 where the audio speeds up for a moment, and then slows back to about the original speed. For the rest of this video file, the sync is unmatched by a difference of about 23 frames.

Going back to the original capture avi, the audio speeds up just the same but virtualdub may have added frames to make up almost all of the difference. The screen pauses quickly in a couple quick spots totaling probably about 23 frames.

I never had this happen until about a month ago, and since then this is the 4th occurrence.

Things I've been doing differently:
- Using Virtualdub 1.9 for capture instead of Virtualdub2, more closely following the directions that I found on digitalfaq.
- Adding AG-1980 to my workflow for SLP tapes. For 2 years before that, most of what I had been transferring was taped in SP and played on a JVC.
- I'm currently transferring a box of 6-hour tapes acquired from a friend, taped in 1999 with a 2-head VCR.
- I transferred entire 6-hour tapes 4 or 5 times with the JVC. I eventually figured out that its audio quality is terrible. (I own 2 of the same model, so I know for sure it's the type of deck). So I always captured audio from a different VCR and then matched the two in Audacity. While matching them up, I never once had issues with the sync of the original capture avi. There were often speed-up and slow-down moments due to my timing preferences, but the audio always returned to a correct sync.
- During recent transfers, it's possible I changed one crucial timing setting but I don't know which one it could be.

My capture timing preferences in VirtualDub 1.9:

x "Drop frames when captured..."
x "Insert null frames..." - Burst limit = 10
Resync mode = Sync audio to video
x Correct video timing for fewer frames
Audio latency determination: Automatic, Number of blocks at start = 30
Everything else is unchecked.

Raw audio: 48000Hz, stereo, 16-bit
Compression: FFMpeg Lame MP3

This got buried in my tabs. Did you ever figure it out? :hmm:

In most cases, out-of-sync encoding is a settings issue. I notice you mentioning converting to "mp4" (container only; did you mean H.264?), but did not mention the software. Was it Hybrid?

I think I figured it out.

I cleared up half of my comp's hard drive space, and that probably made some difference.

But I think what really helped the most was after I started compressing the original capture instead of saving it uncompressed. I'm pretty sure I now always use ffmpeg huffyuv lossless codec - and select 4:2:2 for the pixel formatting. I think there's been a couple timing issues since I started doing this but they happen a lot less often.

Also i know you've advised against this, but I personally have better luck using virtualdub2 for capture.

Hmm....

There are times where VirtualDub2 is indeed the better option. But VirtualDub 1.9.x is better 90%+ of the time. Something I worry about here is the integrity of the audio captured. Because a main flaw (of several) of VirtualDub2 is related to the audio capturing.

Uncompressed is not good. Use lossless.

Lots of variables here. But if you think it's solved, let's move on. :congrats:

Oooo ok, got it.

So when using VirtualDub2 to capture video from the JVC SR-MV45U, I've been capturing audio separately from a hi-fi 6-head VCR on Audacity. So that might be why I haven't noticed any audio issues.

The next time I use the AG-1980 to capture video and audio together, I'll try VirtualDub 1.9 a few more times and pay closer attention to the audio. I don't recall why, but something was frustrating the last few times I used it.