VHS capture in VirtualDub 1.9.11 audio drift?
 

Hey helpful people!!

Doing VHS captures with the workflow below. I am seeing a lot of audio drift (at zero minutes audio is right on, and by two hours, it's off by probably 10 seconds). I wouldn't expect to see that with a frame TBC and a VCR with line TBC. CPU on the machine is never over 50% during capture, so I don't think it's related to that.

Could be helpful information:
- I did a bunch of captures with a Sony TRV-460 (has line TBC) and when trying to use my frame TBC, I had audio sync issues. When I removed the frame TBC from the equation, I had no audio sync issues at all. Finished capturing my Video8/Hi8 stuff with ease and moved on, figuring it was something weird with the camcorder. Seeing this issue now, I'm wondering if my frame TBC is having issues? Any way to test that the frame TBC is doing what it's supposed to?

In my "Capture timing options", I have only these two options (screenshot attached)
* Do not resync between audio and video streams
* Use audio timestamps when available
* Audio latency determination is set to "Automatic" with "30" as the Number of audio blocks to use at start.

My thought is that with the TBC cleaning things up, I wouldn't have any dropped video frames and so the audio would stay in sync. Maybe my thinking is off.

Workflow:
- JVC SVHS (SR-MV50)
- CDM-831TR (equivalent/similar) TBC
- ATI TV Wonder 600 USB
- Dedicated Win7 Machine with no extraneous software installed or running (7th-Gen Core i5 w/ 8GB RAM)
- VirtualDub 1.9.11 (pulled from the forums here)
- HuffYUV 2.1.1 being used
- S-Video Cables (Belkin Synapse)
- RCA Audio Cables

Thank you very much for taking the time to read and help. Any help is appreciated!

Do not uncheck those first two boxes. All that accomplishes is disabling drop/insert frames reporting. With these unchecked, the Hi8/V8 captures are now suspect. It likely "maintained sync" by dropping/inserting frames. If/when you actually watch the video, expect errors/stutters.

The frame TBC disallows drops, minimal inserts.

Check automatic disable resync.
Disable audio timestamps.

If that CPU is even over 10-20%, something is wrong. It should not be anywhere near 50%.

This is great to know -- thank you! I have now checked those top two boxes, automatically disable resync, and disabled audio timestamps at the bottom. I'll report back!

I'll call it luck -- I have watched all of the V8/Hi8 footage and it was incredibly clean all the way through. I'll take luck wherever I can get it.

SMH -- I was tired when I looked at all of this. The 50% was during re-encoding, not capture. During capture, there is little-to-no CPU usage. Thank you for pointing this out so I could go back and confirm. :wall1:

-- merged --

I updated the suggested settings and ran a new capture. Still seeing the same audio drift. For reference, the stats on the capture say zero frames dropped and -7 jitter. Not sure what to try next. Is there a way to test the frame TBC? Is it even possible the frame TBC has an issue and is causing this?

I just realized something: Are you properly bypassing the TBC for audio? Just use a TBC for video, and wire audio directly from camera/VCR into capture card.

The frame TBC doesn't process audio. It just passes (or worse, though rarely) when present. Most TBCs entirely lack audio functions, but this specific model has passthrough because it also acts as 2-out distrib amp.

Thank you for that information -- I was so excited when I read this and realized I should have the audio go directly from the VCR --> Capture device and only have the video go through the TBC. Ran another capture -- still having audio drift, though it seems like maybe it's lessened. :-( Anything I can do to try and isolate things to determine my offender?

Apologies for not reading the entire thread. Just wanted to be sure you\'re aware of the Virtualdub Settings Guide. There really should be a sticky for this thing. Seems you would be most interested in the Timing portion of this post in the guide https://www.digitalfaq.com/forum/vid...html#post45242 Note it doesn't necessarily tell you ideal settings for everybody in every setup, but hopefully it helps understand the settings better.

Thanks, Keaton. I have been through that thread, which is hugely helpful to the community, including LS's detailed reply with additional information. I have also been through the VirtualDub docs regarding the timing dialog individual settings and what they mean/do. It feels like there's something else going on, but I can't put my finger on what it might be. Tomorrow morning, I'm going to try a capture without the frame TBC to see the result. I'm just trying to eliminate variables, and that's the easiest to tackle first. Too many variables in the software for a starting point, as we've already seen.

Thank you all for your valuable input along the way on this journey. After the last post about three weeks ago, I just kept testing different timings, different combinations of overlay vs preview vs no preview, timings, TBC on/off, and anything else I could think of. After 4 hours today, I threw in the towel and decided to go a bit nuclear.

Windows 10 1607 (pre-Creators Update) w/ ATI Wonder 600 USB driver installed and all Windows Update blocked, I got 4 hours on one tape with zero audio drift. Grabbed another tape and did a two-hour capture, perfect video and no audio drift.

I know these data points are anecdotal, but at least for me, Windows 7 was problematic from the jump and earlyish Windows 10 worked great. Thank goodness to all of the 2017 posts that mentioned capturing used to work and broke with the Creators Update. At least that told me what version to target. I'd been tempted to pull out some old hardware to use Windows XP, and I'm really glad I didn't have to go that route.

As always, I'm so grateful for the engagement in the forums here. I am finally ready to start the capturing of all the VHS tapes that are waiting. I'm sure I'll have more questions along the way. :-D