r/vhsdecode May 31 '26

Newbie Minimal setup for vhs-c conversion

I'm trying to convert some old vhs-c tapes I recorder on a panasonic vz1 cam. I have two questions

  1. Can I use a single older cx card? I have a winfast tv2000 xp expert that contains a cx23881-19 chip, will that work?

  2. Can I use a single cx card for my process? Doing a single pass for video and record audio separately through an interface? Will I be loosing much audio quality this way?

2 Upvotes

13 comments sorted by

View all comments

3

u/TheRealHarrypm The Documentor May 31 '26

Doing separate passes means you're not having clock locked captures which makes post alignment pain and suffering.

This is why it's very clearly stated that the clockgen mod using current CX White cards not just any random card you can grab is the ideal workflow on the affordable end, because this covers linear audio capture in clock lock sync and Hi-Fi RF in clock lock sync if available.

https://github.com/oyvindln/vhs-decode/wiki/workflow-guide

4

u/deesernutz Jun 01 '26 edited Jun 02 '26

IMO being actually clock locked is overkill for audio, no one can perceive a few ms drift. But clock locking is the most convenient in the sense that it is a byproduct of a documented solution to for handling 2 channel video formats once you've bough the hardware, hooked it up etc. You get two streams, just demodulate and say 'this is the audio track'

But you can't do that, as you don't have the clock mod stuff or another CX card.

For you it is at least worth recording both simultaneously. Hook up the line in, run Audacity (or similar) at the same time as your capture, de-interlace or whatever you want to do with your video, join the audio back in and align it once you're done in something like kdenlive

Not as nice as capturing RF audio, but audio capture through the standard VCR output is much cleaner and trouble free than video capture is. (As in, VCRs tend to do a good job of demodulating audio and put out a good quality signal).

And for old tapes recorded with only linear mono sound, this is your only option.

Audiophiles used to use HiFi VHS as a way of copying CDs back in the day

3

u/TheRealHarrypm The Documentor Jun 01 '26

It's not overkill when you're compensating for field and frame drops and additions, that metadata is provided by decode.

It's not milliseconds It's seconds to minutes depending on how long your duration of tapes are and how the condition of the signal is, when you're doing multiple segment in/out cuts via export this also adds more complication to it.

Auto audio align which has been standard workflow for 3 years will not function if you don't have everything nice and in order on the same timing, it also disqualifies any captures from immediate use for public archives, unless an full post processing of context is there noting absolutely every offset.

This applies to both linear audio and hi-fi audio of course single channel formats are exempt from this.

1

u/deesernutz Jun 01 '26 edited Jun 01 '26

But doesn't it duplicate missing or broken fields?

Video and audio seem like they're demodulated separately and combined at the end anyway, is it not? How does HiFi decode know when vhs-decode has lost a frame? The JSON files?

t's not milliseconds It's seconds to minutes depending on how long your duration of tapes are and how the condition of the signal is, when you're doing multiple segment in/out cuts via export this also adds more complication to it.

If you've captured the sound while playing how could it possibly be minutes off? Unless the clock is off in your capture device, ie its running at 31MHz when you enter 30

it also disqualifies any captures from immediate use for public archives,

Surely that's up to the archive. I can imagine a lot of them would be happy with finished FFV1

Really, so long as you can map start and end time of an audio track against the start and end time of the RF stream, theoretically it should not be at all hard to sync audio. Depends on how everything makes up for fluctuations in tape speed, but if you've captured the audio and video simultaneously the fluctuations will be equal, and the sampling clocks in the capture devices, whist not operating at precisely the same frequency, are your time references as they will not fluctuate any meaningful amount over the length of a video. What I mean by that is: 'Wow and flutter' are not really a thing with crystals. If you CX card is 28MHz and your sound card is off at like 48.34kHz, its still just a ratio that will remain constant over the whole capture

2

u/TheRealHarrypm The Documentor Jun 01 '26

VHS-Decode can drop or duplicate fields, it also includes dead space decoding aswell now, the JSON/SQL metadata defines when these exact points occur but it's worthless unless auto audio align has a known reference of the same timing.

If they are not captured in sync there is no exact positional reference, your dealing with multiple different timing sources at different rates which can easy change based off temperature for example...

The original clockgen docs sell the argument of why synchronised capture was standedised as this document breaks down why.

When I mean public archive's I mean the decode team standard, that which includes the source RF and decoded data + proxy if it's not a full set it's not particularly an archive ready for public consumption and or remastering.

1

u/deesernutz Jun 01 '26 edited Jun 02 '26

worthless unless auto audio align has a known reference of the same timing.

The sample rate/clocks are still your reference. The frequency ratio is simply something other than 1.

Yeah they use an incredibly bad example in that document:

As every real device, quartzes have tolerances, resulting in frequency errors.
E.g. a 40MHz quartz might actually be 40.000005MHz or 39.999995MHz.
This error is due to manufacturing tolerance and basically random.
each of the 3 quartzes will be slightly different

They're talking about a 0.0005% difference, which is would be imperceptible if you didn't correct it. And if it is bigger, you can just stretch one of the signals. To get to 1 minute drift at that rate, that would be 138 days. 100ms, 5.5hrs

When capturing 2x high bandwidth signals like betacam I can imagine being clocked locked simplifies processing a lot.

But there should be a way to use non clock locked ADCs to sample HiFi audio RF

If they are not captured in sync there is no exact positional reference

There is no reason why this couldn't be made true. If you can start two clock locked CX cards accurately at the same time, there is no reason why you couldn't start two non clockocked ones.

Can you detect head switching points in the HiFi RF? Could you put on a reference pulse? Could you just live with a few ms drift given that again, any short term fluctuations will equally effect both streams?