Longtime lurker, first-time poster.
I've captured about half a dozen VHS tapes (featuring 30-year-old home videos) using VirtualDub
1.9.11 (720x480 YUY2 4:2:2, ffdshow's FFV1 [a more efficient lossless codec than HuffYUV
], uncompressed PCM audio). I'm using a Panasonic AG-1980 (from TGrant Photo) connected via S-Video to an AVT-8710 (no dropped frames...knock on wood), which is connected via S-Video to an ATI 600 USB. My PC is a Core i3 3.70 GHz Windows 10 system (I know XP is recommended, but I don't have a working XP system, so I'm using what's available). The ATI 600 USB is connected directly to one of the PC's available USB 2.0 ports (USB 3.0 had bad sync issues).
I had intractable a/v sync issues for a while (moving the ATI 600 from USB 3.0 to USB 2.0 helped immensely), but after trying seemingly every combination of settings in Capture>Timing options, I finally hit upon my current settings (see attached). These current settings have solved most of the major sync issues I was having. Audio is no longer wildly out of sync to start, nor does it slowly drift out of sync over time, as it had been doing earlier.
I re-transferred the earlier tapes, and while the audio is consistently in sync throughout the files (at least, I do not notice any major sync issues upon playback), the audio stream length is usually between 10-30ms shorter than the video stream length (as reported in VirtualDub
's File>File Information...).
However, the latest tape I captured ran over three hours (I'm capturing each in a single session), and while the first half was in sync, the second half was not. Notably, there was about a minute-and-a-half of video snow between the part that was in sync and out of sync. I took a look at File>File Information... (see attached), and observed that the audio stream length was 3:15:13.27, whereas the video stream length was 3:15:12.90 (shorter).
Using Direct Stream Copy modes for both video and audio, I deleted most of the video snow and saved each half as a separate AVI. Loading up the second half, I used Audio>Interleaving...>Audio skew correction>Delay audio track by ___ ms, and set it to -370 ms, then saved a new AVI (using Direct Stream Copy for both again). This corrected the a/v sync exactly, and I then put both files back together and saved them as a new AVI.
Using AVI MetaEdit to generate an MD5 checksum in an AVI file chunk, I have been able to confirm that Direct Stream Copy does not re-compress or alter the video data at all. However, when using Audio skew correction and Direct Stream Copy, VirtualDub does modify the audio (somehow). I realize that any audio editing for audio cleanup/restoration (which I plan to do) is best done in and saved as 32-bit floating point, to minimize quantization errors. It seems that VirtualDub adds or subtracts from either end of the audio track by the exact ms value input in Audio skew correction. How does it do this?
Is VirtualDub converting the audio internally to 32-bit floating point to perform the Audio skew correction (even in Direct Stream Copy mode for audio)? If it's not doing this, is it able to retain the existing audio bit-perfect but for the additions/subtractions from the Audio skew correction without first converting it to 32-bit floating point?
Some additional questions:
1) Assuming it can be determined that there is no quality loss by using VirtualDub's Audio skew correction in Direct Stream Copy mode, should I save the original audio (prior to using Audio skew correction), just in case?
2) Assuming it can be determined that there is no quality loss by using VirtualDub's Audio skew correction in Direct Stream Copy mode, should I use it on the earlier tapes where the audio stream length is only 10-30 ms shorter than the video stream length, despite the sync already looking good to me?
3) Instead of using VirtualDub's Audio skew correction, should I instead save this step for when I edit/cleanup the audio?
Any input would be appreciated! I've learned a lot from this forum. I've yet to tackle learning AVISynth—my immediate goal is just to get the tapes transferred.