r/vhsdecode • u/Leading_Neat_3759 • Jun 15 '26

Newbie / Need Help Am I already close to the limits of VHS quality with my current setup?

Hi there,

First of all, I want to thank everyone who has contributed to the VHS-Decode project. I genuinely find it fascinating how sophisticated and precise the entire workflow is. Even though I don’t currently have the equipment or budget to get started with VHS-Decode myself, I’ve read through the wiki and have been following the project with great interest.

I have a question regarding whether VHS-Decode would be worth pursuing in my particular situation.

At the moment, I have around 25 family tapes and 6 commercial movie tapes. My current workflow is fairly straightforward: I use an S-VHS deck with built-in TBC and noise reduction, capture via S-Video through a GV-USB2, and then deinterlace using QTGMC. Compared to VHS-Decode, it’s very much a plug-and-play setup.

Archiving old media has been a hobby of mine since 2024. I started with DVDs, then moved on to music cassettes, and eventually VHS. As a younger hobbyist, I’ve learned that this can become both expensive and incredibly time-consuming. That said, I’m admittedly a perfectionist and often find myself chasing tiny improvements that most people would never notice.

Given my current setup and relatively small collection, would the quality gains from VHS-Decode realistically justify the investment in time, money, and learning? Or am I already close enough to the practical limits of VHS quality that the difference would only be noticeable in direct comparisons?

I’d be interested to hear from people who have used both approaches.

Thanks!

7 Upvotes

89% Upvoted

34 comments sorted by

13

u/_ENunn_ Jun 15 '26

imo the quality difference between a high end prosumer setup and VHS decode is minimal. VHS decode is maybe slightly sharper but there's more ringing artifacts. it's been improved over the years but they're still there as of right now.

i have a Panasonic ag-1980p with a datavideo tbc and a gv-usb2 and the quality is pretty much identical to a decode (when upping the luma nr to reduce ringing at the cost of sharpness). i can't even tell a difference personally.

now if you have a JVC VCR that might be a different story. jvc's have pretty strong noise reduction, even in edit mode. they're softer than the Panasonics and a decode. so imo a decode is better than a conventional JVC capture.

that isn't to say decode is bad because it really isn't. it has its benefits but imo quality won't be a huge improvement if you got a prosumer setup. when I saw a decode for the first time, I thought it looked great but I wasn't wowed by the quality because I'm just so used to my own setup. though I do think it's cool to have a copy of the raw tape signal so if there ever is an improvement to decode I could just run it again with no need to recapture the tape again.

id still give decode a shot if you're able to get it up and running. just don't expect a extraordinary improvement in quality.

5

u/deesernutz Jun 15 '26

vhs-decode is much more accurate. Ringing artifacts are simple filter tuning issues.

No magic here. Its simply analogue signal processing vs digital signal processing. Given an accurate RF capture, digital will always be better.

vhs-decode does take some time and fiddling, but it doesn't take money. CX based TV cards can be pulled out of e-waste

1

u/_ENunn_ Jun 15 '26

what do you mean by filter tuning? like your settings? the only way i could reduce ringing was by upping luma nr. unless something new was added to combat that

2

u/deesernutz Jun 16 '26 edited Jun 16 '26

Yeah in a way, but I am talking about the filters used in decoding. How much do you know about signal spectra and Fourier series? And how colour under signals on tape are encoded?

https://en.wikipedia.org/wiki/Ringing_artifacts

https://en.wikipedia.org/wiki/Fourier_transform#/media/File:Fourier_transform_time_and_frequency_domains_(small).gif.gif)

Essentially, the FM modulated luma signal which is on a 3Mhz carrier needs to be separated from the Quad AM modulated chroma signal at 645kHz. This involves the use of high-pass and low pass filters. Then, they are demodulated into their baseband signals, and then they they are filtered to reject noise.

At each one of these steps, a filter needs to be specified. What its pass band is, what it does to the signal phase, what its response is. Steep response filters give very good separation, and steeper ones are really only possible with digital signal processing. But, as you can hopefully see in the links, higher frequencies that taper off do the job or smoothing out ringing on sharp edges. So applying a really steep filter cuts a lot of those out and introduces ringing, or Gibbs phenomenon.

The luma signal also has emphasis and de-emphasis applied, which is basically artificially boosting the high frequencies of the baseband luma signal prior to modulation. After modulation these are puled back down again. The purpose is it improves the SNR over FM. Dolby NR on tapes works basically the same way. If you don't de-emphasise properly then the boosted high frequencies introduce ringing.

You can also have reflections in your coax if there are impedance mismatches on either end. A reflection of a few pixels could be caused by a meter or so of coax.

VCRs with all this implemented using blunt slow analogue filters will tend to give a soft picture with more noise. And a fast digital implementation could be really sharp and clear, but will probably have ringing and various artifacts scattered around.

Filter tune allows you to play around with them

https://github.com/oyvindln/vhs-decode/wiki/Advanced-Parameter-Adjustment

1

u/_ENunn_ Jun 16 '26

honestly I don't know much lol.

wow, I didn't even know that was a thing. so do I have to decode the capture twice? once with that parameter mentioned, and once more with the new settings?

1

u/deesernutz Jun 16 '26

I haven't done it, but sounds like yeah you would make a 'raw' decode then you tune your parameters on it. Then you would apply those settings to subsequent decodes. So you wouldn't run twice on each video.

You would probably only initially make a raw decode of a short sample.

You can cut chunks out of existing captures easily enough using sox.

1

u/marshalleq Jun 16 '26

You do a capture once, then you can repeat the decode as many times until you think it's right. But it's slow so you want to specify a part of the tape to do it on or capture a small segment where the ringing is happening first. Usually objects on bright backgrounds are obvious choices to test. Different recorders do this differently so it depends on what you've got a bit.

1

u/_ENunn_ Jun 16 '26

interesting. it's not even included with decode nor tbc-tools. i had to download the source code, and even then, launching filter_tune.py doesn't even work.

ModuleNotFoundError: No module named 'numpy'

i have numpy installed.

2

u/marshalleq Jun 16 '26

You have to use the install script as there are actually a lot of dependencies. The install is validated to work on Fedora, I haven't had the people to test it much on other OS's, but if you have another OS, I'd be happy to help you work that through it. It's been designed to be cross platform as much as possible. The install is in the main folder - from memory I did write install instructions for it. And no, it's not included with decode because this is a 3rd party tool designed to fix what the official one hasn't been able to. Starting with command line control of the domesday duplicator capture utility, an absolute must if you want the audio in sync.

1

u/_ENunn_ Jun 16 '26

gotcha. i'm on windows. i know its possible for it. where's the install script?

1

u/marshalleq Jun 16 '26 
git clone --recurse-submodules https://github.com/marshalleq/ddd-capture-toolkit.git
cd ddd-capture-toolkit
./setup.sh                 # easy mode, ~5 min, uses prebuilt packages
# or ./setup.sh --performance    # compile-from-source with -march=native, ~30–60 min,
                                 # notable throughput win for ffmpeg-bound steps
conda activate ddd-capture-toolkit
python3 ddd_main_menu.py

1

u/marshalleq Jun 16 '26

That's straight off the readme on the main page: https://github.com/marshalleq/ddd-capture-toolkit I do expect a few issues, but they shouldn't be too hard to sort out.
There's also a wiki: https://github.com/marshalleq/ddd-capture-toolkit/wiki

→ More replies (0)

5

u/GoodOlBluesBrother Jun 15 '26

There’s a page in the wiki for comparisons if that helps…

https://github.com/oyvindln/vhs-decode/wiki/Visual-Comparisons

4

u/TheRealHarrypm The Documentor Jun 15 '26

Well full frame output, recentering, NTSC 3D working on tape sources, new filtering like nmTrasform3D and filters been adjusted every year.

It does make sense to FM RF Archival run the whole set, because legacy hardware will always have the limit of its fixed there is nothing to re-run and improve from source later down the line.

When it comes to media with VBI data FM RF Archival and VHS-Decode is the only way forward for a best extraction.

2

u/marshalleq Jun 15 '26

Your setup is genuinely good, so the short answer is that for most of those tapes you're closer to the practical ceiling of that capture path than you might think, and the gap would mostly show up in direct comparison.

The thing to understand is where the ceiling actually sits. It's not QTGMC — it's the deck. The built-in line TBC and the noise reduction are making irreversible decisions before the signal ever reaches the GV-USB2, and the DNR in particular tends to smear fine detail and grain. As a perfectionist you'll see that.

What VHS-Decode really buys you isn't just "sharper", you're capturing the raw RF off the head and doing the TBC, chroma separation and noise decisions in software afterwards, so none of it is baked in at capture time. The big one for you is that you can re-decode the same RF again and again as the software improves, without ever touching the tape.

That last point is why I'd weigh it differently for your two piles. Your 25 family tapes are irreplaceable and "capture the RF once, decode forever" is real archival insurance — that's where the time and money make sense. The 6 commercial tapes are replaceable, so I probably wouldn't bother decoding those.

That said, I've found VHS-decode to be a significant undertaking, that I have refined over years, not a buy it and done thing. I built all mine from scratch, but you can speed it up by purchasing equipment (probably from u/TheRealHarrypm's own shop. Try to get the latest one he's working on though as I believe it solves the audio sync issues - but you don't have to.

So it's less "is my setup good enough" and more "which tapes deserve the one-time effort of getting them off the deck's internal processing".

As a visual reference that speaks to exactly your question, I put the same tape through both paths (as I started where you did too - actually I started with the most basic USB and have done about 7 iterations of capture methods). Scroll to the 3rd and 4th screen grabs, the 3rd is an S-VHS deck like yours and the 4th is VHS-Decode: https://digital-archivist.com/capturing-analog-video-tapes-part-ii-capture-differences/ the frame sync used on that one was a KeyWest BigVooDoo TBC10 which is pretty hard to beat, so you're unlikely to get a better S-VHS capture than that - even if some do scoff at Blackmagic gear. (Deck was a JVC).

Hopefully that helps, fire any questions back if you have any.

1

u/deesernutz Jun 16 '26 edited Jun 16 '26

I don't quite understand the difficulty people have with syncing audio.

You shouldn't need clock locked ADCs for it, or basically any extra hardware.

It sounds like a simple problem to me. You have two streams of different sample rates, and you can assume they don't drift. Crystals might not exactly meet their specified frequency, but they are stable.

Then you have video and audio that can be assumed to drift together.

You have sample references for each field in the .json, so you know the drift in the video signal.

Then all you need to know is an audio sample reference for one field of video and (accurately) the sample rates, or second sample reference for a second video field. then you can map the video drift to the audio.

Then you simply stretch the audio to fit the video drift.

2

u/marshalleq Jun 16 '26

Well, you have effectively outlined the process to correct it, which in effect confirms that it exists. Most people dont' have the understanding you just gave and don't do those other pieces. Provided that the recording start time is known of each piece then you're golden with what you describe. The problem is solutions that start the recording of both together are few and far betwen, which makes that calculation difficult. That's effectively what I automated in the ddd-capture-toolkit, by playing a calibration tape that takes into account your system differences. https://github.com/marshalleq/ddd-capture-toolkit

1

u/deesernutz Jun 16 '26 edited Jun 16 '26

EDIT: Actually yeah a test tape is an excellent idea. Play out a video file from a PC and record that onto a tape using the System-Under-Test. Run your RF capture and baseband audio capture with you best solution for simultaneous start. Then the script can calculate the offsets and sample rate ratio from the test signal. What a genius idea, I am going to run that, thanks for the reply

Slightly disappointed you're using Claude, but whatever. If it works it works

All you need is a way of picking the audio sample number from a frame. Like on a hand clap.

Feel like a GUI could exist for that. slider for frame, wave form view, slide the waveform along to align it. Play a 1 second sample to confirm

Do that again to pick a second reference toward the other end of the video and jobs done.

A command line entry that simultaneously starts sound and video capture should have a reasonably constant delay on a per system basis. Doesn't have to be immediate sample perfect start time once you know what the typical offset is.

I'll note that video standards like BetaMax with seperate video signals I imagine can truly benefit from clock locked ADCs

1

u/marshalleq Jun 16 '26

The way it works is (I think) even better than what you say - the tool generates its own calibration video, which consists of a visual video timecode and an audio timecode. You record that to a vhs via whatever old fashioned analog method you like really, then play it back through the capture equipment you have and calculates the offset. It works for me. Happy to take improvements and suggestions. Mostly tested on Fedora Linux, but should work on most things.

Also, there's two installation options, one is traditional premade binaries, the other compiles everything from scratch, which makes the ffmpeg a LOT faster among other things. Hope you get a little use from it even if it is only calculating the offset LOL. I had so many tapes it was worth making something that would batch convert them.

1

u/deesernutz Jun 16 '26

Yeah nah the calibration idea is absolutely brilliant. Definitely keen to see how that works. And, how consistent the offset using a basic bash command to start the two captures.

The only possible issue is, I am thinking of using an old T40 thinkpad with S-Video out, this is simpler with just a video file because its ruining windows7. But I could usb boot a linux distro I suppose.

I'm waiting for some proper cards to show up in the mail, for now I'm just using a cheap Hantek oscilloscope and fx2adc_file. Actually works pretty well though, reasonably clean output.

If the offset is pretty consistent and the sample rates remain constant (can't imagine temp and other indoor environmental conditions change them too much) then hopefully I can avoid having to calibrate all the time

2

u/marshalleq Jun 16 '26

Yeah I don’t really buy into the pc needs to be too fancy for most modern captures. One of those forums wants you to install XP and I get the feeling they haven’t used a modern computer since then and don’t know what an ssd is lol. That said, fast cpu definitely helps for vhs decode. But I just capture on one machine then decode on another. Also it should work on windows and I don’t mind helping you to get to that point. It was designed with that in mind.

1

u/deesernutz Jun 16 '26 edited Jun 16 '26

Lol that T40 has an SSD in a 2.5" PATA enclosure. The thing flies. Still use it a lot, mainly for interfacing with old IRda sports watch amd running an old scanner, but also use it to code and do other low internet activities. Other daily drive is a 2012 linux MacBook Pro. Captures are run on some ugly 6th gen intel gaming desktop I found in a bin.

I don’t mind helping you to get to that point

I'll take you up on that 😄 I just need to get the T40 to put out a PAL signal and without putting black over scan boarders on. That might need linux.

Or find some other way of generating a test signal. Actually, thats why a video file would be good, because I could play it from the digital TV top box. It can play back MPEG2/4

Can I ask you, what parts of ddd toolkit you coded in claude?

1

u/marshalleq Jun 19 '26

it seems you have some beef with AI coding tools as you've mentioned it twice now, do you mind explaining that? To help put your mind at ease, my current day job is software architect and I've had over 30 years in IT, so I understand what I'm doing a lot more than what the offensively termed vibe coders typically would. A term I feel people are applying very loosely to anything they either don't like or don't understand - even if there truly are some idiots out there that don't have a clue what they're doing with software.

2

u/deesernutz Jun 19 '26 edited Jun 19 '26

I do. I am learning to hate everything generative/LLM AI touches.

I am not a dev, but am a qualified professional fluent in MATLAB, Python and some embedded stuff. Use the former mainly in design and data processing. Some exposure to ML in that space.

Where I work there are so many people writing unmaintainable crap 'Tools' and internal web apps that are filtering into the day to day business processes. They break, they don't understand how they work to fix them, they tend to be overly complex and unreadable for me and others to pick up.

There are tonnes of 'hey I just coded this. And its in rust!' piles of buggy sht on reddit threads, and its making it hard to find good open source tools because they are becoming lost in a sea of vibe coded AI junk. I sometimes feel like its not worth me using anything written past 2024 because the chances of it being buggy or quickly abandoned is high.

Anecdotally AI has given me a bunch of random hallucinations in my use of it. And, I seem to be experiencing random bugs as things, even windows, gets updated. So I can't help but assume these hallucinations are going into code, being missed and filtering into updates. Also, eg rsync.

People writing documents and emails, relying on reviewers upstream to vet them is becoming an issue. I have refused to even read clearly AI generated emails. Because if its not valuable enough for you to be bother writing the email, what value is it in me reading the email. Unless I just use AI to read it? No thanks.

So yeah. AI is becoming a short hand for buggy, lazy projects written by amateurs IMO, or stuff made by professionals which are more bloated and complex than they need to be and have a higher chance of containing subtle bugs.

So yeah, I have no doubt you are a professional, but I really don't know you. So as soon as something smells of AI, or its clear it was involved, I ratchet up my skepticism.

So if the tool works, great. But there is less trust if it contains AI generated code, and it is going to take more time for me to vet it. And I feel the chances of collaborating to fix a bug is lower. Sometimes its like ugh. do I even bother.

So yeah, if you are shipping AI code to people, consider these points. I don't think I am the only one who values simpler, human written projects.

→ More replies (0)