Lines in capture in VirtualDub?

[AriZoNaiCe]

Hey all,

I recently started my VHS capture journey, and I've got things going with my workflow pretty well (thanks, LS). When capturing in VirtualDub (I followed settings in here, nearly verbatim: https://www.digitalfaq.com/forum/vid...-settings.html), I do see some lines. The attached image shows them pretty clearly in a still, but they are very noticeable during motion, especially in brighter parts of the frame.

Does anyone know off hand what might be causing this? I can upload a short capture video as well, if it helps, but I felt it was pretty clear in the still. The lines are ultra consistent, and they are visible in all tapes I've tested. It almost looks like anti-aliasing or something weird like that, but I'm just not sure where to look.

Workflow:
- JVC SVHS (SR-MV50)
- CDM-831TR 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 try to help!

-- Brian

[lordsmurf]

I've seen this. In each cases, it's been the cables. Those "fancy" (gold, whatever) fat-header s-video cables are expensive junk. I would never use Belkin cables.

FYI, that's not a 831TR, but similar, not important.

[AriZoNaiCe]

Quote:

Originally Posted by lordsmurf

I've seen this. In each cases, it's been the cables. Those "fancy" (gold, whatever) fat-header s-video cables are expensive junk. I would never use Belkin cables.

FYI, that's not a 831TR, but similar, not important.

Thanks, LS. I can certainly try some other cables. I have been using Belkin Synapse for many years. They are actually quite high quality. Standard Belkin = absolute junk. Belkin Synapse, a different beast entirely. They are double-shielded, 75-ohm coax. These aren't the regular Belkin stuff you see on the shelves. You'll find these in recording studios.

As a point of reference, there were a lot of tests run against their RCAs over the years, and all came back positive - this was the first two I found, but there are many others:
http://www.soundbsessive.com/belkin-...tinum-digital/
https://www.hifivision.com/threads/a...s.10233/page-2

These lines, to me, look more digital than analog in nature, which is why I didn't immediately think it was a cable issue.

I also agree with your statements linked below, in that s-video really doesn't have a ton of difference between good/bad cables. It's absolutely more noticeable in digital cables -- just ask everyone who complains about their Apple Lightning cables all the time. :-)
https://www.digitalfaq.com/forum/vid...html#post46960

I'll see if I can find any cheap s-video cables hanging around or pick some up -- but I really think that's a fool's errand and cables are a red herring here. Ideally, I'd be able to test with some composite, just to be absolutely sure, but both the JVC and the TBC only output over s-video for the VCR (the DVD portion outputs on both, strangely).

Any other thoughts out there?

[lordsmurf]

The TBC composite output is via BNC, so you just need adapters. If you can't find any, let me know, I can give you a pair, just pay the shipping.

Look at the deck from the front, use the far left outputs. Ignore the DVD recorder, focus just on the VCR.

Those "good" cables can be a real PITA. Image noise is common with those, which seems silly since those supposedly have "good shielding".

[themaster1]

Call me crazy but i don't see your offending "lines" except interlacing fields indeed

[lordsmurf]

Perhaps. I didn't think he was referring to interlace. We need some more samples.

[AriZoNaiCe]

Thanks for the engagement, all. It could definitely be interlacing I'm seeing (in fact, it almost certainly is), especially given how uniform the pattern is across the frame. I've attached a short clip. I find I see it ultra clearly when the sky becomes visible during the dialog. The still I included also shows the uniformity pretty clearly.

If it is, indeed, due to the interlaced nature of the analog NTSC signal, what's the recommended approach to de-interlacing the captures?

[traal]

It reminds me of the lines in this post.

[AriZoNaiCe]

Quote:

Originally Posted by themaster1

Call me crazy but i don't see your offending "lines" except interlacing fields indeed

Well -- nobody needs to call you crazy. It was, in fact, interlacing fields I was seeing.

Used QTGMC with AviSynth and was able to deinterlace the video. What a difference! Any recommendations on resolution? I used Spline64Resize at 720x540. Also, using HuffYUV, that resulted in a 3x jump in file size. The video is 2 minutes and 41 seconds. Original AVI capture is 1.3GB and the deinterlaced is 3.5GB. Is that expected? I suppose it's double the frames and slightly higher resolution, so maybe that makes sense? Below is my AviSynth script, in case it helps:

AssumeTFF()
QTGMC(preset="Slower", EdiThreads=6)
Spline64Resize(720,540)
Prefetch(18)

@themaster1 - can't thank you enough -- huge help! @LS - as always, your willingness to contribute and engage is appreciated!

[lordsmurf]

Quote:

Originally Posted by AriZoNaiCe

what's the recommended approach to de-interlacing the captures?

Why?

It's like saying "OMG, I have this thing with fingers on my body! How do I remove my hand?"

VHS video exists as interlaced. It should be captured and archived as interlaced.

Now then, you can create a deinterlaced copy, if needed. But that begs the question: Why is it needed here?
- If the answer is "because", then never do it.
- If, for example, the answer is "because I'm making a Youtube video", then it's (obviously) required.

Interlaced video only has "lines" on a progressive/deinterlaced display. Not interlaced displays, ie TVs (including HDTVs).

So again ... why?

Quote:

Originally Posted by AriZoNaiCe

Used QTGMC with AviSynth and was able to deinterlace the video.
Below is my AviSynth script, in case it helps:

AssumeTFF()
QTGMC(preset="Slower", EdiThreads=6)
Spline64Resize(720,540)
Prefetch(18)

Why that script?

preset=Slower may as well as preset=Softer, as it always softens the video some. This is because QTGMC is not merely "a deinterlacer", but rather a script that deinterlaces. The Slower preset adds some aggressive NR, and should only be used when needed. In general, Faster is much better, most of the time.

EdiThreads is very system based, something that must be tested, not random in use. Basically just memory/CPU management for the scripts, no real affect on the quality. Same for Prefetch, which is actually only part of that scripted pairing -- and again, must be chosen per system, not random, not copy/pasted (monkey see, monkey do) from other scripts online.

Spline resizing has issues with adding artifacts, so it must be carefully chosen for sources. Bicubic and bilinear are vastly safer, and should be used by novice users (without guidance).

Quote:

Also, using HuffYUV, that resulted in a 3x jump in file size.

Which specific Huffyuv version, and in what software?

[AriZoNaiCe]

Quote:

Originally Posted by lordsmurf

VHS video exists as interlaced. It should be captured and archived as interlaced.

Agreed, and is the case here. I have the interlaced capture separately and will not be replacing it. The deinterlaced is for viewing on PCs and is kept separately.

Quote:

Originally Posted by lordsmurf

preset=Slower may as well as preset=Softer, as it always softens the video some. This is because QTGMC is not merely "a deinterlaced", but rather a script that deinterlaced. The Slower preset adds some aggressive NR, and should only be used when needed. In general, Faster is much better, most of the time.

Thanks! Will run this again with the faster and compare.

Quote:

Originally Posted by lordsmurf

EdiThreads is very system based, something that must be tested, not random in use. Basically just memory/CPU management for the scripts, no real affect on the quality. Same for Prefetch, which is actually only part of that scripted pairing -- and again, must be chosen per system, not random, not copy/pasted (monkey see, monkey do) from other scripts online.

This was not, in fact monkey see, monkey do. I have 12 physical cores on the machine doing the rendering. Those numbers were chosen intentionally.

Quote:

Originally Posted by lordsmurf

Spline resizing has issues with adding artifacts, so it must be carefully chosen for sources. Bicubic and bilinear are vastly safer, and should be usede by novice users (without guidance).

Same as above. I tested Bilinear, Bicubic, and Spline -- for the specific video I was capturing, the result looked best with Spline.

Quote:

Originally Posted by lordsmurf

Which specific Huffyuv version, and in what software?

HuffYUV 2.1.1 in VirtualDub2 (not being used for capture -- only for deinterlacing/rendering using AviSynth). AvsPmod for previewing AviSynth results before rendering.

Your responses above are valuable for the community, in covering why not to just direct-copy my script. But, aside from the choice to use preset=slower (which I presumed would give sharper results due to the extra time to process frames), nothing was copied/pasted. I have some unrelated questions cropping up, so I'll start a new thread for those in the coming days.

Thank you to all for resolving this one. I tried to edit the title to reflect that, but it doesn't seem like I can. Maybe it's been too long.

[lordsmurf]

Excellent, then you're on top of it.