Since we are looking at bad tapes, here's a sample from that same broadcast recording with the tracking errors. It might help to improve decoding of poorly tracked cassettes with fluctuating SNR. This one did not decode properly whatsoever and is full of white fish artifacts, skipped fields, and several dropped frames where sync pulses could not be found. Same tape as the documentary that decodes fine, but something is definitely off here. It sounds like the RF capture is quite noisy. Is there a way to tell if it's SP, LP, or SLP without having the tracking signal present in the capture?
Edit: Nevermind, my capture is corrupted. Disregard.
+ Reply to Thread
Results 601 to 630 of 643
Last edited by Titan_91; 5th Jun 2021 at 22:05.
In cxadc, how do I change vmux?
It seems this changed since my previous install, and I don't understand the readme.
Most of these parameters (except latency) can be changed using sysfs after the module has been loaded. Re-opening the device will update the CX2388x's registers.(Formerly vaporeon800)
I use this command to use different CXADC parameters:
sudo rmmod cxadc && sudo insmod ~/cxadc/cxadc.ko vmux=1 tenxfsc=1 tenbit=1 level=29
Thanks guys, that worked! Just used CVBS from DVD player as input. Still gotta move things around before I can try VHS-RF again.(Formerly vaporeon800)
Got some RF captures from my PV-S4622 last night. They look good, but "noisy". Maybe as much as my old PV-S4670 Spider-Man sample. Didn't get to try grounding the VCR to the PC; that's on tonight's agenda.
On a somber note:
His Facebook is a memorial page, and his website went down at some point. The last Wayback Machine archive is Mar 2020.(Formerly vaporeon800)
That's sad, He did a lot of VCR and video projects in his time even when computer wasn't a thing back then, Last time I've sent him an e-mail about something else was in 2019 and he said it's better to contact him via Facebook, Never get the chance to talk to him about this project. What a loss, RIP.
Definitely sad to hear. As for your result, the grounding will hopefully help. If it's still a bit noisy using a direct connection to your card from the test point, it could be your card. My ATI card has issues with noise and I stopped using it. The Asus Blackbird card performs stellar with VHS. This is of course assuming your VCR does not have a noisy test point. As you know I've been down that rabbit hole before with my DVD VHS combo machine, and even had a similar issue with a LaserDisc player. Both situations were resolved by using different players.
For a VCR, I would strongly recommend the Philips VR620CAT21. I have had zero issues with the output RF signal which is clean and decently strong. Also, don't be afraid to use a higher gain level on the card itself if you are nowhere close the peaking out on your captures. These cards were designed for video, but also an RF input from a TV tuner. So the amplifiers in the CX2388 chips themselves work very well for SNR using both video signals and RF signals.
Last edited by Titan_91; 3rd Jun 2021 at 19:18.
Thanks for all the info. Here's where I'm at so far. Maybe there is another test point I should be using instead.
These are from Panasonic PV-S4622 @ TP2 according to board silkscreen. (PV-S4670 also calls it TP2 on the board, but according to the service manual it's TP6002. I don't have the SM for this one.) CXADC, 8fsc (28MSPS) @ 8-bit.
The tape is the Canadian release of Mighty Ducks The Movie: The First Face-Off.
md1 was captured from Eject state, so it starts off with pure noise. Then I inserted the tape, it threaded, and started playback. vhs-decode produces a lot of complaints with this one, understandably: the VCR itself only shows blue-screen during the noisy start.
md2 is similar in that I started playback from the unloaded state, but I didn't start capture until almost immediately after playback started. It starts off unstable, but without tons of junk that produces complaints.
md3 was captured during normal playback.
It looks like the bothersome crosshatch noise I'm talking about isn't present until about frame 55 of md1. In the other two, it's present throughout. Even during the black fade, it's in the Horizontal Blanking Interval. I picked this screen because my other testing shows that it's most obvious on high-saturation chroma. WholesomeOcean on Discord is having the same or similar issue.
[Attachment 59262 - Click to enlarge]
[Attachment 59263 - Click to enlarge]
vhs-decode settings used. I'm not on the latest version. What's the simplest way to change to the newest?
~/./vhs-decode/vhs-decode -t 4 --cxadc -n --noAGC mdN.u8 mdN ... and for md1 only I had to add: --recheck_phase
AG-1980 (TBC off, EDIT)
[Attachment 59264 - Click to enlarge]
NV-DHE10 (DNR off, TBC on)
[Attachment 59266 - Click to enlarge]
HS-HD2000U (DNR&TBC off) [this capture is 486 lines; some VITS visible]
[Attachment 59265 - Click to enlarge]
AG-1970 [DScaler's vertical delay used with SAA713x to see VBI]
[Attachment 59267 - Click to enlarge]
Last edited by Brad; 4th Jun 2021 at 08:34.(Formerly vaporeon800)
Note: one way to display .tbc files in Windows is with Avisynth's RawSource or RawSourcePlus plugins. These are 263-line fields though, not 525-line woven interlaced frames as ld-analyse can display.
FileName = "md3" RawSourcePlus(FileName + ".tbc",910,263,"Y16",show=false).AssumeFPS("ntsc_double").AssumeFieldBased()
[Attachment 59272 - Click to enlarge]
md3.tbc field 225
[Attachment 59273 - Click to enlarge]
Last edited by Brad; 5th Jun 2021 at 01:34.(Formerly vaporeon800)
I looked at your Mighty Ducks samples. You seem to have two issues, one being background noise generated by your VCR and another being a reflection in the form of an upper sideband.
The background noise is faint, but present even before you insert the tape. How do I know it's coming from your VCR? Because there seems to be a 15KHz horizontal sweep pattern to the signal if I listen to it in Audacity. This pattern follows the same beat as the actual FM luma signal coming from the tape. Basically I had this exact same issue with but with a LaserDisc player, and in my case it was much worse. However, I do not believe this is causing your crosshatch pattern in the captures. It may reduce your SNR level a bit though.
The main issue is your upper sideband. This manifests as a copy (an image) of the entire tape signal at a higher frequency. Here's what your scan lines look like in ld-analyse after I decoded one of the samples:
I counted the number of peaks in each scanline. With this and the blanking intervals in mind, it appears to be the chroma signal coming from the tape that is creating the crosshatch pattern. Two things tell me this, the frequency of the peaks at 39 per scan line and the fact that every other track has its phase rotated. Here's the spectrum view of your capture:
You can see the luma signal centered at 3.9MHz and the chroma signal below it at 629KHz. In the FLAC file the rate has been divided but the proportions remain the same. So instead of K on the scale, imagine the scale says M. Sometimes reflections of the signal in the upper sideband are innocuous, as long as the reflection does not corrupt, or alias, the source signal. Since we know there are chroma signal artifacts in our luma signal, the only explanation is the upper sideband of the chroma signal is corrupting our luma signal. We can see that here:
I have highlighted most of the bandwidth where the luma signal lives, between 3.4MHz and 4.4MHz. We can see this problem from here, but let's zoom in:
In blue is our original FM luma signal. In yellow is the original chroma signal. In green is the upper sideband caused by the reflection. The luma signal of the upper sideband is clear of the luma bandwidth we are listening to, but the chroma signal in the upper sideband intrudes into the space of the original luma signal. We can now clearly see this as a faint line in the upper right section of the blue box at the start of the field, just after the Macrovision pulses. That signal should not be there, and it's the root cause of the crosshatch pattern.
Here's your NTSC Spider-Man sample as well using your other Panasonic S-VHS machine, with the same crosshatch pattern. You can see it has even more sidebands, both above and below the main signal:
To try and fix this, can you confirm if you're using 50 ohm coax cable going from your VCR to your capture card? Here's my Tom and Jerry capture using such a cable, it shows very clean with a faint upper sideband but it's far enough up in the band where it doesn't interfere with the source signal we are trying to decode:
I can post links to the card, cable, and pigtail adapter I'm using if you like.
Last edited by Titan_91; 5th Jun 2021 at 10:27.
I don't know if it's purely about the capture setup itself, or if there is some degree of this inherent to the format (signal reflections caused by some aspect of the capture could probably worsen it though in any case). I know it's not uncommon for there to be a crosshatch pattern where there are strong colors on conventional PAL captures, especially with noise reduction turned down/EDIT mode. I don't know if it's as common on NTSC captures though and to what extent there are filters in VCRs to reduce it. For standard VHS, PAL also has the luma band a bit higher than NTSC, while the color under frequency only differ by a few khz on between all systems beside SECAM-L.
As for other noise, there is some high-frequency noise (faint vertical/diagonal bars on part of the image) visible on Brad's images of the conventional capture, most noticeably on the NV-DHE10 one, and similar visible when decoding the rf capture, so that may be caused by something else.
Gonna take me a little bit to digest all of that info. Thanks very much for taking the time to describe it all and produce the images! I was trying to check that out myself in Audacity, comparing with your samples, but didn't really know what I was looking at and my head started to spin after some hours.
I can post links to the card, cable, and pigtail adapter I'm using if you like.(Formerly vaporeon800)
No problem. This thread serves as a mega wiki of sorts if you're not on Discord or want to go back and look at something specific. My card is unmodified so it uses a 75 ohm s-video connector. But the rest of my cables and connectors are 50 ohm which seems to be best suited for RF.
Not RF expert, but when I see that interference pattern I think of one of two things:
1. Poor Y/C Decoding
Ultimately #2 was my problem and putting in a 10 MHz cutoff frequency (rolling from -3 dB at 8 MHz to -10 dB at 11 MHz) fixed it up for me on a s-video eval-adv7842 capture. However, this might not be terribly helpful here as I'm 8X oversampling - I missed what sampling rate everyone is using here.
A short doc helped me brush up my understanding of what was going on. Again - RF newbie here, so this might be more for the lurkers out there with other problems than what you're troubleshooting here.
Reading over the document, the issue doesn't seem to be caused by the sampling rate in a sense that the sampling rate isn't high enough to capture the source signal. It is, as we are grabbing 14.3MHz of bandwidth, but the issue in this case is unwanted high frequency RF energy being present in upper band that is close enough to alias, or corrupt, Brad's signal in the lower band. It will most likely help if Brad adds a low pass filter to his setup, to filter out that high frequency upper sideband caused by the reflection. I'm using a 13MHz low pass filter. This may be a bit high for VHS, but I use it for LaserDisc as well. VHS tops out at I think around 7MHz based on what someone here told me, but the main deviation is only from 3.4MHz to 4.4.MHz. I'm pretty sure we are using a filter bandwidth that is higher than 1MHz though for the luma, as vhs-decode results are sharper and filtering only 1MHz of bandwidth to me looks like it would be cutting off part of the luma signal anyway, sacrificing sharpness. For LaserDisc, the upper frequency for the FM signal is 9.31MHz at peak white modulation.
Last edited by Titan_91; 6th Jun 2021 at 09:07.
Markertek in the US despite the costs and customs delays. The only alternatives are direct from China, which would take even longer of course.
I can't find anything that definitively states whether or not the impedence even matters for just an adapter, rather than a cable. There are some posts saying that for sub-Ghz frequencies, it "shouldn't" make a difference.(Formerly vaporeon800)
I would think the cable is the most important. The only thing 75 ohm I have is the s-video to male BNC pigtail adapter. Assuming it's actually 75 ohms.
Last edited by Titan_91; 6th Jun 2021 at 20:15.
I got a capture without crosshatching, using a different VCR! Still has high-frequency noise, but this looks much cleaner than my previous attempts. I didn't change any other part of my setup, unless you count moving the VCR from 4" away to 13" away from the PC.
[Attachment 59302 - Click to enlarge]
[Attachment 59304 - Click to enlarge]
[Attachment 59303 - Click to enlarge](Formerly vaporeon800)
I like this clip because it's almost like a multi-burst but in a "real" source. Unfortunately, it was actually animated at 576p25, so North American releases like this Canadian VHS are converted. There is rainbowing; don't know if the tape was mastered in composite or if this is due to the frequency overlap of the VHS format.
[Attachment 59307 - Click to enlarge]
It flickers with the current vhs-decode (20d193b).
~/./vhs-decode/vhs-decode -t 4 --cxadc -n --noAGC -nld --sharpness 50 beastwars1_1.wav beastwars1_1_sharp50
Last edited by Brad; 8th Jun 2021 at 09:28. Reason: I think it's better to say 576p instead of 625p(Formerly vaporeon800)
Originally Posted by readme.md
vhs-decode set to --NTSCJ is horizontally unstable on a few frames here.
[Attachment 59347 - Click to enlarge]
Set to regular NTSC-M, it flickers, then darkens and shakes horizontally for most of the video.
~/./vhs-decode/vhs-decode -t 4 --cxadc --NTSCJ --noAGC --sharpness 100 mmpr_jp_s2v1_0-54-30.vhs.flac mmpr_jp_s2v1_0-54-30_ntsc-j ~/./vhs-decode/vhs-decode -t 4 --cxadc -n --noAGC --sharpness 100 mmpr_jp_s2v1_0-54-30.vhs.flac mmpr_jp_s2v1_0-54-30_ntsc-m(Formerly vaporeon800)
Well, the reflection has disappeared probably due to either the RF signal path being different on the Sony machine or from using a longer cable. The slight high frequency noise that is left can probably be cleaned up with an inline low pass filter:
That Beast Wars sample looks absolutely fantastic. The sharpness is great with minimal ringing along sharp edges the image. There is a bit a of rainbow artifacting like you said, but it's very minor. This is caused by luma information being present in the chroma channel following the decode. Is that particular sample using the Sony VCR? I haven't been able to achieve sharpness over 30 due to ringing and ghosting that results. Maybe the sharpness filtering in the code has improved since I last tried with my Tom and Jerry capture. My goal is to achieve Beast Wars level results. My captures are clean enough.
Last edited by Titan_91; 8th Jun 2021 at 06:59.
Is that particular sample using the Sony VCR?
Here's a comparison of the noise profiles of my three CX cards. The one I've been using up to this point is the V-Stream. The samples were captured with absolutely nothing plugged into them; in the case of the V-Stream & ATI this means that even their breakout dongles were disconnected. Gain level cranked to 31 for each.
I cut each of the files to exactly 5 seconds prior to compressing:
dd if=noisetest_discon_ati.u8 of=noisetest_discon_ati.cut.u8 bs=28636363 count=5
[Attachment 59361 - Click to enlarge]
PixelView Xcapture PV-CX881P (CX23881)
[Attachment 59362 - Click to enlarge]
ATI TV Wonder Pro (CX23883)
[Attachment 59364 - Click to enlarge]
I'm curious what causes these bands of noise. For what it's worth, the ATI is the only one that includes a TV Tuner. Back in the Google Doc days, it was speculated that maybe CX cards without tuners would have less noise.
Last edited by Brad; 10th Jun 2021 at 10:07. Reason: Add chip model #s(Formerly vaporeon800)
Got a bug which I know has been brought up before, but here's another two samples in case they help. Black screen to white flash = decode fail.
[Attachment 59368 - Click to enlarge]
ERROR - please paste the following into a bug report: current sample: 86757778.75903592 arguments: Namespace(chroma_trap=False, cxadc=True, 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='armageddon_ws_1.wav', inputfreq=None, length=99999999, level_adjust=0.1, nldeemp=False, noAGC=True, notch=None, notch_q=10.0, ntsc=True, ntscj=False, outfile='armageddon_ws_1', pal=False, palm=False, recheck_phase=False, sharpness=50, start=0, start_fileloc=-1, tape_format='VHS', threads=4, track_phase=None, umatic=False) Exception: Traceback: File "/home/brad/./vhs-decode/vhs-decode", line 239, in <module> f = vhsd.readfield() File "/home/brad/vhs-decode/vhsdecode/process.py", line 1427, in readfield f, offset = self.decodefield(initphase=initphase) File "/home/brad/vhs-decode/lddecode/core.py", line 3419, in decodefield raise e File "/home/brad/vhs-decode/lddecode/core.py", line 3415, in decodefield f.process() File "/home/brad/vhs-decode/lddecode/core.py", line 3131, in process super(FieldNTSC, self).process() File "/home/brad/vhs-decode/lddecode/core.py", line 1452, in process self.linelocs1, self.linebad, self.nextfieldoffset = self.compute_linelocs() File "/home/brad/vhs-decode/vhsdecode/process.py", line 856, in compute_linelocs line0loc, lastlineloc, self.isFirstField = self.getLine0(validpulses) File "/home/brad/vhs-decode/lddecode/core.py", line 1975, in getLine0 limit = 100 if (self.prevfield is not None and self.prevfield.skip_check() >= 50) else None File "/home/brad/vhs-decode/lddecode/core.py", line 1942, in skip_check line_ire = self.rf.hztoire(nb_median(self.data['video']['demod'][sl])) File "/usr/local/lib/python3.8/dist-packages/numba/np/arraymath.py", line 1224, in _select_two assert high > low # by construction brad@brad-H87H3-M:~/pixelview$ av_interleaved_write_frame(): Broken pipe Error writing trailer of pipe:: Broken pipe
"1" is the initial longer capture. It gets to frame 64 then quits with an error message.
"3" is a re-capture of the first few seconds. It decodes completely, but with warning messages and the video is actually garbled once the white flash happens.
~/./vhs-decode/vhs-decode -t 4 --cxadc -n --noAGC --sharpness 50 armageddon_ws_3.wav armageddon_ws_3(Formerly vaporeon800)
I had that issue with Tom and Jerry a few months back but I haven't been able to reproduce it since. The signal level on that Sony SLV-779HF player looks great, and the RF envelope is flat and consistent. What gain level are you using for the CXADC driver on that Sony machine? That player is from 1999 and made in Japan, while my 2001 Philips VCR is made in China. Assuming your other non-noisy samples are captured with the Sony as well. Seriously considering picking one of these up. Especially since a service manual is available.
Last edited by Titan_91; 9th Jun 2021 at 19:45.
I don't think this model is anything special. I suspect a lot of their models from around this time should be the same.
Mine was actually made in Malaysia. I don't like its regular video output. I got it from a thrift store for $10 several years ago and only kept it as a rewinder. Now it's suddenly more useful.
One nice thing about these models is that the test points we're interested in are clearly labelled on the board, so you don't actually need a service manual. Like late-model LaserDisc players, they're on a header.
[Attachment 59380 - Click to enlarge]
1. HF ADJ
2. PB RF
3. RF SWP
#3 is for video head switching point adjustment and #1 seems to be involved in Hi-Fi audio switching point adjustment.
Google search for models with the same header is here.
Last edited by Brad; 9th Jun 2021 at 20:02.(Formerly vaporeon800)
Pushed a fix that should help a bit on some captures, fixed the flipout on the power rangers one, and the armageddon one works with --noAGC at least. Gonna look at the agc code a bit more later, right now it seems it may be looking at levels on some areas where macrovision stuff will affect it and may need some other tweaks too.
It's still a consumer VCR sure, but the signal level you're getting really helps avoid the slight noise floor generated by using maximum amplification on the card. I tried to do an SNR comparison but the SNR graph in ld-analyse is no longer working. I wonder if something upstream in ld-decode broke this for VHS samples. It would be nice to have something measurable. From my experience really good results start at 40dB SNR. I wouldn't be surprised if that Beast Wars sample is pushing 50dB. If so, that's still a solid 25% increase.
In addition to a proper test point being present on these Sony's, this model has a shielded power supply. May or may not make any difference. Your capture just has less "tape noise" than my best results so far. And that's using 50% sharpness and no post-processing. Plus the color saturation seems better as well, and the chroma channel also looks very clean. Likely a result of the higher signal level and SNR.
I also understand that tape is a Canadian PAL(?) to NTSC transfer, and all tapes vary in signal quality.
Last edited by Titan_91; 9th Jun 2021 at 22:03.
@oln: Awesome, thanks! That was fast. -n and --NTSCJ both seem to output the same results with the MMPR sample now. Should there even be a need to process them differently?
It looks perfect now except for frame 35, which flickers up in brightness, and has some skewed VBI lines.
[Attachment 59390 - Click to enlarge]
armageddon_1_ws now decodes, as you know (yay!). It has a big AGC-type brightness flicker at frames 263-266 even though --noAGC is enabled. This "Touchstone Pictures" logo is really the shot I wanted to check out when I captured this clip, as I noticed an "AGC jump" on it when I did a conventional capture with AG-1970 (TBC on, EDIT) into Intensity Pro 4K.
I haven't checked it out through any other workflow yet.
@Titan_91: ld-analyse's SNR graph is still working for me, with the latest pull.
[Attachment 59391 - Click to enlarge]
Last edited by Brad; 10th Jun 2021 at 00:58. Reason: Info on Armageddon(Formerly vaporeon800)
Stuart Little 2 (US release): DVD -vs- HS-HD2000U -vs- vhs-decode
No reason for picking the HS-HD2000U as comparison here; I just happened to have a capture sitting on my HDD. It's a premium D-VHS VCR, but by no means perfect. My complaints with its picture quality are noted here:
I'm showing luma only because I manually adjusted the levels for each image to try to match them as fairly as possible, and I didn't feel like doing that with the chroma as well.
In general, vhs-decode seems to currently retain all detail, but adds some soft glow/smear. Not sure if different settings could help this.
In this shot, the HS-HD2000U has a dark trail next to the text, and the luma DNR which can never be truly disabled has shifted the clouds in the background. (This particular ad isn't on the DVD, unless I missed it.)
[Attachment 59408 - Click to enlarge]
[Attachment 59409 - Click to enlarge]
HS-HD2000U has dark trails next to everything on the chalkboard.
[Attachment 59402 - Click to enlarge]
[Attachment 59403 - Click to enlarge]
[Attachment 59404 - Click to enlarge]
[Attachment 59405 - Click to enlarge]
[Attachment 59406 - Click to enlarge]
[Attachment 59407 - Click to enlarge](Formerly vaporeon800)