VideoHelp Forum

Try DVDFab and download streaming video, copy, convert or make Blu-rays,DVDs! Download free trial !
+ Reply to Thread
Page 10 of 10
FirstFirst ... 8 9 10
Results 271 to 298 of 298
Thread
  1. 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.
    Quote Quote  
  2. Originally Posted by Titan_91 View Post
    Thanks, but I'm wondering if I can skip the chroma decoding and tbcc file in vhs-decode.
    I think you can disable chroma file writing if you change the line 324 in process.py from:
    Code:
    self.outfile_chroma = open(fname_out + '.tbcc', 'wb')
    to:
    Code:
    self.outfile_chroma = None
    But this hack may not avoid background chroma processing.
    Quote Quote  
  3. 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.
    Quote Quote  
  4. Member dellsam34's Avatar
    Join Date
    Jan 2016
    Location
    Paris Ca, 92345 Mexico
    Search PM
    Hey Zcooger and oln are we there yet?
    Quote Quote  
  5. Are we where? This is a volunteer project worked on in everyone's spare time.
    Quote Quote  
  6. Member dellsam34's Avatar
    Join Date
    Jan 2016
    Location
    Paris Ca, 92345 Mexico
    Search PM
    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.
    Quote Quote  
  7. 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.
    Quote Quote  
  8. Member dellsam34's Avatar
    Join Date
    Jan 2016
    Location
    Paris Ca, 92345 Mexico
    Search PM
    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.
    Quote Quote  
  9. 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.

    https://youtube.com/watch?v=gs-XbbHQMvc

    Examples of noise:


    Last edited by Titan_91; 1st Jul 2020 at 18:15.
    Quote Quote  
  10. 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:
    Code:
            self.video_sdl_sink_0 = video_sdl.sink_uc(0, 2291, 625, 0, 1135, 625)
    to:
    Code:
            self.video_sdl_sink_0 = video_sdl.sink_uc(0, 2275, 525, 0, 910, 525)
    Image Attached Files
    Quote Quote  
  11. 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.
    https://www.youtube.com/watch?v=SPfD--x0Uqo
    https://www.youtube.com/watch?v=6dqE1aoaz_s
    https://www.youtube.com/watch?v=_3PxjMIRpXw
    https://www.youtube.com/watch?v=v6bSq3Rhe6Y
    https://www.youtube.com/watch?v=XyKRcVD4r94

    The HiFi envelope by default has too strong signal so I added small potentiometer to change the gain.
    Quote Quote  
  12. Originally Posted by Zcooger View Post
    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:
    Code:
            self.video_sdl_sink_0 = video_sdl.sink_uc(0, 2291, 625, 0, 1135, 625)
    to:
    Code:
            self.video_sdl_sink_0 = video_sdl.sink_uc(0, 2275, 525, 0, 910, 525)
    Very helpful scripts, thank you! Works fine with GNU Radio Companion.



    Originally Posted by Zcooger View Post
    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.
    https://www.youtube.com/watch?v=SPfD--x0Uqo
    https://www.youtube.com/watch?v=6dqE1aoaz_s
    https://www.youtube.com/watch?v=_3PxjMIRpXw
    https://www.youtube.com/watch?v=v6bSq3Rhe6Y
    https://www.youtube.com/watch?v=XyKRcVD4r94

    The HiFi envelope by default has too strong signal so I added small potentiometer to change the gain.
    That's actually brilliant, why didn't I think of that sooner? The 1.3MHz and 1.7MHz Hi-Fi FM carriers are plenty far away from the 3.4MHz - 4.4MHz video FM carrier. Because the Hi-Fi signals are deep recorded with the video signal being shallow recorded, your Hi-Fi levels are much higher than the video level.

    Originally Posted by Wikipedia
    The modulated audio carrier pair was placed in the hitherto-unused frequency range between the luminance and the color carrier (below 1.6 MHz), and recorded first. Subsequently, the video head erases and re-records the video signal (combined luminance and color signal) over the same tape surface, but the video signal's higher center frequency results in a shallower magnetization of the tape, allowing both the video and residual AFM audio signal to coexist on tape.
    Originally Posted by SENCORE tech tips
    VHS HiFi Stereo uses two separate FM carriers to record the stereo information onto the video tape. The audio is recorded linearly as well so that non-Hi-Fi Stereo VCRs can play back the tape. The left channel audio information modulates a 1.3 MHz carrier while the right channel audio information modulates a 1.7 MHz carrier as shown in Figure 3. Since the left and right audio information is kept separate and is not matrixed together, there are few stereo separation problems with this system.

    VHS Hi-Fi is the only format that uses separate audio and video heads on the rotating drum. The audio head first records the audio information. Then the video head records the luminance and chroma information over the top of the audio.

    At first this might appear to be a problem since the video head would, theoretically, erase the audio information. This is overcome by recording the audio information with heads containing wider gaps and by increasing the record current so that the signal records deep into the tape. The video information is then recorded only on the surface, leaving some audio information still embedded deep in the tape. The process of deep recording necessitates a high quality tape with sufficient oxide coating. Some problems in VHS Hi-Fi VCRs can be traced to the consumer not using a high quality tape that has a deep enough oxide layer.
    Last edited by Titan_91; 7th Jul 2020 at 21:06.
    Quote Quote  
  13. 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).
    Quote Quote  
  14. Originally Posted by oln View Post
    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 hope your move is going well. I did another manual decode on my Arthur capture. The chroma layer currently needs to be deinterlaced before I merge it, or else I get alternating lines of complementing colors (due to the phase rotation issue between 2 fields of a single frame). Also, would it be possible to further adjust the NTSC filters to include more detail? The images I'm getting are clean but a bit soft on the luma and chroma decodes. The TBC is pretty stable now though, and so is the hue and saturation within each field.



    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.
    Quote Quote  
  15. 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.
    Quote Quote  
  16. 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.
    Quote Quote  
  17. 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:

    Code:
    # Band-pass filter for Video rf.
    # TODO: Needs tweaking
    RFParams_NTSC_VHS['video_bpf_low'] = 3200000
    To this:

    Code:
    # Band-pass filter for Video rf.
    # TODO: Needs tweaking
    RFParams_NTSC_VHS['video_bpf_low'] = 2400000
    This allows a bit more bandwidth to come through, but also sharpens the existing noise slightly. However, this causes slight luma clipping/streaking on a few lines in certain high brightness scenes. Also, the slight ghosting/ringing on the right edge of outlines is present in the source video I have, as I saw it played back on my actual VCR. Decode with Oln's improved LPF:



    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.
    Quote Quote  
  18. 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.

    https://youtu.be/gNtZOD6zl1k


    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!)


    Edit 2:

    I've been experimenting with gnuradio and the raw binary captures provided in this thread.

    Here is my circuit:

    Click image for larger version

Name:	VTR head RF signal conditioner test.jpg
Views:	11
Size:	244.8 KB
ID:	55015

    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:
    Demod03a.flac

    Here is lowering the playing speed by 0.4
    Demod03.flac

    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.
    Image Attached Thumbnails Click image for larger version

Name:	VTR head RF signal conditioner test_gui.jpg
Views:	8
Size:	455.1 KB
ID:	55019  

    Last edited by VideoMem; 27th Sep 2020 at 02:32.
    Quote Quote  
  19. 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.
    Quote Quote  
  20. Originally Posted by VideoMem View Post
    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).
    Yeah each line below the vsync area of a normal PAL and NTSC video will have a color burst signal at the start for the color decoder to get a reference phase from, the further details depends on the TV system. VCRs usually make does some phase and jitter correction upconversion process from the signal on the tape to the normal broadcast frequency (which was an advantage of using a down-converted color signal, full composite open reel formats required big TBCs to compensate for phase issues due to jitter, while the phase/frequency compensation during upconversion can be done with pretty simple components.) This does mean though that the burst may not work too well for accurate sync detection in a VCR (or external) TBC as it would normally be hooked up at the end. There were a handful of japanese models that did TBC on the video signal before upconverting but I don't know if it made much difference or if any of those made it into the west. Sync-detection in vhs-decode just uses the horizontal sync signal currently as well, but it's already proving to be extremely stable at the level on or better than TBCs in VCRs.

    Originally Posted by VideoMem View Post
    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.
    In theory you could, but the VCR doesn't normally have good way of knowing which field is which unlike a floppy drive, and you are reading analog data, so it's not on/off, a low strenght bit may not be that much nicer than a dropout. What processing the RF signal does allow though is much more advanced dropout compensation that what's available in VCRs. Most VCRs (even high-end Panasonic and JVC SVHS decks) are only capable of inserting a 1h delayed signal from a CCD (or quartz delay line in old vcrs) to repeat the luma of the last good line which is okaay for very short dropouts, but if it's a line or more it's usually quite noticeable. A handful broadcast decks had more advanced digital dropout correction integrated with the TBC that could look at previous frames and compensate color but even that had to be done in real time. When doing software decoding you could do much more advanced stuff using motion compensation etc, and take into account pull-down on video from film sources. I'm working on some very basic DOC currently to hook into the current dro-out replacement stuff in ld-decode, but more advanced stuff could be done later.

    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.
    Quote Quote  
  21. Member dellsam34's Avatar
    Join Date
    Jan 2016
    Location
    Paris Ca, 92345 Mexico
    Search PM
    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.
    Quote Quote  
  22. 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.

    https://youtu.be/wl1ZrEza7uY

    I wonder if there are microphonics artifacts from the head and the tape during switching and scanning at very high speed.

    Demod1.flac

    [ 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:

    https://youtu.be/kbOrISo4GY4
    Last edited by VideoMem; 27th Sep 2020 at 04:11.
    Quote Quote  
  23. Member dellsam34's Avatar
    Join Date
    Jan 2016
    Location
    Paris Ca, 92345 Mexico
    Search PM
    Would capturing S-VHS's luma be different from VHS? I know the chroma is the same for both standards.
    Quote Quote  
  24. 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.
    Quote Quote  
  25. 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:

    http://www.mediafire.com/file/j0yprevxhyyxwtn/vhsjittertest.r8/file

    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.
    Quote Quote  
  26. Originally Posted by oln View Post
    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.
    Not to sorry at all, I like text walls with lot of information on the subject!!

    Originally Posted by Titan_91 View Post
    The tone you are seeing appears to be the first lower harmonic of the 629KHz NTSC chroma subcarrier. 629 / 317 = 1.98421.
    Yes, It is near to that!
    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.

    Blue_jitter04.flac

    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.

    10) Profit!

    Here another samples:

    First pattern to second pattern switch:
    Blue to second pattern change.flac

    Second pattern jitter example:
    Second_pattern_jitter.flac

    Second to third transition:
    Second to third pattern transition.flac

    Third pattern jitter:
    Third jitter.flac

    End noise:
    End noise band.flac
    Last edited by VideoMem; 28th Sep 2020 at 02:56.
    Quote Quote  



Similar Threads