VHS audio out of sync with VirtualDub, not AmarecTV?
 

Hello, I'm trying to transfer VHS to digital. I'm using a Vidbox USB capture device (I know, it's all I have right now though). When I transfer through VirtualDub2, the audio is out of sync and comes in around a second before the video. When I transfer to AmarecTV, I don't have this issue, which leads me to believe it's not a hardware or VCR issue, but rather settings in VirtualDub (or maybe VirtualDub itself?). I've tried messing around with the audio settings with no luck. I can post screenshots or let you know any of my specific settings if anyone is willing to help me out!

Using a device like the Vidbox without a hardware TBC can lead to dropped and inserted frames. It's the same for everyone. Experts like Lord Smurf on this forum argue that while AmarecTV seems more stable, it’s essentially masking the underlying signal issues. VirtualDub 1.9.11 is generally the gold standard because it’s brutally honest. It reports every dropped frame and timing jitter.

But you may ask (as have I) if Amarec gives you a sync-perfect file while VirtualDub causes a headache if one doesn't have a TBC, then shouldn't you just use the one that seems to work better for your imperfect setup?

I think that might be the answer for most people. But there's another thing to consider, Amarec’s internal RGB conversion. As experts frequently warn, this process can clip "illegal" whites and blacks, permanently destroying detail in the highlights and shadows that a pure YUY2 capture in VirtualDub would have preserved.

So what this means is that if you use Amarec, make sure that your video levels are within the 16 to 235 range. Adjust the brightess and contracts on the levels screen to set it perfectly before you capture. If you do that, then you won't lose visual data. And then later on after deinterlacing etc., you can bring the video back into Resolve or Premiere and tweak the brightness and contrast as you wish for the final version to make the contrast stronger and so on. Hope that makes sense.

Not sure if you mean it's falling out of sync over time rather than a fixed amount across the entire duration starting from the beginning, but Amarec prevents the former by stuffing the video full of duplicate frames.

Also if the audio is consistently out of sync, should be easy to correct.

Such as if an external TBC adds a 1 frame delay, meaning the audio is consistently out of sync by 1 frame, just fix that by delaying the audio by 33ms.

Though some tapes might have a 1 frame de-sync baked in, leading the audio to be delayed by 2 frames / 66ms

Ahh, so it may be that Amarec is compensating by forcing extra frames and an overall bad picture quality to make the audio sync? Interesting. I really wish I had the money for a TBC, or even a better VCR, but I will have to make due for the moment. I was hoping to avoid having to do extra audio synchronization after capturing as I'm just trying to get a solid side hustle going converting old tapes for people, but it may come down to a little post-processing. Anyway, thanks for your comments!

The VidBox uses Empia drivers, which I suspect are buggy. I observed the same de-sync issue using VirtualDub2 and an ATI600 USB using newer Empia drivers that work on Windows 10 and 11. Annoyingly my one TBC is broken at the moment, so I can't confirm if adding one back in the chain fixes the problem.

Looking at the specs of the VidBox NW03, its using a Philips/NXP SAA7113H, which is similar to the chip used in the AVT-8710. These chips seem very tolerant of sync issues present on VHS sources.

Need to correct myself. Another thread at another forum has convincingly proved that this is incorrect. In fact, Amarec will produce YUV color space files if you pick a codec that uses YUV. So, that is great news. I haven't use Amarec much but am now testing it. In particular, I want to better understand how it logs inserted frames (and dropped frames). From my initial test, it produces a detailed log that shows you exactly where the inserted frame was added. And I confirmed it was accurate by putting the AVI file into VirtualDub and scrubbing to that frame to see visual evidence of the inserted frame.

So, it Amarec allows one to capture in YUV color space, and automatically keeps audio and video sync by its smart use of inserting frames, and if it logs everything in a way that VirtualDub does not, then I am seriously considering switching to AmarecTV as the capture software I use.

Oh nice! Please keep me posted if you don’t mind, or if you just end up posting a video about it on YouTube I’m sure I will catch that :cool:

The problem is that AmaRecTV is Japanese analogs streaming software, essentially a pre-OBS. Streaming software borrows from the broadcast world, and is a bit twitchy at dropping/inserting frames. This is because the #1 priority is constant unbuffered/semi-buffered output.

By contrast, VirtualDub was specifically created for analog video ingest, not streaming/broadcast. It allows tweaking how the buffering prioritizes drop/insert -- as well as a poorly-labeled de facto "turn of buffering" and "stop reporting" by checking those top two boxes in the Timing Settings.

The outcome is AmaRecTV will insert and drop more, on average. I know you like to test everything, so have at it. Realize it will vastly differ per card and driver, even more than you've experienced in the past.

AmaRecTV, again Japanese software, was really made to mate with Japanese cards based on Japanese chipsets (aka PEXHDCAP, GV-USB2, etc), using the AMV4 codec. Outside of that specific combination, it tends to be mediocre to crap.

Read this thread from 5 years ago,
specific jwillis post:
https://forum.videohelp.com/threads/...B2#post2619908
then this post from lollo:
https://forum.videohelp.com/threads/...B2#post2619908

Note specifically lollo's comments here:
So 5 years ago, he was far more friendly, and a bit more honest about card performance. I don't know why he now takes the stance that the card walks on water, can do not wrong, never drops/inserts frames. And lollo is probably the biggest fan of AmaRecTV, and probably the source is the GV-USB2 meme that was picked up by YouTubers and Redditors (who all wanted shiny new cards from Amazon, even if worse, not better used cards).

So don't be too giddy to switch over. :wink2:

Thanks for those details. My strategy is to

1. Run my Amarec-captured AVI file through a tool to look for duplicated frames.
2. Compare that log to the Amarec log to see if Amarec underreports.
3. Run my VDub1911-captured AVI file through a tool to look for duplicated frames.
4. Compare the number of duplicated frames with the Amerec method and the VDub method.

Can you think of anything else for this test?

This will probably prove a separate point, but if you haven't already and are working with capture hardware and a computer that came out of the 2000's, maybe try different operating systems, e.g. 7/10 vs XP. Both programs work generally fine (or at least a whole lot better) for me in XP - reasoning for this has been stated elsewhere on this form.

Speculation here, and assuming the above: Amarec and VD doing what they do with the frames is, I think, is less a problem with the programs themselves and more a presentation of flaws at the OS/driver level (and thus device selection). My suspicion is that they're likely both performing exactly as they're programmed or configured to - in different ways, and when faced with said flaws Amarec paints over them more gracefully just because it's what it does. (It's been a bit, but I seem to remember VD being able to insert frames too, but the results were a lot less good looking. Maybe less frequently but in larger clumps?)

I don't know the reality of this, as I just stuck with my XP setup once I found that it worked for my purposes and stopped looking elsewhere, but I think the real win in this situation would be finding a capture device that runs on a modern OS and legitimately doesn't cause these errors to happen in the first place.

Some further thought: this is probably the most important part, and in addition to or instead of using a reporting tool for this, I'd confirm visually by pulling up both samples each in their own VD instance simultaneously, trim both so they are starting at the same frame, and then scrubbing both to the same frame near the end and seeing if the numbers line up (or moving both the same number of frames and seeing if the frames line up). The longer the samples the better.