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

[oln]

It's supposed to respect the

-t

argument. What it does specifically is give blocks to demodulate things to worker threads. I don't think the rest of the python code that involves dropout detection (and in vhs-decode chroma upconversion) is threaded in either vhs-decode or ld-decode, so it's possible it may be hitting some limits while waiting for stuff to be processed.

[Titan_91]

Good point, as I am doing dropout detection on this decode. At this rate it will take me between 2.5 and 3.5 hours to decode a ~35 minute tape. Not terrible to start off with, it's doable. Also, something odd (shocking, I know). The black SNR graph in ld-analyse as of today on my main PC now reads 46dB as opposed to 40dB on my capture PC. The sample capture is exactly the same. The only tweak I did was to increase the chroma gain by 1.9X in the NTSC script that builds the MKV file, which I did on both PCs. Did something change with the filtering in the last two weeks to drastically improve SNR? The capture PC has that older version from a couple of weeks ago. That's the only difference I am aware of.

[oln]

There are probably a fair number of optimizations that could be done in the code beyond threading, it just hasn't been a big focus yet, but it will probably be improved eventually.

I don't think ld-chroma-decoder supports adjusting the viable output right now, though .tbc files are simply unsigned litte-endian 16-bit grayscale data, so if you don't need to decode color it's possible to read them directly with ffmpeg or similar with the right parameters.

[Titan_91]

When I import a TBC file in to Audacity as 16 bit raw data I often get clipping/rolled over samples. Is the data big endian or little endian?

[Zcooger]

Audacity cannot read unsigned 16 bit data but signed only. The best way to open it is to compress it with flac encoder first or use VirtualDub2 build 44282 to display as image and select raw video type (grayscale 0-65535). Correct dimensions can be found in .json file.

[Titan_91]

Cool, thank you. Turns out the information in the HBI is in fact not cut off when I do the decode. So that saves a lot of steps. If anyone here wants to work with me on a simple Python script to decode audio from grayscale values, let me know. I'm preserving some special TV Teddy videos. Audio is encoded as a vertical bar on a line by line basis. All that would be needed is to have a buffer to store 8 bit brightness values to a WAV file by reading a specific set of lines from each field. The center would be 127 for gray, representing zero amplitude in the WAV file. I can't code Python, or anything else, but can provide detailed information on the technology used.

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

[nogginvid]

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.

I guess as long as you can sample the composite video WITHOUT it going through a PAL/NTSC/SECAM decoder and end up with 4fsc or 8fsc (the latter possibly better if you can't subcarrier lock your sampling) digitised composite video then that will be very useful.

I think subcarrier locked sampling is unlikely to be that simple though - as to do so would require a feedback loop between the ADC and some kind of subcarrier and sync detection software running at the time of sampling (not post sampling)

Broadcast 4fsc gear uses precisely subcarrier phase locked sampling (particularly for PAL as you can go over the valid video range of the 4fsc digital sampling standards if you sample at the wrong phase on very bright saturated yellow...)

[Titan_91]

I made a really weird and interesting discovery. I determined my monitor produced electromagnetic fields when it started making faint tones depending on what was displayed on screen. I took a telephone pickup coil and plugged it into my voice recorder. I then played back this test video in full screen and could hear the music. I had known about the Tempest EMF spying project using monitors before.

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

So it dawned on me, why not try a Tempest Teddy decode as a quick and dirty test to recover the voice? I found a YouTube video where the TV Teddy audio bar is visible. Then cropped this down and scaled the bar all the way across and put it in full screen. Then played it back and recorded the EMF. TV Teddy can be heard! What witchcraft is this?!

[dellsam34]

Could be picking up the HiFi track from the tape deep layer??

[Titan_91]

TV Teddy videos work differently. I intentionally took the waveform part of the image and stretched it out to full screen. What was surprising is I could hear the ghost of Kath Soucie through EMF noise coming off my monitor, with the right pickup tools to convert that magnetic field back to sound.

[nogginvid]

TV Teddy videos work differently. I intentionally took the waveform part of the image and stretched it out to full screen. What was surprising is I could hear the ghost of Kath Soucie through EMF noise coming off my monitor, with the right pickup tools to convert that magnetic field back to sound.

I wonder if the TV Teddy stuff is a basic PWM style audio encoding using bars at the beginning of lines that the decoder picked up, used PWM to convert to audio, and then radiate on a spare unlicensed RF channel to the toy?

If stretching the bars generates PWM-modulated RF energy then that might explain why you get audio ?

[Titan_91]

Yep that's how it works. According to the patent the transmitter uses a comparator and a 22 bit ring buffer to delay the samples between frames before transmitting the signal to the teddy toy, so there aren't gaps in the audio between fields.

[Titan_91]

Tried one of my TV Teddy videos. It seems the chroma filtering may be off for these, as there is yellow/blue color smearing I'm not seeing in my other samples. Capture is attached.

[Titan_91]

It's definitely the chroma. The luma decode looks great. I'm getting 46dB SNR for both luma and chroma (this was 40dB before, but I think something changed in the last couple of weeks to improve the SNR by 6dB).

[oln]

I haven't gotten around to look at it yet, do you have an example of how the chroma looks on that tape when played normally?



The SNR stuff is probably due to some recent adjustment to de-emphasis and RF filters which has helped improve the output a bit.

There is now basic PAL (regular band) U-Matic support, and we're working on cvbs decoding as well.

[Titan_91]

I don't have any normal capture drivers/software handy for my Linux machine but I can get a photo of my PVM monitor displaying the normal playback, as well as a CXADC CVBS waveform capture from the VCR. If you want something immediate, here's a video from YouTube. The plane is at the beginning:

https://youtube.com/watch?v=HJcnDgATxuM

[Titan_91]

I looked at the normal hardware decoded playback from my VCR. The color is terrible, it's full of noise and bleeds over the whole screen. The chroma demodulation circuits on this player are of low quality. As for the smearing in vhs-decode, know it's not the signal quality on the tapes though or the RF frontend on the VCR. The filtering I guess for these particular videos is different.

Don't worry too much about it right now, it seems to be an edge case. I'm working with someone else to decode the Teddy voice from the luma portion of the videos, which is definitely doable as-is. I'm excited to see other developments like the luma de-emphasis improvements and CVBS decoding.

[Titan_91]

I was made aware that early CVBS (composite, the "gold standard" of video) decoding support has been implemented. Honestly I didn't expect that until much later, incredible job for everyone involved! I tried the new -cvbs flag on my Wii and VCR sources, but no sync pulses are found. My samples have an inconsistent DC level that changes based on the image. I think this is caused by an AGC feature of the card, but not sure. They were also captured with level 1 gain though. I saw a screenshot of a successful CXADC decode using level 10.

[oln]

Try using

cvbs-decode

with the

-A

option. (You will need the latest version from git.)

We've moved the cvbs stuff to a separate command. the -A option tries to auto-detect the sync levels (old code worked off some assumed levels as it was working on tape/laserdisc with known levels.)

[nogginvid]

I was made aware that early CVBS (composite, the "gold standard" of video) decoding support has been implemented. Honestly I didn't expect that until much later, incredible job for everyone involved! I tried the new -cvbs flag on my Wii and VCR sources, but no sync pulses are found. My samples have an inconsistent DC level that changes based on the image. I think this is caused by an AGC feature of the card, but not sure. They were also captured with level 1 gain though. I saw a screenshot of a successful CXADC decode using level 10.

It's not AGC as such - the gain stays the same. It's more the lack of DC-coupling means the assumed DC offset seems to change as the ADC tries to centre the sampling range based on picture content by the look of it (comparing full-field white with full-field black shows it very clearly). This looks to be the standard behaviour of the ADC, with the CX chip doing clamping when it detects video (which we do our best to avoid at the moment, as it resamples and/or adds jitter for some reason)

As oln has said - the -A option that's been added now clamps black level from the back porch.

I captured the above sample using level 10 - that seems to be a good compromise between capturing a decent level range, but not triggering the CX into 'valid video' mode

[Titan_91]

I see, didn't realize that code had been moved to a new script. It works great! My test images from my Wii are a bit soft, because of the way the 240p Test Suite upscales bitmap images from 240p to 480i. That's normal and not the fault of cvbs-decode (I mean there's really no luma filtering that's needed as the data is just there from the start). I did notice the below, which is also not the script's fault. This is GPU damage to the framebuffer/video RAM that happened over 10 years ago back when the Hollywood chips in these things were overheating due to a design flaw. I had the GPU re-pasted since then and it hasn't gotten any worse on my console.



I tried the Tom & Jerry composite capture. It looks bad, because of the terrible time base errors in the signal from the VCR. This screws up the time base correction in cvbs-decode, and causes issues with phase lock in the chroma decoder. This means nothing, and I expect no fix for this, as vhs-decode achieves near perfect results as-is and using cvbs-decode on VHS is pointless.



It does have me wondering though, I have some old Hi8 camcorder cassettes I want to to capture. I have 3 options for that: digital DV conversion done by the camcorder (hardware), the normal composite/s-video capture method (hardware), and the new cvbs-decode method (software). Or, there's always finding a Hi8/Video8 deck on eBay to try and tap the RF on as well. But I have no reason to try that unless my Sony Handycam dies. What may be an advantage on using a straight DV capture through FireWire is potentially luma/chroma separation, assuming the video is stored that way on tape. If it's stored combined on tape, then no real advantage that I can see over using cvbs-decode. In fact, relying on a Digital8 DV camcorder from 1999 to perform analog to digital conversion may be an issue with decades old capacitors.

[oln]

8mm is stored on the tape in a similar way to VHS, the chroma is downconverted and stored at a frequency range below the fm-encoded luminance. 8mm squeezes in fm audio and "tracking" signals there as well (it doesn't use depth-multiplexing like VHS Hi-Fi). PCM audio is stored on the not quite edge of the tape in some way I think, though still helically scanned. (8mm has specs for two linear tracks, one audio and one cue, but that seems excessively rare if it was ever used.) So, the chroma is separate on the tape. The TBC in those late-model sony hi8 and d8 camcorders is also very solid, much more reliable than the ones in VHS VCRs.

[dellsam34]

It does have me wondering though, I have some old Hi8 camcorder cassettes I want to to capture. I have 3 options for that: digital DV conversion done by the camcorder (hardware), the normal composite/s-video capture method (hardware), and the new cvbs-decode method (software). Or, there's always finding a Hi8/Video8 deck on eBay to try and tap the RF on as well. But I have no reason to try that unless my Sony Handycam dies. What may be an advantage on using a straight DV capture through FireWire is potentially luma/chroma separation, assuming the video is stored that way on tape. If it's stored combined on tape, then no real advantage that I can see over using cvbs-decode. In fact, relying on a Digital8 DV camcorder from 1999 to perform analog to digital conversion may be an issue with decades old capacitors.

To be honest I'm not really impressed by the vhs-decode samples (except for the rock solid steady frame) let alone CVBS-decode, DV will cut the chroma in half, The only viable option left is to capture the old fashion way with a camcorder built in line TBC and S-Video out, I posted samples everywhere, this is one of my customer's de-interlaced and encoded Hi8 tapes.

[Titan_91]

Good to know, that Hi8 sample looks great. A standard S-video hardware capture would beat out CVBS-decode due to Y and C being combined with composite video. I also didn't think about color sampling limitations of the DV format. For deinterlacing, did you use Yadif to interpolate the missing lines and double the framerate or something else?

[dellsam34]

DV is 4:2:0 for PAL, 4:1:1 for NTSC, lossless AVI is 4:2:2. I used QTGMC with fast setting for de-interlacing.

[Titan_91]

I read into QTGMC. Looks great, is there a way to use it with Avidemux and AvsProxy per this article? Can you share the avs script file you used for that Hi8 sample?

http://www.avidemux.org/admWiki/doku.php?id=using:avsproxy

I won't be going off topic beyond this.

[dellsam34]

Pretty basic, no filters:
QTGMC( Preset="fast" )

[Titan_91]

I tested with my new BNC splitter and 50 ohm terminator with my modified directly tapped card with LPF capacitors removed. Using the same tape and same frame as one of my Blackbird captures, SNR increased from 39dB to 42dB. I then decoded and compared the same frame side by side. I saw no visual differences at all. I also looked at the same lines from both captures and saw no appreciable difference. I also checked the spectrograph which looks pretty much the same. The signal amplitude on the modified card is higher. Gain still set to 31, using the BNC T splitter and 50 ohm terminator.

I'm not sure where the extra 3dB of SNR came from. Likely using the modded card and proper termination. I highly doubt using 40MSPS over 28.6MSPS alone would do it. But 40MSPS instead of 28.6MSPS for VHS has no return on investment for me.

[oln]

The SNR measurement isn't going to be super accurate in any case, it just looks at how clean one of the black lines in the VBI is. I also don't think the higher sample rate would make much difference, it should already be way more than high enough to accurately sample the frequencies from a standard VHS tape.

[Titan_91]

Yeah people have made the argument that a higher sample rate results in a cleaner reproduction, but at a rate of 4 samples per cycle which we are exceeding for VHS, it's not necessary. There's plenty of bandwidth captured above the luma signal already at 28.6MSPS, which captures 14.3MHz. Also, capturing more than needed can cause unwanted high frequency signals to be sampled, which could contaminate the signals we want to capture. 4x fsc was good even even for Ampex with their D2 system, which used a 14.3MSPS rate giving you 7.15MHz of bandwidth, still plenty for the 5MHz or 6MHz frequencies that could exist in a composite video capture. That's apples to oranges of course, but it validates my argument.