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.