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

[Titan_91]

Here's a good example showing the chroma bleed/offset issue seen with some tapes. Maybe U and V are misaligned? This is from a recorded broadcast but is the same effect seen on the TV Teddy retail videos. This tape was recorded at SP speed. The tracking is poor, it's the best I could get with this Philips VCR considering it was recorded in 1992. Perhaps tracking on the original machine was misaligned during recording.

[oln]

Yeah it almost looks a bit like U and V don't quite line up. Does the chroma bleeding happen on a normal capture too? I will look a bit more at the sample later.

[Titan_91]

Well I feel silly now. That UV error was in the broadcast, specifically the WSMV bumper before the main program, which starts off in sepia tone with no color to compare against. I watched again and the other ads/segments don't exhibit this problem. Played back directly from the VCR on my LCD monitor:



Though vhs-decode does show a bit more smearing in the luma channel than the VCR's native output. But of course that's filtering and de-emphasis which is experimental, and chroma killer for the luma channel isn't implemented yet. Let me know if I can do anything else to help with anything.

[uff]

I just realized a lot of the family tapes I wanted to digitize have been apparently played in a defective VCR with (probably) misaligned tape guides. This caused wrinkling of the tape over the whole length at the bottom. While digitizing them, my 2 VCRs (with classic composite capture for now) often couldn't read the sync pulses, causing one of them to blank the screen and the other one just display noise/really distorted images. The VCR that blanks the screen is a lot more sensitive to these issues, so it might just be bad "software" blanking out the screen too early, while the other one outputs what it can.

Interestingly, if I dump the same tape twice, the VCR collapses at different times, allowing some video to be recovered by merging multiple captures.

I don't have my cxadc machine set up right now, so I can't check what vhs-decode would do. Could software decoding help with the restoration of these tapes? I'm thinking of doing the merge method I described on the RF level, which should be much easier to automate.

Basic algorithm could work like this: Allow specifying multiple RF captures as input. For each frame, from all files that do have proper sync for that frame, merge the sources so that always the one with the best signal for a given point is used. This can both allow for correcting minor dropouts and also major "frame drops". It might also help with noise, due to kind of averaging out the captures.

[Brad]

Well I feel silly now. That UV error was in the broadcast, specifically the WSMV bumper before the main program, which starts off in sepia tone with no color to compare against. I watched again and the other ads/segments don't exhibit this problem. Played back directly from the VCR on my LCD monitor:



Though vhs-decode does show a bit more smearing in the luma channel than the VCR's native output. But of course that's filtering and de-emphasis which is experimental, and chroma killer for the luma channel isn't implemented yet. Let me know if I can do anything else to help with anything.

There's a lot of crosstalk along the coloured edges of the bottom graphics on the vhs-decode version, while your LCD shot looks clean. (But also way too noise-filtered for my taste if this wasn't a static graphic.) Is that what you're referring to, or something else?

[Titan_91]

Partially yeah. That may be because I'm using the NTSC 2D comb filter, but there should ideally be no luma/chroma crosstalk on the tape. It may exist on the tape though, since my VCR and LCD monitor may be smoothing out this effect. The more minor difference I was pointing out though was the slightly worse luma filtering in vhs-decode, which results in a bit more smearing than the VCR's native output. Some of the PAL source material looks sharper/less smeary than this, so it may just be a matter of perfecting the NSTC filtering/de-emphasis. Here are comparison images with vhs-decode on top and native composite output on bottom:

[dellsam34]

Wow, has U-Matic support already been implement in ld-decode/vhs-decode?

NTSC (regular-band) U-Matic is supported yeah. The emphasis is probably a bit more off than the VHS one though, I don't really have a good reference to how the output from the u-matic machine should look. I will add in support for (presumably "regular-band") PAL as well since we got some samples of that now. It's is not actually that complicated to add support for it when we already have VHS working, U-matic is pretty similar. Luma works the same way, just with the rf frequencies and deemphasis bands/filters using different constants. Color is simpler than VHS, it's downconvetred in a similar way, but there is no extra phase rotation or inversion like in VHS and other later formats. Or, at least it was that way with regular-band NTSC. I don't know for certain if all the variants are similary simple, but I think most of them are.

Apologies for back-tracking, Is the head RF out BNC connector available on certain u-matic machines such as the Sony VO-9850 can be used directly with the ld/vhs-decode board?

[Titan_91]

I would think so, that's probably a clean amplified output directly from the RF backend.

I built from the latest repository again. For the news bumper segment, I applied some of the same filters in Avidemux that a modern VCR and monitor would. First I deinterlaced the sample, then added noise reduction, a contrast and brightness adjustment, and upped the color saturation. I also did an extra step and corrected the UV alignment as best as I could. On top of brightness/contrast, NR, and saturation boost I'm sure the VCR and/or LCD monitor is also doing some sharpening. Although the black lettering looks sharper on the VCR's output, there is a light halo effect around the transitions of the letters, just like you would get with a digital sharpening filter. This effect misled me into believing vhs-decode wasn't capturing all of the available luma bandwidth, when in reality it actually is. Recalling the multiburst test on my VCR, the 3MHz pattern is present in the decode (although attenuated because my equipment is inexpensive).

Post processed deinterlaced result, minus sharpening:



Applying the same filters (no UV alignment correction of course as not needed) on the Tom and Jerry retail movie decoded with today's repo, which turned out AMAZING by the way:





In short, I thought there was a regression in some of the latest code. Turns out that is not the case, and on top of what was mentioned above my broadcast source just has a lot of dot crawl in the form of crosstalk. I verified this in ld-analyse as well. My Tom and Jerry sample is attached encoded in lossless HuffyYUV. Honestly if if weren't for VHS's limited color resolution, it would have likely won the late format war against DVD.

[oln]

[QUOTE=dellsam34;2616904]

Apologies for back-tracking, Is the head RF out BNC connector available on certain u-matic machines such as the Sony VO-9850 can be used directly with the ld/vhs-decode board?

I think output may just have the rf after chroma has been filtered out but would have to check the service manual. I think one use of that output was with external tbc units that featured more advanced dropout compensation, and the rf would let the tbc measure where dropouts occurred.

I've now added a function that does an extra diffed demodulation pass if there is noise spikes, which should help a bit with avoiding white streaks on noisy low signal tapes.

Also, this has been possible for a while it seems, but just came up during a discussion on the discord, you can use the ld-process-vbi tool to decode NTSC closed captioning from the tbc file. After running that on the .tbc you can see subtitles in ld-analyse. It's a bit clunky though, so you have to go frame by frame for it to display properly. Another user is working on a tool to translate the subtitles from the json metadata file to something usable by other tools.

Example from titan_91's tom and jerry sample:

[Attachment 58452 - Click to enlarge]

[VideoMem]

I would think so, that's probably a clean amplified output directly from the RF backend.

I built from the latest repository again. For the news bumper segment, I applied some of the same filters in Avidemux that a modern VCR and monitor would. First I deinterlaced the sample, then added noise reduction, a contrast and brightness adjustment, and upped the color saturation. I also did an extra step and corrected the UV alignment as best as I could. On top of brightness/contrast, NR, and saturation boost I'm sure the VCR and/or LCD monitor is also doing some sharpening. Although the black lettering looks sharper on the VCR's output, there is a light halo effect around the transitions of the letters, just like you would get with a digital sharpening filter. This effect misled me into believing vhs-decode wasn't capturing all of the available luma bandwidth, when in reality it actually is. Recalling the multiburst test on my VCR, the 3MHz pattern is present in the decode (although attenuated because my equipment is inexpensive).

You can use the sharpness parameter -sl
It boosts the 3MHz region after the demod.
The flat point is between 50 and 80 and depends mostly on the VCR standard + head + amplifier combination.

It does EQ with the full numerical range precision (it is not limited to 256 greyscale levels)

I found the NTSC samples here having more high frequency video losses than the PAL samples I tested.
So maybe your captures can benefit from the video sharpness filter.
Tried the -sl 70 with the multiburst and the 3MHz burst shows better on NTSC.

(sharpness level zero, default)


(sharpness level 70 -sl 70)

[Titan_91]

Nice! The sharpness level parameter is used with the vhs-decode script? Like:

vhs-decode --cxadc -n -sl 70 testinput.r8 testoutput

Also, I tried one of the noise reduction filters in Avidemux. Just tried one with the default settings. Looked at the 3MHz multiburst pattern following the filter. Pleased to say that pattern is still present. So between the sharpness adjustment and noise reduction, theoretically that's the best way to remove tape noise in the decode without losing the 3MHz of bandwidth (sharpness/detail) in the image.

[VideoMem]

Yes, that is the parameter it can be used on the command line directly as you described.

There is a function not implemented yet to cut the bandwidth of the tape to 2.7MHz if the signal comes weak.
Some VCRs does that automatically to avoid excessive snow/noise on difficult tape sections.

You can also use the -t parameter to speed up the decodes.

If your decoding machine has 4 cores with 8 threads you can use -t 7 to run 7 parallel demodulation threads.

The rule is one thread less than the all ones available on the machine like when doing 'make -j N' when compiling.

[Titan_91]

I fiddled around with the sharpness adjustments. For Tom & Jerry higher values bring out excessive ringing on brightness transitions. The best level to use for that sample is 30, where the ringing is no worse than with the default adjustment of 0. Before and after sharpness adjustment:

[Titan_91]

That sharpness adjustment may work better for PAL. With NTSC I can't seem to go very far without compromising the quality with ghosting and ringing. The multiburst comparison looks great otherwise. If there's a way to further fine tune that, great. But if not it doesn't matter to me. 30% is still an improvement.

[dvd3500]

Am I the only one that finds humor in using a Blockbuster Video add to examine analog sources?
I may be strange,,,,

[Titan_91]

What's more appropriate? Lol.

[Titan_91]

I have an SLP source recorded on Sony "standard grade" tape from 2004 that looks considerably worse than the software decoded SP retail tapes. Using a real VCR, this SLP video looks better than vhs-decode. As in the filtering appears to be better and the colors are more accurate. But the vhs-decode version is slightly sharper. If there's any interest at taking a look at it I will post it.

[jrg]

Hello! I'm coming from the Domesday86 discord. Here's the PAL-M sample I captured to test out the decoder. It's 10-bit, FLAC compressed, with normal cxadc Fsc. The tape itself is second-generation, SP, presumably from VHS-C source. I have also included a reference for what it should look like with proper color decoding, captured the old-fashioned way onto a DVD.

The fact that it's a second-gen copy is relevant due to the fact that there are some bearding artifacts that have become "burned-in" and will not go away with the --doDOD argument enabled.

[dellsam34]

Can you guys include a final video sample from your cxadc captures? Is there an easy way to convert the FLAC into a useful video?

[Titan_91]

I don't do this for the sake of attachment size and forum resources, but you can download any of my 8-bit 28.6MSPS compressed FLAC file samples and decompress them using this command:

flac --best --sample-rate=48000 --sign=unsigned --channels=1 --endian=little --bps=8 -f test.flac -o test.r8

Then run an NTSC decode to render an interlaced MKV video file with another single command:

./vhs-decode -n --cxadc --doDOD -t 4 /path/to/video/file.r8 output_name ; ./gen_chroma_vid_ntsc.sh output_name

[dellsam34]

Using which application for those commands?

[Titan_91]

Terminal opened from the vhs-decode program folder after you have built the software from source.

[dellsam34]

I was just asking the posters to post a conventional capture vs a vhs-decode converted to digital video so the public can see the progress, Posting a FLAC file is not useful for anyone who is not experimenting with the project. I personally try to stay away from any Linux crap.

[Titan_91]

Post #578 has an MKV video file you can play in VLC Media Player:

https://forum.videohelp.com/threads/394168-Current-status-of-ld-decode-vhs-decode-(tru...20#post2616954

[oln]

I was just asking the posters to post a conventional capture vs a vhs-decode converted to digital video so the public can see the progress, Posting a FLAC file is not useful for anyone who is not experimenting with the project. I personally try to stay away from any Linux crap.

In that latest post it was a PAL-M sample which we haven't finished implementing support for in vhs-decode yet.

[jrg]

It's unnecessary to decompress flac captures to decode them, as the decoder can handle them natively. It's daunting since there are almost no instructions on how to do any of this (still working on that,) but it's really not that complicated.

I'll upload a decoded video just for the sake of comparison, but like oln said, PAL-M support is very early and still looks very off.

[Titan_91]

I had forgotten about native FLAC support. Is there a flag needed to decode FLAC files?

[VideoMem]

I think it doesn't need any extra flags.
If the file ends with .flac or .vhs it handles it.

The standard of capture and the sample rate are the most important parameters.

I made a small sample demo of the current vhs_decode branch tests over tape captures with previous known decoding issues and it seems to be decoding them better than before.

https://youtu.be/7R92_b7ZDao

There is some issues with the AGC on ld-decode with some samples, it halts prematurely without error (figuring out why)

The current code features an automatic level clamping based on the VBI serration blanking/sync levels.
It adjusts them if it can measure that section.
If it cannot measure it, it falls back to the previous sync level logic with some added tweaks.

Once it gets the serration blanking level it uses that value with a moving average filter of the previous 30 fields measures.
The same kind of filter is applied to the fallback previous logic if the serrations can't be found.


For making the final lossless unfiltered videos, there are two scripts on the root of the project

gen_chroma_vid_pal.sh
and
gen_chroma_vid_ntsc.sh


As an example, to decode one of the samples of this thread I use (on the root folder of the project):

./vhs_decode --doDOD -t 6 -sl 30 --cxadc -n  /external_drive/straight-to-card-bnc-filter.r8 testrun

It will produce a testrun.tbc and testrun_chroma.tbc files

testrun.tbc contains the luma channel information and the other, only the chroma.

The result can be inspected using ld-analyze (needs to be installed from source, see below)

./ld-analyze testrun.tbc

The final video gets rendered by the gen_chroma scripts

For the mentioned sample:

./gen_chroma_vid_ntsc.sh testrun

It will produce a playable lossless testrun.mkv


For installing the tools from source, once all dependencies installed, it can be built issuing (again, root of the project folder)

make -j6

Then:

sudo make install

To install the tools system wide.

A better README will be added.
As some features on it are experimental, and they are not settled yet, only mentioned here the most stable features/parameters.


PD: The current black level clamping could be disabled on the picture area with the -noclamp flag

For more information on flags:

./vhs-decode --help

[Titan_91]

Fantastic post summing everything up. Thanks!

[VideoMem]

I confirm the installation dependencies for Ubuntu Focal 20.04 and Hirsute 21.04.

Tested it on a fresh installation.

Required to update and/or build the tools / make final videos:

sudo apt install build-essential git ffmpeg libavcodec-dev libavformat-dev libqwt-qt5-dev qt5-qmake qtbase5-dev python3 python3-pip python3-distutils libfftw3-dev openssl

Dependencies required to generate .tbc files:

sudo pip3 install numba pandas matplotlib scipy numpy samplerate

Complementary to this information:
https://github.com/happycube/ld-decode/wiki/Installation

I heard that it works on Windows using WSL2, no dualboot required.