Nero Video Grabber vs Hauppauge WinTV-USBlive2 vs August VGB300

[rgr]

I don't use version 1911, only the latest x64 build 2.1.3.667. I have frame dropping disabled in VirtualDub, so if something drops frames, it's the device, not the program (you can't set this in AmarecTV, it always drops more frames than VirtualDub).

Frame dropping improves when TBC is enabled (but that's later), in VirtualDub it drops to around 0 (but not in AmarecTV), so as you can see my hardware is completely fine.

[Brad]

Hi rgr, Bogilein, aramkolt. I have also "built" my own test pattern for A/V sync and field-fidelity using a few publicly-available sources.



Then last week, I saw this interview: https://www.retrorgb.com/interview-with-video-preservationist-peter-b.html

# DVA-Fidelity
The testvideo I mentioned, I invented to test a firmware-timing issue with a Focus Video ADC: https://www.av-rd.com/products/dva-fidelity/detectable_issues.html#top

All the “detectable issues” that show an image, are actual “timing interventions” that 4 different ADCs introduced. Ranging from 1000 to 12000 EUR from low-pro to broadcast-bling gear.

The system allows to detect if /any-and-all/ images (fields/frames) arrive in the right order (time and top/bottom) – throughout any signal chain.

We used this video to proof (around 2010) that Virtualdub + ffdshow +ffv1 is perfectly lossless throughout the whole “questionable FOSS stack”: Harris Velocity editing workstation SDI out -> genlocked -> SDI-IN blackmagic => ffv1/pcm/avi.

We ran several 4h-long tests from different sources: digital, digibeta, VHS – even DV.

The site describes how it works: https://www.av-rd.com/products/dva-fidelity/introduction.html#how_does_it_work

I’ve published the code online: https://github.com/ArkThis/DVA-Fidelity/

Yeah, it’s “Xubuntu 20.04 (live) distro” – then:

“`
$ git clone …
$ make all
$ (sudo) make install
“`

I’ve had a patch made for a version of ffmpeg, but which never went upstream – so it requires to build ffmpeg manually.

Here’s a special one: https://www.av-rd.com/products/dva-fidelity/issues/yc_interpolation/images_3/000002err-ftb.jpg

It’s a snel-&-wilcox 12000 EUR ADC, which inserted a new, visibly-interpolating 2 fields from different frames (#19+20).

Finally! What I've been searching for over the course of years has existed for over a decade, and was shared on GitHub in Nov 2023!

I still need to give it a go. Too busy this past week so far.


---

@rgr I don't see direct "DVD player" results listed, only VHS captures. Have you verified every one of your workflows using this "control" first? Note that according to Peter's testing, 1hr is an insufficient test length. He recommends 4hr.

I simply loaded a file generated by AmarecTV or Vdub into VDub (+deinterlace if necessary).
Maybe AmarecTV doesn't report drops (it doesn't report me -- 0 drops), but it drops a lot of frames, most in the test.
The test procedure is described above, you can also see the screenshots -- these are 180000 numbered frames recorded on a VHS tape. It was enough to set the dump to a frame with a counter of 0 and move forward 180,000 frames (I checked every few to a dozen thousand). Then you can see that AmarecvTV's reports have nothing to do with reality.

My tests confirm your own -- in contrast to Alwyn's experiences.

In addition to post #23 which disproves the claim that AmarecTV does not record drops/inserts, I have just done a bunch of tests with a very bad tape. My conclusion is that AmarecTV and Vdub both report Inserts accurately, verified by going through the capture files in VDub with Shift ].

All my captures were stabilised with either a Pioneer 645 or a ES10. I therefore conclude that the claim that both do not report dropped/inserts is invalid.

In any case, every time my tape was stabilised and captured with ATV, there were no drops/inserts.

Now try without the stabilizer in-line and check whether AmaRecTV accurately reports drops/inserts. I mentioned the issue 9 years ago.

[Alwyn]

Now try without the stabilizer in-line and check whether AmaRecTV accurately reports drops/inserts. I mentioned the issue 9 years ago.

Start:

[Attachment 85887 - Click to enlarge]

End:

[Attachment 85888 - Click to enlarge]

Screenshot of ATV towards the end:

[Attachment 85885 - Click to enlarge]

VDub found no dropped frames.

ATV report attached.

System: JVC 5700, IOData GV-USB2, AmarecTV into MagicYUV, Intel i5-750, Win 10 64bit, connected to the 'net

[Sharc]

@rgr (or others): Did you ever try to capture using ffmpeg directly instead of using GUIs like Vdub, AmarecTV .....? How does it compare?
Advantage is that you can capture directly into any of ffmpeg's internal native codecs like huffyuv, ffv1, ProRes etc.

[aramkolt]

I'd be curious if you could post your test sample for AV/Sync or describe how you made it and what the output chain looks like.

I've theorized that the way to go would be to make a davinci 480i timeline and then output via a Blackmagic 3G monitor (which is SDI and can output 480i) and this automatically bypasses any color settings within the operating system, then go to something like a brighteye SDI to analog converter which also has a proc amp for fine tuning and can produce S-Video, composite, or Component. From there, would put a waveform monitor/vectorscope in line to make sure levels coming off of that are correct.

Not sure how I'd put all the test features I'm seeing there in your screen capture though? Guessing it is probably a rather large file that is too big to post unless it's on repeat or something?

[Sharc]

Now try without the stabilizer in-line and check whether AmaRecTV accurately reports drops/inserts. I mentioned the issue 9 years ago.

Start:

[Attachment 85887 - Click to enlarge]

End:

[Attachment 85888 - Click to enlarge]

Screenshot of ATV towards the end:

[Attachment 85885 - Click to enlarge]

VDub found no dropped frames.

ATV report attached.

System: JVC 5700, IOData GV-USB2, AmarecTV into MagicYUV, Intel i5-750, Win 10 64bit, connected to the 'net

Some doubt here about the significance of this test:
If the video content on the tape is the frame (or field) number on a static (e.g. black) background only, the average analog signal level is pretty constant over time. Means the luma+sync signal on the Y-wire does not put any challenge on the DC restoration and AGC of the receiving device, which would be critical for the device's sync pulse and vertical frame pattern detection capabilities (slicer). The test result for a static background may therefore be optimistic. For a more conclusive test I would suggest to superimpose the frame/field number onto a real (natural) video with the usual "wild" luma and chroma fluctuations. I suspect that it can make a (device dependent) difference.

Edit:
In a similar context - when a Panny DVD recorder in passthrough is in place - the result may also depend on whether one takes the S-Video signal from the DC-coupled (and DC restored, clamped) SCART output or from the AC-coupled MiniDIN (aka Hosiden) connector.

[Alwyn]

I can't be bothered, Sharc. Brad hasn't even acknowledged the effort I went to to answer his request so I'm not going to waste any more time on this stuff. I know what I see and that's good enough for me. Fill your boots if you want to test your theory.

[Sharc]

I can't be bothered, Sharc. Brad hasn't even acknowledged the effort I went to to answer his request....

Offended again?

[Alwyn]

Offended again?

I'm never offended. Annoyed that I spent considerable time making that up and using 3 hours of head wear I'll never get back on a good VCR, for nothing.

[Brad]

I can't be bothered, Sharc. Brad hasn't even acknowledged the effort I went to to answer his request so I'm not going to waste any more time on this stuff. I know what I see and that's good enough for me. Fill your boots if you want to test your theory.

I'm never offended. Annoyed that I spent considerable time making that up and using 3 hours of head wear I'll never get back on a good VCR, for nothing.

Hi Alwyn. Thank you for your contribution. I'm sorry I didn't reply until now, and I'm sorry you used your good VCR for this test.

I viewed your post on my commute to work three days ago. [EDIT: Actually, I guess I didn't view it until your Mar 5 edit, since the images showed the VDub frame counts when I looked.] I wanted to respond with a capture of my own instead of just words, but it's been a busy week.

So far we have:

1. My 9-year-old post about the older version of AmaRecTV, indicating it doesn't report accurately.
2. rgr's post in this thread, indicating that AmaRecTV doesn't report accurately.
3. Your post here that shows AmaRecTV ending 1 frame shorter than expected and reporting "(-1)".

From the log, it appears that more than 1 frame is missing though.

VT=01:06:59.479s(100478f), Cap=101290f( 0D), Enc= 2.605ms, Siz= 226KB( 28%)KEY, Drp=0, (+)0, (-)0, Buf= 1, o
IT=01:06:59.479s, HDD=5.7MB/s( 97%), fps=25.0f/s
VT=01:06:59.541s(100479f), Cap=101291f( 0D), Enc= 2.567ms, Siz= 226KB( 28%)KEY, Drp=0, (+)0, (-)0, Buf= 1, o
VT=01:06:59.573s(100480f), Cap=101292f( 0D), Enc= 2.589ms, Siz= 226KB( 28%)KEY, Drp=0, (+)0, (-)0, Buf= 1, o
VT=01:06:59.606s(100481f), Cap=101294f( 0D), Enc= 3.520ms, Siz= 225KB( 28%)KEY, Drp=0, (+)0, (-)0, Buf= 2, o
AT=01:06:59.606s(100475f), Bsy= 0ms, Dif= 5760, Smp=9600
VT=01:06:59.637s(100482f), Cap=101294f( 0D), Enc= 2.705ms, Siz= 226KB( 28%)KEY, Drp=0, (+)0, (-)0, Buf= 1, o
NT=01:06:59.637s(Drop), Total=1
VT=01:06:59.733s(100483f), Cap=101296f( 0D), Enc= 2.486ms, Siz= 225KB( 28%)KEY, Drp=0, (+)0, (-)1, Buf= 1, o
VT=01:06:59.766s(100484f), Cap=101298f( 0D), Enc= 3.355ms, Siz= 226KB( 28%)KEY, Drp=0, (+)0, (-)1, Buf= 2, o
AT=01:06:59.766s(100480f), Bsy= 0ms, Dif= 1920, Smp=9600
VT=01:06:59.797s(100485f), Cap=101298f( 0D), Enc= 2.468ms, Siz= 226KB( 28%)KEY, Drp=0, (+)0, (-)1, Buf= 1, o
VT=01:06:59.861s(100486f), Cap=101299f( 0D), Enc= 2.587ms, Siz= 226KB( 28%)KEY, Drp=0, (+)0, (-)1, Buf= 1, o
VT=01:06:59.893s(100487f), Cap=101300f( 0D), Enc= 2.677ms, Siz= 226KB( 28%)KEY, Drp=0, (+)0, (-)1, Buf= 1, o

How is this log meant to be read? There's VT and there's Cap.

It seems to me that 3 frames were skipped from the input and 2 were duplicated. If you CTRL+F, these don't exist:

Cap=101293f
Cap=101295f
Cap=101297f

Increasing "VT" frame number but duplicated "Cap" frame number. I see Buf increased to 2 and then decreased back to 1 each time.

VT=01:06:59.606s(100481f), Cap=101294f( 0D), Enc= 3.520ms, Siz= 225KB( 28%)KEY, Drp=0, (+)0, (-)0, Buf= 2, o
VT=01:06:59.637s(100482f), Cap=101294f( 0D), Enc= 2.705ms, Siz= 226KB( 28%)KEY, Drp=0, (+)0, (-)0, Buf= 1, o

VT=01:06:59.766s(100484f), Cap=101298f( 0D), Enc= 3.355ms, Siz= 226KB( 28%)KEY, Drp=0, (+)0, (-)1, Buf= 2, o
VT=01:06:59.797s(100485f), Cap=101298f( 0D), Enc= 2.468ms, Siz= 226KB( 28%)KEY, Drp=0, (+)0, (-)1, Buf= 1, o

---

There are multiple variables between the workflows that each of us used.

Not currently possible to eliminate all of them, even if you were interested in spending more effort on this. I'm only able to capture VHS in NTSC. I believe your VHS sources are limited to PAL.

[Sharc]

Just my 2 cents:
If I see such "gaps" in the amarec report I use the script below, navigate to the time code or frame/field number, and step through those "odd" frames/fields to draw conclusions on the actual capture.

AVISource("your.avi")
converttoYV16(interlaced=true)
clip=last

frame=clip.subtitle("     frame",size=24).showframenumber(scroll=true,x=55,y=100,size=24).showtime(x=100,y=128,size=18)
top = clip.AssumeTFF().separatefields().subtitle("     Assuming TFF",size=24).showframenumber(scroll=true,x=55,y=100,size=24).showtime(x=100,y=128,size=18)
bottom = clip.AssumeBFF().separatefields().subtitle("     Assuming BFF",size=24).showframenumber(scroll=true,x=55,y=100,size=24).showtime(x=100,y=128,size=18)
SBS=stackhorizontal(top,bottom)

#select the output layout:
return sbs    #frame or top or bottom or SBS

[rgr]

@rgr I don't see direct "DVD player" results listed, only VHS captures. Have you verified every one of your workflows using this "control" first? Note that according to Peter's testing, 1hr is an insufficient test length. He recommends 4hr.

Direct DVD test --> I haven't done that. I have a few perfect transfers from VHS tape, so I can assume this test would be OK too. But I'll do it at the end.
About 4h test --> I was considering a longer test and maybe I'll do it for the best devices. For now I'll skip it -- if something doesn't pass a 1h test, it certainly won't pass a 4h test.

[rgr]

@rgr (or others): Did you ever try to capture using ffmpeg directly instead of using GUIs like Vdub, AmarecTV .....? How does it compare?

No. I don't even remember how to do it

Advantage is that you can capture directly into any of ffmpeg's internal native codecs like huffyuv, ffv1, ProRes etc.

Using VirtualDub I capture to UTVideo.

[rgr]

I'd be curious if you could post your test sample for AV/Sync or describe how you made it and what the output chain looks like.

If this is for me, it is described on the previous page. And with each test additionally.
All captures are currently around 300GB.

[rgr]

System: JVC 5700, IOData GV-USB2, AmarecTV into MagicYUV, Intel i5-750, Win 10 64bit, connected to the 'net

My conclusion is that maybe IOData is just more stable than Hauppauge. Unfortunately, not available for purchase. And I would do a test for him.

[Brad]

Direct DVD test --> I haven't done that. I have a few perfect transfers from VHS tape, so I can assume this test would be OK too. But I'll do it at the end.

Sure, if any particular chain is "perfect" even with VHS, no need to waste time redoing the test for that one workflow with pure/stable DVD source.

About 4h test --> I was considering a longer test and maybe I'll do it for the best devices. For now I'll skip it -- if something doesn't pass a 1h test, it certainly won't pass a 4h test.

Yes, of course. If you do plan to start a 4hr test, please consider using the software I mentioned since it can scan the capture and point you to any error sections for human analysis.

[Brad]

I'd be curious if you could post your test sample for AV/Sync or describe how you made it and what the output chain looks like.

rgr and I don't know who this was directed toward. In case you were intrigued by my screenshot with the blonde (AVSuzie) then my point was basically that I don't have to suffer any more using my homebrewed test pattern.

I'll start using DVA-Fidelity instead, with its automagic issue-detection. Just need to sit down and set it up.

I've theorized that the way to go would be to make a davinci 480i timeline and then output via a Blackmagic 3G monitor (which is SDI and can output 480i) and this automatically bypasses any color settings within the operating system, then go to something like a brighteye SDI to analog converter which also has a proc amp for fine tuning and can produce S-Video, composite, or Component. From there, would put a waveform monitor/vectorscope in line to make sure levels coming off of that are correct.

Speaking as a perfectionist myself, this is overkill preventing you from getting started. You'll never achieve such accuracy with any consistency if you're recording to VHS. Not in the world of luma and chroma AGCs.

If just verifying the system using the pure YPbPr etc signal, sure, put the effort in to use the scopes.


I use the YC output of my Blackmagic Intensity Pro 4K. But for my VHS purposes, I've also used DV output (via Digital8 cam as I don't own miniDV) and that's totally fine.

[Alwyn]

Brad, understood, thanks for the reply.

[rgr]

Now it's time for tests with TBC enabled.

Round 2 part 2 (TBC on) -- drops/inserts and a/v sync - capturing 1h tape, Philips VR1100 (JVC HR-S7700 clone), edit/distinct mode, BEST on, S-Video out (SCART)

a) Hauppauge USB-Live2 --> AmarecTV 3.10
CLOCK OFF -- 20 dropped frames out of 180,000, a/v sync -- 1 frame at the beginning, 2 at the end of the test
CLOCK ON -- identical results, only at the end of the test the audio delay increased to 2.5 frames

Rating: 6/10
AmarecTV traditionally drops almost the same number of frames regardless of the TBC state.


b) Hauppauge USB-Live2 --> VirtualDub2
PERFECT -- 0 dropped frames!
A/V sync -- perfect synchronization at the beginning and end of the test (attachment 1).

Rating: 10/10

I searched the entire AVI file from VirtualDub2 and found a single image glitch. The VCR couldn't read two frames, and they were replaced with adjacent frames, so both video continuity and synchronization were maintained (attachment 2).


Using a VCR with TBC + Hauptpauge USB-Live2 + VirtualDub2 is the ideal combination for now, as is using a VCR without TBC and a miniDV camcorder (Sony Digital8 DCR-TRV210E) as an analog-to-digital converter and capturing via FireWire. Theoretically VCR with TBC and Hauppauge should be better due to the lossless quality, but that remains to be seen after comparing the captures.

[rgr]

Not sure how I'd put all the test features I'm seeing there in your screen capture though? Guessing it is probably a rather large file that is too big to post unless it's on repeat or something?

I combined several different clips and added this test at the beginning and end:
https://www.youtube.com/watch?v=ucZl6vQ_8Uo&list=RDucZl6vQ_8Uo

[rgr]

Summary (attachment).

[Sharc]

My experience with Amarec:
Seems that I never got in its report (log) any reported dropped frames, I only get occasional inserted frames. Checking the captured file in Vdub, the inserted frames - as reported in the Amarec log - are easily identified as duplicates. Stepping backwards and forward from there I sometimes find the associated non-reported dropped frame, sometimes not (or it is too far away), so there seem to be "orphaned" inserts for keeping A/V in sync.
@rgr: Which version of Vdub were you using? and what were its settings?

[rgr]

x64 v2.3.0.845
But I could also use a slightly earlier version.
However, the capture module seems to have remained unchanged for years.

I turned on the last option ("Ignore video timestamps") because of the UGREEN device -- with it turned off I had a lot of drops. Normally I had it turned off.

[Sharc]

ok, thanks.

[Sharc]

Good ole' VirtualVCR has always been working fine and reliably here. I still use it with W11 as a lean alternative to Amarec or Vdub. It has nice real-time luma histogram and audio oscilloscope views as well (in preview).

[rgr]

My experience with Amarec:
Seems that I never got in its report (log) any reported dropped frames, I only get occasional inserted frames

This is a problem with AmarecTV. It drops but doesn't report it.

[Alwyn]

Using a VCR with TBC + Hauptpauge USB-Live2 + VirtualDub2 is the ideal combination for now, as is using a VCR without TBC and a miniDV camcorder (Sony Digital8 DCR-TRV210E) as an analog-to-digital converter and capturing via FireWire.

The second option will be music to the ears of those befuddled by the maze and cost of analogue TBC capture, at least in the PAL world.