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

[Zcooger]

The script is in the main directory of https://github.com/oyvindln/ld-decode repository.
Also the newest features including these from ntsc_color_broken and ld-decode are now merged to master branch.

[oln]

It's in the git repository, it should be in the same folder as vhs-decode.

[Titan_91]

Thank you, I found the script. Didn't know it's now included. I installed a BNC jack with ferrite shielded RG_174 cable and am still getting 42dB SNR with T&J, and the pulsing pattern in the color seems to be gone. The color fringing in the luma decode using ld-analyse is gone too, which is odd. Noise floor is even further reduced as well. I ran the script, but noticed the chroma .rgb file wasn't created. I'm not sure what PATH refers to. All my files are in the main vhs-decode folder I'm running the script from.

  libavutil      56. 31.100 / 56. 31.100
  libavcodec     58. 54.100 / 58. 54.100
  libavformat    58. 29.100 / 58. 29.100
  libavdevice    58.  8.100 / 58.  8.100
  libavfilter     7. 57.100 /  7. 57.100
  libavresample   4.  0.  0 /  4.  0.  0
  libswscale      5.  5.100 /  5.  5.100
  libswresample   3.  5.100 /  3.  5.100
  libpostproc    55.  5.100 / 55.  5.100
straight-to-card-bnc_chroma.rgb: No such file or directory

[Zcooger]

You need to provide full terminal output of the script command as there are important info that can explain why the file is not created.
My best guess is you need to recompile chroma decoder after update since it got extra argument for chroma compensation.
To run compilation of these modules run these commands in vhs-decode folder (where Makefile is present):

make clean
make -j8 all
sudo make install
make clean

And remember to repeat this step after downloading any update from github repository.

[Titan_91]

Great, that worked. Thank you. Just made a new folder and extracted the zip file of the latest repo changes. The project is moving so fast I'll need to do this weekly now. I added the 13MHz low pass filter back into the mix and that really cleaned up the luma. Before there was smearing, now that's completely gone. I'm back down to 40dB with T&J, but the result is much better now. My final step is to get rid of this long 75 ohm RCA cable and use a proper 1 foot 50 ohm RG316 BNC cable with the VCR on top of my capture PC. Hopefully that will get rid of the ~600Hz chroma pulsing signal I still have. Also need to AC couple the line with another 0.1uf capacitor, as I think I have a very slight ground loop causing scrolling hum bars.

No filter:



With filter:



Also discovered this filtered sample managed to cause a warning (exception?) in vhs-decode, which caused a second of the video to be lost. Sample is attached if anyone wants to troubleshoot. Leave the extension as .zip this time.

File Frame 343: CAV Frame #None Unknown                                         
Field phaseID sequence mismatch (4->3) (player may be paused)
File Frame 344: CAV Frame #None Unknown                                         
Raw data loc didn't advance.
File Frame 345: CAV Frame #None Unknown                                         
Raw data loc didn't advance.
Field phaseID sequence mismatch (2->1) (player may be paused)
/usr/lib/python3/dist-packages/numpy/core/fromnumeric.py:3256: RuntimeWarning: Mean of empty slice.
  return _methods._mean(a, axis=axis, dtype=dtype,
/usr/lib/python3/dist-packages/numpy/core/_methods.py:161: RuntimeWarning: invalid value encountered in double_scalars
  ret = ret.dtype.type(ret / rcount)

Unable to find any sync pulses, jumping one second
Possibly skipped track, re-checking phase..
Raw data loc didn't advance.
Field phaseID sequence mismatch (2->1) (player may be paused)
File Frame 377: CAV Frame #None Unknown                                         
Field phaseID sequence mismatch (2->1) (player may be paused)
File Frame 379: CAV Frame #None Unknown                                         
Field phaseID sequence mismatch (4->3) (player may be paused)
File Frame 381: CAV Frame #None Unknown

[Zcooger]

Here's quick analysis of the clip:

[Attachment 57586 - Click to enlarge]
After extracting this problematic fragment with Vooya player:

[Attachment 57588 - Click to enlarge]
Here are happening instant brightness changes "flashes", possibly sync detection does not like it. Here frames 0-3 are decoding fine, on first field of frame 4 decoding breaks.

By the way this is the best compression method for raw video, two commands for packing and unpacking with barebone FLAC codec. These apply for 8-bit and 10-bit CXADC captures, remember to set --bps=8 or --bps=16 respectively. This forum supports .flac extension files and the decoder also.
Encoding:

flac --best --sample-rate=48000 --sign=unsigned --channels=1 --endian=little --bps=16 -f test.r16 -o test.vhs

Decoding:

flac -d --force-raw-format --sign=unsigned --endian=little -f test.vhs -o test.r16

Thanks to it I reduced size of your 17-second long, 531MB Tom&Jerry sample to 280MB instead of 384MB in .zip plus no unpacking is necessary.

[dellsam34]

What does FLAC has to do with video? Isn't it limited to audio only at 20-20KHz? The same question goes for Audacity.

[Zcooger]

It's all about analog waveforms that are sampled with X frequency the ADC is working at. Once sampled the waveforms can be played back at any speed in the digital domain.
Sample rate in file is just indication in the file at what speed the samples should be played back. Video decoder is reading them much faster.
Audacity itself can read .wav and .flac files with video, however it's not possible to play them with native sample rate or save them with such high values because the developers obviously made this editor to work with audio.

Here are official values FLAC format can store in its header: https://xiph.org/flac/format.html#metadata_block_streaminfo

[Titan_91]

Yeah that flash is when Tom gets struck by the wizard. That decoded fine without using the filter before, which is strange.

[VideoMem]

I'm glad to add some updates here.

After a code tour, with a lot of tests and fun with the guys at DD86 discord, I successfully 'ported' the GNURadio FM deemphasis code into vhs-decode.
It acts over the luminance only.
Also, I added the --noAGC command line flag to disable the luma AGC on demand as ld-decode does.

It will be merged on the main repository, but for now, and if you want to test it, is there:
https://github.com/VideoMem/ld-decode

Just make sure to checkout the vhs_decode branch

The new deemphasis implementation makes the picture smoother and less noisy (maybe very attractive to animation content, and to upscale it using AI techniques)
It also helps the TBC as it produces cleaner Hsync pulse edges than the previous implementation.

We found that the upper sideband of the Y FM if it gets too much low passed it start to produce a phenomena called 'black fishes' on datasheets.
They appear as black stripes near to high contrast image regions.
On the other hand, if the RF FM Y lowpass is too high, reading noise can cause 'white fishes'. They are the same as the black ones but whites.

There is some specialized circuitry that does ASO (Automatic Sideband Optimization) found on some decks, that might be a nice feature to add.

For now, if your tape has lot of white fishes, try decreasing the

RFParams_(NORM)_VHS["video_bpf_high"]

value a bit on vhsdecode/formats.py
Where (NORM) is PAL or NTSC (there is a value for UMATIC too)
If your tape presents lots of black fishes, then increase that value.

Also, I made some research on DTW (Dynamic time warping) for the RF, and I hope to craft a code for that very soon.
It will deal with the reading velocity compensation as one field is read by one head and the other by the second one, there will be a subtle reading speed difference between head to head that makes one field to play faster or slower than the previous one.
The current TBC code fixes that issue a lot, and the phase-compensation chroma filter fixes the chroma jitter a lot too.
But I think it is worthy to try some DTW trickery with that (and maybe it also will improve chroma further).

These are the head speed measurement results.
They were made on colorbars pattern and piped thru GNURadio for producing the graphs and the sound files
The NTSC VHS sample is the one mentioned here before, and I think the PAL sample comes from here as well.

In the left channel you will hear a signal analog to the relative speed of the drum, It can be noticed it is around 60Hz for NTSC and 50Hz for PAL (this is mainly due to the head switch point). The right channel has a VCO driven with that to aid hearing that low frequency variations.

NTSC VHS:

head_speed_NTSC_VHS.flac

PAL VHS:

head_speed_PAL_VHS.flac

NTSC UMATIC:

head_speed_NTSC_UMATIC.flac

That measure will be used as the distance metric on the DTW
The goal will be to compensate the speed in a way these measures will result in an (almost) flat line.

Maybe the physical magnitudes typed on the Y axis of the graphs are not accurate, for the moment ignore these.
The time axis is right.

[dellsam34]

When do we expect a GUI Windows based app at least for tinkering?

[VideoMem]

I like the GUI idea, but I don't know when it will be there.

In the current development stage there is a lot of room for testing, tweaking and optimizations and the code can change.
Adding a GUI to a moving target is costly, as it doubles the coding time, adds complexity and dependency jungle.
There is nothing that prevents it to run on Windows, at least Windows 10 with WSL2 support.
However the command line interface will be there always as it is convenient for running batches and use it as a frontend for any video codec. Specially ffmpeg.

I think it will be the first thing to do after we considered it complete on the backend level.

And if you have coding knowledge, now it is a good time to dive in.
The code is big, but not so big and almost all the hard work is already done.

[Titan_91]

Sweet updates. Can you share a before and after screenshot with the new deemphasis code using this sample I have in this post? It's the cleanest NTSC capture I have yet. My luma decodes still have a bit of noise, which I thought was just the tape. If there's a way to reduce that noise without losing sharpness/bandwidth, that sounds awesome.

https://forum.videohelp.com/attachments/57585-1614649416/straight-to-card-bnc-filter.zip

[VideoMem]

Sure

Before -> After (same post-processing pipeline)

--noAGC parameter

./vhs-decode --noAGC --cxadc -n straight-to-card-bnc-filter.r8 testrun
./domkv.sh testrun

domkv.sh (based on Zcooger script)

#!/bin/bash

ffmpeg -hide_banner -thread_queue_size 1024 -f rawvideo \
  -r 30000/1001 -pixel_format gray16le -s 760x488 \
  -i <(ld-dropout-correct -i $1.tbc --output-json /dev/null - | ld-chroma-decoder -f mono -p yuv --input-json $1.tbc.json - -) \
  -f rawvideo -r 30000/1001 -pixel_format yuv444p16le -s 760x488 \
  -i <(ld-dropout-correct -i $1_chroma.tbc --input-json $1.tbc.json --output-json /dev/null - | ld-chroma-decoder -f ntsc2d --ntsc-phase-comp --chroma-gain 2.0 -p yuv --input-json $1.tbc.json - -) \
  -filter_complex "
    [0]
      format=yuv422p10le
    [deinterlace];
    [deinterlace]
      yadif
    [eq];
    [eq]
      eq=
      contrast=1.5:
      brightness=0:
      saturation=2.3:
      gamma=1:
      gamma_r=1:
      gamma_g=1:
      gamma_b=1:
      gamma_weight=1
    [luma];
    [luma]
      unsharp=
      luma_msize_x=7:
      luma_msize_y=7:
      luma_amount=2.5
    [chroma];
    [chroma]
        mergeplanes=0x001112:yuv422p10le
    [output]" \
  -map "[output]":v -c:v ffv1 -coder 1 -context 1 -g 30 -level 3 -slices 16 -slicecrc 1 -top 1 \
  -pixel_format yuv422p10le -color_range tv -color_primaries smpte170m -color_trc smpte170m \
  -colorspace smpte170m -aspect 4:3 -shortest -y $1.mkv

[Titan_91]

That looks good as far as better dynamic range in the blacks and less noise. However, it looks softer than before and there is a slight horizontal smearing effect now. Are there any adjustments that can improve that?

[VideoMem]

You can change the 'deemph_tau' parameter in vhsdecode/formats.py for controlling the knee point of the deemphasis filter and to get different sharpening levels.
It is specified in RC time constant (tau) as it is found in the literature / standards.

Particularly this line:

#Video Y FM de-emphasis (1.25~1.35µs)
RFParams_NTSC_VHS["deemph_tau"] = 1.30e-6

The effective corner frequency is:

Fc = 1 / (2 * pi * tau) (hz)

Or:
tau = 1 / (2 * pi * Fc) (seconds)

So if you want more sharpness, you should try making tau smaller (however it is a trade-off between sharpness and noise)
The current value 1.30µs is taken from the JVC reference (it specifies a range from 1.25µs to 1.35µs for standard SP mode VHS)
Below 1.25µs and above 1.35 the results start to show funkiness.
These values depend on the expected recorder component tolerances.

With 900ns tau:


With 1.5µs tau:



The numbers are specified in engineering notation:
1.30e-6 is 1.30µs, 900e-9 is 900ns

e-6 ending is µs (microseconds 1/1000000 s), and e-9 is ns (nanoseconds 1/1000000000 s)

I guess the smearing is something related to the RF bandpass, specially high corner frequency.
Try tweaking

RFParams_NTSC_VHS["video_bpf_high"] = 5600000

To something like 6000000 to 6.2e6

There is an extra sharpness control pending.

I hope most of the smearing issues / fishes will be resolved with ASO code.

[Titan_91]

Thanks again for the additional info. Something I didn't notice before. For some reason, both your de-emphasis before and after results look worse than mine, with more noise and less sharpness, and a lot of low level brightness lost in the background details. Here are my results of the same frame, frame #129. Is there anything different about your filter settings? I'm using the main branch and left formats.py and everything else for luma set as default. That produces a much sharper and cleaner result, and preserves the background brightness. What I'm getting is fit for preservation at this point for my own uses, even without the de-emphasis code which is interesting.




By the way, to use as a control I found a DVD clip of this scene: https://www.youtube.com/watch?v=voW-SaJdtRo

[VideoMem]

Sure, I'm showing the results after FFMPEG on which I deliberately added a sharpening filter to show the noise difference, I will remake the tests without that filtering.

The parameters tweaking is an art, if you got a nice result that satisfies you, keep that.

This is my results with 1.23µs deemph




Previous deemph as in main branch.




The result is softer but the edges are better, or it might be completely wrong for this sample and great for other tape.
Or something as an step before for better result.

This is a PSNR comparision of the overscans. (Red where the most differences are)


After FFMPEG result:

[Titan_91]

Agreed, it's a matter of preference. Much of the Python in this project is human readable, thanks to the comments in the code. So if someone wishes to tweak something it's relatively easy. Once the new de-emphasis code is merged in to the main branch is there a planned way to disable it? All progress is appreciated but that one isn't for me.

[VideoMem]

I don't think it gonna be merged as default on main branch unless it gets a better (general) result than the previous one.

Maybe there will be a flag to enable it if there is a tape where it makes a difference. Or be a part of some debug mode.

That's why there are other code branches.
As programmer I'm pretty comfy with discarding useless code if doesn't work as expected.

But I will try to add a post EQ first to see what happens.
Maybe there is no fixed code for that and it will evolve as presets.


[Update]

I reviewed it with the multiburst test, and it just don't have a flat response in the 0~3MHz region. So forget it.

It needs at least a frequency compensation EQ for sure.

I rushed here, that's not the way it will work!

Thanks for the feedback, I appreciate that.

[dellsam34]

You can change the 'deemph_tau' parameter in vhsdecode/formats.py for controlling the knee point of the deemphasis filter and to get different sharpening levels.
It is specified in RC time constant (tau) as it is found in the literature / standards.

Particularly this line:

#Video Y FM de-emphasis (1.25~1.35µs)
RFParams_NTSC_VHS["deemph_tau"] = 1.30e-6

The effective corner frequency is:

Fc = 1 / (2 * pi * tau) (hz)

Or:
tau = 1 / (2 * pi * Fc) (seconds)

So if you want more sharpness, you should try making tau smaller (however it is a trade-off between sharpness and noise)
The current value 1.30µs is taken from the JVC reference (it specifies a range from 1.25µs to 1.35µs for standard SP mode VHS)
Below 1.25µs and above 1.35 the results start to show funkiness.
These values depend on the expected recorder component tolerances.

Will this figure be the same for both NTSC and PAL or is format dependent, Also will it vary from one VCR manufacturer to another?
I can see that at the extremities of 0.9µs and 1.5µs is pretty bad, I'm guessing in the final product it will have a dial to set this value, Correct? What will be called though, Sharpness?

[VideoMem]

I recently reviewed the tests in more depth and with a cleaner mind perspective.

As I tought it will work was wrong.
The deemphasis is fixed value for the format as it figures on the literature, documentation and schematics. It doesn't depend on the standard and it won't change.
It depends a bit on the component tolerances of the recorder ( that made the tape ) , and it is specified in the range 1.25~1.35us being 1.30us the middle point. If the recorder (not the player) is on-spec there is no need to alter that.
I made these extremes at 900ns and 1.5us for demonstration of how sensitive the value is over the image and nothing more.

The current code on the main branch does two steps in the same filter.
It applies the deemphasis and it equalizes the result to get almost flat bandwidth frequency response on the 0~3MHz range.
But as it is, it adds ringing on sharp transitions. You can spot them as an echo after a sharp edge that isn't there as strong with the 'new code'.

I need to test an EQ to make the frequency response flat.
That EQ will be after the deemphasis and it will be calibrated using a multiburst test chart.

Then some control can be added over that to alter how sharp or soft the picture should be being the default value a flat frequency response like an audio EQ.
Currently it, isn't.

Currently is the equivalent on video of listening only the bass and mids of the signal and having the highs at very low amplitude in comparision.
But they are there waiting the EQ.

[Titan_91]

Ok that was confusing. From what I understood there was no de-emphasis code and you were adding it for the first time. But there is de-emphasis code in the main branch already, otherwise the contrast would probably be way off and it would look horrible.

It appears this cheap Philips VR620CAT21 VCR from 2001 does a great job of putting out a clean signal that's strong enough to be very usable. It's a Magnavox rebrand, but I'm not sure who made it. I think the important thing with VCR compatibility is the quality of the RF test point circuit, and to ensure the signal is amplified before it goes to the TP301 test point. Looking into this, it appears the same main board might be used for the VR620 and the VR550. There's also a VR620CAT99 that looks identical for anyone wanting to scour eBay. Not only that but these things are also really easy to open and tap with 3 screws for the top cover. I'm also suspecting the test point is already AC coupled.

[oln]

Interesting. The mech in the picture looks a lot like the Funai ones (Most of the 2000s NTSC Philips decks are fuinais I think, a few look like JVCs inside, in europe they also had their own "turbo drive"/"apollo mechanism" models, and older philips decks can also be rebadges of other stuff). They also used confusing naming, there is are PAL VR620/xx that's are different, one with JVC innards and several with philips own stuff. These late model decks had compacted most of the video stuff into one chip, so they could probably do things a bit cleaner than an older deck full of stuff on different boards. Many of the late model decks use the same all-in-one Sanyo ICs.

Also, for people in PAL regions, you wanna avoid the philips turbo drive/apollo decks for rf capture as they lack an easily accessible test point for rf out, they use a rf envelope strength test point for adjustment isntead. (The ones with innards like this, a few also have hitachi badging though hitachi have their own models too which are totally different.., philips slapped the turbo drive badge on their models regardless of the insides.)

[VideoMem]

I made some adjusts, it needs more, but sharing here the intermediate results.
Added a moving average sync clamping, it stabilizes the image brightness (but needs some tweaks as sharper picture is darker).

In previous deemph + EQ implementation -> new deemph + EQ order





After FFMPEG:

Sharpness 0


Sharpness 100 (+ some gamma adjust)


Sharpness 50 (+ double chroma gain + denoise + brightness and contrast tweak)


This is the clip on YT: https://youtu.be/FTEgaEHuHk0
It has macroblock destruction compression artifacts, not present in the original.

Yes, there is overshoot and ringing, but it is closer to the previous deemphasis + EQ code (the previous one also have overshoot and ringing)

If someone want to test it. It is here: https://github.com/videomem/ld-decode/tree/vhs_decode
I added the --sharpness command line parameter, it goes from 0 to 100, the default is 100.

I calibrated it with the PAL multiburst sample Zcooger posted.
As this sample is NTSC, and the reading speed for NTSC is faster, it might be useful to have a NTSC multiburst to compare with.

Can someone make a multiburst chart test recording on a blank tape in NTSC, and capture it back?
Only a couple of seconds needed.

Thanks in advance!

[Titan_91]

The adjustments look amazing so far! Give me a day or two and I'll record and capture an NTSC multiburst pattern on the same VCR (anyone can do this but the same machine would isolate other variables). I will record and play back on this Philips VCR. For SNR, can I re-use my tape for the test patterns I had originally? Or would it be ideal to have a factory blank tape?

[VideoMem]

Thank you!

Yes, you can reuse the tapes. If they don't have excessive dropouts, they're just fine.
And using the same machine at the same tape speed as the prerecorded ones would be great to isolate variables and to match the EQ with the machine.

I'll wait for it, there is no hurry.
There are a lot to optimize in the meantime.

[Titan_91]

Before I do that, here's another capture replacing the long RCA cable with the short 1ft coax. SNR is still 40dB, vertical hum bars are still there. Need to check for the chroma splotches as well.

[oln]

I think I've fixed some of the random chroma splotches or whatever you wanna call them you can see on the previous screens by increasing the overlap between blocks as there was a bit of distortion on the edges which made it through.

[Titan_91]

Oh nice, I thought it was my capture. Can you explain what was wrong in more detail? I looked at the spectrum for the RCA vs 1ft cable captures. The RCA cable introduced a higher noise floor, so a shorter matched cable is definitely an improvement. I get about 3dB higher signal level using the 1ft coax cable going between the VCR and Asus Blackbird card.

Long 75Ω RCA cable:



Short 1ft 50Ω RG316 coax cable: