I bought the Bonkers home video "I Oughta Be In Toons" off eBay. It's one of the few surviving VHS tapes of the show. I'm curious to see how it will decode.
+ Reply to Thread
Results 811 to 840 of 921
Last edited by Titan_91; 11th Jan 2022 at 12:09.
Re "slow-scanning" the video tracks, someone on the discord that lives in japan linked a japanese article talking about a business working on some system/vcr type thing that was designed to digitize tapes by scanning in less than realtime and decoding, giving the output as files or something. Whether anything will come from it idk. I can't find the link right now and I can't read japanese so a bit hard to find it again.
I don't think it would be impossible to modify a vcr to scan things at a lower speed or similar but it would take a fair bit of engineering for sure. For VHS the two active video heads during playback have an offset of +/- 6 degrees from the drum angle iirc, don't remember what the audio heads are. The different azimuth for each track was an improvement on older formats like u-matic which I think did not have any extra azimuth, allowing putting the video tracks closer together.
I don't think the video heads normally contact the extreme upper and lower part of the tape where the audio and control tracks sit, or if they do, it's the head that is currently inactive. The video rf output from the head amp is contiguous than the switch between heads having a bit of distortion as the signal from the two heads don't 100% line up (this may be intentional, not sure). There is not gap.
I've linked them before, but if you missed them, these two docs from JVC and Panasonic contain a lot technical details about the workings of VHS, both mechanical and electronic aspects:
Last edited by oln; 11th Jan 2022 at 11:04.
This was the Aug 2021 Japanese article linked by sepmag-master on Discord: https://news.mynavi.jp/article/20210803-1937853/
And in the opposite direction, attempting faster-than-realtime, is one we've discussed before: https://forum.videohelp.com/threads/402303-SingMai-FPGA-VHS-player-(future-capture-alternative)
Thanks for the docs, that's very useful.
It's a valid question whether the video heads can reach the entire width of the tape - I'd assume it should be the case if the tape is wrapped more than 180° around the head cylinder. I also understand that the RF output is electronically switched between the video heads every half-cycle and the signal from the tape edges might be cut out, since it would be undesired cross-talk in normal playback mode, so full tape imaging won't work that way. But if there's a way to tap the raw signal from one specific head (or both) during the full 360° rotation, it should work. I mean completely bypassing the VCR electronics except the mechanical head spin and probably the pre-amp if there's one for each head before the switching.
I think the head/read-out portion should be very simple to do if the VCR is well enough documented - just spin the head motor at a constant speed and hook up the correct signal traces from the heads. The "micro-step" transport would require replacing a part of the belt drive with a stepper motor, that should be the only "hard" part hardware-wise. Anyhow, if there isn't a fundamental problem with that approach (like the reach of the video heads across the tape), I might give it a try in the future when I have a bit more time.
Originally Posted by Novgorod
New to this forum, just catching up on this, it's fascinating. I've tried a couple of hours of playing with this and I'm not ready for showtime yet but would like to think I may be able to help possibly with this project.
Apologies if it's already been covered (I'm an instrument engineer by trade, my mind goes here) but is there any merits in impedance matching here or using active filter circuits etc from the RF output?
Yeah as noted on discord, I think there is merits to maybe make some small mods or use amps to reduce interference and signal reflections.
Was testing capture bit on my Samsung SV-6553x just now, and found that connecting the ddd directly with my scope probe to the env and gnd test points produced a lot of noise on the output:
Putting the probes in 10x mode got rid of the noise, but seems to attenuate the output a bit much giving e.g noisy chroma:
Tried adding in a 0.1uf film capacitor, first just an old one hanging loosely on which seemed to give good output, however when I actually soldered one in (different cap but still 0.1u film) it gave the same result as earlier.
I then tried to connect the ground on the probes to the vcr chassis instead of the test point ground, and it got rid of a lot of that noise:
Doing the same without the 0.1uf cap showed a bit more noise (different tape but should be visible enough) so it seems having that helps a bit (some vcrs like the sonys put a cap on the test point already but not these samsungs):
I don't know if this is entirely optimal yet, maybe a resistor on the env output would let one use the test point gnd instead, but haven't tested more yet. Maybe someone with more electronics knowledge can deduce something based on the datasheets, as the sheets for the video IC are available on the web, the env test point on this is direct from pin 21 (same on funai-made decks using the chip I think, LG ones using it are a bit different it with the tp connected via some transistor and pin 78/79):
I haven't found the full sheet for the NTSC-only variant of the sanyo ICs used in the US models (LA71206, LA71207), but I suspect it's similarly designed.
Here is my workflow, which works extremely well for me (around 35dB SNR):
1. Sony VCR with a 50 ohm RG174 cable soldered between the PB RF test point to a 50 ohm BNC panel mount jack on the back of the VCR
2. Thick ground wire screwed down between the VCR's chassis and capture PC's chassis which is confirmed to reduce noise
3. 50 ohm RG174 cable with BNC ends going from the VCR to a MiniCircuits 13MHz low pass filter
4. Low pass filter to T splitter and 50 ohm BNC terminator
5. T splitter to BNC port added to my card which is overclocked to 40MHz, for 40 MSPS 8-bit sample rate
6. RG174 cable going from BNC port on the card to a capacitor in series for DC isolation (as mentioned above, may not be needed for Sonys)
7. Series capacitor goes straight to the input #1 pin of the Conexant chip on the card via an existing trace
For capturing, I set the gain on the card to level 15. Anything above that raises the noise floor and reduces SNR. Credit goes to 9954tony on the LDDB forum for providing the splitter/terminator, filter, and custom modified capture card. Without this my results would be considerably worse.
Last edited by Titan_91; 14th Jun 2022 at 21:41.
I'm quite happy to look in to this, just spit-balling here but a buffer stage and an active filter setup should be quite easy and cheap to accomplish, even as a first pass measure for experimentation.
Impedance matching I'm happy to look at, a buffer stage is the easiest way to accomplish this, I can draw something up and assemble it over the weekend on a board, it could be reduced to a say 10-15 pounds/dollars/euros worth of components for a very simple buffer and filter. Maybe something coin-cell based would be useful for experimentation.
I've noticed quite a few reflections fiddling today - was the 50Ω cable arrived at scientifically or is that just a case of what people have been using? A buffer for matching would allow full transfer in to nominal 75Ω on the CXADC board (assuming it's 75Ω).
Obviously the 'sky is the limit' with this stuff price wise, but for basic impedance matching I'm happy to experiment and throw a few gerbers up if that can be my contribution to this?
For impedence on my capture card, the 75 ohm termination resistors have been bypassed.
This is something I'd love to experiment with, the option is to buffer for 75Ω or consider the whole lot as 50Ω with a resistor bypass. 50Ω & 75Ω mixed though at 'high' frequencies is never going to be an ideal solution. It's great for fiddling with, but it's not ideal, I'll have a fiddle on the bench over the weekend and see what I can find out.
I have a quick question regarding the Domesday Duplicator device: Is it strictly necessary to use an FPGA as a FIFO between the ADC and USB interface? I plan to build a similar USB-ADC device (but with more ADC channels to read multiple heads at once) based on the Cypress FX3 USB3.0 kit and want to keep it as simple as possible. It has a very beefy digital interface for the price (100MHz x 32bit), which can be configured as a FIFO, and has enough headroom for at least 200MByte/s continuous streaming. It should also be able to provide the clock for the ADC.
The FPGA "just" increases the onboard buffer (from 0.5MB to 32MB), right? If the PC can't keep up with the data rate, there will be data loss regardless, because even the FPGA's RAM can only buffer a fraction of a second. The USB3.0 connection itself should be relatively stable, maybe occasionally dropping a few packets, which should be easily covered by the FX3's onboard buffer, and any bigger physical disruption should lead to a link disconnect anyway. I know some people use the FX3 directly as a logic analyzer, so it should also work with an ADC. What do you think?
Both the OS, and the USB interface could lag, the data stream speed is high and it increases linear with the number of desired channels if all of them are sampled at the same rate.
I think a simpler and by consequence cheaper solution could be implemented, but it will require work. We have the CX and the domesday device as capture devices at this moment tested for use with the project.
They're the first enabling devices for doing this kind of accesible signal exploration, and they can be improved.
Buffer stages for driving the coax out of the VTR seems to be a must, also for not loading/attenuating the internal signal path of the device.
The experiments seems to confirm that.
The probe's grounding point position could also affect the end result!
You would have to ask smally/simon/happycube for the details but I believe there was issues with sample losses without the extra FPGA buffering from the De0.
All that ghosting could be caused by the group delay issue.
It is compensated in LD, but it also needs to be improved on tape.
Lower frequency and slow details comes on time, but the higher frequency part of the video is coming earlier or after and it is causing that ghosting and/or ringing.
That's my best educated guess.
I've got another error with cvbs-decode.
Almost every frame in the log: Field phaseID sequence mismatch (4->7) (player may be paused)
ERROR - please paste the following into a bug report:
current sample: 18751676938.351295
arguments: Namespace(AGC=False, auto_sync=True, chroma_trap=False, cxadc=False, cxadc3=False, cxadc3_tenbit=True, cxadc_tenbit=False, debug=False, infile='001.r16', inputfreq=None, length=99999999, notch=None, notch_q=10.0, ntsc=False, ntscj=False, outfile='001_v3full', pal=True, palm=False, seek=-1, sharpness=0, start=0, start_fileloc=-1, system='PAL', threads=1)
Exception: slice indices must be integers or None or have an __index__ method Traceback:
File "/usr/local/bin/cvbs-decode", line 126, in <module>
f = vhsd.readfield()
File "/usr/local/lib/python3.8/dist-packages/lddecode/core.py", line 3563, in readfield
f, offset = self.decodefield(initphase=initphase)
File "/usr/local/lib/python3.8/dist-packages/lddecode/core.py", line 3542, in decodefield
File "/usr/local/lib/python3.8/dist-packages/lddecode/core.py", line 3538, in decodefield
File "/usr/local/lib/python3.8/dist-packages/lddecode/core.py", line 3005, in process
File "/usr/local/lib/python3.8/dist-packages/lddecode/core.py", line 1478, in process
self.linelocs1, self.linebad, self.nextfieldoffset = self.compute_linelocs()
File "/usr/local/lib/python3.8/dist-packages/lddecode/core.py", line 2157, in compute_linelocs
self.rawpulses = self.getpulses()
File "/usr/local/lib/python3.8/dist-packages/cvbsdecode/process.py", line 259, in getpulses
File "/usr/local/lib/python3.8/dist-packages/cvbsdecode/process.py", line 126, in getpulses_override
sync_level, blank_level = find_sync_levels(field)
File "/usr/local/lib/python3.8/dist-packages/cvbsdecode/process.py", line 69, in find_sync_levels
search_start = np.argwhere(on_sync[offset:])
Last edited by peppi001; 2nd Feb 2022 at 11:34.
That message is for ld-decode and does not apply to VHS. Laserdisc uses data in the vertical blanking interval for frame number and field order, and that data isn't used for VHS.
Yeah that message is generally not a worry, the crash is likely a bug due to the code accounting for not finding any sync pulses or similar. cvbs-decode is a bit bare-bones currently as we don't have a good way of capturing raw composite. The cx cards like to start messing the input when they detect a normal video signal giving weird artifacts and the DDD filters out too much of the low frequencies for it to work.
Thanks for the answer. I try cvbs-decode, because the picture is better than vhs-decode in certain situations. The vhs-decode ghosting effect annoying me But I prefer the vhs-decode method
I've been getting several compliments from the churchgoers on the picture quality vhs-decode can produce. These are older people who probably haven't seen VHS in years and can immediately discern the difference. They are comparing it to DVD. To all involved, thank you so much for your excellent contributions to this amazing project.
Next on my list is a wedding video from the late '80s. Should look great.
oln: I modified your code a little bit. (this is the diff file: https://mega.nz/file/o0c2zDzC#3HbPLNqA71GfAft8Mjat339LAN29ZbeCuuFzrGOoo1g )
This patch resolve:
- "field order" problem in vhs-decode and cvbs-decode too
- cvbs-decode Exception: slice indices must be integers or None or have an __index__ method Traceback: error
Please if You think, add it to your repo.
PS: I'm not a programmer, I only change the code
Last edited by peppi001; 16th Feb 2022 at 12:35.
Modified the latest git version.
This is a cleaner and maybe better mod
diff -ruN 20220216.oln/vhs-decode/cvbsdecode/process.py 20220216.peppi/vhs-decode/cvbsdecode/process.py
--- 20220216.oln/vhs-decode/cvbsdecode/process.py 2022-02-16 19:26:15.349060500 +0100
+++ 20220216.peppi/vhs-decode/cvbsdecode/process.py 2022-02-16 19:27:13.029060500 +0100
@@ -57,7 +57,7 @@
difference = max_val - sync_min
# Find approximate sync areas.
- on_sync = data < (sync_min + (difference / 15))
+ on_sync = data < (sync_min + (difference / 14))
found_porch = False
diff -ruN 20220216.oln/vhs-decode/lddecode/core.py 20220216.peppi/vhs-decode/lddecode/core.py
--- 20220216.oln/vhs-decode/lddecode/core.py 2022-02-16 19:26:15.359060500 +0100
+++ 20220216.peppi/vhs-decode/lddecode/core.py 2022-02-16 19:29:42.199060500 +0100
@@ -3914,7 +3914,7 @@
if prevfi["isFirstField"] == fi["isFirstField"]:
# logger.info('WARNING! isFirstField stuck between fields')
- if inrange(fi["diskLoc"] - prevfi["diskLoc"], 0.95, 1.05):
+ if not inrange(fi["diskLoc"] - prevfi["diskLoc"], 0.95, 1.05):
decodeFaults |= 1
fi["isFirstField"] = not prevfi["isFirstField"]
fi["syncConf"] = 10
diff -ruN 20220216.oln/vhs-decode/vhsdecode/format_defs/vhs.py 20220216.peppi/vhs-decode/vhsdecode/format_defs/vhs.py
--- 20220216.oln/vhs-decode/vhsdecode/format_defs/vhs.py 2022-02-16 19:26:15.379060500 +0100
+++ 20220216.peppi/vhs-decode/vhsdecode/format_defs/vhs.py 2022-02-16 19:30:01.029060500 +0100
@@ -9,7 +9,7 @@
# Ideally we would calculate this based on tau and 'x' value, for now
# it's eyeballed based on graph and output.
rfparams["deemph_mid"] = 260000
- rfparams["deemph_gain"] = 14
+ rfparams["deemph_gain"] = 12
# Parameters for high-pass filter used for non-linear deemphasis, these are
# probably not correct.
It looks like you skip a field if you have to consecutive fields of the same type? I'll see if I can add a parameter to enable that behaviour, it could possibly cause issues on some other stuff so not sure if I would want to enable it by default.
The cvbs change is probably fine as is if it works a tad better than the current parameter.
Thanks, if You can add as a parameter that is perfect
Someone on the Discord channel posted a sample recording from Spider-Man using an unmodified CX card. The capture turned out good and the resulting image using combined TBC files (using the sox audio editor) looks phenomenal. This combined method is not only easier to quickly review in ld-analyse, but may be a superior way to decode from here on out. I was initially against the idea of essentially turning digital s-video into digital composite, but the comb filters in ld-chroma-decoder are simply fantastic. Perhaps that gives an advantage over the current rendering method?
I think I've figured out why the combined method looks better. That screenshot is using the 2D comb filter, not 3D like I was assuming. The 3D comb filter does not respect the "phase compensating decoder" option and thus creates artifacts, dot crawl, and wrong colors on every other frame. As to why the combined result looks better, for some reason the luma TBC file on its own exhibits some added noise vs. the combined TBC file. This is interesting and I wonder if it's a bug in ld-chroma-decoder or the result of ld-chroma-decoder expecting a 3.58MHz color subcarrier but not finding one. I was aware of this noise in my decodes, and thought it was simply tape noise that could not be eliminated. I used the below command line from 9954tony on the LDDB forums to combine the two files. I only made one change to remove the gain as this was causing clipping errors in the terminal:
sox -m -r 14318181 -b 16 -c 1 -e unsigned -t raw INFILE.tbc -r 14318181 -b 16 -c 1 -e unsigned -t raw INFILE_chroma.tbc -r 14318181 -b 16 -c 1 -e unsigned -t raw OUTFILE.tbc
Black screen from combined TBC file:
Black screen scope trace from luma TBC file:
Black screen scope trace from combined TBC file:
Columbia Pictures logo from luma TBC file:
Logo from combined TBC file:
Tobey Maguire from gen_chroma_vid_ntsc script, which uses separate TBC files for luma and chroma:
Tobey from combined TBC file using ld-chroma-decoder example script on the ld-decode wiki pages:
Oln can you confirm if you can reproduce this? I can see the noise appear only when loading a luma TBC file in to ld-analyse, regardless of the ld-analyse settings I'm using. The noise seems to vanish after combining the two TBC files into one using sox. These examples I have are from the same source and same decode run.
Last edited by Titan_91; 20th Feb 2022 at 09:07.
On that note if anyone is interested in getting the 3D comb filter working with combined VHS sources, would it be better to add an option in vhs-decode to correct for the chroma phase rotation early on? I'm aware that ld-chroma-decoder and ld-analyse have separate options for this already. But doing so during the decode would prevent having to do it in multiple utilities downstream. And that would make the TBC files useful for potential new utilities from the parent ld-decode project.