VideoHelp Forum

+ Reply to Thread
Page 26 of 26
FirstFirst ... 16 24 25 26
Results 751 to 768 of 768
Thread
  1. Originally Posted by wright96d View Post
    Is there some sort of straight forward tutorial for this? I'd love to try it, but I have no idea where to start. Also, would the RF hookup allow me to get the tape path alignment perfect? I messed with it a few years ago trying to fix a tracking issue, and have never been able to get it to 100% perfect.
    A while ago someone posted the series of terminal commands needed from start to finish, but I can't find that post now. The best thing I can recommend is start about 10 pages back and read each post, it's a slow and tedious read but it explains the full history of what has already been tried and what works and doesn't. Here's a post that may help:

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

    Zcooger, I found this video by random chance and noticed your comments about vhs-decode. Considering the apparent "anything on tape" scope of this project is anyone interested in implementing PXL-2000 support? It's a "toy" camera that records in a LBTV format onto audio cassettes at about 16.875 inches per second, with a theoretical video bandwidth of about 200KHz (9x the playback rate and bandwidth of 12KHz). His video demonstrates a played back section of a single frame (slowed down to what I assume is 44100Hz) and he calculated and showed various signal timing for sync, etc. That would be a just for kicks thing, as it has literally no application and source material available in 2021.

    https://youtube.com/watch?v=G4hM5X7m5_k
    Quote Quote  
  2. Member
    Join Date
    Sep 2016
    Location
    Hungary
    Search Comp PM
    I found another bug or error.

    The vhs-decode stuck at frame 71 and the log file repeat the same message until I pressed CTRL+C "lddecode - DEBUG - VBI serration levels 3 - Sync tip: 3703.07 kHz, Blanking (ire0): 4000.73 kHz"

    The command: "vhs-decode -p -t4 --10cxadc3 -cafc error.vhs error_out"
    The test file: https://files.videohelp.com/u/264498/error.vhs
    Quote Quote  
  3. Member
    Join Date
    Sep 2016
    Location
    Hungary
    Search Comp PM
    Update: The latest version from oyvindln git is working.
    Quote Quote  
  4. Is anyone aware of a software based digital audio to video conversion tool? Like something that would take a WAV or FLAC file and convert it to a video signal with digital "pixels" that would allow me to store digital audio on VHS for archival purposes.

    https://m.youtube.com/watch?v=WVDCxTtn4OQ
    Quote Quote  
  5. Member
    Join Date
    Sep 2016
    Location
    Hungary
    Search Comp PM
    Originally Posted by Titan_91 View Post
    Is anyone aware of a software based digital audio to video conversion tool? Like something that would take a WAV or FLAC file and convert it to a video signal with digital "pixels" that would allow me to store digital audio on VHS for archival purposes.

    https://m.youtube.com/watch?v=WVDCxTtn4OQ
    Maybe this is what you looking for:
    https://forum.videohelp.com/threads/396928-Recovering-VHS-Beta-PCM-Video-DATA
    Quote Quote  
  6. Here's package that allows to convert between audio and video in PCM-F1/STC-007 format:
    https://odysee.com/PCM-Video-Conversion-Kit:b
    More information you can find on "Fagear Tech Corner" Discord server, #pcm_diy channel (mainly russian but they talk in english too).
    Quote Quote  
  7. Originally Posted by peppi001 View Post
    Yes, fantastic! What an awesome tool. I'll have to play with PCM Coder. Thanks for the link.
    Last edited by Titan_91; 1st Nov 2021 at 08:52.
    Quote Quote  
  8. Following this video guide, I finally got QTGMC working in Wine:

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

    Now that I've tried it, the de-interlacing is fantastic but I don't like the noise reduction. It completely decimates any detail gains achieved using vhs-decode over a normal VCR/capture device workflow. Is there a preset that does not use noise reduction? If not, do I need to try SourceMatch to disable noise reduction and sharpness filters? Literally the only thing I want to do with QTGMC is de-interlacing.
    Quote Quote  
  9. Member Skiller's Avatar
    Join Date
    Oct 2013
    Location
    Germany
    Search PM
    Originally Posted by Brad View Post
    I'm surprised that decoding of these files is working so well, though. Unless Audacity is interpreting the file incorrectly, your waveform is clipping often. This may be the cause of the black streaks visible in the screenshots above.
    If you are talking about these black streaks:

    Image
    [Attachment 61538 - Click to enlarge]



    They are called "fish" or "comets" and are an artifact of analog satellite TV reception. They tend to occur in areas of high color saturation and on sharp transitions. Not so much in flat, pale areas. Especially when the weather was bad, this was a common sight in the 90's and early 2000's in Europe.

    Since they are "baked in" into the VHS recording, they cannot be fixed by ld-decode. However I used to have reasonably good success masking them with an old AviSynth plugin called "DePulse".
    Last edited by Skiller; 31st Oct 2021 at 20:17.
    Quote Quote  
  10. Member lollo's Avatar
    Join Date
    Jul 2018
    Location
    Italy
    Search Comp PM
    ... analog satellite TV reception. They tend to occur in areas of high color saturation and on sharp transitions. Not so much in flat, pale areas. Especially when the weather was bad, this was a common sight in the 90's and early 2000's in Europe.
    I remember the old time of Analog Satellite reception. Even on "strong" transponders on Astra and Hotbirds, without a laaaarge dish and ideal wheater the white/blacks spots were there on some channel. Lot of time trying to move the satellite dish just few millimiters for best reception. A nightmare
    Quote Quote  
  11. Here's the AviSynth+ script I settled on to avoid noise reduction:

    Code:
    FFMPEGSource2("vhs-decode.mkv")
    AssumeTFF()
    QTGMC(SourceMatch=1, Lossless=2, EdiThreads=4)
    Prefetch(14)
    I took this output from VirtualDub2, bumped brightness and contrast by 2 ticks (mouse wheel scrolls) and saturation by 3 ticks using Avidemux, and have attached the result. This, to me, is the most balanced end product from this particular tape where exposure is constantly changing from the camcorder. Indoor shots where exposure doesn't swing so much will allow me to get more contrast. My stock Ryzen 7 3700x can chew through the QTGMC and FFV1 compression workload at around 25FPS, at 100% overall utilization, not bad at all for a CPU intensive process.
    Image Attached Files
    Quote Quote  
  12. I did a successful decode of another tape where the signal ended and some white noise was captured at the end of the sample. Here is the terminal output. The white noise is present in the decode at the end of the tape, which is normal. The entire tape decoded fine with no issues or artifacts. Please note I adjusted formats.py to use a 1.5MHz lower cutoff frequency for the NTSC band pass filter.

    Code:
    /usr/lib/python3/dist-packages/numpy/core/fromnumeric.py:3256: RuntimeWarning: Mean of empty slice.
      return _methods._mean(a, axis=axis, dtype=dtype,
    /usr/lib/python3/dist-packages/numpy/core/_methods.py:161: RuntimeWarning: invalid value encountered in double_scalars
      ret = ret.dtype.type(ret / rcount)
    
    no valid lines found! Guessing or using values for previous field so result will probably be garbled!
    
    ERROR - please paste the following into a bug report:
    current sample: 57572109582.63985
    arguments: Namespace(AGC=False, cafc=False, chroma_trap=False, cxadc=False, cxadc3=False, cxadc3_tenbit=False, cxadc_tenbit=False, debug=False, disable_comb=False, disable_dc_offset=False, disable_diff_demod=False, dod_hysteresis=1.25, dod_threshold_a=None, dod_threshold_p=None, dodod=False, high_boost=None, infile='newhope-windowdedication95.flac', inputfreq=None, length=99999999, level_adjust=0.1, nldeemp=False, noAGC=None, nodod=False, notch=None, notch_q=10.0, ntsc=True, ntscj=False, outfile='newhope-windowdedication95', pal=False, palm=False, recheck_phase=False, sharpness=0, start=0, start_fileloc=-1, sync_clip=False, tape_format='VHS', threads=15, track_phase=None, umatic=False)
    Exception: cannot convert float NaN to integer  Traceback:
      File "./vhs-decode", line 258, in <module>
        f = vhsd.readfield()
      File "/media/user/vhs-decode/vhs-decode new/vhsdecode/process.py", line 750, in readfield
        f, offset = self.decodefield(initphase=initphase)
      File "/media/user/vhs-decode/vhs-decode new/lddecode/core.py", line 3466, in decodefield
        raise e
      File "/media/user/vhs-decode/vhs-decode new/lddecode/core.py", line 3462, in decodefield
        f.process()
      File "/media/user/vhs-decode/vhs-decode new/lddecode/core.py", line 3177, in process
        super(FieldNTSC, self).process()
      File "/media/user/vhs-decode/vhs-decode new/lddecode/core.py", line 1472, in process
        self.linelocs1, self.linebad, self.nextfieldoffset = self.compute_linelocs()
      File "/media/user/vhs-decode/vhs-decode new/vhsdecode/process.py", line 307, in compute_linelocs
        int(line0loc) : int(line0loc + (self.meanlinelen) * 4)
    Quote Quote  
  13. Will have a look at it, suspect it's just some function not accounting for no line starts being found in the noise part or something.

    Originally Posted by Skiller View Post
    They are called "fish" or "comets" and are an artifact of analog satellite TV reception. They tend to occur in areas of high color saturation and on sharp transitions. Not so much in flat, pale areas. Especially when the weather was bad, this was a common sight in the 90's and early 2000's in Europe.
    Yeah it's something can happen when the signal is demodulated or modulated from/to FM if there is much noise, signal is weak etc. Similar effects can be caused from tape playback/recording too as the luminance is FM encoded on tape as well, though in this case you may be right right that it could be from the reception rather than a playback issue.
    Last edited by oln; 8th Nov 2021 at 12:10.
    Quote Quote  
  14. Here's that last sample I did for a church. Turned out great only with a few frames of a darker image shown only at certain times (at 17:50 and 18:36 for example). The source is SP and recorded in 1995. Signal level on the tape is still good, dropout correction wasn't even needed. I no longer have the tape but kept the RF capture. Audio was captured traditionally using the VCR's standard RCA audio jacks.

    https://youtube.com/watch?v=3UtiIKo47-Y
    Last edited by Titan_91; 8th Nov 2021 at 19:02.
    Quote Quote  
  15. There's a bit of an issue when trying to mux audio on a bad tape that causes dropouts in the decoding. I have a degrading tape recorded at EP speed with what appears to be a few seconds of video loss. I think this tape was dubbed with multiple camera sources, which could explain it. Since vhs-decode skips these frames, it causes an audio/video desync in my muxes at the point the frames were skipped. As fields are dropped here and there it causes gradual desync I can't correct for. The logs shows this at certain times:

    Code:
    Unable to determine start of field - dropping field
    In a previous version it would actually decode the end of the tape as static in the image like a VCR would, with log entries saying something like "using TBC data from previous field." Can this be re-enabled where vhs-decode displays static and does not drop/skip fields? The video just needs to be the same length as the audio I recorded separately.
    Last edited by Titan_91; 4th Dec 2021 at 21:28.
    Quote Quote  
  16. It's not an intentional change, would want it to still output something regardless. I suspect my last commit that fixed another issue causing an infinite loop may have broken it but not sure, does reverting the change on line 181 here (or going back to the previous commit if you feel comfortable with git) change the behavior back?

    Your last sample looks nice, I'm noticing a slight bit of this bug on it, need to go over the line start detection code to see if it can be improved (I have spotted a similar effect a fair bit on e.g conventional captures done with no line-tbc, especially on dubbed ones.). I think this happens due to the "ghosting"/overshoot/undershoot from the bright spots at the right edge being long enough to affect the levels on the downward part of the horizontal synchronization pulse.
    Last edited by oln; 5th Dec 2021 at 13:34.
    Quote Quote  
  17. In process.py, would I just need to delete...

    Code:
    if self.prevfield is not None:
                    ldd.logger.info("lastline < proclines , skipping a tiny bit")
                return None, None, max(line0loc - (meanlinelen * 20), self.inlinelen)
    and add...

    Code:
    return None, None, line0loc - (meanlinelen * 20)
    ...back as it was before then try decoding again? Also I'm glad you mentioned that bug. I believe this same poor quality tape from 1993 is triggering it. There are times where SNR takes a dip and causes diagonal shearing of the image:



    I do believe the root cause is over/under shoot during dark to bright transitions as I have black fishes in this scene:



    Also, wasn't sure if any automatic gain control code was causing the image to go dark during corrupted fields (is AGC still turned off by default)?



    As with all my decodes I'm using a lower cutoff of 1.5MHz for the NTSC band pass filter to get a bit more bandwidth. Should I revert this adjustment back to the default setting for this bad tape? I wonder if it's contributing to the black fishes and ghosting. I would assume not, as the bright transitions are on the upper side of the signal, not the lower side. If I was going too low wouldn't I see a checkerboard pattern from the chroma signal in the luma channel?
    Last edited by Titan_91; 5th Dec 2021 at 17:36.
    Quote Quote