Current status of ld-decode / vhs-decode (true "backup" of RF signals)

[Brad]

Trying out a CCTV amplifier. It actually included a "DC barrel to bare wire" adapter cable even though that wasn't mentioned in the listing. But I'm currently powering it using 8x AA batteries in the hope that it's a less noisy power source, as suggested by Tony on Discord.

Here is another attempt at getting 8mm samples from the TEAC. Even with the amp cranked all the way, the card's level can be set to 31 without clipping. This weak, double-amplified signal may be too noisy to do anything with. But I figured it was worth posting so you guys can take a look.

I didn't touch the amp's HFGAIN adjustment, so I'm sure it's not set optimally.

VHS samples using the amp will be posted tomorrow or the following days.

[Titan_91]

I adjusted the filtering quite a bit, bringing the bandpass filter further above the chroma signal, increasing bandwidth, reducing it, etc. Everything I did still shows the checkerboard pattern. Does this mean the issue is likely chroma oscillations present in the luma signal during recording of some of these tapes? My spectrum appears to be fine.

Also, while I was messing around with the filtering I sort of got Brad's Hi8 sample to decode. Luma is mostly correct, chroma is broken. I'm surprised this worked at all. There's definitely more post-demoulation bandwidth than VHS as I'm seeing sharper borders and a sharper image overall. And that's with the post-demodulation band limiting in place in the current code. I could not get Video8 to decode, however.

[Titan_91]

So, hopefully I can put this checkerboarding thing to rest as I may have isolated it. I have another tape I captured earlier on my Philips machine that did not show checkerboarding. So I tried that tape in the Sony and viola, no checkerboarding. I don't want to say the tapes themselves are the definitive cause, but they may be. It would certainly explain why I couldn't get rid of the effect on the Stuart Little tape if chroma noise is baked in to the luma signal at the time of duplication. There also seems to be less overall noise on the Arthur video. And while I was at it, I used this opportunity to compare sharpness between the 5MHz filter and 13MHz filter now that the checkerboarding wasn't getting in the way. Unsurprisingly, the 13MHz filter gives the best results.

5MHz:




13MHz:

[oln]

Yeah the crosshatching does seem to be inherent or baked in (from insufficient separation) to some degree, just don't know how much exactly. At least for PAL on normal playback it seems to be a bit more visible with decks with EDIT mode on, so I assume the noise reduction or other post-filtering in VCRs do reduce it to a degree.

Hi8 is higher bandwidt than even SVHS so it ought to be a fair bit more detailed than a standard VHS capture. Additionally the format (and SVHS) has an extra (non-linear) emphasis/deemphasis step to further increase detail reproduction. Video8 and Hi8 has a slightly higher color carrier frequency on tape and did the phase rotation stuff a bit differently to VHS so will have to add that to make chroma work. (I think it just inverts rather than doeing 90 degree rotation but not sure.)

9954tony discord did a frequency sweep test on a cx card (one of the chinese modern ones with pcie connector and pci bridge chip and bnc connectors.) if anyone is curious about that:

[Titan_91]

The Arthur video has more bandwidth than some of my other tapes. Check out how low the luma sideband goes:



So I lowered the band pass filter cutoff from 2.6MHz to 2MHz to capture more of the lower sideband. This improved sharpness even further just a bit. Does using the -sl flag also do the same thing?

[oln]

Yeah the current lower cutoff is a bit higher than ideal. Afaik in a VCR it's more like 1.5 mhz (not sure what order and type, and in B/W mode it will be lower) I think, so need to tinker with the filter makeup and demodulation to push lower without introducing white streaks on some samples. On most samples it's fine to lower it a bit though, as long as you don't get streaks or start picking up the chroma.

The -sl flag is a simple post-demodulation filter boosting some frequency bands so it's not the same.

[Titan_91]

Results with the 1.5MHz lower cutoff are pretty awesome! Attached is the 8-bit 40MSPS sample and two lossless MKV files, one interlaced and another deinterlaced with Yadif. Deinterlacing is the only thing I did. The result is so good using chroma gain of 1.7 and no sharpness level adjustment. Great color, contrast, and sharpness! Zcooger or VideoMem feel free to use this example in another YouTube video. We may want to merge the 1.5MHz adjustment in formats.py to the main branch at this point.

# Band-pass filter for Video rf.
# TODO: Needs tweaking
RFParams_NTSC_VHS["video_bpf_low"] = 1500000
RFParams_NTSC_VHS["video_bpf_high"] = 5300000

[dellsam34]

In my opinion that's below normal capture quality, You could get better results with a good VCR built in line TBC, I see a lot of jagged edges on those white window frames, I though the whole purpose of VHSdecode is to get rid of line timing jitter. Or was that your normal capture sample from normal video out such as composite?

[Titan_91]

That's all vhs-decode. My VCR outputs a softer image with no time base correction. Keep in mind too that VCRs perform noise reduction and other processing on the image such as artificial sharpening, which can also be done in software if desired. I just opted to forgo the noise reduction as it removes detail. As Chad Page said, once you're in the digital domain "Everything else is a solved problem." I'm eventually going to watch some of these software decodes on a CRT RGB monitor and see how it stacks up against a VCR with a normal composite output. The software comb filter alone is superior unless your TV has a fancy 3D comb filter.

In addition to this, many people believe the VHS format has no luma and chroma separation. We know this isn't true, and further limits the TV's ability to properly separate and decode the channels. This video is a good example. His close-up shots using a composite capture device have more noise and less definition than my results.

https://youtube.com/watch?v=P00QS3lXJeI

[VideoMem]

There is something on the chroma downconversion on which the documents are not very clear.

There is a mention on the JVC Video Technical Guide about the chroma carrier frequency being shifted 1/4 Fh (Horizontal frequency) between tracks/heads to avoid crosstalk.
It also mentions something about adding the last 4 chroma lines together to filter out the crosstalk component (or something alike).

The first issue is a fixed test on this https://github.com/VideoMem/ld-decode (with -cafc flag)

It also happens to show the crosshatch artifact more precisely on the reds of the Tom & Jerry sample.
And it can be seen at its strongest expression using the simpler ntsc1d chroma decoder.

The artifact is so clear that I think there's some processing to be done to eliminate it.
Also it seem to be something NTSC bounded.

For the ringing/ghosting part.
I guess there is some group delay between 2.5 ~ 3.7 Mhz on the baseband video that is not quite right, it need some kind of compensation.

BTW, there is an updated test run here:



Bear in mind, all of these are random samples from different VCRs using the flag parameters shown in each chart.
Most of them, are far from ideal and some could be multi generation and or LP tape copies.

[dellsam34]

That's all vhs-decode. My VCR outputs a softer image with no time base correction. Keep in mind too that VCRs perform noise reduction and other processing on the image such as artificial sharpening, which can also be done in software if desired. I just opted to forgo the noise reduction as it removes detail. As Chad Page said, once you're in the digital domain "Everything else is a solved problem." I'm eventually going to watch some of these software decodes on a CRT RGB monitor and see how it stacks up against a VCR with a normal composite output. The software comb filter alone is superior unless your TV has a fancy 3D comb filter.

I wasn't talking about image enhancement, I was talking about line time base correction, The VHSdecode should act as a TBC for VCR's that lack TBC and should fix both HBI and VBI signals otherwise what's the purpose of capturing RF if the VCR's line TBC performs better.

[VideoMem]

There is still an issue with the sync when the pulses on the back porch have a glitch at the beginning (crafters sample).

On that sample the sync pulse doesn't go straight to sync level at the end of the line, it has one step intermediate level that might be confusing things.

[Brad]

Initial tests with the CCTV amp for VHS.

I recorded this segment on the Mitsubishi HS-HD2000U via S-Video. The source is a DVDR played on Philips DVDR3575H/37. (Actually, what I'm showing in this particular post is the player's own blue screen before the DVD started.)

The tape is played back on the Sony SLV-779HF, as usual.

In the images below, no amp with card level=31 always comes first. Followed by amp with card level=0 (again HFGAIN not tweaked).

I don't see checkerboarding in the "no amp" decode, but I certainly do when it's added. What do we make of that?

[Titan_91]

This is caused by a reflection above the RF envelope. Like before, the chroma signal of the reflection (second harmonic) is protruding down into the bandwidth space used for luma. This shows up as a line right above the brightest trace. The brightest trace is your FM envelope for the luma signal. For me, this does not happen if I use 50 ohm mini coax cable, a 50 ohm BNC terminator, and 50 ohm BNC connectors on my VCR and my capture card (which someone modified for me). But that requires soldering and a bit more work.

If I look carefully, the reflections are there originally but they are only amplified in this case along with the main signal. The first screenshot also shows checkerboarding as well but it's very faint.

Does anyone in the US want this Philips VCR I've already modified with a BNC connector? I'll include a BNC to RCA plug as well. I don't need two modified machines.

[VideoMem]

Seeing these graphs, some boost is needed for the chroma band, and there are two residues of the HiFi FM track that might be causing issues.

[ thinking about playing with the audacity EQ and expanders plugins ]

[VideoMem]

Boost or calibration, need to check if the burst amplitude matches specs.

[Titan_91]

I should be able to QTGMC deinterlace some of my final results by serving frames from Avsproxy running in Wine to Avidemux running natively.

[oln]

Here's a potential NTSC S-VHS sample, which causes vhs-decode to immediately barf. I don't know if this RF is accurate, since the SLV-779HF is just a plain VCR without even SQPB. And the CX cards may not have sufficient bandwidth? But a signal is there.

This was a bug, most of the NTSC SVHS settings copied the PAL ones as they use the same luma frequencies but due to a typo one of the filters to have an order of 5 million instead of 3 which caused scipy to barf. It now decodes fine, though the deemphasis is wrong (as with PAL) so it looks a bit off.

[Titan_91]

New video:

https://youtube.com/watch?v=mjQj_8Bxywo

Is there a new regression in the NTSC code? NTSC samples now have magenta/yellow color streaks that weren't present before.

Before:



Now:

[oln]

It's a bug with the -cafc option afaik, videomem is working on it, it's not enabled by default.

[Titan_91]

Gotchya, thanks.

[Titan_91]

I know someone who used to work at a broadcast news station in the late 80s. He is willing to show me some Panasonic MII casettes he has. However, no MII machine to play them on obviously. He has the smaller tapes. He also told me these machines may have been backward compatible with VHS. Looking at photos of the small casettes, the reel size and shape may be the same as VHS. Can anyone verify these machines could play VHS tapes?

Television Format: NTSC; 525 lines, 60 fields
Modulation System: Y; Frequency modulation
C: Time compressed multiplexing (PB, PR)
Bandwidth:
Component Y: 30Hz~4.5MHz +1.0/-4.0dB
C (PB, PR) 30Hz~1.5\MHz +0.5/-3.0dB
S/N Ratio:
Component Y: Better than 49dB
Composite Y: Better than 47dB
C (AM, PM): Better than 52dB
Y/C Delay: Less than 20ns
K Factor: Less than 2%
Differential Gain: Less than 3%
Differential Phase: Less than 3
Linearity: Less than 3% (Component)

[dellsam34]

I highly doubt it it, video99.co.uk youtube channel did few videos on the format, check them out.

[Titan_91]

Thanks. After watching a couple of his videos he mentioned some, but not all, MII machines had S-VHS backward compatibility. He also referred to MII has being "VHS based" whatever that means. So I'll try something. I'm going to disassemble a mini MII tape and try to transfer the reels to a VHS casette. If that is mechanically possible and the reels appear to be identical, I'll then try the tape in a VCR to see what happens. It will most likely be unable to track the tape being the MII speed is 2X SP for VHS, and will likely eject the tape with an error code displayed.

If by some freak accident this actually tracks and "plays" then I'll do an RF capture and share a sample.

[dellsam34]

No, It will not work, MII used just the VHS form factor cassette just like Betacam used the Beta form factor cassette, The tapes are metal formulated, the video is split into two channels Y and C and recorded in two independent tracks not like VHS where both are recorded in the same track but separated by frequency, The audio however is mixed with the C channel in the MII system, The speed is not the same.

The backward compatibility means that a MII machine can playback VHS/S-VHS, not the other way around, not a VHS machine can playback MII tapes.

[Titan_91]

Pretty basic, no filters:
QTGMC( Preset="fast" )

Figured I would ask about this since the vhs-decode project is more usable now. I have Avisynth+ 32-bit installed in Wine. I'm also familiar with using AVSPmod. I'm able to import the MKV files to the script and have installed the prerequisite DLL libraries and scripts to the plugins folder needed for QTGMC. When calling QTGMC though I get an error about a missing function related to Avisynth version. Reading a thread on this, I tried using an .avsi script that has this function by putting it in the plugins folder, but I kept getting different errors.

Could you upload your entire Avisynth program installation folder so anyone wanting to try QTGMC has all the needed files?

[dellsam34]

I can't find any folder on my computer by that name or I must be forgetting something. I will dig deeper and get back to you.

Edit: Ok it is actually in Program files, But I think it's OS dependent I don't think it's a matter of copying the folder.

[Titan_91]

Thanks. Correct, I tried just copying the folder but I got errors for avisynth.dll. So I started over, installed a clean 64-bit Wine prefix, installed AviSynth+, installed AvsPmod, and merged your plugins folders with mine (adding the files I didn't have, but not overwriting the files I already had). I can use the below script to import a file and load QTGMC:

FFVideoSource("beastwars.mkv")
QTGMC( Preset="fast" )

But I get:

I don't know what 'AvsPlusVersionNumber' means.
(C:/Program Files (x86)/AviSynth+/plugins+/QTGMC.avsi, line 231)
(New File, line 2)

Which is where I was stuck at before. Evidently that's a very common issue. This guy had to use the 32-bit plus version from GitHub to get his filters working.

http://www.digitalfaq.com/forum/video-restore/11042-qtgmc-avisynth-installed.html

[Brad]

Bug report:

Got two samples from retail tapes that can't decode. I assume different forms of MV are to blame.


Galaxy Quest (US) = Unable to determine start of field - dropping field
Small Soldiers (CA) = Unable to find any sync pulses, jumping 100 ms. On the spectrogram, I see that VSYNC rests above the normal frequency. Yesterday I read a data sheet that indicated sync in MV can be +10 IRE higher than normal, so maybe that's it.

Good news to report: with my current workflow, the PV-S4622 isn't decoding with checkerboarding. (I'm using the blue AliExpress card, two components removed with tweezers according to Tony's instructions.)

That wavy noise is still there, and it's in exactly the same spots on the frame as the older SLV-779HF capture. Every part of the capture chain is different except for the tape and the PC, so perhaps it's safe to conclude this is present on the tape and that VCRs normally filter it out, as speculated earlier.


[Attachment 60410 - Click to enlarge]

Compare to my previous post:

I got a capture without crosshatching, using a different VCR! Still has high-frequency noise, but this looks much cleaner than my previous attempts. I didn't change any other part of my setup, unless you count moving the VCR from 4" away to 13" away from the PC.

Sony SLV-779HF

[Attachment 59302 - Click to enlarge]

JVC DR-MV7

[Attachment 59304 - Click to enlarge]

Panasonic PV-S4622

[Attachment 59303 - Click to enlarge]

For the two Stuart clips attached, is it just me, or are there added waves of chroma noise on the level 15 capture? The black SNR looks equivalent between them.

[Titan_91]

I know I had already determined the Stuart Little 2 release has chroma waves/checkerboarding baked in to the luma signal, for I can't reproduce it on all retail releases. I also can't reproduce it on my home videos which were shot with a $1600 1988 Quazar "HQ VHS" camera, likely a VM-21 or VM-24. In fact, the signal level on these home movies is higher than many of my retail tapes!