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

[Titan_91]

Hum bars eliminated! I connected the VCR and PC grounds together. Then, my loading mechanism decided to stop working. There is a little plastic piece that gets pushed up by another armature to open the casette door when unloading. That somehow got jammed on the door itself and I had to take the front faceplate off to fix it. It's now working again, otherwise I'd have to spend $50 on eBay for a replacement machine.

I'll get a multiburst test uploaded tomorrow.

[Placeholder II]

Hi,
I am a newbie here.

Long 75Ω RCA cable:



Short 1ft 50Ω RG316 coax cable:

The wave impendance of the cable should match the output impendance of your vcr and the input impendance of your capturing device, otherwise you’ll encounter problems.
We are in high frequency domain, so the signal behaves like a wave and when the impendances don’t match, the signal is reflected at the connections.
Depending on the cables length, this reflection can attenuate the signal or even cancel it entirely.

[Cornucopia]

Since your setup is akin to audio capture, and you have just witnessed that grounding issues may have factored into less than optimal results, I suggest it might be a good idea to consider using conditioned power on the capture chain.


Scott

[Titan_91]

Good advice. I have a spare battery backup/UPS I can try. In the meantime here is my multiburst test. Fair warning, this VCR is absolutely awful at recording, plus my VGA to NTSC encoder board isn't great. Both of these result in high levels of chroma noise and time base errors, causing squigglies. It's not vhs-decode, as the playback looks just as bad on my PVM monitor. Besides that, based on eyeballing the multiburst pattern it looks like I'm getting all 3MHz of video bandwidth, but that 3MHz pattern is heavily attenuated.




I'm also seeing what I mentioned before, where the luma .tbc file has a chroma decoding step added to it. Is it possible to adjust the code to skip the chroma decoding step on the luma .tbc file? This may be left over from the original ld-decode code where luma and chroma decoding takes place in the same .tbc file. Currently, this generates rainbow patterns on black/white edges.

[Placeholder II]

[Attachment 57704 - Click to enlarge]
[Attachment 57705 - Click to enlarge]
What do you think of this?
It is a time lapse vcr, designed for video surveillance and ultra slow motion playback.
So it can read the same field about 60 times before stepping forward.
I thought of a sigma clipped average function to reduce the readout noise by combining the 60 separate readouts of a field.
Also the vcr has three RF test points for the video heads, I guess one for luma, chroma and HiFi audio, since the signals are recorded separately on the tape.
Thought of modifying the domesday duplicator layout for digitizing three input signals.
But that together with the slow motion playback would increase the data enormously again.

@Titan_91:
I saw you are using a ferrite core on the cable. Actually also this can cause problems in high frequency domain, when the core is overly tight around the cable it might harm its geometry and changing the wave impendance, resulting in a pass behaviour depending on the cores position on the cable and the wavelenght of the signal.

[oln]

I'm also seeing what I mentioned before, where the luma .tbc file has a chroma decoding step added to it. Is it possible to adjust the code to skip the chroma decoding step on the luma .tbc file? This may be left over from the original ld-decode code where luma and chroma decoding takes place in the same .tbc file. Currently, this generates rainbow patterns on black/white edges.

The current scripts are set to use the mono decoder on the luma file which just copies the tbc out to grayscale data, not sure if you can select that in the options in ld-analyse yet. Have not implemented a chroma killer function tho, like in vcrs, so the chroma .tbc decode will contain some residual noise that if strong enough could result in some rainbow effects. If the tape was recorded on a vcr with composite input, there may also be some residual chroma that the Y/C filter did not completely filter out at sharp borders, and there is some minor crosstalk between the luma and chroma signal on the tape itself. There is probably a lot of tweaking and improvement that could be done still tho to reduce artifacts a little.

[dellsam34]

Hi,
I am a newbie here.

Welcome on board.
I think the time laps VCR's have short field tracks since they scan the tape at stand still position, They cannot be used for reading regular VHS tapes. If your intent is to recover CCTV footage then it should have a special software that can analyse and compare the frames for higher details output, This is not what this project is for.

[Placeholder II]

Hi,
I am a newbie here.

Welcome on board.
I think the time laps VCR's have short field tracks since they scan the tape at stand still position, They cannot be used for reading regular VHS tapes. If your intent is to recover CCTV footage then it should have a special software that can analyse and compare the frames for higher details output, This is not what this project is for.

Well, this specific time lapse vcr can playback standard ntsc and pal vhs and s-vhs tapes in ultra slow motion.
But if there is no interest in my contribution to this project (electrical engineer working as developer of media preservation technology for quality management and restoration), then I would go my own way and develop something solely for me (and maybe my employer, but he is not sure if there is a market for it).

[Zcooger]

This is exactly what this project is for. I even thinked yesterday about extra playback features of video cassette decks that could help in deep scanning the worst parts of the tapes including these with destroyed control tracks or jumping playback. There are no automation scripts for this specific task currently.
you would need to stack these frames manually. I tested my cheap combo VCR with backward playback, still and frame by frame preview. Decoded frames are a bit misaligned but partly usable.
However already exists cheap capture solution that can save tape from progressing deterioration so software may only improve at this point.

[dellsam34]

Well, this specific time lapse vcr can playback standard ntsc and pal vhs and s-vhs tapes in ultra slow motion.
But if there is no interest in my contribution to this project (electrical engineer working as developer of media preservation technology for quality management and restoration), then I would go my own way and develop something solely for me (and maybe my employer, but he is not sure if there is a market for it).

This a public forum, Any help or contribution is always appreciated, There is always interest in getting this project moving forward, You can work on both the time laps and normal VHS decode, Getting a VCR is not that hard especially here in the US where you can get one from any thrift store for few bucks.

[VideoMem]

I think there is no specific scope limitation of this project for analog recorded RF signals.

If it is RF, and it is on tape, then this is the place.

Optical media, and capacitive media are welcome too.
The ld-decode part is more mature at this stage, but vhs-decode is on the flow right now. (VHS is the more popular format, but it currently decodes UMATIC too)
There might be 2 inch Quad in the near future too.

And yes, there is no commercial interest at all, any collaboration is appreciated.

You're welcome.

[ downloading the multiburst to adjust the Video EQ for NTSC ]

[Titan_91]

Welcome to the thread! I plugged one of those "dirty electricity" meters in to my battery backup and found it does not condition or smooth the power at all. Even when it's inverting (running on batteries) it puts out a dirty modified sine wave. Oh well.

[dellsam34]

If it uses a PWM scheme it is not good, Get a true sinewave inverter.

[Titan_91]

I tested again with the ferrite core removed from my tap cable. The spectrum plot may look a bit better noise wise, but I see no difference using the line scope and SNR is still about 36dB. This capture crashed vhs-decode, so I attached that to this post if anyone wants to replicate it and find out what caused the Python traceback. I was able to use Ctrl+C to break out of this and go into the dropout detection phase, where it found the JSON file was corrupted/incomplete so not all frames were processed in the final output. The output stops at about 500 frames, in the middle of the blue multiburst. However, about 800 frames are present in the TBC file(s) so the script may have crashed when the RF envelope ended. This recorded signal cuts off and the previous RF envelope on the tape slowly fades back in.

On the subject of time lapse VCRs, I have a time lapse tape of security cameras switched in sequence. This doesn't decode, and the waveform of the capture shows wildly fluctuating amplitude, like the tracking is way off. Not a flat envelope like there should be. Some of the vertical sync pulses are missing as a result. When played back on my monitor, it doesn't sync either. So I don't know of a way to capture time lapse videos of security footage without using a time lapse VCR. I'm pretty sure conventional capture methods would not work either.

I also thought about the VHS equivalent of "disc stacking" which involves scanning the same field more than once to composite the image to minimize dropouts and noise. The problem I'm seeing with that though is one, barring storage space and capture time issues, is the lines are doubled which halves the number of horizontal lines. Also, SNR goes way down for me when I pause the tape while capturing.

Check out this video too:

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

[nogginvid]

What's the purpose of CVBS capture? Isn't that what a conventional capture card does anyway?

I'm personally very interested in a CVBS decoder - there are a number of VTR formats (2" Quad, 1" C-format and B-format, D2 and D3 digital composite etc.) that would hugely benefit from software PAL Transform decoding, but that may not need RF capture. If there were a route to capture 4fsc 8-bit composite (which is the standard used by D2 and D3 VTRs on-tape and for digital I/O) that would be very useful indeed.

4fsc = ~17.72MHz for PAL and 14.32 for NTSC. PAL is non-orthogonal (i.e. there are not an exact number of samples each line because of the 8-field PAL sequence), NTSC is orthogonal. AIUI the ld-decode family use 4fsc (there is an orthogonal and non-orthogonal option in Transform as ld-decode may use non-orthogonal PAL still)

[Brad]

@Titan_91 (and anyone else, if they know): what can I do to improve upon my Spider-Man RF capture? If you remember that file I posted way back.


I see this project has come a long way in the past year since I last logged in. Cheers for all who contributed!

[Titan_91]

Welcome back! For your VCR I would first make sure you have a thick ground wire connected between the VCR and your capture PC. I backed out a screw on my tape mechanism and another screw on the power supply on my PC. Then bent the wire in a hook shape and tightened the screws back down over the wires. Same way you would wire a new power outlet or light switch. The wire I used is nearly the same gauge as house wiring, slightly thinner.

I would also make sure you have proper 50Ω coaxial cable designed for RF going to your VCR's test point, and a 50Ω BNC connector on the VCR. Then another 50Ω coax cable, about a foot or two long at most, going between the VCR and capture card. I used an s-video to BNC adapter pigtail to connect this coax cable to my card. Not the absolute best way to deliver the signal, but it's all have and I'm done with modifying/destroying capture cards. My results peaked at 42dB SNR on one occasion, which I am extremely happy with. There's always a better way to do something, but if you don't draw the line somewhere you will never finish or achieve any results.

If you go back a page, there's a photo of how I wired in my VCR.

[dellsam34]

What's the purpose of CVBS capture? Isn't that what a conventional capture card does anyway?

I'm personally very interested in a CVBS decoder - there are a number of VTR formats (2" Quad, 1" C-format and B-format, D2 and D3 digital composite etc.) that would hugely benefit from software PAL Transform decoding, but that may not need RF capture. If there were a route to capture 4fsc 8-bit composite (which is the standard used by D2 and D3 VTRs on-tape and for digital I/O) that would be very useful indeed.

An Ensemble Designs BrightEye 26 or 25 with built in digital TBC, a composite to SDI converter (Exactly D1 standard) gets you a better results than the current composite capture. You do need a SDI interface in your computer to save the AVI stream to hard drive, The USB on the back of the unit is just for GUI control and firmware updates.

[Titan_91]

What's the purpose of CVBS capture? Isn't that what a conventional capture card does anyway?

I'm personally very interested in a CVBS decoder - there are a number of VTR formats (2" Quad, 1" C-format and B-format, D2 and D3 digital composite etc.) that would hugely benefit from software PAL Transform decoding, but that may not need RF capture. If there were a route to capture 4fsc 8-bit composite (which is the standard used by D2 and D3 VTRs on-tape and for digital I/O) that would be very useful indeed.

Yeah the possibilities would be endless. You can get composite out of just about any playback equipment for any standard definition format. I added an issue to the ld-decode GitHub page, but I don't think Chad/Simon will consider it. Their focus is much more narrow, which is LaserDisc preservation. I only added that issue/feature request since most of the code to convert a baseband signal to an image is already there. ld-decode just adds the needed RF demodulation steps prior to the baseband composite video decoding, as composite is what is stored on the disc prior to being FM modulated.

One or two people on here also seem to be interested. I posted some CVBS video samples a few pages back. Looks like several have at least downloaded the samples.

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

Rather than a new fork, there can be a new utility added to the current vhs-decode project named cvbs-decode. Just feed it an 8-bit 8fsc sampled signal as an input and the rest of the process remains mostly the same as it is now, with a single resulting TBC file as the signal contains both luma and chroma. Not to mention getting a dump of an Ampex D2 digitally sampled composite signal. If analog composite was the gold standard, software decoding a perfectly preserved digital composite signal should be the platinum standard. That would allow for true broadcast quality acquisition at full bandwidth. All that would take is an FPGA with a USB board (USB 2.0 would probably work) to latch onto the digital signal coming out of the D2 machine and dump the raw samples to disk. Would be really fascinating to be able to analyze some D2 sources.

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

[nogginvid]

What's the purpose of CVBS capture? Isn't that what a conventional capture card does anyway?

I'm personally very interested in a CVBS decoder - there are a number of VTR formats (2" Quad, 1" C-format and B-format, D2 and D3 digital composite etc.) that would hugely benefit from software PAL Transform decoding, but that may not need RF capture. If there were a route to capture 4fsc 8-bit composite (which is the standard used by D2 and D3 VTRs on-tape and for digital I/O) that would be very useful indeed.

An Ensemble Designs BrightEye 26 or 25 with built in digital TBC, a composite to SDI converter (Exactly D1 standard) gets you a better results than the current composite capture. You do need a SDI interface in your computer to save the AVI stream to hard drive, The USB on the back of the unit is just for GUI control and firmware updates.

Does that Bright Eye solution have PAL Transform decoding implemented in it? Having seen how well the software version of Transform compares with the Hardware implementation at the BBC - it would still be a very neat solution if we could properly implement 4fsc capture (analogue and digital) and use software decode.

Transform is near-magical in its ability to remove PAL decoding artefacts - and I've not seen any other broadcast decoder that matches it yet. (Don't get me started on how poorly performing the decoders in Black Magic kit are)

[nogginvid]

What's the purpose of CVBS capture? Isn't that what a conventional capture card does anyway?

I'm personally very interested in a CVBS decoder - there are a number of VTR formats (2" Quad, 1" C-format and B-format, D2 and D3 digital composite etc.) that would hugely benefit from software PAL Transform decoding, but that may not need RF capture. If there were a route to capture 4fsc 8-bit composite (which is the standard used by D2 and D3 VTRs on-tape and for digital I/O) that would be very useful indeed.

Yeah the possibilities would be endless. You can get composite out of just about any playback equipment for any standard definition format. I added an issue to the ld-decode GitHub page, but I don't think Chad/Simon will consider it. Their focus is much more narrow, which is LaserDisc preservation. I only added that issue/feature request since most of the code to convert a baseband signal to an image is already there. ld-decode just adds the needed RF demodulation steps prior to the baseband composite video decoding, as composite is what is stored on the disc prior to being FM modulated.

One or two people on here also seem to be interested. I posted some CVBS video samples a few pages back. Looks like several have at least downloaded the samples.

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

Rather than a new fork, there can be a new utility added to the current vhs-decode project named cvbs-decode. Just feed it an 8-bit 8fsc sampled signal as an input and the rest of the process remains mostly the same as it is now, with a single resulting TBC file as the signal contains both luma and chroma. Not to mention getting a dump of an Ampex D2 digitally sampled composite signal. If analog composite was the gold standard, software decoding a perfectly preserved digital composite signal should be the platinum standard. That would allow for true broadcast quality acquisition at full bandwidth. All that would take is an FPGA with a USB board (USB 2.0 would probably work) to latch onto the digital signal coming out of the D2 machine and dump the raw samples to disk. Would be really fascinating to be able to analyze some D2 sources.

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

For D2 read D3 if you're NBC, the BBC or NHK (Those broadcasters used Panasonic's 1/2" Digital Composite standard rather than the 3/4" Sony D2 standard - but the ECL Parallel I/O standard is the same for both - and there was an SDI path for NTSC and PAL 4fsc too - though first gen D3 machines are parallel only, and don't have embedded audio)

[dellsam34]

Does that Bright Eye solution have PAL Transform decoding implemented in it? Having seen how well the software version of Transform compares with the Hardware implementation at the BBC - it would still be a very neat solution if we could properly implement 4fsc capture (analogue and digital) and use software decode.

Transform is near-magical in its ability to remove PAL decoding artefacts - and I've not seen any other broadcast decoder that matches it yet. (Don't get me started on how poorly performing the decoders in Black Magic kit are)

I don't know what that is, but you can ask the design engineers at Ensemble Designs. All what I know is that my BE75 (a YPbPr, Y/C, CVBS version) captures better than any consumer capture device I've ever tried.

[VideoMem]

All forks are temporary, each programmer works/tests on his fork.
When a cool feature is added it gets merged to upstream, which is oyvindln/ld-decode fork and then the happycube/ld-decode upstream.

https://github.com/oyvindln/ld-decode/network/members

Some members adds features more often than others, but all cool things gets merged after it passes the tests and if there is overall consent.

There is a DBDuncan fork who is translating ld-decode to be executed on GPU for acceleration.

cvbs-decode will be a thing, but I don't want to put a deadline on that.

This is the multiburst in PAL VHS:


And this the same on NTSC:


The VideoEQ has some work to be done and there is a chroma trap missing.

This is a current 'final product' test result of the vhs-decode branch on my fork (sharpness level 60)


It was generated with this script https://github.com/VideoMem/ld-decode/blob/vhs_decode/vhsdecode/scripts/do_test_animation_mkv.sh
(NTSC, based on Zcooger scripts)

Zcooger also tested the capture setup using CVBS CCTV isolation baluns ( to break ground loops ).
The results seems to be promising, as the spectra shows less overall noise.

I'm on the luminance signal path, I don't touched the chroma yet.

Some results with the sharpness control cranked up to 100 (NTSC VHS)

[oln]

I've also been thinking about looking into cvbs-dedode after I've sorted a few things in vhs-decode, there is a fair bit of overlap.

[Titan_91]

Thanks for the feedback on the composite idea. Imagine taking something like a CED disc and software decoding that via composite. Applications like that where the players are either extremely fragile now or are so hard to find it would be unwise to try and RF tap them directly. The really nice thing overall though is the CX cards are engineered and designed to handle composite video as an input, improving the use cases for these cards.

A/V output jacks can be added to the RCA SFT100, SGT075, SGT100, SGT101, SJT090, SJT100, SJT101, SKT090, SKT100, and Zenith VP2000, which, if well shielded, will markedly improve the quality of the audio and video sent to the television monitor itself equipped with separate A/V input jacks. All other CED player models came from the manufacturer with separate A/V jacks already installed. RCA provided audio and composite video test points on the signal processing board to which a set of external A/V jacks can be connected with a length of shielded wire.

[Titan_91]

I'm having an issue building this on my main Linux Mint 20 PC, using the instructions that worked on my Linux Mint 20 capture PC. This is using a new pull from this week's repository. Here is what I see in the terminal:

https://pastebin.com/VcqZFKzQ

[oln]

Looks like you may be missing the

libavutil-dev

package. I don't know when ld-ldf-reader that uses it was added, maybe they forgot to point out that a dependency was added.

It's also complaining about the git command missing, so you may want to install that. It's the most convenient way to keep up to date anyhow, if you're just using it to pull updates it should be very simple to use.

[Titan_91]

I resolved the issues, forgot to install the prerequisite packages on the ld-decode wiki. All working now. Something I did notice, vhs-decode seems to default to 4 threads no matter what I specify for -t. On my 8 core 16 thread Ryzen CPU usage is only 40%, with the same decoding speed using -t 4 as -t 8 or -t 16.

[VideoMem]

I think vhs-decode will be running on single thread until the processing pipeline goes stable. (it currently ignores the thread parameter)
However you can decode various different captures in parallel to make use of all CPU cores.

[Titan_91]

Ok. Not a big deal really, I can do other stuff while I decode a single tape. I confirmed it does use 4 threads on my quad core capture PC.