VHS capturing device in 2022?

[lansing]

My TBC mixer finally arrived after 9 days of shipping, lol, finally I can do some test.

I ended up getting a Panasonic WJ-AVE5 mixer because the Videonics MX-1 I first brought was broken, with the outputting video shifting about 10 pixel to the left and all control buttons malfunctioning.

Testing on my Japanese VHS anime, the tbc mixer seems pretty good, all small jittering gone as well as those horizontal color streak..

non-tbc
https://i.imgur.com/OhgB5zW.png

tbc
https://i.imgur.com/VrtquAK.png

I feel like the mixer also did some auto white balancing internally?

One thing I don't understand though is the quality difference between composite and s-video output on the default blue screen. With s-video out, for some reason there is a frequency of square pattern casted on top of the frame, however there is none on the composite out.

composite
https://i.imgur.com/CBhiIkw.png

s-video
https://i.imgur.com/IRt3UKc.png

mixer
https://i.imgur.com/jdPANJg.png

[Sharc]

I feel like the mixer also did some auto white balancing internally?

This is possible, yes. Auto white, level shifts, AGC .....

One thing I don't understand though is the quality difference between composite and s-video output on the default blue screen. With s-video out, for some reason there is a frequency of square pattern casted on top of the frame, however there is none on the composite out.

I am not sure if I understand your current system configuration correctly, but the dots (dotcrawl or hanging dots) are probably remnants from imperfect luma/chroma separation depending on the comb filter which is ON or OFF somewhere along your signal path. There is probably a setting for switching it ON or OFF. Laserdisc is natively composite and needs to have an Y/C filter in order to provide an S-video signal. These filters are however never perfect.

[lansing]

My VCR is a JVC HR-S4800U, with "picture mode" set to "EDIT" when capturing.

I don't really see any dot crawl on my VHS playback, so I guess that's just an issue with the blue screen. Switching from composite to s-video did fix the issue of artifact popping up on overexposed color, so that means the s-video is doing its work.

The TBC doesn't seems to do much though on my 4th generation VHS copy.

[lansing]

Test capture for 8 minutes with AmaRecTV in Lagarith lossless, 0 drop frames, no chroma ghosting, the mixer seems pretty good.

Now questions about the video and audio driver settings, I'm trying to capture Japanese vhs, do I choose NTSC_M or NTSC_M_J? For the audio setting, how do I determine the optimal volume to record the audio?

[Sharc]

My VCR is a JVC HR-S4800U, with "picture mode" set to "EDIT" when capturing.....

Sorry about my confusion regarding your setup and mentioning laserdisc. I had another discussion (https://forum.videohelp.com/threads/404835-Looking-for-3D-comb-filter-capture-card-for-Laserdisc) in mind.

[Sharc]

Now questions about the video and audio driver settings, I'm trying to capture Japanese vhs, do I choose NTSC_M or NTSC_M_J?

https://forum.doom9.org/showpost.php?p=511686&postcount=2

For the audio setting, how do I determine the optimal volume to record the audio?
In VirtualDub2 you can display the audio signal and check if it clips, for example:
View->Audio display
The level can be adjusted in Windows' sound settings (details depending on Windows version)

[lansing]

https://forum.doom9.org/showpost.php?p=511686&postcount=2



Does that mean capturing in NTSC_M_J will be darker?

[Sharc]

Does that mean capturing in NTSC_M_J will be darker?
Not necessarily. I would do some test captures of dark and bright scenes including pictures with high brightness changes within the picture. Then inspect the capture with avisynth's 'histogram("classic")' or 'VideoScope' and apply corrections as appropriate (eg. using Levels() and/or tweak() in avisynth). Or upload a captured sample and collect comments from forum members.

About the NTSC pedestal you may want to read here:
http://www.glennchan.info/articles/technical/setup/75IREsetup.html

[lansing]

Not necessarily. I would do some test captures of dark and bright scenes including pictures with high brightness changes within the picture. Then inspect the capture with avisynth's 'histogram("classic")' or 'VideoScope' and apply corrections as appropriate (eg. using Levels() and/or tweak() in avisynth). Or upload a captured sample and collect comments from forum members.

About the NTSC pedestal you may want to read here:
http://www.glennchan.info/articles/technical/setup/75IREsetup.html

The article is a little bit confusing, what I got is basically for VHS capture we'll need the black level to be at 16 on the waveform and white level at 235.

I tested with both options and they do have differences. For my Japanese tape, using NTSC_M gets a darker video. Waveform showing NTSC_M dark level at 0 while NTSC_M_J at 16 and highlight being the same. So NTSC_M_J is the correct option.

[lansing]

Regarding the recording volume, I have checked several old anime dvd I have, all their volume sit at -12 db on the waveform. Don't know why they go this low but I'll just follows.

As for the video proc-amp in Hauppauge's device setting, is it the same thing as to running color correction filters in the post? My anime has blowout red that needs fixing, so I want to know the position of the device's proc-amp in the processing chain.

[Sharc]

The article is a little bit confusing, what I got is basically for VHS capture we'll need the black level to be at 16 on the waveform and white level at 235.

Exactly. That's the main point for the luma (Y). Once we are in the digital domain the IRE has no relevance any more.
Next step could be check the chroma (U,V). This is normally no problem as the chroma (U,V) is usually well within the legal 16 .... 240 range. However it is possible that some YUV triplets - although all valid within the range - lead to out-of-gamut RGB (usually clipped, rarely folded-over R,G,B) when converted to RGB for viewing on a monitor. It materializes as loss of details for example, and (slight) color distortions which can however be corrected in post processing if need be - unless the capture is totally off the kilter.
Last but not least color tweaks are also a matter of personal preference which is not always in line with 'technical correctness'.

[Sharc]

As for the video proc-amp in Hauppauge's device setting, is it the same thing as to running color correction filters in the post?

As long as Y and U,V are within their legal ranges ie. Y(16....235) and U,V (16 ....240) or even 0....255 for 8 bit, it should be possible to do all corrections in post, I think.
I don't believe that the device "proc-amp" does anything with the USB-live2 on its analog side of the video (the original meaning of proc-amp). It's all done after A/D conversion in the digital domain as I understand it. So I don't see a real difference between the "proc-amp" settings and post correction tweaks as long as the Hauppauge's A/D converter does not clip due to an excessive input signal level. If so (unlikely), one would probably have to use an external attenuator before the signal is fed into the Hauppauge USB-live2.
Maybe there are different opinions on that ....


My anime has blowout red that needs fixing, so I want to know the position of the device's proc-amp in the processing chain.
It has to be done experimentally with the help of the levels and/or RGB inspection and tweaks. Can you upload a sample, or at least post a .png snapshot of a critical frame?

[lansing]

As long as Y and U,V are within their legal ranges ie. Y(16....235) and U,V (16 ....240) or even 0....255 for 8 bit, it should be possible to do all corrections in post, I think.
I don't believe that the device "proc-amp" does anything with the USB-live2 on its analog side of the video (the original meaning of proc-amp). It's all done after A/D conversion in the digital domain as I understand it. So I don't see a real difference between the "proc-amp" settings and post correction tweaks as long as the Hauppauge's A/D converter does not clip due to an excessive input signal level. If so (unlikely), one would probably have to use an external attenuator before the signal is fed into the Hauppauge USB-live2.
Maybe there are different opinions on that ....


It has to be done experimentally with the help of the levels and/or RGB inspection and tweaks. Can you upload a sample, or at least post a .png snapshot of a critical frame?

sample here (https://www.mediafire.com/file/lh3ju1gw2spimey/ntsc_m_j.mp4/file).

The image looks so saturated, but vectorscope was showing all color within legal range. The red channel was blowing up in the RGB parade in Davinci Resolve, but surprisingly it didn't clip and was recoverable with decreasing "color boost" or "saturation" parameter.

[Sharc]

sample here (https://www.mediafire.com/file/lh3ju1gw2spimey/ntsc_m_j.mp4/file).

The image looks so saturated, but vectorscope was showing all color within legal range. The red channel was blowing up in the RGB parade in Davinci Resolve, but surprisingly it didn't clip and was recoverable with decreasing "color boost" or "saturation" parameter.
Yes, legal YUV triplets translate into illegal RGB. For example many of the pinks are around YUV(190,126,167). With the 601 matrix these get converted to RGB(265,172,199) which is eventually clipped to RGB(255,172,199).
I don't know how DaVinci Resolve deals with it, but I would suggest to legalize the colors in Avisynth before taking the clip to an NLE, and only then do the fine color tweaks in the NLE in RGB color space. My point is as soon as the capture gets converted to RGB (e.g. by the NLE) the damage is already done, hence the first correction should be done in the YUV color space. But as I said, I don't know how DaVinci Resolve handles this, and the Gamut legalization step in Avisynth may not be required.

Also, I think the black level is high, e.g. the black background of the intro.

Here a proposal which 'legalizes' the colors and shifts the black level down:
SmoothTweak(contrast=0.95,saturation=0.7,HQ=true,TVrange=True, Limiter=False)
mergechroma(SmoothLevels(input_low=16,gamma=1.0,input_high=235,output_low=8,output_high=235,HQ=true,TVrange=True,Limiter=0),last) #black level adjusted with chroma copyback

Edit:
And b.t.w. the chroma really deserves some sharpening (not included in the script above).

[lansing]

The black level looks fine on the rgb parade

https://i.imgur.com/UDX1scN.jpg

I compared the RGB Parade on both the NTSC_M and NTSC_M_J captures. The blown up red in NTSC_M_J was recoverable while the other one was permanently clipped.

NTSC_M_J before and after decreasing "color boost"
https://i.imgur.com/jILdylX.jpg

NTSC_M
https://i.imgur.com/ZW76hdb.jpg

Why?

[Sharc]

Did you capture lossless in YUV or RGB? The sample you posted was AVC reencoded, so that was YUV (YV12) but this doesn't tell how it was captured. If your capture (the .avi) got converted from YUV (S-Video) to RGB it is possible that you got out-of-gamut values which are irrecoverably lost.

The NTSC_M_J after decreasing "color boost" looks fine to me. No clipping, that's essential.
I don't use DaVinci but it looks like "color boost" tweaks the contrast and saturation (in avisynth terminology), very similar to what I suggested with my script.
You can judge yourself whether the black background of the intro is "black enough" or still a bit grayish.

Can you sharpen the chroma in DaVinci? The edges would look sharper with less color smear.

[lansing]

Color boost in Davinci Resolve is a saturation/saturation curve that affects more on higher saturation while not really touching the lower one.

My original capture is in Lagarith lossless. I converted to x264 because Resolve couldn't open it.
https://i.imgur.com/5BSOWNM.jpg

The thing I don't understand is why was the red in the NTSC_M_J version not clipped like the NTSC_M.

How do I sharpen the chroma?

[Sharc]

You could also capture in YUV (YUY2) 4:2:2 rather than RGB and significantly reduce the file size (but keep an eye on potential Gamut violations).

No idea why the NTSC_M messes with the red channel. (Is it really the same frames which you compare? or did you capture to a different color space?)

Chroma sharpening in Avisynth for example:
MergeChroma(last,Spline36Resize(last,width(last)/8*4, height(last)).aWarpSharp2(depth=20).Sharpen(0.4,0.4).nnedi3_rpow2(2, cshift="Spline36Resize", fwidth=width(last), fheight=height(last)))
ChromaShiftSP(x=0.0,Y=1.0) #adjust for best luma/chroma fit

[lansing]

Oddly I couldn't reproduce the clipping anymore on my new test captures. The blown up red on both NTSC_M and NTSC_M_J versions are recoverable now. So it seems like color adjustment can be done after the conversion without problem.

Switching RGB mode in Lagarith setting to YUY2 mode makes no difference in file size.

Another thing I found is that if I load in my original capture Lagarith file and run ConvertToYV12(), the default "interlaced=false" parameter will cause chroma ghosting.


AVISource("source.avi")
ConvertToYV12(interlaced=false)
tfm()
tdecimate()

[Sharc]

Switching RGB mode in Lagarith setting to YUY2 mode makes no difference in file size.

I would have expected a smaller .avi file size in YUY2 due to the color subsampling. I made a few tests: the pixel format of the captured stream seems always to be YUV (e.g. yuv422p), even for RGB mode in Lagarith. This would explain why the filesize is the same for RGB and YUY2 mode selection; it's always YUV for S-video or composite signals, which is fine - unless you want to capture Component.

Another thing I found is that if I load in my original capture Lagarith file and run ConvertToYV12(), the default "interlaced=false" parameter will cause chroma ghosting.
One should capture VHS (VCR output signals) as interlaced and specify 'interlaced=true' when converting, because VHS is natively interlaced, even if the source is telecined or PsF. The header of the standard .avi container has however no flag to indicate "interlaced", therefore one has to state it explicitely. One may also want to specify the conversion matrix, although the default "Rec601" (for SD, based on vertical resolution) is fine.

(P.S. I just noticed that your uploaded telecined sample (x264 encoded YV12) has been encoded as progressive. It should have been encoded as interlaced, I think.)

[Sharc]

Oddly I couldn't reproduce the clipping anymore on my new test captures. The blown up red on both NTSC_M and NTSC_M_J versions are recoverable now. So it seems like color adjustment can be done after the conversion without problem.

Maybe the red clipping oddity happens for the first frame after the intro only? There seems to be some transition effect (fade-in, telecined).

[lansing]

One should capture VHS (VCR output signals) as interlaced and specify 'interlaced=true' when converting, because VHS is natively interlaced, even if the source is telecined or PsF. The header of the standard .avi container has however no flag to indicate "interlaced", therefore one has to state it explicitely. One may also want to specify the conversion matrix, although the default "Rec601" (for SD, based on vertical resolution) is fine.

(P.S. I just noticed that your uploaded telecined sample (x264 encoded YV12) has been encoded as progressive. It should have been encoded as interlaced, I think.)
Yes, the x264 sample was inherently converted to yv12 by the encoder. Though the "interlaced" parameter seems to only affect the output of yv12. There is no chroma ghosting when I convert to YUV422 or YUV444

ConvertToYUV422(interlaced=false)
tfm()
TDecimate()

[Sharc]

Yes, the x264 sample was inherently converted to yv12 by the encoder. Though the "interlaced" parameter seems to only affect the output of yv12. There is no chroma ghosting when I convert to YUV422 or YUV444

ConvertToYUV422(interlaced=false)
tfm()
TDecimate()

I assume your captured .avi is already YUV 4:2:2, interlaced. So converttoYUV422(interlaced=true) has no effect. ConverttoYUV422(interlaced=false) mixes the croma between fields when you put it before the IVTC I am afraid. I don't see that it eliminates the residual ghosting, but as I have only your YV12 progressively re-encoded AVC version I can't tell for sure.
Add santiag() or vinverse() after TDecimate if you see residual combing.

[lansing]

I assume your captured .avi is already YUV 4:2:2, interlaced. So converttoYUV422(interlaced=true) has no effect. ConverttoYUV422(interlaced=false) mixes the croma between fields when you put it before the IVTC I am afraid. I don't see that it eliminates the residual ghosting, but as I have only your YV12 progressively re-encoded AVC version I can't tell for sure.
Add santiag() or vinverse() after TDecimate if you see residual combing.

Here's a sample (https://www.mediafire.com/file/cbgy0n0zxhtzkw6/chroma+ghosting+test.avi/file) of the original capture to play around

[Sharc]

Here's a sample (https://www.mediafire.com/file/cbgy0n0zxhtzkw6/chroma+ghosting+test.avi/file) of the original capture to play around
Do you still see the same ghosting with this?
https://www.mediafire.com/file/xd12x1bczo54c0a/lansing3.mp4/file

P.S.
For capturing one should normally switch NR (noise reduction filters) off (VCR, DVD-recorder passthrough device), as these filters may cause ghosting. It is usually better to make the noise reduction in post processing.

[lansing]

Do you still see the same ghosting with this?

What I'm saying is ConvertTOYV12(interlaced=false) behaves differently from ConvertTOYUV422(interlaced=false) or ConvertTOYUV444(interlaced=false), where the latter two don't produce chroma ghosting.

[Sharc]

What I'm saying is ConvertTOYV12(interlaced=false) behaves differently from ConvertTOYUV422(interlaced=false) or ConvertTOYUV444(interlaced=false), where the latter two don't produce chroma ghosting.
The pixel format of your uploaded .avi is yuv422p means 4:2:2 subsampled. ConverttoYV12 halves the vertical chroma resolution (4:2:0). Interlace=false may however apply because the underlying video is telecined rather than true interlaced, i.e. there is no motion between fields.

[jefix]

I'm sorry if I'm asking in the wrong place. I would like to know at what point should I use NeatVideo noise reduction? Do I need to de-interlace first?
I think I need to do noise reduction before de-interlacing. Is this true?

[Sharc]

I don't know NeatVideo filters, but usually one would deinterlace before noise filtering. Few noise filters do have an "interlace-aware" setting though which typically means that they filter even and odd fields separately and then reinterlace.
Spatial and temporal filters also behave differently. When in doubt I would just deinterlace first.

[jefix]

Sharc, I think I can open the file in Adobe as interlaced.

[ReinerSchweinlin]

Maybe this archived version of the old webpage helps ?

https://web.archive.org/web/20060110050644/http://www.pinnaclesys.com/PublicSite/us/Products/Consumer+Products/Home+Video/Expression/DV500+PLUS+Support/Ask+a+Questions_+Find+an+Answer_/Click+here+to+find+your+answers_++Ask+a+question_/Ask+your+questions+here_

[Gomes202]

Just guessing.

[PatchWorKs]

I've just buyed a CX card from aliexpress (~18€ shipped) to test the VHS-decode (https://github.com/oyvindln/vhs-decode#readme) approach...