AmarecTV Capture Washed out compared to VirtualDub

[Sharc]

ConvertToYUV420

x264 does it by itself (default), or maybe one wants to keep it as 422

NEVER UPSCALE SD

Wrong as an absolute statement. It depends on the destination (and personal preference). YT for example.

Besides, I advise against AmarecTV - it loses frames.

The OP - like some others - already had his bad experience with Vdub ....

[rgr]

ConvertToYUV420

x264 does it by itself (default), or maybe one wants to keep it as 422

But he applies it at the beginning of the script.

NEVER UPSCALE SD

Wrong as an absolute statement. It depends on the destination (and personal preference). YT for example.

But as a general rule, it is.
"Never upscale SD unless you have some super important reason (and you consulted it on the forum)."

Besides, I advise against AmarecTV - it loses frames.

The OP - like some others - already had his bad experience with Vdub ....[/QUOTE]

Just configure it correctly.



Sometime I need to see what's worse - AmarecTV or OBS

[lollo]

To OP (@BullBuchanan): do not listen to false statements. AmarecTV is the best capture software by far, so keep using it

[rgr]

To OP (@BullBuchanan): do not listen to false statements. AmarecTV is the best capture software by far, so keep using it

Not everyone likes lost frames like you do

[lollo]

I have 0 dropped frames and 0 inserted frames in 99,9% of my captures. Verified by comparing the captured video versus same source in dvd and/or dvb-s/t. Solid result, the opposite of your (and unique) flawed test!

[rgr]

I have 0 dropped frames and 0 inserted frames in 99,9% of my captures. Verified by comparing the captured video versus same source in dvd and/or dvb-s/t. Solid result, the opposite of your (and unique) flawed test!

Oh, you're not doing well
For me, AmarecTV reported 0 dropped frames in 100% of the captures.
But I counted these frames and always, even with TBC, it usually came out about 20 lost but not reported frames.

https://forum.videohelp.com/threads/416658-Nero-Video-Grabber-vs-Hauppauge-WinTV-USBli...00#post2765023

[lollo]

I do nothing bad or good, simply because there is nothing to do.

I just compare two different videos, one is the analog capture, the other is another source of the same program. And guess what? The match frame-by-frame-by-frame-by-frame-by-frame for more than 2.5 hours!

I ignore if this can help your (crap) experiment, but AmarecTV is sometimes inserting a frame as a consequence of a previous dropped frame (that is in this case not reported as such). I have explained that many times...

[rgr]

I do nothing bad or good, simply because there is nothing to do.

I just compare two different videos, one is the analog capture, the other is another source of the same program. And guess what? The match frame-by-frame-by-frame-by-frame-by-frame for more than 2.5 hours!

Is this questionable quality test from an "unknown other" source supposed to prove anything?

I ignore if this can help your (crap) experiment, but AmarecTV is sometimes inserting a frame as a consequence of a previous dropped frame (that is in this case not reported as such). I have explained that many times...

Since, as usual, no argument was made as to why the test is "crap", thank you for agreeing with me. Come back with some arguments
https://forum.videohelp.com/threads/416658-Nero-Video-Grabber-vs-Hauppauge-WinTV-USBli...e2#post2769332

[lollo]

Is this questionable quality test from an "unknown other" source supposed to prove anything?

Of course. Did you understand the "test"? What do I have to add to the fact "comparing a capture frame-by-frame with a refercence"? Do you want me to draw a picture for you?

Since, as usual, no argument was made as to why the test is "crap", thank you for agreeing with me. Come back with some arguments

As usual, a crap test which has not confirmed by any other experiment by anybody (and there are a lot of AmarecTV user, not only myself) does not need any more evidence.

[rgr]

[quote]

Is this questionable quality test from an "unknown other" source supposed to prove anything?

Of course. Did you understand the "test"? What do I have to add to the fact "comparing a capture frame-by-frame with a refercence"? Do you want me to draw a picture for you?

Test? It wasn't even next to the test, I can't even call it a "crap test"

As usual, a crap test which has not confirmed by any other experiment by anybody

So far we have:
My 9-year-old post about the older version of AmaRecTV, indicating it doesn't report accurately.
rgr's post in this thread, indicating that AmaRecTV doesn't report accurately.
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.

Search until you find.

In summary - 100% of tests showed that AmarecTV loses frames after all. If you finally do a test, let me know

[lollo]

Test? It wasn't even next to the test, I can't even call it a "crap test"

How can yoube so idiot?

Mine is the "ultimate test", a comparison with a known and trusted reference, not your crap experiment that nobody is able to reproduce in term of results (the fundamentals of the science)!

So far we have:
My 9-year-old post about the older version of AmaRecTV, indicating it doesn't report accurately.
rgr's post in this thread, indicating that AmaRecTV doesn't report accurately.
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.

Search until you find.

In summary - 100% of tests showed that AmarecTV loses frames after all. If you finally do a test, let me know

Bullshit.

In the thread you are trying to mention as an evidence, Brad (vaporeon800) was not able to understand the log file of AmarecTV, showing that the inserted frames were in fact a consequence of dropped frames not reported as such (I explained that many times some time later).

Go back to re-read the whole discussion.

[Sharc]

@rgr: I refer to posts #13 ...#18 in your thread. Your testsource is still a secret ....
https://forum.videohelp.com/threads/416658-Nero-Video-Grabber-vs-Hauppauge-WinTV-USBli...00#post2765683
https://forum.videohelp.com/threads/416658-Nero-Video-Grabber-vs-Hauppauge-WinTV-USBli...00#post2765753
Perhaps you can shed some light on it.

On a sidenote: Apart from what is right or wrong, your test is statistically irrelevant (sample size is to low) to draw general conclusions: 1 source, 1 tape, 1 (maybe 2) VCRs, 1 PC/HW configuration, few capture cards and drivers as opposed to the many users posting their experience for many different cases (=constituting a large sample size alltogether). For many desperate users AmarecTV came as a godsend after having pulled their hair (frame drops and AV sync issues) trying all Vdub settings variants .....

[rgr]

@rgr: I refer to posts #13 ...#18 in your thread. Your testsource is still a secret ....
https://forum.videohelp.com/threads/416658-Nero-Video-Grabber-vs-Hauppauge-WinTV-USBli...00#post2765683
https://forum.videohelp.com/threads/416658-Nero-Video-Grabber-vs-Hauppauge-WinTV-USBli...00#post2765753
Perhaps you can shed some light on it.

It's no secret to anyone who read that thread.

On a sidenote: Apart from what is right or wrong, your test is statistically irrelevant (sample size is to low) to draw general conclusions: 1 source, 1 tape, 1 (maybe 2) VCRs, 1 PC/HW configuration, few capture cards and drivers as opposed to the many users posting their experience for many different cases (=constituting a large sample size alltogether). For many desperate users AmarecTV came as a godsend after having pulled their hair (frame drops and AV sync issues) trying all Vdub settings variants .....

1. source - same for VDub and AmarecTV
2. tape - same for VDub and AmarecTV
3. VCR - same for VDub and AmarecTV
4. PC/HW configuration - same for VDub and AmarecTV
5. capture cards and drivers - same for VDub and AmarecTV
+ several attempts

What one variable distinguished them?

lollo's pseudo-test:
1. different source
2. different "tape"
3. different "VCRs"
4. different hardware (?)
5. different capture cards

[lollo]

What one variable distinguished them?

A real distinguishing is missing the understanding of what happens by a deep analysis of log files (in your one-of-a-kind experiment)!

lollo's pseudo-test:
1. different source
2. different "tape"
3. different "VCRs"
4. different hardware (?)
5. different capture cards

lollo's test: hundreds and hundred of captures of who knows how many tapes, on many JVC and Panasonic VCRs (with and without internal TBC), with and without Panasonic ES-10/ES15, with and without external TBC, with cards like Canopus-NX, Hauppauge USB-Live 2, IOData GV-USB2, ATI USB-600, Diamond VC-500, Terratec Cynergy 400 PCI, a couple of Blackmagic cards, 2 Windows 7 laptop, 2 Windows 10 laptop, 1 Windows 11 laptop, DELL Desktops, etc

In addition, access to who knows how many captures performed by member of my fan organization, dedicated to old sci-fi TV shows, with different workflows.

And comparison with a trusted sorce, i.e. a master provided to us by the TV channels, or a DVD release, or a DVB-S/DVB-T dump of the same program being captured from the analog tapes.

What is really "pseudo" here, is your brain!

[Sharc]

1. source - same for VDub and AmarecTV
2. tape - same for VDub and AmarecTV
3. VCR - same for VDub and AmarecTV
4. PC/HW configuration - same for VDub and AmarecTV
5. capture cards and drivers - same for VDub and AmarecTV
+ several attempts

Well, that's what I meant by statistical irrelevance: You are comparing 2 sets of tires (brand A and brand B) by putting them on a single (same) car, driving them on a single specific road in a specific environment (setup), the car driven by a single and same driver etc., and then establish a general conclusion that tire A is better than tire B and discourage others from using B.
Even when you are convinced from your test result you cannot generalize it, as by changing the test environment (different car model/road/driver) other testers may come to a different result. To validate (or invalidate) your statements the sample size should be much broader. In fact the sample size and test condition variety is pretty huge considering all the many users who have tried both and made their personal choice.

[rgr]

It's like testing tires designed for a given car. One breaks with each test, the other performs OK.
Your conclusions: you may need to change driver/car/whatever.

[andratek]

Hi,

This is my first time trying to do VHS capture, so please bear with me if I've overlooked something. I'm trying to digitize some rare and out of print folk music recordings for personal use, for some friends and others of interest. I have some modern video editing experience (DaVinci Resolve), but this type of work is all new.

I initially did a capture with VirtualDub2, but ran into audio issues, so I tried VirtualDub 1.9 where I was able to capture, but was still experience audio sync drift that was not consistent throughout the video. I then tried AmaRec which captured with no sync issues. I've been running all captures through StaxRip for QTGMC deinterlacing, scaling etc, but I verified that the saturation/contrast difference is present in the raw captures as shown in the pic.

Both sets of software had contrast and saturation at 128 with all other settings at 0.

Any ideas?


[Attachment 93152 - Click to enlarge]

[Attachment 93153 - Click to enlarge]

Equipment:
VCR: Toshiba D-KVR20
Capture card: Oassuose VHS to Digital Converter
PC: AMD 7700x, 7900XTX, 32GB DDR5 RAM
Staxrip2.52.4
AmaRecTV 3.10
VirtualDub 1.9
VirtualDub2 Build 44282



AmaRec File

Format : AVI
Format/Info : Audio Video Interleave
Format settings : WaveFormatEx
File size : 22.0 GiB
Duration : 56 min 48 s
Overall bit rate : 55.5 Mb/s
Frame rate : 25.000 FPS

Video
ID : 0
Format : YUV
Codec ID : ULY2
Codec ID/Info : Ut Video Lossless Codec
Codec ID/Hint : Ut Video
Duration : 56 min 48 s
Bit rate : 51.7 Mb/s
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 5:4
Frame rate : 25.000 FPS
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:2
Compression mode : Lossless
Bits/(Pixel*Frame) : 4.991
Stream size : 20.5 GiB (93%)

Audio
ID : 1
Format : PCM
Format settings : Little / Signed
Codec ID : 1
Duration : 56 min 48 s
Bit rate mode : Constant
Bit rate : 1 536 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Bit depth : 16 bits
Stream size : 624 MiB (3%)
Alignment : Aligned on interleaves

VirtualDub File
Format : AVI
Format/Info : Audio Video Interleave
Format profile : OpenDML
Format settings : WaveFormatEx
File size : 21.8 GiB
Duration : 56 min 46 s
Overall bit rate : 54.9 Mb/s
Frame rate : 25.000 FPS

Video
ID : 0
Format : YUV
Codec ID : ULY2
Codec ID/Info : Ut Video Lossless Codec
Codec ID/Hint : Ut Video
Duration : 56 min 46 s
Bit rate : 51.8 Mb/s
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 5:4
Frame rate : 25.000 FPS
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:2
Compression mode : Lossless
Bits/(Pixel*Frame) : 5.001
Stream size : 20.6 GiB (94%)

Audio
ID : 1
Format : PCM
Format settings : Little / Signed
Codec ID : 1
Duration : 56 min 46 s
Bit rate mode : Constant
Bit rate : 3 072 kb/s
Channel(s) : 2 channels
Sampling rate : 96.0 kHz
Bit depth : 16 bits
Stream size : 1.22 GiB (6%)
Alignment : Aligned on interleaves
Interleave, duration : 42 ms (1.04 video frame)

Hi,

The "washed out" look with HDMI capture devices is usually a YUV range mismatch — the capture card outputs full range (0-255) but the player/editor assumes limited/TV range (16-235), or vice-versa. That crushes the blacks/whites and makes everything look flat and pale compared to a source read directly like VirtualDub does.

Worth checking: does your capture app have a "full range" / "limited range" or "PC level / TV level" toggle? If not, try forcing the color range interpretation on the playback side.

FWIW, I develop Andratek AthenaRecorder, which handles VHS-via-HDMI capture with correct range handling and has a 40-day free trial if you want to compare results — happy to share more details if useful.