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

[Titan_91]

If you're skeptical of the software's ability to exceed the quality of a conventional capture setup, here are a few examples comparing the same tape played on a VCR vs. decoded with vhs-decode. The VCR captures are straight from my capture box unprocessed, the raw MPG file, without modifications. The vhs-decode results are straight from the NTSC generation script, the raw MKV file, without modifications. This example is Disney World Orlando Magic Kingdom, 1995. Here are the video files as well:

https://www.mediafire.com/file/415tzi5p5r35nl4/VCR+decode.mkv/file
https://www.mediafire.com/file/ky0dne5wjmc2573/vhs-decode.mkv/file

Scene 1

VCR:



vhs-decode:



Observations:

Picture is sharper on vhs-decode, bringing out detail in leaves, foliage, and rocks in the background. The vhs-decode sharpness level (-sl) filter was not used. VCR source is overdriven, causing the sky to wash out detail in the foliage. Brightness is better on VCR source, but this is due to processing by the VCR. vhs-decode appears to have more overall contrast. Very slight crosshatch pattern on vhs-decode result in the blue stripes on the canopy, but the VCR source has horizontal stripes. The horizontal stripes are verified to be on the tape itself, as vhs-decode exhibits them in other scenes. Likely noise generated by the camera at time of recording.

Scene 2

VCR:



vhs-decode:



Observations:

More color bleed in the red shirts on the VCR source. This mostly due to pixelation on the peoples' shoulders caused by a low chroma subsampling resolution. Can be avoided with better capture equipment, but some smearing is also caused by the composite video coming from the VCR as well. Faint horizontal lines in the sky are present in both sources, but on the VCR source this triggers the chroma slightly resulting in alternating pink and green bars. On the white shirts, the overdriven brightness hides details such as wrinkles. This may be due to poor de-emphasis from the VCR.

Scene 3

VCR:



vhs-decode:



Observations:

This scene demonstrates several advantages for vhs-decode. The castle building on the left has almost no detail due to noise reduction done by the VCR. Detail in the walls and shingles on the castle roof are restored using vhs-decode. The excessive brightness discussed earlier makes the thin outlines in the white canopy to the right mostly invisible. vhs-decode shows this detail. The points of light representing the lamps on the merry-go-round are sharper and smaller on the vhs-decode source. The bricks under the planters in front of the merry-go-round lose all detail with the VCR source. With vhs-decode, the lines in the bricks and texture are present. Again, color bleed on the back of the woman's red dress is minimized with vhs-decode. For the dropout correction, there are red and yellow lines on the VCR source. vhs-decode does not have this issue. Dropout correction by the VCR is not robust enough to prevent sync pulse corruption and the image skips around as a result. The software decoded video does not lose sync.

[servese]

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

It's actually possible to run QTGMC natively on linux with Vapoursynth. QTGMC is included in the havsfunc plugin so you'll need to install that first. A basic script would look something like this:

from vapoursynth import core
import havsfunc as haf

clip = core.lsmas.LWLibavSource(source='source.mkv')
clip = haf.QTGMC(clip, Preset='Fast', TFF=True)
clip.set_output()

[dellsam34]

It depends on what method of conventional capture workflow you use and the quality of the VCR, I would say that with the current limitations of the VHS-decode I can fairly say that I can produce better results with the hardware I have, But since I don't have any setup for VHS-decode to compare it to side by side I cannot backup this bold claim unless someone willing to send me the same tape.

[Brad]

I'm getting inconsistent & confusing noise floors with cxadc captures. Please see the update at the bottom of my previous post.

[Brad]

Last night on Discord, I posted these preliminary screenshot comparisons of hardware low-pass filters.

Mini-Circuits BLP-10.7+ (cutoff frequency = 14 MHz)
Mini-Circuits BLP-5+ (cutoff frequency = 6 MHz)

BLP-10.7+ vs BLP-5+
https://imgsli.com/NjkxMjE
https://imgsli.com/NjkxMjE/2/3
https://imgsli.com/NjkxMjE/4/5
https://imgsli.com/NjkxMjE/6/7

Note for other international buyers: the cheapest shipping option their site showed was $87. Using the contact form at the bottom of the item page, shipping estimate was $35. I placed the order via email, and the invoice said $26 once it was actually shipped.

[Titan_91]

The 10.7+ filter recovers a little more detail. I believe that's the same one I'm using actually and is the one I settled on.

[Brad]

Here are clips from a capture of one of my worst tapes. This is from a summer animation program I took part in as a kid. As I recall, the machine could somehow be set to record 1, 2, 3, etc. individual frames at a time to VHS. This constant start/stop would be a chaotic signal even if this was the 1st-gen recording. I believe what we were given is 3rd-gen.

I didn't think YouTube would handle this comparison quite so poorly.

[Titan_91]

Good example! I also have some time shifted recordings from an old security VCR. These do not sync properly when playing back to a CRT TV. Might be a tracking issue. I'll try and find the tape.

[dellsam34]

The DCR-TRV340 is the most stable capture and vhs-decode being the worst, But chroma wise the DCR is the worst due to DV compression maybe?

[oln]

It could be DV compression in part, though the ADV may have a more advanced chroma decoder than the DCR too, though I don't know to what degree that comes into play with Y/C as opposed to composite. Chroma seems more stable/less flickery in vhs-decode though even when it's unstable vertically, maybe the fact that it's tbced before upconversion makes a difference the video quite wiggly, idk.

Also, forgot to mention earlier, but I have a first decode of a PAL Betamax capture. This is with standard VHS settings so it won't really look right yet and chroma won't work since it's a bit different on beta. I haven't done any further work on it yet as I haven't found the technical details (frequencies, color encoding, emphasis etc) for PAL Betamax yet. (The dropout is on the tape, doc was not turned on in vhs-decode.)

[nicholasserra]

Sorry for a random question during all of this: Has anyone tapped RF on an AG1980? I'd like to start messing around with this on one of my Panasonic decks. Apologies if this has already been discussed, would love a link if so.

Amazed at all this work and want to say thanks to everyone for their effort!

[Brad]

Why not start with a less-complex VCR? I think to access the test point you have to flip up the circuit board. Also, if either of my AG-1980 units was working at full-quality, I personally wouldn't want to risk messing them up somehow.

[nicholasserra]

Well i'm sending one off to Deter for refurb, so figured this would be a good opportunity to get it tapped in, if it wasn't super complex.

[oln]

On the previous generation model (AG1970P, NV-FS200, FS88 and lower end variants) it's quite simple to poke in to the rf output from the head amp on the connector with a scope or similar. They seem to have swapped to using ribbon cables on the 1980P and other newer ones though, which makes it slightly more involved. It may be accessible from one of the connectors points on top of the main board too where it enters the relevant video board but not sure. Anyway, as noted, I would maybe try on something cheaper first.

This is on a NV-F77 (Top of the line hi-fi deck that shared most electronics other than the video boards with the FS88/FS200 and same mech except lacking the tape stabilizer thingy).

[Attachment 60891 - Click to enlarge]

[peppi001]

Hi Guys!
This is a great project. Congratulations to everyone. The quality is very good.
I tested it with Winfast tv2000 extreme.
This is my test video: https://archive.org/details/mono14_202109

My only question is. How can I decode the hifi rf audio signal?
Thanks

[VideoMem]

First, you need at least an 8bit 8MSPS capture of the audio FM channel. (12MSPS to be sure)
The HiFi audio is not in the same signal path as the video.
It is read by a separate set of rotary heads.

There is a way to decode it via gnuradio+audacity route.
The first one for the FM demod, deemphasis and log expander, then on audacity the pattern based noise cancel filter to silence the head switch.
There is still to be implemented the dynamic part of the noise reduction. There are very little documentation on the subject at least for VHS.

Lip sync and audio timing might be handled manually as both video and audio RF captures might clock drift.
But maybe not so noticeable.

I'm planning to add support for that on vhs-decode, but it has some challenges in to translate to pure python implementation and we lack of RF samples from different vcrs to fine tune it along with the original source audio.
The gnuradio part is easier, and I might write some code soon.

By the way, there is the last test run.

https://youtu.be/crgGXoh9Lz4

[dellsam34]

If FM audio is to be added on the fly it would require two simultanious RF captures from two pickup points (Audio and Video test points) and two capture modules, That will require some serious horse power.

[Titan_91]

I just capture audio using the standard RCA jacks on the VCR and save it losslessly, because of these limitations. Plus if HiFi drops out, the VCR will switch to linear stereo automatically if available. I use a ground loop isolator to eliminate mains hum.

[peppi001]

Thanks for the answers. I thought the audio "capture" was ready

[peppi001]

VideoMem's last test run has more contrast than my own video. Can you use any filter?

(Sorry, the problem was is in my vlc player.)

[peppi001]

I capture videoclips, and I've got a problem. (Attached the test video files)

When the 2nd clip start there is a problem with interlace lines.
But if I split the same test file there is no problem.

The command that I used:
vhs-decode -p -t3 --10cxadc3 viva_error.vhs test
gen_chroma_vid_pal.sh test

It's a bug or what am I doing wrong?

https://files.videohelp.com/u/264498/viva_error.vhs
https://files.videohelp.com/u/264498/viva_error_p1.vhs
https://files.videohelp.com/u/264498/viva_error_p2.vhs

[Brad]

Pretty sure the problem is the dropouts during VSYNC. They're the grey lines at the very top and bottom of the frame, visible in ld-analyse. If you only view the output of the gen_chroma_vid script, you can't see this because the Blanking Intervals are cropped away.

[Attachment 61192 - Click to enlarge]

After this frame, the current version of vhs-decode incorrectly assembles the rest of the fields. The "p2" split doesn't include this frame, so decoding proceeds normally.

[Attachment 61193 - Click to enlarge]

[Attachment 61194 - Click to enlarge]

I'm surprised that decoding of these files is working so well, though. Unless Audacity is interpreting the file incorrectly, your waveform is clipping often. This may be the cause of the black streaks visible in the screenshots above. You should lower the gain level to allow some headroom, like in my example waveform below yours:


[Attachment 61195 - Click to enlarge]


I'm curious, what's your hardware workflow?

[peppi001]

Is it possible to detect VSYNC dropout by software?
Maybe drop the incorrect frame?

My HW workflow is: Philips vr948 and Winfast TV2000 Extreme

Gain level (with leveladjust) is 19.

[oln]

Yeah as noted it's a bug or lack of feature or whatever you wanna call it in vhs-decode. I've seen it happen on other clips too, though I haven't seen it affecting later frames.

[oln]

I've changed drop-out detection to be enabled by default. If it does weird things it can be tweaked or turned off with command-line options described in vhs-decode --help

[peppi001]

Yeah as noted it's a bug or lack of feature or whatever you wanna call it in vhs-decode. I've seen it happen on other clips too, though I haven't seen it affecting later frames.

This is my feature request

[Titan_91]

Good example! I also have some time shifted recordings from an old security VCR. These do not sync properly when playing back to a CRT TV. Might be a tracking issue. I'll try and find the tape.

Finally got around to finding the tape. It's time shifted, recorded at EP speed, tracks poorly, and confuses vertical sync on CRT TVs and LCD monitors. Enjoy.

[oln]

What sample rate/bit detph combination is it?

[Titan_91]

Sorry, it's 40MSPS 8-bit. Basically plays back like this:

https://youtube.com/watch?v=rGvblGCD7qM#t=01m04s

[wright96d]

Is there some sort of straight forward tutorial for this? I'd love to try it, but I have no idea where to start. Also, would the RF hookup allow me to get the tape path alignment perfect? I messed with it a few years ago trying to fix a tracking issue, and have never been able to get it to 100% perfect.