Most family-archive projects arrive at the same question eventually. You've captured the tape, you've watched it back, you can see the soft picture and the speckles, and somewhere along the way you've read about an AI tool that promises to turn standard-definition video into something approaching 4K. Topaz Video AI is the usual name. The question is whether you can just run your tapes through that and skip the rest.

The honest answer is mostly no — but the nuance matters more than either the marketing or the purist forums make out. AI tools do have a real place in this work. The place tends to be narrower than the marketing suggests and broader than the purists allow, and where it sits depends on what you mean by “your tapes” and which copy you're talking about. So this is the version with the nuance kept in.

The shape of the answer up front

If you want the one-paragraph summary before the long read, here it is. For an archive master — the file you're hoping will outlive your hard drives and your hobby and possibly you — AI upscaling is the wrong tool, for reasons that come down to the way the model is built and the way the source is built. For a viewing copy — the file you actually watch, share, or upload — AI has a few narrow, useful applications, and a much larger number of expensive ways to make things worse. The rule that follows from that, and which the rest of this article is essentially an unpacking of, is the two-master discipline: capture cleanly, keep the original untouched, and treat any AI processing as something you do to a copy of that original, never to the original itself.

Why analog tape is the wrong test for AI upscaling

The thing worth understanding about an AI upscaler is what it was trained on. In the published research and in most open-source models — Real-ESRGAN, BasicVSR, the academic super-resolution literature — somebody takes a large collection of high-resolution digital masters (modern films, broadcast HD, photography), runs each one through an artificial degradation step (shrink to a lower resolution, add some compression noise, blur it slightly), and feeds the model billions of paired examples: degraded input on one side, clean original on the other. The model's entire job is to learn to reverse that specific artificial degradation. It's good at it, because that's what it has seen. Commercial tools like Topaz Video AI don't publish their training data, so the picture is less certain at that end of the market — but the community's experience with Topaz on VHS is consistent with what you'd expect from a model that hasn't seen much real tape in training: it treats the format's characteristic artefacts as image content rather than recognising them as part of the medium.

Now consider what comes off a VHS tape. The chroma signal that was recorded down at around 629 kHz, with usable bandwidth in the region of 400 kHz — roughly an order of magnitude less than the luminance gets. The interlacing. The white band of head-switching noise at the bottom of every frame. Chroma that doesn't sit on top of luminance quite right. Ghosting where the FM modulation has smeared a high-contrast edge. Sparkle and grain that move from one play to the next. Dropouts where the head briefly lost the carrier. None of these are the degradation the model was trained on. From the model's point of view they aren't degradation at all — they're image content, because they look unlike anything in the training pairs.

So the model upscales them. Faithfully. It treats the head-switch band as detail, the chroma fringing as detail, the sparkle as detail, and inflates all of it to whatever target resolution you asked for. The result looks plausible at a thumbnail. At full resolution it falls apart, because what you're looking at is a high-resolution rendering of the things you were hoping to remove.

There's a deeper version of this argument too, and it sits underneath everything else in this article. A VHS recording at roughly 240 lines of horizontal resolution for NTSC, or 250 for PAL — 240 to 250 TVL, television lines, in the analog-video shorthand — is the original at that resolution. The tape didn't fail to capture some higher-resolution master; the tape was the master at that resolution, and the analog signal stops there. Film, by contrast, has physical grain finer than most scans of it, and a higher-resolution scan of the same negative recovers real detail that was always there. Tape has no such reserve. There is nothing on the tape that 240 TVL of resolution was insufficient to capture. The implication is the one most people resist when they first encounter it: any pixel an AI upscaler invents above the tape's native resolution is invented. Not recovered. Not enhanced. Made up, by a model, from a prior of what it thinks the picture probably should look like. That prior was trained on someone else's content.

Image-and-video super-resolution as a field calls this the one-to-many problem: there are many different high-resolution images that could produce the same low-resolution one when downscaled, and the model picks one. The pick can be sharp and convincing. It isn't your tape. For science, medicine, and forensic work, this property is a disqualifier — you can't have a model picking among possible originals when the question is what was actually there. For entertainment, where the brain happily papers over plausible detail and the goal is “looks good enough”, it can be acceptable. Knowing which side of that line you're on matters.

The formal preservation field has implied this for years without quite saying it directly. The IASA, NDSA, FADGI and AMIA documents talk about authenticity, signal integrity, and the duty to preserve the original as the original — but none of them, as of the time of writing, have published a position statement that explicitly addresses generative AI restoration applied to consumer analog tape. The institutional silence is itself data. The principles are there; the specific guidance for this specific question hasn't been written down yet. Until it is, the principles are what we have to work from.

What AI tools genuinely help with on tape material

I want to be specific here, because the broad-brush “AI bad” position misses real ground. There are tools and techniques on this list that I'd use without hesitation when the situation calls for them — usually on a viewing copy, often as part of a larger pipeline that isn't AI-first.

Frame interpolation. Of all the AI-class tools in current use, frame interpolation is the one with the least friction. The open-source RIFE tool, and Topaz's Chronos model in the commercial world, both do a creditable job of synthesising in-between frames — useful when smoothing a stuttery handheld pan, recovering a dropped frame, or doing a careful framerate conversion. Standards-conversion work (30→24, say) tends to look acceptable on low-motion material and worse the faster the motion gets; that's true for AI and non-AI tooling alike.

Dropout inpainting on viewing copies (experimental). ProPainter and similar inpainting tools can do a reasonable job of filling small dropouts on a per-field basis. The output is currently 8-bit RGB and the pipeline is fiddly — separate field handling, conversion back to YCbCr — and it absolutely belongs in the viewing-copy lane rather than the archive lane, because the filled pixels are the model's guess at what was there, not a recovery of what was there. For a tape you actually want to watch, it can be a real improvement on the bare dropout. For an archival master, the bare dropout is the more honest record.

Light denoise on already-clean captures. The temporal denoiser inside Topaz, set conservatively on a clean SD source that's already been deinterlaced, produces results roughly competitive with traditional motion-compensated denoisers (SMDegrain, KNLMeansCL) for the last layer of fine hiss. Two preconditions matter. The capture has to be clean to start with — feeding heavy VHS noise into AI denoise tends to emphasise the ringing and chroma artefacts rather than remove them, because the model treats the artefacts as detail. And the source has to be deinterlaced first; AI denoisers do badly on interlaced source because they can't tell which fields belong to which moment. If both preconditions are met, AI denoise is a usable choice. If either isn't, the traditional toolchain tends to be safer.

Neural Y/C separation inside the decode pipeline. Down at the lower levels of the vhs-decode toolchain, there are neural-network-trained models doing chroma separation — the work of pulling colour information cleanly away from luminance in composite-encoded sources. These aren't AI upscalers in the consumer sense; they're trained models doing a narrow signal-processing task on the demodulated data. For the family archivist, the relevant point is that “AI” as a label spans a wide range of things, and some of them are doing genuinely useful work that has nothing to do with hallucinating extra pixels.

Nnedi3 inside QTGMC. The default community deinterlacer, QTGMC, has used a small neural network (nnedi3) for spatial interpolation for years. It's so well-integrated and so well-behaved that the community largely doesn't think of it as “AI” — it's just part of how QTGMC works. By the strict definition it is AI; in practice it sits closer to a careful interpolator than to a generative model. The point is that neural-network-augmented processing has been in the standard pipeline for a long time, doing useful work, without controversy.

Animation and cartoon content. AI upscalers tend to do considerably better on flat-shaded animation than on live-action material. Hard lines and large areas of single-colour fill are exactly the kind of structure the training data is full of. If the tape is an animated cartoon rather than a family wedding, the same tool can produce a meaningfully better result. Community-trained models specifically for anime and cartoon LaserDisc upscaling have existed for years.

Where AI upscaling falls down on tape — the failure modes worth knowing about

The other side of the same coin. These are the cases where I'd be cautious, or wouldn't use the tool at all.

Generative upscaling on VHS live-action. This is the headline use case and the one most family archivists arrive at. It's also where the structural mismatch between trained model and tape source is most visible. Generative upscalers tend to produce a characteristic appearance: sharpened, defined outlines on objects, with the fine detail inside the outlines smoothed away. Edge structure is enhanced; texture is lost. On atmospheric content, the model will often interpret real haze or low-light noise as defect and clean it out, producing a “clear day” version of footage that was overcast or dim. That isn't restoration; it's a different recording.

Faces. Family video is largely faces, and faces are the category AI upscalers handle worst. The result is the familiar plastic / mannequin / Snapchat-filter appearance — smoothed, generic, oddly youthened. For a family wedding or a child's birthday, the entire emotional content of the footage lives in those faces, and the AI version replaces them with the model's idea of similar-looking faces. The likeness is approximate. Personally I find it unsettling. I'd avoid AI face restoration on any footage with people in it I care about, and that covers most family material by definition.

Deinterlacing as a headline AI feature. Topaz Video AI is marketed in part on its deinterlacing capability. If you peek behind the marketing and look at the actual command lines the tool emits, it turns out the deinterlacer being used internally is bwdif — a perfectly good open-source FFmpeg filter, but not AI in any meaningful sense. The AI branding gets attached to the upscale or denoise stage that runs after deinterlacing. Topaz isn't doing anything wrong by using bwdif; it just isn't doing what the marketing implies it's doing. For deinterlacing specifically, QTGMC remains the community default, and there isn't a strong AI-based reason to switch.

Recovering dropouts on an archive master. This is a viewing-copy operation, not a master operation. The data isn't there. The model invents something that looks like detail and pastes it over the gap. On a viewing copy that's a reasonable creative choice — you're making something to watch, not an evidential record. On the master, I'd argue it's worse than leaving the dropout visible, because at least a visible dropout is honest about being damage. A hallucinated dropout fill is damage pretending to be detail.

Chroma reconstruction in the general case. Some experimental work in the community uses AI tools to clean up the chroma signal specifically — process the colour channels through an AI denoiser, then recombine with the original luminance — and the early results are interesting. The technique is genuinely fiddly, requires careful chroma/luma separation in the pipeline, and is firmly experimental rather than something I'd offer to a family archivist as a recipe. The point is mostly that AI applied surgically to a narrow part of the signal chain is a more credible use than AI applied broadly to “the whole picture”.

Topaz Video AI specifically — what it actually is in 2026

Topaz Video AI is the tool family archivists most often arrive at because it's the most marketed and the most consumer-facing. A short, calm description of what it is at the time of writing.

It's commercial software, subscription-based. Topaz moved to a subscription model in October 2025 and perpetual licences are no longer being sold; at the time of writing, the personal tier sits at roughly US$25 per month or US$299 per year, with a higher-priced Pro tier around US$699 per year for users who need local execution of the heaviest models. Pricing changes; the specific numbers are a current-state snapshot rather than a permanent fact.

Topaz bundles several different models under its banner. The older models — Artemis, Proteus, Iris — are conventional convolutional super-resolution and denoise models, available locally on consumer GPUs. The newest model, Starlight, is a generative diffusion-based upscaler. Starlight is the one most relevant to the “fix my VHS” question because it's the model marketed for difficult source material. It's also the most expensive to run: at standard tier it's cloud-only (you upload, the work happens on Topaz's servers, you download), and at Pro tier it can run locally if you have a high-end NVIDIA GPU with substantial video memory. Practical throughput on local hardware sits in the range of fractions of a frame per second on consumer cards; on a top-end RTX 4090 the reported figure is around 1.4 frames per second. For an hour of source material, that's a long compute job.

The community verdict on Starlight specifically, distilled across a few years of practitioner observation: impressive in some cases, broken in others, with the failure mode being exactly the one the structural argument predicts. On a face it might do a reasonable job of upscaling the genuine detail that was present; on a flat area where there's no detail to recover, it invents texture that wasn't there. Atmosphere shifts. The mood of a scene changes. That's intrinsic to how generative diffusion models work, not a Starlight-specific bug.

It would be unhelpful to either recommend or anti-recommend Topaz in general. The right framing is what it's used for. On a clean, deinterlaced SD capture, treated as a viewing-copy enhancement step rather than a magic fix, Topaz can produce results some practitioners are happy with. Used as a one-button “restore my tape”, it produces the failure modes described above. The tool isn't the problem; the use case is.

It's also worth knowing that several open-source alternatives exist and are being actively developed — Real-ESRGAN models accessed through ChaiNNer, VapourSynth plugins, the newer SeedVR2 model from ByteDance, various community-trained models for specific content types. Some of these may surpass Topaz on specific tasks; the field moves fast and the comparisons aren't stable from one quarter to the next. If you find yourself interested in the tooling for its own sake, the open-source world is where most of the experimentation happens.

The two-master discipline

The single thing every named preservation authority agrees on is the two-master discipline. IASA TC-04 and TC-06, FADGI, NDSA, AMIA, the Library of Congress, the BFI, the NFSA, the Cinémathèque suisse, the Österreichische Mediathek — they all land in the same place, often using different language. The preservation master is the unprocessed, lossless capture of the source signal. Everything else is a derivative. Processing belongs in the derivative.

Translated to the family archivist's situation:

• The master is the cleanest capture you can make, kept untouched. For an RF-based workflow it's the FLAC-compressed RF file plus the decoded FFV1 in MKV (see how vhs-decode actually works for what those mean and why). For a conventional CVBS or S-Video capture, it's the lossless FFV1 file. Either way the master is interlaced, full-resolution, untouched.
• The viewing copy is a separate file derived from the master. It can be deinterlaced. It can be upscaled — by any technique, AI or otherwise. It can be denoised, frame-interpolated, encoded down to a manageable size, uploaded to YouTube or kept on a phone. None of this touches the master.

The asymmetry of the two-master rule is the whole point. The master is the thing you cannot easily remake — you'd need the deck, the tape (which is degrading), and the patience for another capture session. The viewing copy you can remake in an afternoon, from the master, any time you like. So you make the master once, properly, with as little processing as possible, and you treat every viewing-copy decision as reversible. Twenty years from now, when better tools genuinely suited to tape exist — whether that's a model trained on real captures, or something none of us has thought of yet — you'll pull the master off the shelf and re-derive a better viewing copy. If you'd applied today's best AI tool to the master and thrown away the original, you've permanently locked your archive to today's tooling. That tends to look like a worse trade with each passing year.

The community follows this discipline naturally — the practitioners most active in tape capture keep their RF files, their interlaced FFV1 masters, and separately their derived 4K viewing copies, without much discussion. The institutional literature codifies it formally. The article you're reading is mostly an attempt to make it explicit for family archivists, who arrive at the problem fresh and reasonably ask whether the shortcut works. The shortcut doesn't work; the long path with two masters does.

The YouTube 4K upscale — a quick note

A pattern worth surfacing because it confuses the question. Practitioners who work with tape captures routinely upscale their output to 4K before uploading to YouTube. From the outside this looks like an endorsement of high-ratio upscaling, and by extension a possible endorsement of AI upscaling. It isn't.

The reason for the 4K upscale is that YouTube allocates bitrate by stream resolution. A 1080p stream gets a relatively low bitrate budget and tends to crumble into macroblock noise on detailed material; the same source uploaded at 4K gets a much larger budget and survives the compression considerably better, even though the underlying detail is still SD. The upscale itself is almost always done with a conventional sharp resampler — Spline64 or Lanczos — not with an AI model. The point isn't to invent detail. The point is to fool YouTube's bitrate allocator into giving the upload more bandwidth.

So if you've watched a YouTube video of someone's VHS capture and it looks reasonably good, the cause is unlikely to be AI restoration. It's more likely a conventional sharp upscale to 4K, applied for the bitrate hack, with whatever processing was done sitting upstream of that step. The YouTube practice isn't an argument for AI upscaling either way; it's a platform quirk, with its own logic.

Where AI does sit in institutional archives

For completeness, because it's worth knowing that the formal field hasn't simply banned AI from the preservation workflow. Several named institutions and practitioner-grade tools use machine learning openly and routinely. The pattern is consistent: AI is used for description and detection, not for signal generation.

The Institut national de l'audiovisuel in France runs AI across millions of hours of archived material for speaker identification, shot detection, OCR and scene classification — generating metadata, not modifying video. The DVRescue toolkit (developed by MediaArea with the Moving Image Preservation of Puget Sound) uses pattern-recognition techniques to flag dropouts and tape defects, leaving the decision to repair or not to the operator. QCTools (Dave Rice and BAVC) algorithmically characterises video to surface artefacts; the tool deliberately does not modify the file. iZotope RX is widely used in AV archives for audio restoration, but exclusively on access copies, never on the preservation master.

The line the field has settled on, in the absence of formal AI-restoration guidance: AI for description, defect detection, and access-layer audio repair is accepted; AI for signal generation, super-resolution, or generative restoration of preservation masters is not endorsed by any named institutional authority I'm aware of. The Criterion Collection has disclosed AI-based noise reduction on some commercial restoration projects, with the underlying high-resolution scan preserved separately as the authoritative source. That's the closest the commercial world has come to an AI-restoration standard, and it sits comfortably inside the two-master discipline rather than displacing it.

What to do if your tapes matter

Reduced to a practical plan, what falls out of all this is short.

Capture the tape cleanly, once, to the best master format you can manage. The exact format depends on the workflow; the principle is the same either way. The vhs-decode explainer covers what RF-based capture is and when it's the right path; the hardware article covers the device choices in 2026. For a conventional pipeline, a TBC-corrected lossless FFV1 capture into MKV is the master format the community has settled on.

Keep the master untouched. Back it up. Don't run it through AI tools, don't deinterlace it, don't denoise it, don't upscale it. The master is the thing you preserve.

Derive a viewing copy from the master. This is the file you actually watch, share, and upload. Here AI tools are reasonable — for frame interpolation, for light denoise on a clean source, for dropout inpainting on small gaps if you're inclined to experiment, for a conservative upscale if you intend to view on a large screen. The viewing copy is by definition disposable. You can re-derive it from the master any time you change your mind.

If you find a tool that genuinely helps, save the AI-enhanced output alongside the master, never as a replacement for it. The question “can I run my tapes through Topaz” has a sensible answer: yes, on a copy. The question “is this my archive now” has a firmer one: no, the unprocessed master is.

The reason the two-master rule is the whole answer, rather than just one option among several, comes down to what these tools can and can't do. AI upscaling is invention. It adds things — pixels, frames, edges, textures — that weren't on the tape. Invented content can be plausible, attractive, sometimes preferable as a viewing experience. It is not a recovery of what was recorded. The line between processing (subtracting things that obscured the signal) and invention (adding things that weren't in the signal) is the line between work that's reasonable on a preservation master and work that belongs only in derivatives. Hold to that, and the rest of the question more or less takes care of itself.

What's next

How vhs-decode actually works is the layman explainer for the RF-capture pipeline that produces the cleanest possible archive master. Capture hardware in 2026 is the device-selection companion piece for anyone weighing the hardware side of a clean capture path.

If you've already decided that vhs-decode is the right tool for your tapes, the next question lands almost immediately: which capture hardware should I actually buy? The open web has remarkably little to say on this. The GitHub readmes assume you've already picked. The forum threads are years out of date. The Discord channels where the real conversation happens are deep and unsearchable, and most of the useful comparison sits in scrollback nobody has written up. The point of this article is to translate that scrollback into something a person sitting in front of these options can use to make a decision.

A note on scope before going further. This article assumes you already have a working sense of what RF capture is and why anyone bothers with it — the bit depth, sample rate, head-amplifier tap, the whole conceptual move from "capture the deck's output" to "capture the deck's input". If any of that is unfamiliar, the vhs-decode explainer is the right place to start. The piece you're reading now sits one step beyond that — picking which hardware path to commit to, and dealing with the awkward second question that follows immediately after: how to capture audio in sync with the RF, because most of these paths capture RF only and treat audio as somebody else's problem.

There are five paths worth considering in 2026. Two are production-ready, one is mature but increasingly legacy, and two are still firmly in the "watch this space" category. I'll walk through each, then settle the audio-with-the-DdD question, then try to offer something resembling a real recommendation.

The 2026 RF capture baseline — CX2388x + Clockgen Mod + Rewolf amp

If you've read any vhs-decode discussion in the last year and a half, this is the build you've seen mentioned more often than any other. It's the current consensus starting point — the cheapest viable RF capture chain, the one with the most documentation, the one with the largest community of people who have got it working. It's the recommendation I'd give first to anyone who isn't sure where to start.

The build is three parts. A Conexant CX2388x capture card, in either PCI or PCIe form — sold originally as a generic TV-capture card, available second-hand for somewhere between fifteen and forty dollars depending on condition — does the actual analog-to-digital conversion. (The chip itself is fundamentally a PCI device; cards that present on PCIe slots do so via a bridge chip, and the cxadc driver doesn't care which.) A Clockgen Mod board (a small Raspberry Pi plus a Si5351 clock generator and a PCM1802 audio ADC, a community-designed PCB) replaces the CX card's stock crystal with a programmable shared clock, and adds an onboard 24-bit stereo audio ADC for line-level audio. A Rewolf ADA4857 amplifier board, fitted inside the VCR, buffers the deck's high-impedance head-amp test point down to the 75-ohm input the CX card expects to see.

Each of those three parts is doing real work. The CX card on its own is fine as a fast ADC, but its stock 28.6 MHz crystal locks it to a single sample rate, and — more importantly — its clock has nothing to do with whatever clock your audio capture is using. Two clocks from two crystals drift, because manufacturing tolerance and temperature drift make every crystal slightly different. Over a two-hour tape that drift accumulates into audible audio-versus-video sync error. The Clockgen Mod fixes both problems at once: it lets the CX card sample at 20, 28.6, 40 or 50 MHz and switch live during capture, and it derives the audio ADC's clock from the same source, so video and audio are bit-exact synchronous for the entire length of the recording. The Rewolf amplifier is the other half of the puzzle — the head-amp test point inside a VCR is an internal circuit node that was never designed to drive a load, and connecting a capture card directly to it pulls the signal down and distorts what you measure. The amplifier sits invisibly between the test point and the cable, presenting a high-impedance load to the deck and a 75-ohm source to the card.

A reasonable rough budget for the whole build, deck not included, sits somewhere in the 150 to 250 US dollar range. The CX card is fifteen to forty used. The Clockgen Mod is sold as a kit via a community Ko-fi store; the exact price moves with chip availability and shipping, and I'd check the current listing rather than commit to a number here. The ADA4857 amplifier is around forty dollars when in stock, though it was reported sold out at one point in early 2026, which is worth being aware of — these are small-batch community-built products, not high-street items. Cables, connectors, RG178 or RG316 coax for the short runs inside the deck, and a few odds and ends bring the total up.

The skill floor is real but manageable. The CX card needs its stock crystal removed (a single SMD desolder). The Clockgen Mod ships as a kit you assemble — surface-mount soldering on a small PCB. The amplifier wants per-deck resistor tuning to match the signal level coming off your particular VCR's tap point, which means either following one of the documented combos for a known deck model or measuring with an oscilloscope and adjusting by hand. None of this is exotic, but none of it is plug-and-play either. Plan on a weekend.

What you end up with is, as of mid-2026, the build the community most commonly recommends for VHS RF capture. It isn't because the raw specs are the highest available — the DdD's 40 MS/s at a full 10 bits gives more data per second than the CX card in any mode — but because the CX path gets the practical job done at the lowest cost, with synchronous audio in the same package, and with the deepest documentation and community support of any current path. The configuration is 40 MS/s at 8-bit, or 20 MS/s at 10-bit if you switch the driver's tenbit flag on — you trade sample rate for bit depth, you don't get both at once. Synchronous 24-bit audio. Linux-native via the cxadc driver. It works, it's documented, and the community knows how to help when something goes wrong. One structural limitation is worth flagging up front: the CX card needs a free PCI or PCIe slot, which rules out laptops, Macs without a Thunderbolt-to-PCIe enclosure, and compact desktops with no expansion. If that's your machine, the DdD (next section) is the USB-3 alternative. For most readers with a tower desktop who want to start now, the CX path is the answer.

The DomesdayDuplicator — the purpose-built path

The DomesdayDuplicator (DdD for short) is the original RF capture device the community produced, designed years before the CX-card workflow had been figured out. It's built around a DE0-Nano FPGA development board, a discrete analog ADC, and a Cypress FX3 USB-3 endpoint. The FPGA's job is to buffer samples against USB jitter so that no frames are dropped at sustained rates. It samples at 40 MS/s at 10 bits, with a fixed onboard low-pass filter at around 14 MHz.

It was originally built for LaserDisc, where the higher sample rate and the LD-tuned filter are both important. For VHS, the rate is more bandwidth than the format strictly needs and the LD-optimised input stage is mild overhead — but the device still works perfectly well, and the 10-bit depth (a factor of four more amplitude resolution than the CX card at 8-bit) is part of why some archivists prefer it. I use a DdD myself, for what it's worth — the original 10-bit / 40 MS/s configuration. Whether that bit-depth advantage produces a measurable improvement in the decoded picture compared to a CX card running at the same rate is, honestly, an open question. The principle that more information at capture time is better than less is sound, and I'd rather have data I don't need than lack data I do need. But the claim that one card produces visibly better video than another is the kind of thing I'd want side-by-side captures to settle, not first-principles arguments, and the side-by-side captures haven't been published.

The reasons people pick the DdD are usually some combination of: it was the device they bought when they first got into RF capture and the workflow still works fine, they value the slightly higher bit depth, or — for LaserDisc work — there is no real alternative on offer. The DdD remains the LD reference device. Nothing has replaced it on that side.

The reasons people might abandon it for VHS work tend to come down to two things. The first is audio. The DdD captures one RF channel and nothing else; audio is a separate problem to solve, with no single canonical answer (more on this in the audio section below). The second is USB reliability. The FX3 + libUSB path has a reputation for being quietly fragile on Windows — particularly sensitive to USB-3 cable quality in a way that produces silent capture corruption rather than obvious failure. Linux users report fewer problems. The common first-step debugging advice is to swap the cable, which is exactly the kind of advice you only need if cable quality is doing more work than it should be.

On cost, the historical PCBway path was around 130 US dollars in 2023 for five bare boards plus one fully assembled — a figure that gets quoted occasionally but is now several years old, and PCBway pricing, component availability and chip costs have all shifted since then. I wouldn't commit to a 2026 figure without checking; the more useful thing to know is that the ordering path is still available, my own DdD came that way, and the community has walked dozens of people through the process. Pre-built units occasionally appear second-hand, though availability is hit-and-miss.

The honest summary in 2026: the DdD is mature, supported, and still in active use, but newcomers to the project are no longer routinely pointed at it as the first hardware to buy. For VHS work specifically, the CX-card-plus-Clockgen path is the more common recommendation. For LaserDisc work, it's still the answer.

MISRC V2.5 — the integrated successor

The Multi-Input Simultaneous Raw Capture board (MISRC) is the longer-term aim of the community's hardware effort. It's the device a CX-card-plus-Clockgen-Mod build wants to grow up to be: dual 12-bit ADCs and the clock generator and four-channel integrated audio capture all on one PCB. One USB-3 connection, one board to assemble, no clock-sync wiring to get wrong. The current dev prototype (V1.5a) is in production and people are using it, and a tidied next revision (V2.5) is approaching release at the time of writing.

The pitch is straightforward. Twelve-bit RF on two channels means you can capture video RF and HiFi RF simultaneously, both clocked from the same source, on a single device. A four-channel integrated baseband audio ADC — clock-synced to the same master — handles line-level audio capture in the same unit, so for the common case of a linear-track-only tape you get clean baseband audio from the deck's RCA outputs without needing a separate Clockgen Mod, and for HiFi tapes you have the option of capturing HiFi RF on the second channel for software re-decode. The new anti-alias filter handles LaserDisc cleanly, which the V1.5a doesn't. And the capture software is being explicitly aimed at cross-platform stability — the design intent is that it should be the device a Windows user can buy, plug in, and have working.

The catch is that V2.5 isn't shipping yet. As of this writing the dev batch has been built and is in the developer's hands, and the remaining blocker is software stabilisation — particularly USB stability across platforms. It's positioned as a release version rather than a tinkering development version, and the project's stance is to hold the release until it actually works that way. That's the right call, but it does mean the article you're reading can't give you a release date.

The price is also higher. V1.5a is around 90 US dollars depending on chip pricing and tariff exposure. The V2.5 dev batch is being floated in the 350 to 375 GBP range all-inclusive — board, case, capture card, tested and shipped — which is a dev-batch margin-rate price rather than a production price. The expectation is that production V2.5 may come down somewhat with cheaper fabrication, but I wouldn't budget for that until it's confirmed.

The MISRC also doesn't replace the Rewolf amplifier on the deck side. The amplifier is required regardless of which ADC you pair it with; the MISRC is the ADC half of the equation, not the amp half.

For a reader picking hardware right now, the practical question is whether to start with CX-plus-Clockgen and switch when V2.5 ships, or to wait. My honest answer is to start now. The CX path works, parts are available, and the conversion from one to the other is a card swap rather than a workflow overhaul — the deck-side amplifier and tap point don't change. Waiting for the next thing has cost the project a steady stream of would-be users over the years, and the captures you didn't make while waiting are captures you can't go back and make.

The cheap-and-experimental direction — hsdaoh and the RP2350 boards

There's a parallel line of work that doesn't fit the same CX → Clockgen → MISRC evolutionary story, and it's worth understanding even if you don't end up using it. It's based on a clever observation: cheap HDMI capture sticks contain ADCs running at impressive sample rates and the silicon has registers that let you bypass the video-pipeline processing and ingest raw data instead.

The project is called hsdaoh — High Speed Data Acquisition over HDMI. It repurposes the MacroSilicon MS2130 / MS2131 family of HDMI capture sticks (the ones sold on AliExpress for around thirty dollars each) as raw-data ingest pipes. The sticks have to be reflashed with a custom firmware via an open-source tool, and then they happily push raw 12-bit ADC samples back to the host at well over 175 MB/s sustained. Pair the stick with a Raspberry Pi Pico 2 (the RP2350 board, around five dollars) running matching firmware, plus one or two cheap AD9226 ADC modules, and you have a usable 12-bit 40 MS/s capture chain for a BOM target of around fifty dollars total. A PCM1802 audio ADC module covers audio in the usual way.

A community-designed PCB integrates the RP2350, two AD9226 ADCs and the audio path into a single board, with reported performance around 38 dB SNR. Several people have built it; it produces working captures. Going through the project's hardware-hacking discussion channel turns up a handful of working builds in production use.

So why isn't this the recommendation? A few reasons, and they're worth being direct about. There is no anti-alias filter on the front end — you need to build a small external low-pass filter as part of the input stage. There is no production kit available; you order the PCB from the design files, source the components yourself, and flash the firmware yourself. The discussion channel where this work happens is a research-and-development conversation rather than a beginner-support channel, and the software side is still evolving — Windows support is partial, and the documentation lags the current pull requests. The 38 dB SNR figure floating around for the dual-ADC RP2350 board is the designer's own measurement; to my knowledge it has not been put head-to-head against a fully-set-up CX card in controlled conditions, so comparing it directly to the CX card's commonly-quoted figures is misleading.

The honest take: if you enjoy the build, want a sub-fifty-dollar BOM, and don't mind being a contributor as much as a user, this is one of the most interesting directions in the project. If you want to capture a tape this weekend without any of the above, it isn't the recommendation. The disruptive potential is real — if a kit version ever materialises, the entry cost of the project halves overnight — but that hasn't happened yet, and predicting when it might isn't something I'm in a position to do.

Audio with the DomesdayDuplicator — four paths

If you go the DdD route — either because you already have one, because you specifically want the 10-bit depth, or because you're working on LaserDisc as well as tape — the audio-in-sync question is its own small project. The DdD captures one RF channel and nothing else. Audio has to come from somewhere, and it has to share a clock reference with the DdD if you want it to stay in sync over a long capture. There are four ways people are solving this in 2026, and they're worth laying out together because the right choice depends on what you already have on the bench.

A quick note on terminology, because it trips people up. Baseband audio is the deck's analog audio output — the signal at the RCA sockets after the deck has decoded whatever was on the tape. That's the audio most VHS tapes carry as a linear track recorded along the edge of the cassette, and it's also the audio you get from a HiFi-equipped deck after it demodulates the HiFi carriers internally. HiFi RF is a different thing: the FM-modulated audio carrier pair sitting at around 1.4 megahertz on the helical drum tracks, captured before any in-deck demodulation. Capturing HiFi RF directly (and decoding it in software) only matters for tapes that were recorded in HiFi to begin with — and the majority of consumer tapes from the early eighties through into the mid-nineties were linear-track only. For a family archivist working through home videos from that era, capturing clean baseband audio in sync with the video RF is the actual problem to solve, and HiFi RF capture is a non-issue.

The first path is the Clockgen Lite mod plus an external audio ADC and the ddd-capture-toolkit project. This is the route I use. The toolkit has a specific history. In April 2025 a number of people, myself among them, discovered after the fact that they had built or bought a DdD without realising it wouldn't capture audio in the same pass — the DdD's official capture app is GUI-only, and a GUI-only app can't be coordinated with a separate audio capture from a script. The toolkit started as a fix for exactly that. Its load-bearing technical contribution is adding command-line support to the official DdD capture app, which lets a single command kick off the RF capture and a synchronised audio capture together. That CLI patch was submitted upstream as pull request #2 on the official DomesdayDuplicator-gui-app repo in January 2026; it's still open with no maintainer activity at the time of writing, so the toolkit runs from a fork of the official app that's periodically resynced to upstream master when significant changes land. If you'd like the CLI support to land in the official app, the PR thread is the right place to say so. A Clockgen Lite (a simpler, hand-wired version of the Clockgen Mod scaled down for the DdD's needs) shares the DdD's master clock with a PCM1802 audio ADC module — the same chip used in the full Clockgen Mod for the CX-card workflow. The audio path produces a -72 dB noise floor at 24-bit, which is to say it's perfectly clean. I've run six-hour captures with this setup. One honest limitation worth flagging: the audio-video alignment still requires a one-off manual calibration pass — a known alignment tape played through the deck so the toolkit can lock the relationship between the two streams. The toolkit creates the alignment file for you and walks through the recording, but the alignment itself isn't yet automatic; I don't know that this is solvable with the DdD at the hardware level. The trade-off is the soldering and wiring of the Clockgen Lite mod, the fact that there's no kit version — you build it from documentation — and that one calibration pass.

The second path is a recent piece of community work: a custom FPGA gateware build for the DE0-Nano that multiplexes audio samples from the DE0-Nano's own onboard ADC128S022 directly into the DdD's RF data stream. This is the cheapest possible path because the audio ADC is already on the board — it's part of the development kit and the DdD just doesn't use it by default. Two 5 kΩ resistors and a 68 µF capacitor per channel are the only external parts needed. The catch is that the onboard ADC isn't an audio-grade part; the achieved noise floor is around -30 dB, which is honest but audibly hissy compared to a PCM1802. The author's own framing is that it is good enough rather than excellent, which strikes me as fair. The other catch is that this is custom FPGA work, with the gateware partly LLM-generated and described as a first-time FPGA project by its author. The code works; anyone integrating it upstream would want to read it carefully first.

The third path is a variant of the second, swapping in a PCM1802 for the onboard ADC. Same gateware, same multiplexing-into-the-RF-stream idea, but with the PCM1802's clean 24-bit / -72 dB audio going into the DE0-Nano's spare FPGA pins instead of using the dev board's onboard ADC. You get the audio quality of path one with the no-separate-USB simplicity of path two. The trade-off is that you have to build the gateware (Quartus for the DE0-Nano), flash it to the FPGA, and demultiplex the audio out of the RF stream in post-processing. The PCM1802 module itself has a small build gotcha worth knowing about — the mode jumpers on the back of the module need a specific bridge configuration, and people regularly get this wrong on first build.

The fourth path is a purpose-designed daughterboard for the DdD that wraps the third path in a production-friendly PCB rather than a hand-wired prototype. The first revision had a connector flipped and the wrong board dimensions; the second revision works correctly and is documented at github.com/JonasCz/DomesdayDuplicator-audio-ADC with compiled firmware in the releases section. There's no production batch, but the design files are available for anyone willing to order the board themselves. One open question worth flagging: a 5 kHz whine in the baseband audio has been reported, appearing the moment the DdD starts capturing — not present when it's idle. The cause hadn't been identified in the material I had to hand. If you go this route, expect that it may or may not still be an issue depending on whether it's been chased down by the time you read this.

One thing all four DdD audio paths share: none of them captures VHS HiFi RF directly. They all rely on the deck's internal HiFi demodulator (when the deck has one and the tape was recorded in HiFi) and capture the resulting baseband audio at the deck's output. Capturing HiFi RF separately — sampling the 1.4 megahertz carrier pair from the head amp and decoding it in software — needs its own RF channel in the capture chain. The DdD has one RF input, occupied by the video RF. The gateware approaches multiplex a single baseband audio stream into the existing RF data stream; there's no room for a second RF capture.

Whether any of this matters depends on what's on the tape. For the majority of family-archive tapes — home videos from the eighties and into the mid-nineties, recorded linear-track only — there's no HiFi RF on the tape, the deck plays back from the linear track, and the baseband audio at the deck's output is everything there is. The four paths above cover this case completely. If your tapes were recorded in HiFi VHS specifically — later consumer camcorders, commercial pre-recorded tapes, some 90s home recordings — and you want to re-decode the HiFi RF in software rather than trust the deck's internal demodulator, then the DdD is structurally the wrong device. The architectures that handle HiFi RF directly are the CX-card-plus-Clockgen-Mod build with a second CX card, and the MISRC (V1.5a with HiFi on channel 2, or V2.5 with both video and HiFi natively).

A decision tree, given different starting points

The honest answer to the question of which one to buy depends on what you have on the bench, what you want to capture, and how much fiddling you enjoy. Some rough recommendations follow, expressed as how I'd think about it rather than as one-size-fits-all.

If you have no rig yet and want to start now, I'd go CX2388x + Clockgen Mod + Rewolf ADA4857 amp. It's the cheapest viable working chain, the documentation is the best of any path, and the community can help when something goes wrong. Two hundred dollars and a weekend gets you a working setup. The caveat is that this assumes a desktop tower with a free PCI or PCIe slot — see the next point if that isn't you.

If your machine has no PCI or PCIe slot — laptop, Mac, or compact desktop — the CX-card path isn't an option, and the DdD over USB-3 is the obvious answer. The audio-pairing approaches in the section above all work over USB. The MISRC V2.5 will be a USB-3 alternative once it ships, and worth waiting for if you can. hsdaoh paired with the RP2350 board is another USB-based direction but isn't beginner-ready.

If you already have a DdD — and this is partly speaking from my own experience — keep using it. The bit-depth advantage is real if not dramatic, the LaserDisc capability is real if you ever cross over to that side, and the audio-sync problem is solvable with any of the four paths above. The Clockgen Lite plus the ddd-capture-toolkit is what I use; the daughterboard approach would be where I'd look first if I were starting that piece today rather than a year ago.

If you specifically want the cleanest, most-integrated future-proof option and you're willing to wait — the MISRC V2.5, when it ships. Two channels of 12-bit RF, four channels of integrated audio, single board, single USB. It will be the right answer when it's ready. Right now it isn't quite ready.

If you want the lowest possible cost and you enjoy the build, hsdaoh paired with a community RP2350 dual-ADC board is the interesting direction. Plan on contributing to the project as much as consuming it, and accept that some pieces of the workflow are not yet plug-and-play.

If you specifically need to capture VHS HiFi RF as well as the main video RF, the DdD is structurally the wrong choice. Either two CX cards on a Clockgen Mod with both clocked synchronously, or wait for the MISRC V2.5 with its dual channels.

If the tapes you care about are LaserDiscs, the DdD is still the answer; the MISRC V2.5 will join it once it ships.

What's coming

The landscape is still moving and a few items are worth keeping an eye on. The MISRC V2.5 release will be the most consequential single event — when it ships and stabilises, it becomes the obvious starting recommendation, and CX-plus-Clockgen takes a step back into legacy. The RP2350 dual-ADC board, if it ever productionises as a kit, halves the entry cost of the whole project; that would change everyone's recommendation. hsdaoh as an ecosystem may mature to the point of being beginner-friendly, though I wouldn't bet on the timeline. The DdD audio daughterboard may evolve into something with kit availability and the 5 kHz whine resolved. The CX2388x cards themselves are second-hand-only and the supply is finite — at some point in the next several years the path is going to disappear, which is part of why the MISRC matters as a successor.

None of these is far enough along to base today's purchase decision on. They're worth keeping a soft eye on rather than a held breath.

What's next

The vhs-decode explainer covers the wider question of whether this approach is right for your tapes at all, if you're still weighing that. The TBC versus frame sync article and the longer piece on why a time-base corrector matters are relevant if you're also considering a conventional capture path alongside this one — the principles overlap, even though the hardware doesn't.

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 somewhere between 3.4 and 4.4 megahertz. The colour information is sitting underneath at around 629 kilohertz on PAL or 688 kilohertz on NTSC, 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, which I maintain, is one way to handle that pairing. 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 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, sits over the top of the capture and decode steps with the explicit aim of 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.

So far in this series we've talked at an overview level, shared the quality differences between different ways of capturing so you can see for yourself and covered some potential buying guides. In this part we're going to assume you have now mostly decided a pathway and are ready to progress to make your first capture.

Getting the most from your player

• Always clean the heads with isopropyl alcohol and cotton buds or even better a chamois bud to ensure they are physically clean
• Be careful cleaning the rubber capstan, clean it lightly, over cleaning will (especially on older decks) make it slip and as a result you won't be able to use the deck until you replace or restore the roller. This happens due to older rubber capstans becoming hard with age and when you clean them too much, the dirt happens to be the only thing that was maintaining consistent grip and as a result you'll have problems with your capture

How to maximise the audio quality

Tape Mould - If a tape has mould on it, not only can it clog up your nice clean heads, but it will also affect the sound and picture quality. It is strongly recommended to do a general clean on these tapes before recording.

Tape Mould and other issues

Depending on your situation, there may be various issues with your tapes that could include mould, sticky tape syndrome, etched plastic housing that can cause tape breakage etc. As the years go by these tapes are going to get worse. If you're concerned about it and want your tapes to last longer, get them cleaned and store them in a dehumidified cabinet.

General Clean

First step here is to do a general external inspection of the tape. If there is white dust like in the picture, you will need to disassemble the tape and clean it. Unfortunately, it's basically impossible to find a tape cleaning device these days, so the only option available to most is to disassemble the tape and clean it by hand.

For this you will need:

• Cotton Buds / Or Chamois Swabs / Microfibre Cloth
• Isopropyl Alcohol
• Screwdriver - preferably Philips
• Can of compressed air
• Spare tape player
• Optional - Blank Cassette tapes that can be undone with a screwdriver

The below outlines the basic process I use:

1. Rewind the tape in the donor player
2. Remove the cassette and disassemble the case (If the case cannot be unscrewed and must be forced open, find a new blank cassette tape that can be unscrewed and transfer the magnetic tape into it. If possible, transfer the tape onto the new spools as well. You can still buy these online in various forms (or just buy some second hand blank tapes - preferably with the plastic seals still on.
3. With the cassette still open, blow away the loose mould with the can of compressed air (recommend do this outside or a place that can be cleaned afterwards)
4. Completely remove the tape spools from the cassette taking care to do so by holding on to the covering plastic protectors on either side. This will help prevent the tape from unravelling
5. Clean the inside of the case with isopropyl on a microfibre cloth. Also clean any spooling rollers, both sides of the plastic covering protectors etc. It's also a good idea to clean the leader path (first few cm's of the tape roll) manually as well as these cannot be cleaned by the remaining steps. Don't forget to clean inside the spool where the tape will go once it's been forwarded as well with isopropyl and I find a microfibre cloth on your finger is quite good.
6. Reassemble the case
7. Insert the tape into the spare cassette player whereby the front casing has been taken off so you can have direct access to the tape path
8. Fold a thin covering of microfibre cloth over a cotton bud and drop a decent amount of isopropyl alcohol onto the end of it, if this is too big, just use a Chamois Swab (though these can be hard to get)
9. Press the isopropyl covered cloth / swab / bud onto the outside facing part of the magnetic tape in the tape path on the right hand side (before it enters into the spool). It's very important to makes sure you do this on the right hand side when fast forwarding or the tape will jumble up and be damaged.
10. Fast forward the tape while holding the swab on the tape, until the end of the tape is reached. If you feel you need to add more isopropyl, you can do that by stopping part way and re-applying or another system of your devising
11. Once at the end of the tape, remove and disassemble again
12. From here, repeat from step 3 -8, except this time for step 8 put the microfibre cloth on the left hand side of the tape path (before it enters back into the spool and rewind. Like before it's very important to be on the left hand side to avoid damaging the tape
13. Open the cassette one last time and do step 3 again
14. Completed

Tip 1: It's safest to wear a full-face respirator with ABEK2P3 filters. Most types of mould can be hazardous to your health and should never enter your lungs or eyes, wash/wet clean your mask before removing it and showering. 

Tip 2: Practice this first on an unimportant tape. It's easy for the tape to unravel and end up in a mess.

Tip 3: If you see parts of the tape are coming off or the tape is making screetching sounds, you probably have sticky tape syndrome. To fix this, it requires baking your tape. For more information on currently identified tapes exhibiting this problem please see the Wikipedia article on the topic.

Tip 4: You will find a point where you can rest one finger on the player somewhere as a nice steady point while you hold your finger and cloth over the tape. Yes this is a bit hacky, but I haven't found a better way, please do let me know if you find one!

Once this is complete, you should now have a clean deck to play your tapes in and mould free tapes to give you the best audio quality possible.

You are now ready to do an actual capture!

NEXT: Capturing Analog Video Tapes - Part V - Capturing! (Coming soon)

Oh, and I also fixed the annoying footer at the bottom of the community forums.

D.A based in Auckland, New Zealand customer services go be on normal services. Highly Recommended.

D.A based in Auckland, New Zealand customer services go be on normal services. Highly Recommended.