I don't think there is an option in the chroma decoders for it at the moment but it should be quite simple to add. You may be able to simply grab the frames manually from the TBC file, I think it's just raw RGB48 data, will have to check the code.
+ Reply to Thread
Results 271 to 298 of 298
It's not a big deal if chroma decoding can't be turned off, it would just significantly speed up luma only decoding for further processing of things like TV Teddy audio, closed captions, and other monochrome VBI data.
Hey Zcooger and oln are we there yet?
Are we where? This is a volunteer project worked on in everyone's spare time.
Are we there where a final GUI is available for the public obviously, I know it's a volunteer basis project but I'm just looking forward to a useful outcome.
The capture app for the Domesday duplicator is a GUI, capturing from conexant cards is command-line at the moment. There isn't a gui for the decoder for the moment, it's command-line, though there's an ld-analyse app to look at individual decoded frames. A more integrated GUI for decoding and various parts is certainly doable, but it hasn't been a priority yet, focus is on improving decoding. I've been a bit busy moving lately, but I'll be back working on it more again soon.
I'm not interested in the Domesday duplicator since it doesn't work on the VCR's RF without tweaking and I don't have a laser disc player or discs.
Zcooger, was this PAL clip played back on a VCR or using vhs-decode? It looks fantastic. I wish I could help with the luma noise in the current NTSC version. At this stage there's potential to meet high end VCR playback results. If the noise can be filtered out I think we'll get there.
Examples of noise:
Last edited by Titan_91; 1st Jul 2020 at 18:15.
No, this video is not related to VHS-Decode project. It's my standard capture chain: Panasonic NV-HD630 (or NV-FS200) > Panasonic DMR-ES15 > Medion/Creatix 918 > Virtualdub2. Additionaly I use QTGMC MT deinterlacer with "placebo" preset and Neat Video Demo. It's enough for my need of TV advert ripping for now. I think some VCRs use some kind of noise suppression that we don't know.
For CXADC capture I made shortcuts for it with preview window. You must have GNU Radio installed. Just click the python scripts. They save the cxadc.r8 file in the same location where they are launched.
If you want NTSC framing for the preview - in python script change line 73 from:
self.video_sdl_sink_0 = video_sdl.sink_uc(0, 2291, 625, 0, 1135, 625)
self.video_sdl_sink_0 = video_sdl.sink_uc(0, 2275, 525, 0, 910, 525)
Last edited by Zcooger; 4th Jul 2020 at 15:49.
Today I made first attempt to decode video and HiFi audio tracks simultaneously - I briged video RF pin in the amplifier box of the Panasonic NH-HD630 and envelope test point which contains HiFi signal.
The HiFi envelope by default has too strong signal so I added small potentiometer to change the gain.
Originally Posted by WikipediaOriginally Posted by SENCORE tech tips
Last edited by Titan_91; 7th Jul 2020 at 21:06.
Can you go into detail on how you spliced in the Hi-Fi test point? I need to amplify my video signal quite a bit with a 3 stage process (VGA splitter, RCA video amp, onboard amp for the Conexant chip). Clearly I would need a simple way to attenuate the Hi-Fi RF coming from the test point. Maybe through wireless coupling using an exposed bit of the Hi-Fi line air gapped near my existing video wire? This would also prevent any RF backfeed returning to the VCR (or VGA splitter depending on where I would splice).
This is all the wiring I made to make it work:
As for the exporting itself, I asked Chad in the LDDB forum ld-decode thread if he can write a batch PNG frame export function for ld-analyse built on the current single frame export code. This should make exporting video from samples and full tapes a lot easier.
Last edited by Titan_91; 11th Sep 2020 at 14:53.
I'm working on the PAL side right now, I got automatic detection of track mostly working in the latest branch (but there's a bug with it in the latest commit EDIT: should be fixed), gonna try to fix it for NTSC next so color works properly.
You can tweak the high/low pass filter cutoff frequency in vhsdecode/formats.py. I did change the NTSC filter a little in a more recent commit, but it's not in the main branch yet, it probably needs more tweaking though. You can see if it's better + other changes in the NTSC_COLOR_BROKEN branch which is the one I've committed to recently, but as the name states, NTSC color isn't working in that branch at the moment. The edges of the rf(luma) sideband and chroma signal conflict a bit more in NTSC than PAL (as the frequency for the darkest black is lower), so it's a bit more tricky to get the filter right while avoiding patterning from the chroma signal but at the same time not impacting the luma RF too much.
Last edited by oln; 12th Sep 2020 at 11:17.
Ok cool, I'll see what I can come up with regards to luma testing on the new branch. Thanks for the advice and continued work on this.
I adjusted the low pass NTSC luma filter. This, surprisingly, made quite an improvement! Not only that, but chroma isn't fully broken in this branch. I was still able to decode several fields with correct color. I really don't know what I'm doing though. I basically just changed this in vhsdecode/formats.py:
# Band-pass filter for Video rf. # TODO: Needs tweaking RFParams_NTSC_VHS['video_bpf_low'] = 3200000
# Band-pass filter for Video rf. # TODO: Needs tweaking RFParams_NTSC_VHS['video_bpf_low'] = 2400000
And decode with my adjusted LPF:
Further examples of hidden details recovered from lowering the low pass filter cutoff, quite a difference:
Last edited by Titan_91; 11th Sep 2020 at 21:16.
Hi, I've been invited to this thread, by dellsam34 on this other thread: https://www.tapeheads.net/showthread.php?t=82905
I've been reading this entire one, and found it amazing.
First, I don't tested the software provided, and I didn't read the source code or analysed the flowgraph in GNUradio (yet).
Yesterday, I wasn't aware that this project existed at all.
For the technical observations, on the chroma decoding, I remember something related to the "color burst".
The chroma subcarrier needs to be in phase with that "color burst" signal.
It happens on every line, on every field, prior to the image and after the horizontal sync pulse (AFAIK).
Then it needs to be separated from the luma spectrum by a LC trap type response filter, or a comb filter (better results).
TBC with only the horizontal sync is a rough approximation, then a finer one could be done with the colour burst signal frequency offset.
Even for the luma part, to compensate the line compression and expansion caused by the rotary drum speed jitter.
As for the discussion between the Composite/S-Video way or the Direct RF head capture.
Both are different products, and both are needed.
One could improve the another, they're not mutual exclusive.
We have something great here, in one way we're talking about the VTR tape bandwidth, and USB3.0
The derived storage applications that could become after this is a whole new market.
What if the software could control the transport and, rewind to re-read a tape portion on which a read was dropout?
Then it cross correlates the signal to a previous read to arbitrage the better solution.
Floppy drives and old computer tapes already did that.
I'm sure the reading quality cannot be beaten once it is done.
Proper RF amplifier and a clear path for the signal to the ADC is a MUST.
I would like to add an AGC to that pipeline to ensure proper and normalized signal amplitude at the ADC.
I don't want to grandmother and eggs here at all.
I'm here for the show!
Don't let it down!
Edit: I viewed on a CuriousMarc video on Youtube, the implementation of a wideband amplifier (ECL gate) to operate in the GHz range.
He done it with discrete transistors and a LTSpice simulation.
I guess the whole "RF Testpoint" amplifier/buffer prior to the AGC can be done in that way, with the same transistors and a similar topology.
Other things to consider is the closed feedback loop, if the goal is to replace all the VTR electronic hardware with a software defined one, this must be bear in mind.
Both the linear audio and the servo control signal should be captured and synced.
And the software must output the control signals to increase/decrease the speed of the drum motor, the capstan, and to control the transport.
(At least for the player part, recording would be another adventure!)
I've been experimenting with gnuradio and the raw binary captures provided in this thread.
Here is my circuit:
Here the gnuradio .grc project: VTR RF signal conditioner.grc.zip
HEADPHONE SPEAKER WARNING! These files contain an audible representation of an arbitrary region of interest of the binary file provided in this thread.
Here the raw audio output for the archive CXADC_Zenith_XBV342_35.8MSPS_NTSC_test_captures -> blue_75%.raw of this thread.
Its input samplerate was set to 10000000*315/88.0 Hz. (35.7954 MHz)
What it does:
From the raw tape head signal, not time corrected, no jitter compensated raw ADC output:
It frequency shifts / downconverts using the samplerate / 10 as center frequency (35.7954 MHz).
The Xlating/FIR block on gnuradio does that, plus it haves a lowpass filter on the input, with a 5Mhz cutoff frequency, 200kHz transition band.
The output of the demodulator feeds into another demodulator.
I found a peak around 317Khz from the downconverted signal which shows as a jitter dance in the waterfall plot.
It may be a glitch, but it sounds wowy an fluttery as I remember from tape.
The sample rate here is 'as is' the louder one:
Here is lowering the playing speed by 0.4
If someone knows what these tones carry, please leave a comment.
It sounds like tones and chirps, it is something 317kHz over the chroma carrier.
I think the machine have many heads, that's why the patterns repeats a number of time in the short term, and seem to have a periodicity in the long term.
Last edited by VideoMem; 27th Sep 2020 at 02:32.
Welcome to the thread, and great first post! I've been participating in vhs-decode as well as its parent project, ld-decode. That sample is from my nothing special Zenith branded 4 head VHS/DVD combo machine from around 2003. It was branded under several different labels and is a typical run-of-the-mill Walmart buy. I examined that demodulated subcarrier sample you uploaded. I'm thinking it's just a leaked head switching signal, I was seeing some DC bias in my raw recording at the head switch points, resulting in a slight sawtooth shaped waveform. The phase delay you are seeing I would say is due to delay involved with multiple video heads.
Last edited by Titan_91; 26th Sep 2020 at 19:22.
I'm not sure if there would be much point to replace all the control stuff in a VCR, they main control IC typically communicates over I2C or some other serial protocol, so you could maybe put in an arduino or something to send additional instructions to it. (Newer video chips did the same for that matter so you could maybe use it to adjust things the VCR manufacturer typically didn't put in the menu, like noise reduction level and sharpness on this chip used in many late-model VCRs.)
I don't know what the signal you are finding could be, as mentioned, some late-model VCRs added the head switch signal to the rf test output providing some DC bias on alternating fields, so that may cause some oddness. On normal playback VHS VCRs will use a set of 2 heads, one for each field. On models with more video heads a set of two opposing heads are selected based on the tape speed. On fast-forward, slow etc there may be more heads used for each field, hence why you usually get some "teared" lines in fast-forward mode on a VCR with 4 video heads as the VCR is switching between them.
If you want to dive into details, I came across a nice JVC techincal document recently that describe the playback and recording process in their older VCRs. The phase/frequency correction and analog noise reduction may have improved and changed a little since that was printed, but it gives you the general idea. Some service manuals for newer units have descriptions of how the decoding works but they're not as detailed.
Sorry for the wall of text.
I think using the VCR's mechanics in the process defeats the the purpose of extracting the RF signal in the first place, Besides the project needs to move on, there is no need for adding more complexity to it, Thanks for accepting my invitation.
Can you capture the solid color samples from that tape in NTSC again, but this time shaking physically the player while playing and capturing?
It produces such regulating motor kind of sound in that band.
I would like to 'see' how physical jitter traduces to the reproduction.
It also could help us to write the de-jitter part of the signal time based conditioning.
A PLL could be implemented, the problem with gnuradio is that every time I tried to close an internal control loop from the graph itself I get an error telling me it is not possible.
A PLL is a series of three basic elements.
A block capable of outputting the phase difference between two signals like a sine and cosine generated by the same oscillator would give you a constant signal.
That output is connected to a bandpass to focus the in the error band.
And then it goes connected to a local VCO.
One of the Input signals of the phase differentiator circuit is the output of the VCO.
It forms a closed control loop which have similarities with the delta sigma ADC.
The problems I found with these circuits even in software is that they need its parameters to be very adjusted to compensate for the timing error produced by the previous machine and not to introduce new compensation artifacts.
For the CPU load balancing, I connect different graphs executed on its own thread through ZMQ sinks and sources.
At least it will produce a lot of artifacts, some of them played at certain speeds (by resampling) sound very mechanical techno to me.
I wonder if there are microphonics artifacts from the head and the tape during switching and scanning at very high speed.
[ It sounds like lo-fi laser gun effects helicopter something with a vacuum cleaner in the background ]
The marvellous of digital domain non-realtime processing could help us to cheat on the control loop by using something like a cross correlation coefficient of two time series domain signals to get the timing error?
Then it could be sample interpolated head to head switch.
I'm not really sure about this.
I already used a python script to hear the error difference between two digital audio signals with the same audible audio, one previous a signal chain (audio input of a software fm modulator), and the output of the whole chain (software fm receiver wave file on disk) but by an unknown initial lead-in delay at each wave files.
It syncs really good.
It then computes the error and transfer linearity between input and outputs.
Here something similar could be used to de-jitter the signal and dropout compensate in a further 'multi pass' recover mode.
[ NTSC have that tint control thing ]
Edit: Wow! Such wonderful response. Thanks!
I agree with not to add much complications.
The chroma part is not easy. It was not easy even for the people who designed and improved these machines.
I found this video about s-vhs interesting:
Last edited by VideoMem; 27th Sep 2020 at 04:11.
Would capturing S-VHS's luma be different from VHS? I know the chroma is the same for both standards.
SVHS moves and expands the luma frequency band so you would have to make sure you still have enough sample rate to capture it. It also involves some extra filtering and de-emphasis on the luma signal compared to normal VHS. I already managed to get an image from a SVHS-ET recording with an earlier version of vhs-decode by just adjusting the demodulator frequency band-pass and levels so at least with the domesday duplicator it should be doable. Thatwas just with deemphasis and the process for standard VHS though, so it was more akin to what you would get from a VCR with SQPB, but implementing the software equivialent of the full SVHS circuitry is certainly doable.
A VCR uses a PLL on the upconverted signal and a VCO to compensate for jitter in the chroma signal when upconverting, using the VCO to vary the frequency that is mixed wit the down-converted signal to achieve the upconverted one. This was one area playback improved a bit over the years in VCRs, with more accurate PLLs to better compensate for chroma phase issues due to jitter. This isn't implemented in vhs-decode currently, though the TBC helps compensate instead as it's run before upconversion. May look into adding this again later, but not focusing on that right now.
VideoMem, I'll try to find the tape I was doing the red and blue testing with. Once I do I'll try another capture while physically shaking the VCR at certain intervals to see if there is a connection to that subcarrier tone you're seeing.
Edit: I captured my test video again. All screens are present in the capture except for the red screen, which is the first screen on the tape. The pattern is 75% saturation red, 75% blue, and a few test patterns. My LCD TV couldn't display the red screen and I didn't start capturing until the RF signal had been stabilized enough to see the blue screen. If I don't wait for a stable RF signal CXADC (or my card) will apply an extreme DC bias to the capture which will result in clipping. Because I missed it during playback (call it a control sample), I did not shake the blue screen. For each following test pattern screen, I shook the VCR a few times, on two occasions. Once about a second into the screen, and another time several seconds later before the change to the next screen. So you should see the pattern of jitters twice for each screen. I ran this though vhs-decode and saw no effect on the luma image (chroma decoding is broken). The real time video output on the VCR was definitely affected by this, so that appears to be a big advantage for the vhs-decode TBC.
The tone you are seeing appears to be the first lower harmonic of the 629KHz NTSC chroma subcarrier. 629 / 317 = 1.98421.
Link to my new CXADC 35.8MPS capture:
This may not be the case, but the patterns in that signal could have been switching regulator noise from the 12v wall wart used for my Radio Shack distribution amp. I used an older unregulated wall wart this time that puts out about 14v instead of the switching regulated 12v one I had before. So that part of the chain, whether or not it makes a difference in the capture, is eliminated. I'm now using unregulated power supplies for both that and my VGA preamp. If there is any switching power supply noise in the capture, it's going to be from the VCR itself.
Last edited by Titan_91; 27th Sep 2020 at 13:07.
Fast-reading the reference document cited by oln, mentions something CH1 and CH2 track components and 1/4 from the chroma carrier frequency shifting between heads, I will dive on this further.
The jitter capture sounds jittery!!
I like to demodulate and headphone radio signals, as raw, because our ears can do advanced realtime math even if Ain't so good (lazy) on math theory.
Here an evident jitter part of the first pattern on the capture:
It reveals near half minute of the audio and then it detunes as the servo control tries to compensate.
The capture ends with a no colour solid pattern, it demodulates to audible white noise.
So I've been thinking about how to best de-jitter the signal.
Here is a brief resume of what it should be:
1) First it syncs to head switch frequency
2) Then, it syncs with vertical sync and discriminate between 50 or 60Hz
3) It separates the CH1 and CH2 tracks
4) It search for the color standard frequency carrier and compares to the horizontal frequency to guess the standard. (PAL variants, NTSC, SECAM?)
5) It syncs to horizontal frequency
6) If the image is black and white, it search for the FM audio carrier for HI-FI audio, and time compensate with that, if not present, it should use the luma subcarrier (is that existent?)
7) It reconstructs a jitter/ time signal based on the measures and deviations from the standards.
8) It compensates the raw RF by resampling based on the jitter/time signal, it interpolates missing/virtual data.
9) Then it goes to vhs-decode 'as-is', or to the input of the whole process again to do a multipass compensation.
Here another samples:
First pattern to second pattern switch:
Blue to second pattern change.flac
Second pattern jitter example:
Second to third transition:
Second to third pattern transition.flac
Third pattern jitter:
End noise band.flac
Last edited by VideoMem; 28th Sep 2020 at 02:56.