Sooner or later, anyone who spends a bit of time reading about tape preservation runs into the term vhs-decode. Sometimes it’s a forum post claiming it’s the only honest way to capture a VHS tape. Sometimes it’s a GitHub readme that opens with FM carriers and sample rates and loses you in the first paragraph. Either way, the question that lingers is the practical one: what is this thing actually doing, and is it for me?
This article is an attempt to answer that without writing a how-to. By the end you should know what vhs-decode is, why it exists, what it genuinely does better than the conventional path, what it costs, and — the question most articles dodge — whether it’s worth the trouble for the tapes sitting in your cupboard.
The one-paragraph version
Conventional VHS capture plugs the deck’s yellow or S-Video output into a USB or PCIe capture device, which records the picture the VCR has already decoded. vhs-decode does something different. It taps into the VCR earlier — at a test point on the head amplifier, before any of the deck’s own decoding circuitry has touched the signal — and records the raw electrical waveform coming off the spinning heads. That raw recording is then turned into video entirely in software. The advantages are real: better picture quality than the deck’s internal electronics can produce, a file that can be re-decoded as the software improves, and an archive copy that captures what was on the tape rather than what your particular VCR chose to make of it. The drawbacks are also real: more storage, more hardware, more time, and a steeper learning curve than plugging in a USB stick. It isn’t for every tape and it isn’t for every archivist.
Why anyone built this in the first place
A conventional VHS capture is a journey through a series of decisions, made on your behalf, that you never see and can never revisit. The VCR’s chroma processor decides how to separate colour from brightness. Its time-base corrector — if it has one — decides how much jitter to absorb. Its dropout compensator decides what to paste over the moments when the head loses contact with the tape. Every one of those decisions was designed for 1980s silicon costs, and every one of them is baked permanently into the file your capture card writes to disk.
The honest framing of what conventional capture gives you is this: a recording of what your VCR thinks the tape says, made with electronics designed to a price point thirty years ago. If the deck’s chroma circuit slightly overshoots on saturated reds, your file overshoots on saturated reds. If the dropout compensator pastes the previous line of video over a glitch, your file has the pasted line — and there’s no way to tell later which lines are real and which are fill-in. The capture path doesn’t preserve the tape; it preserves the deck’s interpretation of the tape.
vhs-decode was built on a different premise. The reasoning, stated in slightly different ways by different people across the community for the better part of a decade, goes something like this. The signal coming off the head, before any of the deck’s electronics get to it, contains more information than what comes out the other end. Every analog stage between the head and the composite output adds loss. If you can capture that earlier signal — the raw RF — and decode it in software, you have a few things you don’t have any other way. You have a file that doesn’t carry the deck’s mistakes. You have a file the next version of the software can re-decode and improve. And you have something that functions as a digital negative of the tape: the bits and pieces of waveform the head was able to read, captured before any decisions were made about what they meant.
That last bit is the part that genuinely changed my mind about all this. The video file isn’t the archive in this model. The raw RF capture is the archive. The video is a print made from the negative — a print that can be made again, better, when better tools exist.
What’s actually happening in the signal chain
A conventional capture stick is a small box that samples a composite or S-Video signal at around 13.5 megasamples per second — the standard rate for digitising a television signal. The signal arriving at the capture stick has already been through every stage of the VCR’s electronics. The capture stick records what the deck handed it.
vhs-decode samples a different signal at a different point. Inside most VCRs there’s a small PCB called the head amplifier, sitting close to the rotating drum, which is the first stage of electronics the heads’ output passes through. Most consumer decks have one or two test points on this board — small solder pads that the factory used for calibration, and which expose the raw FM-modulated signal coming off the heads. A vhs-decode setup taps that test point through a small capacitor, runs the signal through a wideband amplifier installed inside the deck, and routes it out to an analog-to-digital converter card. The ADC samples at somewhere between 28 and 40 megasamples per second — two to three times the rate a conventional capture stick uses, on a signal that contains everything the heads were able to read off the tape.
What the video heads actually put out, in case you’ve ever wondered, is a single composite waveform with two things layered on top of each other. The brightness information is FM-modulated around a carrier in the low megahertz — roughly 3.4 to 4.4 MHz for NTSC VHS, 3.8 to 4.8 for PAL VHS, with S-VHS shifting the whole band higher again. The colour information is sitting underneath at around 629 kilohertz on NTSC or 627 kilohertz on PAL, downconverted from its broadcast frequency at record time — this is the “colour-under” scheme that VHS, Betamax, U-matic and 8mm all share. Brightness and chroma come off the same heads, through the same amplifier, to the same solder pad, with tape noise threaded throughout. HiFi audio — if the tape has it — is a separate story. It’s recorded by a different pair of heads at a deeper layer in the tape, as a pair of FM carriers around 1.4 megahertz, and read back through a different amplifier in the deck. Capturing it means a second tap point on the audio side. Most people who start with vhs-decode capture video first and add HiFi later if they want it.
The decoder software then does in code what the VCR’s hardware would have done. It demodulates the brightness signal. It finds the sync pulses that mark the start of each line and field. It uses those sync pulses to do time-base correction — aligning every line to a known length, taking out the mechanical wobble the tape transport introduces. It separates the colour signal out of the same captured RF, lifts it back up to its proper subcarrier frequency, and applies time-base correction to it as well — something almost no consumer VCR ever did. And it handles dropouts, with proper linear interpolation rather than the cruder paste-the-previous-line trick consumer decks use.
The intermediate result is a .tbc file — a time-base-corrected pair of streams, one for brightness and one for colour. A second program turns the .tbc into actual video. The split exists for a practical reason: if a smarter colour decoder ships next year, you can re-run that second step against your existing .tbc files in a fraction of the time it would take to demodulate the RF again from scratch.
The naming is slightly misleading
Despite the name, vhs-decode handles more than VHS. The same software, with different parameters, decodes Betamax, U-matic, S-VHS, the Video8 and Hi8 family, and the VHD disc format the Japanese market briefly tried in the 1980s. A sibling project, ld-decode, handles LaserDisc and is the project that started this whole approach. Another sibling, hifi-decode, handles the FM stereo audio tracks. There’s a cvbs-decode for composite-video sources captured directly, although it’s still maturing. The shared architecture across all of them is the same: capture the RF, decode in software, keep the RF as the archive.
What it genuinely does better
The honest list of advantages over conventional capture comes down to four things.
The first is colour. The colour-handling improvements that have landed in the decoder over the last couple of years — proper time-base correction applied to the chroma signal, accurate detection of NTSC’s chroma phase rotation — produce colour better than the analog circuits in any consumer VCR can manage. And the same RF capture, run through a 2026 decoder, looks better than it did when run through a 2023 decoder. Nothing about the tape changed; the software got smarter.
The second is dropouts. Linear interpolation — blending the lines above and below a dropout — produces a better picture than sample-and-hold — pasting the previous line over the gap. The maths of that has been understood for decades; consumer decks all use sample-and-hold because doing it properly in real time was prohibitively expensive in 1985. Software has no such constraint. But the catch is that for the software to do better than the deck, it needs the raw signal before the deck’s dropout compensator has already substituted its sample-and-hold fill-in. That’s only possible with an RF tap.
The third is honesty about the tape’s condition. With the RF in hand, you can tell whether an artefact is on the tape, in the deck, or in the decoder, because you can re-decode the same RF with different settings and see what changes. Without the RF, you can’t make that distinction — you have one rendering and no way to interrogate it.
The fourth is future-proofing. The .tbc and the video file are renderings, and they can be remade. The RF FLAC is what was on the tape. If you keep the RF, you keep the option of doing better later. If you only keep the video file, that option is gone.
What it costs
The list of costs is just as honest.
Storage is the most quantifiable, and the numbers are not small. A FLAC-compressed RF capture at the bit depths and sample rates people actually use runs roughly 100 to 130 GB per hour of tape. A three-hour film comes off the deck as a 300+ GB compressed file. The decoded video, in the lossless intermediate format most people keep, adds another forty to fifty GB per hour on top. While the decoder is running you need at least the size of the capture again in working disk, so the practical requirement during processing is roughly double the capture size. A modest archive of a few dozen tapes lands in the tens of terabytes once the RF, the working files, and the decoded video are all on disk. Plan for storage on that scale, including backups.
The hardware is a deck capable of being modified, plus the capture electronics. A common starting build is a Conexant CX2388x-based PCI capture card (twenty or thirty dollars on the used market), a Clockgen Mod board that lets it sample at higher rates and keeps audio in sync (around eighty dollars), and a wideband amplifier board that sits between the deck’s tap point and the capture card (around forty dollars). All in, you’re looking at one hundred and fifty to two hundred and fifty dollars for the capture rig, not counting the deck itself.
The longer-running alternative is the DomesdayDuplicator — the original purpose-built RF capture device the community produced, born for LaserDisc decoding and adopted by the vhs-decode side — which samples at 40 megasamples per second and 10 bits. It captures RF only, which means audio is a separate device: a second ADC, a sync wire that carries the DdD’s master clock across to that ADC, and software that knows how to interleave the resulting streams correctly. The ddd-capture-toolkit project handles that pairing as part of a wider batch workflow that runs the full capture-to-archive pipeline.
The MISRC project is a more recent purpose-built single board that consolidates the CX-card-plus-Clockgen-Mod functions more cleanly, and a newer line of work uses cheap HDMI capture sticks reprogrammed to dump raw samples. The CX-card-plus-Clockgen-Mod build is still the most common in 2026; the DdD remains the choice for archivists who want the cleanest purpose-built option.
The justification for the DdD’s higher cost and larger files is the principle that the initial capture should be as accurate and information-dense as the hardware can practically manage; data is much easier to throw away later than to recover. The DdD’s 40 megasamples per second at 10 bits per sample is one expression of that principle; a modded CX card running at 40 MS/s and 8 bits is another. Whether the bit-depth difference translates to a visible quality difference between the two paths is the question I’d want to settle with side-by-side captures rather than first-principles arguments.
The deck has to be one that can be modified. Combo VCR/DVD units with modern decoder chips tend to be unsuitable. The community maintains a list of decks with documented tap points, and starting with one of those is much easier than trying to figure out a deck from scratch.
The time cost has several parts. Capture is real time — a three-hour tape takes three hours to capture, the same as conventional. Decoding is not real time and not multi-threaded; the decode of a three-hour tape typically takes longer than the tape itself, sometimes substantially longer depending on format, decoder options, and the CPU. After decode there are still the export, compression, and audio multiplexing steps before you have a finished file. The decoder is single-threaded by design — correctness comes first, performance later. The practical pattern is to queue captures up and run decode plus the downstream steps as overnight or weekend jobs.
The toolchain is mostly Linux. The capture driver is Linux-native; Windows support is experimental; Mac support is patchy. The decoder is cross-platform, but most of the troubleshooting conversations on the community Discord assume a Linux capture machine. It isn’t a deal-breaker — a cheap second-hand laptop running Linux just for capture works fine — but it’s worth knowing before you start.
The skill floor is real and worth naming honestly. You need basic to moderate electronics knowledge — enough to tap a working VCR without breaking it, and enough to build (or, increasingly, buy pre-built) the wideband amplifier board that sits between the deck and the ADC. Even with a pre-built amplifier, unless your deck happens to be one of the few thoroughly characterised in the community wiki, you’ll likely need to solder very small surface-mount resistors onto the amplifier to match it to your particular deck’s signal level — and doing that properly wants an oscilloscope on the bench, or a willingness to work by elimination. Beyond the hardware there’s a multi-step pipeline to chain together — capture, decode, export, compression, audio multiplex — each with its own command-line tool and configuration. Plan on months to get a working setup running, and on continuing to tweak it after that. Managed tooling is starting to bridge some of this — the ddd-capture-toolkit project, for instance, batches the full capture-to-archive pipeline into a single coordinated workflow aimed at lowering the floor — but the user community still skews substantially toward people who enjoy building things.
Who actually benefits
This is the section every article like this should have and most don’t.
For a single box of family holiday tapes, in reasonable condition, that someone just wants to be able to watch on a laptop and email to relatives — conventional capture is fine. A good deck, a decent capture card, a careful capture session: that combination produces watchable, archivable video that everyone in the family will be happy with. The vhs-decode path’s cost in time, storage, skill, and hardware isn’t proportionate to what you’d get back from twenty tapes of someone’s birthday party. The dropout-compensation improvement, in particular, only matters on tapes that have meaningful dropouts to begin with — on a tape in reasonable condition, the deck’s own compensator is rarely the bottleneck.
The case is much stronger when the tapes themselves are irreplaceable. The only surviving copy of a wedding. A grandparent’s home movies. A community-history archive nobody else has. The recordings of a public-access TV show that aired once and was never released. The principle in those cases is simple: the tape is going to be played a very small number of times before something — the deck, the heads, the binder, the tape itself — fails for good. Capturing the raw RF on what may be one of the tape’s last good plays means the archive doesn’t depend on the decoder that happened to be current on the day you captured it. The same RF, decoded with whatever the software looks like in ten years’ time, gives a better picture than is possible today. That’s a real option to have.
The case is also stronger when the tapes are in difficult condition — sticky shed, weak signal, dropouts on every field. Conventional capture lets the deck’s old electronics make all the judgement calls about how to compensate, with no record of what the head actually saw. RF capture preserves what the head saw, and lets the decoder make better calls than the deck can.
And the case is stronger when the archivist genuinely wants the best possible master, knowing they may want to revisit it. A family archive of fifty tapes intended as a great-grandchildren’s archive is a different proposition from fifty tapes intended for next month’s family screening night. Both are valid; they don’t require the same amount of work.
If I had to put a single sentence on it: vhs-decode is a serious tool for tapes that deserve serious treatment, and most family archivists won’t have many tapes in that category. The right answer for most readers is to make peace with conventional capture, do it carefully, and treat the resulting file as good enough — because it is good enough for what most archives need to do.
The misconceptions that keep coming up
A handful of incorrect ideas about vhs-decode recur frequently enough to be worth addressing directly.
It’s lossless. True in one specific sense, misleading in the general sense. The RF capture itself is mathematically lossless — FLAC doesn’t throw any samples away, and the RF is the rawest signal available short of probing the head amplifier with an oscilloscope. But VHS as a format discards information at record time. The colour subsystem is heavily bandlimited; the luminance bandwidth is hard-capped by the FM modulation scheme. No capture path, however good, recovers information the format didn’t record in the first place. The .tbc and video file are also not lossless in the codec sense — they’re one version of the decoder’s interpretation of the RF, which is precisely why the RF stays as the long-term archive.
It needs a thousand-dollar deck. No. The community’s recommended entry-level decks are common, mid-priced consumer units from the late 1990s that turn up regularly on the second-hand market. The flagship deck most people aspire to is the Panasonic AG-1980, but the reason it’s recommended isn’t that it produces dramatically better pictures than other decks — it’s that the tap-point modifications and quirks are extensively documented, the chassis is accessible, and a couple of decades of community experience has been built around it. A simpler deck with documented taps is a perfectly reasonable place to start.
It’s only for VHS. No, despite the name. The same decoder handles VHS, S-VHS, Betamax, U-matic, the Video8 and Hi8 family, and the VHD disc format, each with their own format setting. The sibling projects cover LaserDisc, raw composite video, and HiFi audio. The name predates the project’s scope.
The decoded video is the archive. No — this is probably the most important point in the whole article, and the one the community is most insistent about. The video file is a rendering. The RF FLAC is the archive. If storage forces you to choose, choose the RF. The video can be remade; the RF cannot.
A consumer “TBC” box will clean up the captures. Almost never. The great majority of devices sold as TBCs to consumers are frame synchronisers — they stabilise frame timing but do nothing about the within-line jitter that’s the actual source of most VHS capture problems. vhs-decode is its own time-base corrector, in software, and is much better at the job than any consumer TBC box. The site has a separate article on the distinction and another on why a real TBC matters for the conventional path.
The BNC connector modification is essential. No. People still recommend swapping the RCA jacks on the CX card for BNC connectors as a quality upgrade. Measurements done with actual test equipment show no detectable difference. The mod is fine if you happen to want BNC connectors; it isn’t a quality improvement.
Remove the low-pass filter from the CX card. This is one that genuinely matters because the wrong advice has been circulating for years. Removing the LPF helps for LaserDisc RF capture, where the relevant signal sits above the filter’s corner frequency. For VHS RF, the LPF should stay — removing it makes captures worse and forces you to filter externally. The bad advice on this point predates the more careful community testing and is still findable on old forum posts.
What you cannot get from it
The honest section, which is the part of any technical article most worth reading.
vhs-decode does not recover information that wasn’t on the tape. If the colour was bandlimited at record time, the colour is still bandlimited after decoding. If a passage is permanently dropped because the oxide flaked off, no decoder brings it back. The advantages are about capturing what is there more faithfully and more reproducibly; they are not about magicking back what isn’t.
It does not make a damaged deck produce good captures. A tired head amplifier, dirty heads, a mistracking transport — all of these manifest in the RF capture just as they would in a conventional capture. The cleaner signal path doesn’t compensate for a deck that needs servicing.
It does not save you from having to think about the tape. Cleaning the heads, inspecting the spool, doing a fast-forward-rewind pass on a tape that’s been sitting in a box for thirty years, deciding whether a sticky tape needs baking before a capture pass — none of this changes. The capture chain is one part of a longer process.
And it is not finished. Active development means that the right command-line flags this month may not be the right flags next month. New format support lands, default behaviour changes, edge cases get found and fixed. This is part of why the RF capture is so valuable — it’s the only part of the workflow that doesn’t go stale. The decoders evolve; the RF doesn’t.
Where to go from here
If you’re trying to work out whether your specific situation justifies the effort, the questions to ask yourself are practical ones. How many tapes do you have, and how irreplaceable are they? Do you already have a deck you’d be willing to open, or would the hardware all be new? Are you comfortable with a command-line workflow, or is plug-and-play closer to your line? Are the tapes in good condition, or are dropouts and tracking problems already visible on conventional captures? The answers tend to make the choice fairly clear.
For most readers, the answer is going to be: do the conventional capture carefully, keep the resulting files safe and backed up, and revisit the question only if you have a small number of tapes you genuinely cannot replace. That isn’t a defeatist answer. It’s the proportionate answer for the work in front of most archivists, and there’s no shame in landing on it.
For the small number of readers for whom this is genuinely the right tool — you’ll already have a sense of which tapes the answer applies to. Start small. Pick one tape that matters. Get one capture chain working. Decode it. Look at the result against a conventional capture of the same tape. Then decide whether to scale up. The community will be there if and when you need it.
What’s next
The articles on why a Time Base Corrector matters and the difference between a TBC and a frame sync cover the conventional-capture side of the same territory, and are worth reading either way — the principles of time-base correction are the same whether you’re doing it in hardware or in software.
