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

[dellsam34]

No, tape preamps are specific to a tape formulation, speed and magnetic layer thickness, You can't just put an audio cassette pre-amp and call it a day although it will produce sound but it will be off spec, Read about tape equalization and frequency response it's a fun subject.

[oln]

True to an extent, though if you are only gonna use it for playback and not recording, it might be a bit simpler since you don't have to worry about biasing (which is going to be quite tape formulation specific and probably differs a fair bit between audio tapes and vhs ones.)

[dellsam34]

Even playback, frequency response is crucial, especially for a low quality track like the linear one, The high frequencies above 10KHz will suffer the most from wrong equalization.

[Titan_91]

There is some work being done in an attempt to take the luma and chroma TBC files and spit them through a pair of Fresco Logic FL2000 chips on common USB to VGA adapter dongles. These can be put in a raw sample stream mode at well over 100MSPS over USB 3.0, and up to 14MSPS over USB 2.0. The file playback software will show a warning if the sample rate doesn't match the next closest rate the DAC can send out. In that case the source TBC file(s) will need to be resample first to get the correct payback rate.

https://osmocom.org/projects/osmo-fl2k/wiki

Result so far:

https://www.youtube.com/watch?v=qqIP6tCmqww

The core issues are the use of TCP/IP to send two unsynchronized data streams, and the fact that two dongles with imperfectly synced clocks are used. The ideal solution for s-video would be to use the additional channels on the same dongle as they are crystal locked. Or just use a combined composite signal file and send that out over a single channel.

[dellsam34]

Do you mind asking what's the purpose of this?

[Titan_91]

Not sure what you mean. It's a possible inexpensive DAC solution at very high sample rates.

Edit: Update! vrunk11 got it working using multi channel output!

haha im so proud off me i edited the fl2K_file program and now i can chose 1 file per RGB chanel @9954tony @.Zcooger (making BUSINESS) @Stephen_Neal 🥳
this is with s-video and 2 tbc file chroma + luma

[Titan_91]

Harry requested an initial list of parameters that may improve picture quality. For future reference here are my NTSC adjustments:

1. Set RFParams_NTSC_VHS["video_bpf_low"] = 1500000 in vhs.py
2. Set rfparams["deemph_gain"] = 12 in vhs.py
3. Set rfparams["deemph_mid"] = 280000 in vhs.py (I have not confirmed this)
4. Disable double band pass filtering to improve sharpness slightly by commenting out the following lines in process.py:

if self.options.double_lpf:
            # Double up the lpf to possibly closer emulate
            # lpf in vcr. May add to other formats too later or
            # make more configurable.
            self.Filters["FVideo"] *= filter_video_lpf

[Titan_91]

In contrast, ltewreed did some similar adjustments for PAL tapes to improve teletext decoding. As a result this also improved sharpness and reduces smearing a bit. Harry is documenting these parameters as well as the NTSC parameters above.

rfparams["deemph_mid"] = 210000
RFParams_PAL_VHS["video_bpf_low"] = 1400000
RFParams_PAL_VHS["video_hpf_extra"] = 1120000
RFParams_PAL_VHS["video_lpf_freq"] = 4500000

[Titan_91]

Documenting how to use fl2k_file2 as of October 20, 2022:

GitHub page: https://github.com/vrunk11/fl2k_2

Compiling

In order to compile and install the code, you first need to install the libusb headers if not already present:

On distributions based on debian

sudo apt-get install libusb-1.0-0-dev

Then you can continue with:

git clone https://gitea.osmocom.org/sdr/osmo-fl2k
mkdir osmo-fl2k/build
cd osmo-fl2k/build
cmake ../ -DINSTALL_UDEV_RULES=ON
make -j 3
sudo make install
sudo ldconfig

Before being able to use the device as a non-root user, the udev rules need to be reloaded:

sudo udevadm control -R
sudo udevadm trigger

Usage:

[-d device_index (default: 0)]
	[-s samplerate (default: 100 MS/s) you can write(ntsc)]
	[-u Set sample type to unsigned]
	[-R filename (use '-' to read from stdin)
	[-G filename (use '-' to read from stdin)
	[-G filename (use '-' to read from stdin)
	[-R16 (convert bits 16 to 8)
	[-G16 (convert bits 16 to 8)
	[-B16 (convert bits 16 to 8)
	[-tbcR interpret R as tbc file
	[-tbcG interpret G as tbc file
	[-tbcB interpret B as tbc file

so if you whant to play a file on the red chanel you do -R files -G for green and -B for blue
for the samplerate you can do -s ntsc or -s pal
and then if you want to do tbc playback you need to do the 16 to 8 bit conversion with -R16 for red -G16 for green -B16 for blue and you also need to use -tbcR or -tbcG or -tbcB for remove the extra line on each frame

Example command line to play a single TBC file out the red channel:

./fl2k_file2 -u -R16 -s ntsc -tbcR -R example.tbc

And to play luma out the red channel and chroma out the green channel for s-video:

./fl2k_file2 -u -R16 -s ntsc -tbcR -R example.tbc -G16 -tbcG -G example_chroma.tbc

You should see this:

Allocating 6 zero-copy buffers
libusb: error [op_dev_mem_alloc] alloc dev mem failed errno 12
Failed to allocate zero-copy buffer for transfer 4
Please increase your allowed usbfs buffer size with the following command:
echo 0 > /sys/module/usbcore/parameters/usbfs_memory_mb
Falling back to buffers in userspace
Requested sample rate 14318181 not possible, using 14318170.000000, error is -11.000000

When the end of the file is reached:

(RED) : Nothing more to read

Also, to enable USB zerocopy for better I/O stability and reduced CPU usage:

echo 0 > /sys/module/usbcore/parameters/usbfs_memory_mb

And reboot. This was added to the kernel back in 2014. The default buffer size is 16.

https://lkml.org/lkml/2014/7/2/377

[Titan_91]

9954tony also made a GNU Radio flow graph that does single channel playback:

https://github.com/tandersn/GNRC-Flowgraphs/tree/main/tbc_via_fl2k

[Titan_91]

Vrunk11 has now added support for combining luma and chroma TBC files from vhs-decode on playback:

yes you basicaly put -R2 -G2 -B2 to set the second file to combine with the first one

Example:

./fl2k_file2 -u -R16 -s ntsc -tbcR -R example.tbc -R2 example_chroma.tbc

[Titan_91]

Another development on crosshatching: Rockstar743 on Discord may have a lead (literally). He was initially using an oscilliscope lead to test his capture setup which, when measured at DC, has 350 ohms of resistance between the probe tip and BNC connection for the scope. When using this, it would resolve an issue with white fishes on the left side of the image he was getting when using a direct coax connection to the test point of his VCR. And the other thing that disappeared when using the probe lead was the crosshatching. It is now of the belief that crosshatching may be caused by heavy loading of the test point (low resistance/impedance).

I have not personally tested placing a resistor in series to the signal. I'm pretty sure I could not get away with that without an external amp (which I have had bad luck with).

[Titan_91]

Others have made progress on closed captioning decoding, porting the CXADC driver to more types of Conexant cards, and isolating the crosshatch diamond pattern that often appears in areas of strong color. Tony has made a GNU Radio flow graph to simulate this effect.

I made a graph that produces a pattern similar to the VHS crosshatch on NTSC. What one might deduce from this, is open for consideration. Possibly a discrepancy between the color frequency between odd / even heads?

the apparent rotation is just the interplay between the frequency and the display rate. The lower frequency causes diagonal lines in one direction, and the higher frequency in the other. here's a picture of the fields NOT interlaced:

50 ohm resistor right after the jhooks compared to none. I can still see faint crosshatch in the left one, but probably only when in comparison (i.e. if i just looked at the 50 ohm frame independently, it might not be as apparent).

Following this, Oln seems to have nailed a way to filter it out via phase cancellation, an effect I discovered on my own with drfsupercenter's Spider-Man capture:

hm, a 1h y comb filter does seem to help on this sample at least (didn't help too much when I tried on a PAL a bit back but could have done something wrong not sure)

Tony then adds:

Hmm, this adding a resistor might be a red herring. There are several other problems with my resistor added capture:
A) Detail is lost, look at the hair on the left side of her head, more detail in the non resistor capture
B) Lower SNR
C) More eradic SNR

And Oln goes on to clarify:

It's just averaging each line with half of the signal 1 line forward and half of the signal 1 line backwards, (and before averaging the difference is clipped to not blend too much)
Yeah 1x line frequency

added it earlier for testing if it helped with (what I think is) luma track crosstalk on a EP sample. In LP/EP mode and in some other formats the luma frequency is offset slightly on each alternate track, which supposedly makes signal read from adjacent tracks cancel itself out if a y comb filter is used. It's discussed in one of those technical docs

[Titan_91]

Adam_T is also working on and has tested capturing video and Hi-Fi via 2 Conexant cards using the CX88 driver!

[Titan_91]

Oln has officially implemented the y comb filter. Use option - - y_comb to enable it when decoding tape RF.

I added a command line option for it in the latest commit. Don't want to put it too high as it can smear vertical detail a bit. Not sure if it's the optimal way of dealing with the crosshatching either but the function is needed for slow speed recordings in any case
also since it's on the tbced signal anyhow it would be possible to add it on the ld-chroma-decoder side instead which would make it easy to dial it in with ld-analyse

it just blends each line with the one above and below really (with the difference between them limited to the specified value), it's not very sofisticated