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

[Titan_91]

I wasn't aware of that --recheck_phase flag. Is it new? The log often shows something like "rechecking phase" when it automatically tries to re-detect chroma phase. Will try this flag.

It's been around since at least the time I got back into this. (May 2021, pg.21 of this thread.) And yeah, vhs-decode will automatically recheck the chroma phase when it detects a signal discontinuity. The flag forces it to recheck on every single frame, instead, for the cases where it misses that a new recording has started on the same tape.

I would only expect this to fix "wrong colors", though. It sounds like you're instead seeing "no colors" at times?

Yeah I thought that flag was just for chroma phase (tint). Correct, it's like in my sample a couple posts back where the color is "sort of" there on the second recording, but loses sync and disappears after a couple seconds. The signal itself has good chroma in the spectrum, and the entire tape has color when monitored from the VCR's composite out port.

[Brad]

Latest experimentation. These Sony models feature an easy adjustment for head-switching point, and vhs-decode is extremely tolerant of the head-switch being crammed into VBI instead of its normal placement within the frame where it skews the bottom of the image.

Unfortunately the Hi-Fi audio is affected. I just haven't played around with this enough to try fixing it. After adjusting video head-switching, the VCR automatically switches to the adjustment for Hi-Fi audio head-switching. Ideally, an oscilloscope would be used (which I don't have).

Quick proof-of-concept test with camcorder tape; no audio


Beast Wars tape 1, with audio. Can't be bothered to fix the audio desync since I'm only demoing the look & sound, not AV sync.


The labelling of the jumper wire that you need to short to ground varies from model to model, but so far seems to be in the same position on the board for all of the Sony's we are using.

SLV-778HF


SLV-779HF

[Titan_91]

Good stuff! I ran into the head switch thing when decoding TV Teddy voice audio. My Sony machine's head switch is low enough that it doesn't impact the audio. But another machine of mine that I tapped switches a few lines higher, causing issues with the decoded TV Teddy audio. To be clear, this is not HiFi audio and it's pulled from the video signal on the tape.

[Titan_91]

So, deleting a very small number of samples where the chroma signal is not yet present (highlighted in screenshot) fixes the color loss issue. I'm guessing the PLL code for the chroma signal gets confused when there is no chroma present. When this occurs, vhs-decode skips a few fields at the beginning of the decode with the error stating it couldn't determine start of field. We can see the luma FM coming in on the spectrum view, but not the chroma. I attached the broken result vs. the good result. Maybe simulating a chroma killer circuit would fix this? So the chroma code isn't trying to demodulate a signal that's not there yet before tracking fully locks in. That would also eliminate the rainbow noise in the chroma channel in times of low amplitude.

[Titan_91]

I'm half tempted to do this 8 hour decode again with the sketchy beginning trimmed off but seems there's still a chance I could lose color between recordings even if the decode starts out good.

[oln]

So, deleting a very small number of samples where the chroma signal is not yet present (highlighted in screenshot) fixes the color loss issue

Ah, that could make sense yeah - it's probably to do with the code that tries to detect what track it's currently on - if it gets it wrong due to the start missing chroma it may not re-check. Need to add some extra checks for low chroma levels compared to luma level both for this and other purposes and maybe some more conditions for re-checking phase. Does the ```--recheck-phase``` option make any difference?

As for re-doing, you can do it in steps if there are issues, there are options for vhs-decode to skip to either approximate frame or exact sample number so you could re-start at the new recording etc

[Titan_91]

I agree and think that may be what's going on. But if the chroma phase couldn't be detected properly, wouldn't the colors just be the wrong tint vs. dropping out entirely? In the failed example (assuming you've seen it) the color is the correct tint but it's pretty noisy and unstable, then it drops out a few seconds in.

Looking at the color in ld-analyse, it comes and goes between scenes. I need to look and determine if this is always between recordings, where the RF drops out, or during "cuts" where the pause button on the camera was pressed. In that case RF may be consistent but chroma phase would likely change.

Yeah the frame start argument will be a great help. I'll have to put the video through a non linear editor anyway to sync the video and audio. Love my Sony Vegas. I tried Kdenlive and really tried to embrace it, but it's just not flexible enough. I can't even set project settings for resolution, frame rate, interlacing, etc.

[oln]

I will have a look at the sample to see if phase detection or something else.

[Titan_91]

I "captured" another CVBS test video and the final result was very flickering.
Here is the link of cxadc file: https://mega.nz/file/dpt0VChL#JdYGUy3n6blfdvDoruTekLtMGzlC_v7ap_XYg3o1GfE

Decoded with this command: cvbs-decode -A -t2 -p --system PAL --10cxadc3 cvbs_flicker.r16.vhs cvbs_flicker

What am I doing wrong? Thanks

So I took a look at this while Oln is looking at the chroma thing. I'm not seeing anything that looks like mains hum bars scolling up or down the image. But I do see what you mean with the brightness being a bit unstable. I also noticed the phase/tint in the color drifting a bit in places. These problems may just be due to time base errors in VHS. I saw something similar when testing a composite recording of an NTSC VCR, but my results were much worse.

I wouldn't worry about using cvbs-decode with VHS, as that's what vhs-decode is for. I understand if you can't or don't want to modify your VCR to tap the RF (or if the RF test point gives bad results). But I'm also seeing heavy noise and dot crawl in this sample, probably from the VCR's consumer-grade demodulation and decoding circuits. I'm guessing you are using an unmodified CX card.

[oln]

Yeah cvbs-decode hasn't recieved a lot of attention in a while, sync detection and such is pretty basic so it doesn't work all that well on e.g vhs output for now. Would probably be more actively worked on if we had a more stable method of capturing cvbs output, the cx cards have some issues where they do weird things if they detect a video signal/go above some threshold (not sure what the exact condition is.) which we haven't managed to work around.

[peppi001]

I "captured" another CVBS test video and the final result was very flickering.
Here is the link of cxadc file: https://mega.nz/file/dpt0VChL#JdYGUy3n6blfdvDoruTekLtMGzlC_v7ap_XYg3o1GfE

Decoded with this command: cvbs-decode -A -t2 -p --system PAL --10cxadc3 cvbs_flicker.r16.vhs cvbs_flicker

What am I doing wrong? Thanks

So I took a look at this while Oln is looking at the chroma thing. I'm not seeing anything that looks like mains hum bars scolling up or down the image. But I do see what you mean with the brightness being a bit unstable. I also noticed the phase/tint in the color drifting a bit in places. These problems may just be due to time base errors in VHS. I saw something similar when testing a composite recording of an NTSC VCR, but my results were much worse.

I wouldn't worry about using cvbs-decode with VHS, as that's what vhs-decode is for. I understand if you can't or don't want to modify your VCR to tap the RF (or if the RF test point gives bad results). But I'm also seeing heavy noise and dot crawl in this sample, probably from the VCR's consumer-grade demodulation and decoding circuits. I'm guessing you are using an unmodified CX card.

I've got a modified VCR for vhs-decode, but CVBS-decode has a better picture quality with this LP recorded tape.

[Titan_91]

I've got a modified VCR for vhs-decode, but CVBS-decode has a better picture quality with this LP recorded tape.

That's going to depend on the quality of the RF signal you're getting, and there are adjustments to vhs-decode that can be made to enhance the result (such as increasing the luma bandwidth slightly).

[peppi001]

The text much better on CVBS-decode method with this LP recording.
I don't know what can I adjust with vhs-decode to improve the image quality.
I prefer the vhs-decode and wait for future updates

CVBS-decode:

[Attachment 64503 - Click to enlarge]

vhs-decode:

[Attachment 64504 - Click to enlarge]

[peppi001]

This is the captured raw data for previous post:
Decode command: vhs-decode -p -t1 --10cxadc3 -cafc viva_strap_test.vhs strap_test

https://mega.nz/file/EsNVhD4L#MmaWzRuCiQndAaBLbnDdd09nfEH39lcCrHiAyzszBzo

[oln]

In the failed example (assuming you've seen it) the color is the correct tint but it's pretty noisy and unstable, then it drops out a few seconds in.

Ok, using

--recheck_phase

option seems to prevent the chroma from disappearing. I think the issue is that it detects the wrong track on the first field it decodes due to most of the frame being noise, and then doesn't re-check after. Need to add some logic to tell it to re-check next field if the detected chroma level are low and/or very similar between the two options for phase rotation used detect which track it's on.

[Titan_91]

Awesome, thanks. I was going to check again with that option enabled but you beat me to it. That will, for now, save me a lot of time not having to manually decode and splice different sections of the capture. Much appreciated.

[oln]

I added a change in latest git that makes vhs-decode re-check phase on the next field if the detected phase is very indicisive. It prevents the issue on this sample, and may or may not help in some other cases, at some point I will look at making vhs-decode monitor the chroma level between frames and compared to luma rf level to make it re-check if the chroma level is low too, though that is a bit more involved. If there are a lot of recording gaps it may still be safest to use --recheck_phase though, it shouldn't have all that much overhead.

[Titan_91]

Nice, thank you.

[Titan_91]

Yep, the --recheck_phase option definitely fixes the color issue for me.

[Titan_91]

I added vhs-decode to this fileinfo.com listing, to give the project a bit more exposure.

https://fileinfo.com/extension/tbc

[peppi001]

I "captured" another CVBS test video and the final result was very flickering.
Here is the link of cxadc file: https://mega.nz/file/dpt0VChL#JdYGUy3n6blfdvDoruTekLtMGzlC_v7ap_XYg3o1GfE

Decoded with this command: cvbs-decode -A -t2 -p --system PAL --10cxadc3 cvbs_flicker.r16.vhs cvbs_flicker

What am I doing wrong? Thanks

So I took a look at this while Oln is looking at the chroma thing. I'm not seeing anything that looks like mains hum bars scolling up or down the image. But I do see what you mean with the brightness being a bit unstable. I also noticed the phase/tint in the color drifting a bit in places. These problems may just be due to time base errors in VHS. I saw something similar when testing a composite recording of an NTSC VCR, but my results were much worse.

I wouldn't worry about using cvbs-decode with VHS, as that's what vhs-decode is for. I understand if you can't or don't want to modify your VCR to tap the RF (or if the RF test point gives bad results). But I'm also seeing heavy noise and dot crawl in this sample, probably from the VCR's consumer-grade demodulation and decoding circuits. I'm guessing you are using an unmodified CX card.

Are there any solution for fix the unstable brightness in CVBS decode?

[Titan_91]

I "captured" another CVBS test video and the final result was very flickering.
Here is the link of cxadc file: https://mega.nz/file/dpt0VChL#JdYGUy3n6blfdvDoruTekLtMGzlC_v7ap_XYg3o1GfE

Decoded with this command: cvbs-decode -A -t2 -p --system PAL --10cxadc3 cvbs_flicker.r16.vhs cvbs_flicker

What am I doing wrong? Thanks

So I took a look at this while Oln is looking at the chroma thing. I'm not seeing anything that looks like mains hum bars scolling up or down the image. But I do see what you mean with the brightness being a bit unstable. I also noticed the phase/tint in the color drifting a bit in places. These problems may just be due to time base errors in VHS. I saw something similar when testing a composite recording of an NTSC VCR, but my results were much worse.

I wouldn't worry about using cvbs-decode with VHS, as that's what vhs-decode is for. I understand if you can't or don't want to modify your VCR to tap the RF (or if the RF test point gives bad results). But I'm also seeing heavy noise and dot crawl in this sample, probably from the VCR's consumer-grade demodulation and decoding circuits. I'm guessing you are using an unmodified CX card.

Are there any solution for fix the unstable brightness in CVBS decode?

I believe that is due to the CX chip producing a floating DC offset, or doing something else odd to the captured video signal. I could see this phenomenon when doing a capture myself.

That being said though, someone has developed another driver for the Conexant chips that allows simultaneous capture using multiple cards and device files:

https://gitlab.com/jorgem-dev/cx88_sdr

This has been tested successfully with dd. I'm wondering if this driver has an effect on composite video captures?

[peppi001]

I "captured" another CVBS test video and the final result was very flickering.
Here is the link of cxadc file: https://mega.nz/file/dpt0VChL#JdYGUy3n6blfdvDoruTekLtMGzlC_v7ap_XYg3o1GfE

Decoded with this command: cvbs-decode -A -t2 -p --system PAL --10cxadc3 cvbs_flicker.r16.vhs cvbs_flicker

What am I doing wrong? Thanks

So I took a look at this while Oln is looking at the chroma thing. I'm not seeing anything that looks like mains hum bars scolling up or down the image. But I do see what you mean with the brightness being a bit unstable. I also noticed the phase/tint in the color drifting a bit in places. These problems may just be due to time base errors in VHS. I saw something similar when testing a composite recording of an NTSC VCR, but my results were much worse.

I wouldn't worry about using cvbs-decode with VHS, as that's what vhs-decode is for. I understand if you can't or don't want to modify your VCR to tap the RF (or if the RF test point gives bad results). But I'm also seeing heavy noise and dot crawl in this sample, probably from the VCR's consumer-grade demodulation and decoding circuits. I'm guessing you are using an unmodified CX card.

Are there any solution for fix the unstable brightness in CVBS decode?

I believe that is due to the CX chip producing a floating DC offset, or doing something else odd to the captured video signal. I could see this phenomenon when doing a capture myself.

That being said though, someone has developed another driver for the Conexant chips that allows simultaneous capture using multiple cards and device files:

https://gitlab.com/jorgem-dev/cx88_sdr

This has been tested successfully with dd. I'm wondering if this driver has an effect on composite video captures?

This might be a driver error?

[Titan_91]

It's strange, it's been suggested to be a DC clamping issue. Also dropped samples at high amplitudes, but I haven't reproduced the dropped samples issue.

Could the DC clamping to stabilize the captured composite signal be done in software on the cvbs-decode side?

[Titan_91]

I connected my PC to my PVM monitor and played back some of my samples. Even with using composite, the picture quality really does stand out compared to any normal VCR. I'm using a GBS-8100 scalar board connected to my PC with resolution set to 640x480 60Hz. I had to turn off the flicker filter on the scalar board to prevent blurring the scanlines together. Then I simply used VLC to load a file that has been cropped vertically to 480 pixels with resize fit to window turned off. This way the scanlines of the video line up perfectly with the interlaced field scanning of the monitor, both in full screen and window mode.

Nothing beats that true CRT smoothness. It looks like I'm playing the tape back on a really high-end S-VHS machine, maybe even U-Matic. Here's a couple slow motion videos from my phone demonstrating proper CRT scanning. One of them shows the video paused between two fields of a scene transition. This single frame contains a field from one scene and a field from another scanning repeatedly.

[Titan_91]

I'm giving VLC the stink eye right now. It has a well known design flaw, bug, whatever you want to call it. After about 15 seconds of playback it starts dropping frames. Completely kills the fluid CRT effect. I'm sure I can find the cause and if I do I will share the solution, for anyone wanting to try what I've explained above.

[Titan_91]

The cause of the stuttering wasn't VLC, it was actually Windows. I tried both with Nvidia drivers and with the onboard graphics using Intel drivers. Same exact phenomenon with VLC and Media Player Classic, regardless of settings in both programs. I tried everything but something about the NT kernel, maybe thread scheduling, is screwing it up.

I then tried this with my trusty Linux Mint laptop. Here's a tip, if you're using X as your window server you can install ARandR to easily manage your xrandr screen modes and resolutions. I used this to set my VGA output to 640x480 60Hz. The Linux kernel and Noveau drivers with Intel HD graphics handle this beautifully. No stuttering at all and VLC just keeps going like I'm actually playing a real tape, but far better. Fantastic!

Getting photos of CRTs is really tricky. This looks much better in person.

[peppi001]

I think this is the problem with the sample that I posted earlier for cvbs-decode.


[Attachment 64827 - Click to enlarge]

Maybe some filter can help to remove this. What do You think?

[Zcooger]

Audacity has filter called "repair". Up to 128 samples it can smooth out "pops" and "clicks" in the waveform domain.

[peppi001]

Audacity has filter called "repair". Up to 128 samples it can smooth out "pops" and "clicks" in the waveform domain.

[Attachment 64828 - Click to enlarge]

Cannot remove from the entire waveform