The Best VHS Capture System Using Free Software?

mrcgran asks: "I have been trying to find the best solution to transfer VHS tapes to a digital format using Free Software only. I would like to lose as little as possible in the conversion, sampling optimally, minimizing noise and being in control of every step of the process. Storage is not a problem. I'm expecting to use around 5GB+ for each hour of raw captured footage." If you were going to build a VHS capture system using Free Software, how would you do it?

The software part seems promising: VLC and mencoder for conversion of raw footage, Cinelerra and many others for video editing.

However, the hardware is being tricky. Most try to bloat the device adding functions like TV/compression/edition instead of focusing on the raw A/D conversion. Chipsets are hidden, and parameters like signal-to-noise, sampling rate etc are unavailable for comparison. Information is scattered and very difficult to find.

Which chipsets/products should I look for, specially for use with Linux and BSD? Which ones allow oversampling of pixel resolution and number of frames (in order to average the values and reduce the noise)? Which setup should I use: S-Video/Composite, sampling rate/oversampling, suggestions on high-quality VHS players/heads/tape cleaning processes, etc? Has anyone tried to use scaling algorithms such as hq/scalenx to upscale video and sound resolution? Pitfalls?"

Comments

Hardware

[seinman]

First, get an S-VHS deck. They'll play back VHS tapes with higher quality than a standard VHS deck will. Then, run the footage through a time base corrector. Look on eBay for that, but expect to pay a decent amount of money (the one I use is part of a $1000 video switcher, i've seen basic standalone TBCs for around $400 if memory serves). Then use whatever capture card you can find that works well with whichever distro you're using. Don't bother using an s-video connection (assuming your deck has one, chances are good it won't) as VHS is a composite signal to begin with. There will be no quality gain using s-video over composite in this case. I don't know much about the software side of things, unfortunately, as all the tools I use are commercial software for Windows and Macintosh systems.

Re:Hardware

[Anonymous Coward]

Uh, VHS is *not* natively composite. You want to check your facts there. S-Video outputs do not engage a comb-filter because the luma and chroma are separate on the tape. This is the way to go. A simple moire pattern A-B will show this characteristic clearly.

Re:Hardware

[fyngyrz]

This AC is correct. Use S-Video from a good SVHS deck; that's the best signal source. Also a TBC and a good digitizer - I use a datavideo DAC-100 which has firewire, composite, S-Video in *and* out, converts any to any and does a very good job. It also lets you select 16- or 12-bit audio conversion (for firewire output.)

Since you're not using a Mac, I have no suggestions for software. The Mac itself is so friendly to this process, I've never experienced any problems of any kind.

Re:Hardware

[Phreakiture]

I have an alternative suggestion to getting an SVHS deck.... many of the newer VHS models, especially those that are DVD/VHS combo units, have a feature called SQPB, "SVHS Quasi Play Back". It's capable of playing SVHS tapes, not as well as an SVHS deck, but pretty well, and also benefits from the improvements to regular VHS playback that you would get from using an actual SVHS deck, at a fraction of the cost.

The time base corrector is a good idea if it is in your budget. If not, don't sweat it.

If it is in your budget to do so, get a Firewire Bridge. This device will take in analogue video and turn it into a DV stream for capture via your IEEE-1394 port. Expect to pay about $250 for one.

For software, on Linux, you can just use dvgrab, then use the mjpegtools suite to convert the captured DV streams to progressive-scanned denoised deinterlaced MPEG streams for you to put onto DVDs. If you want a GUI, Kino can front-end all of these processes for you.

Re:Hardware

[GoRK]

Then use whatever capture card you can find that works well with whichever distro you're using. Don't bother using an s-video connection (assuming your deck has one, chances are good it won't) as VHS is a composite signal to begin with.

While it's true that the on-tape signal is composite, it will be the job of a comb filter somewhere to separate chroma and luminance from that signal for display or capture. If you rely on the (probably cheap) comb filter in "whatever capture card you can find" you will be participating in a crap-shoot. If the poster does indeed follow this advice and uses a high quality SVHS deck, using the S-Video output (ie using the deck's high quality comb filter) will likely result in superior quality compared to the catpure card's filter. If you want to nitpick about it, you can also buy component comb filters such as a Faroudja VP100, or look for other video passthrough components such as VCR's or receivers advertising the type of comb filter you want. I am rather surprised the parent poster seems to know the advantages of using timebase correction but did not give this advice. The only time you should skip a comb filter and use the composite signal is if you are doing tape-to-tape work or going between other component sources such as laserdisc or NTSC broadcast.

Re:Hardware

[fyngyrz]

Conversions of otherwise pristine signal could indeed introduce an LS bit or so of degradation; however, depending on the precision of the conversion, this may or may not actually be visible. The more high quality bits used in the various A/D and D/A systems the less of a problem this is. But the presumption that the signal is pristine is a bit unlikely. TBC's can do a lot to fix things, from adjusting sync levels and widths to getting the black level back where it belongs to skewing timing and tweaking chroma phase, and the signal that comes from a tape player is usually in need of one or more of these services. So in the end, whatever degradation might be inherent is swamped out by the other benefits. There's a lot to be said for a video signal that is exactly in spec, and tape decks rarely produce such signals. Most any TBC can be taken out of stream with one button press, so if it's actually not helping, you could just switch it out anyway. I've got some pretty nice decks, including some single frame recording decks, and I can tell you that I consider a TBC to be part of the critical path to best results.

Re:Hardware

[fyngyrz]

Sure. The first thing I tried worked perfectly; that was a free program called Hyper-engine AV.

I bought the DAC-100, and the day it arrived, I downloaded Hyper engine AV. I plugged in the firewire cable between the DAC-100 and the Mac, plugged the SVideo cable between the deck and the DAC-100, pressed play on the deck and record in Hyperengine AV and had no problems. Soon, I ran into an older tape of one of my students that wasn't recording (digitally) well, or playing back well, so I dragged a TBC out of our video lab and put that in line, and got that recorded without any further problems. There was no software configuration involved, no drivers, no etc. It just worked. You can also use various s/w to put PIP into the Mac from the DAC-100 / firewire combo; the Mac knows about incoming video on firewire and there is just no trick to it at all - 2 seconds after you hook up, you're watching video on your Mac in a window. You can also plug in a DV camera with a firewire port directly - nothing to that, either. It just works.

At the time, my machine was a 1.42 GHz single PPC CPU Mac Mini. Today, you get a dual-core Intel mini with about 5x the horsepower for the same price (I suggest you go for 2 gigs of RAM if you get a mini for video work, btw), and my PPC unit never had any trouble at all with handling or recording the signal. However, some tasks - such as encoding the signal into some particular digital file format - are definitely CPU power related. More power means faster encoding. Apple's got a decent range of CPU capacities, from the mini to the recent and expensive 8-core 3-GHz machine (a little under five grand, configured with 8 cores and four gigs, wifi and bluetooth.) I don't know if the multiple cores are used in encoding at this point, but I will know soon. I'll be ordering one of the 8-core machines in the next 90 days or so, and that machine will be my desktop machine.

As multiple cores are fairly new tech, it may well be that only one will be used. But I expect that to change in the near term; video encoding would lend itself very well (on a per-scanline or per frame group basis) to multiple core approaches. And of course there is plenty of other software out there. I didn't explore any more because my needs were met first time out - but I've noticed program after program that provide various interesting combinations of video processing for the Mac. Some free, some not.

Virtual VCR

[toasted_pants]

I've found the Doom9.org's Capture Guide as the best place to get information.

1. Use Virtual VCR to capture from the VCR going to the huffyuv lossless codec.
2. Use AVISynth to fix up the degraded tapes (also in the guide).
3. (Not free) Use Tmpg Encoder 4.0. It was worth the money for me because I wanted a fast, reasonably high quality mpeg2 encoder. But there are certainly free options instead.

Re:Virtual VCR

[Ecuador]

He is asking about Linux, and Virtual VCR is DirectShow based.
Well, in the end I would also recommend to use Windows for capturing, as much as I love my Suse for developing, my HTPC runs Windows for various reasons.
Oh, if he did go to Windows, why Virtual VCR and not the best? I am talking about VirtualDub of course ;) From then on (Huffyuv etc) you are right.

The sky's the limit

[moosesocks]

You're right that you're going to run into hardware problems unless you choose very carefully.

As is the case with most things related to analogue/digital conversion (and also to video editing), the sky's pretty much the limit when it comes to the amount of money you can sink into your equipment.

For starters, a broadcast-quality VCR will set you back quite a bit. Great capture hardware's going to do you no good if the quality of the source is poor. We'll leave this part as an exercise for the reader.

Now that you've got a decent VCR, you can go splurge on an expensive Analogue-Digital converter. Any decent-quality device won't offer all of the unnecessary "bells and whistles" (such as hardware-based MPEG/WMV encoding) that the parent poster describes. Instead, most pro-grade boxes will take an analogue signal (RCA, S-Vid, or even BNC if you want to go all out), and output a standard FireWire DV signal that any decent video editing software should be able to handle. Canopus' hardware is very well-regarded for these purposes. Their products range from somewhat inexpensive (~$150) for consumer-grade products to appallingly expensive for the pro-grade stuff.

However, the fact that you were considering using a TV-tuner card to do the capture seems to indicate that you haven't done anything like this at all. If your content is bad enough that you really NEED to be "in control of every step of the process", you're better off outsourcing this to a professional. Otherwise, a decent VCR and A/D converter should clean up the signal pretty well for you. You can always take care of things like de-interlacing in software later on.

I might also recommend stepping down from your podium, and considering editing your video with non-free software. I can't help but think that the gap that exists between Cineleera and Final Cut Pro is even bigger than the gap between Photoshop and The Gimp (which is pretty huge). Most professional studios use either Avid or Final Cut (and I'm really not trying to be an apple fanboy here -- Apple and Avid basically jointly own the entire industry). Compared to the rest of the costs of video production, Final Cut is a steal.

Alternatively, there are VHS/DVD-R decks out there that will automatically make dubs for you. Sony makes one, and it costs around $200 the last time I checked. Quality's not going to be the absolute best, but will still be pretty darn good. And it's easy as long as your source doesn't have macrovision.

Re:Dscaler?

[MrShaggy]

I was looking into stuff for a linux myth-box, and got reasonably far.

If you are using Linux, you must make sure that you can use HDPARM on your drives.

There are a tons of websites out there that can explain how to get that going.

MS tends to make that happen, while Linux doesn't. I went from stupidly choppy video, to almost real-time, using a relatively older harddrive.

Even on newer drives, you won't see much difference until you can get hdparm on.

You also have to make sure that its in the boot-scripts.

hire a firewire deck

[DrSkwid]

Like a Sony DSR-11 this will bridge from analogue to DV.
We use them at work.

Good VCR w/TBC and Hauppauge PVR-250

[general_boy]

I've digitized a LOT of video tapes, some of them for money (i.e. a small business) and over the years tried many techniques.

Best found and what I use now?

1. Good VCR with time-base corrector. Mine's a JVC HS-S7600U, about $350 several years ago and still works like new. Higher end "broadcast" VCRs will *record* better but not necessarily *play* better - don't bother.

2. Hauppauge WinTV PVR-250 taking S-Video input from the VCR. Uses the Linux IVTV drivers. Hit play on the VCR, "cat /dev/video0 > filename.mpg" to grab the data.

Between these two there are enough tweaks for sharpness/noise reduction/saturation/hue, etc. to deal with most any signal. Whoever said component output matters doesn't know how color information is laid down on (S)VHS tapes - look up "color under" recording for more info. S-Video gets you all the information that's there; Y/Cb/Cr component would be a waste.

The PVR-x50 series of hardware MPEG encoders produce superb results, of course in real time, and have quite advanced noise reduction capabilities. Do your own searches for reviews head-to-head with any other SD encoders. You can run them as high as 27 Mbps. Gotta keep it below 9.5 Mbps or so for DVD though.

In the past I have used a DV camcorder transcode mode to get video into the computer. If the final result is MPEG-2, e.g. for DVD, then you actually have an extra transcode step that way, going from DV to MPEG-2 using a software encoder. Better to go straight to MPEG-2. Downside to this - and practically a small one - is having about 1/2 second edit resolution due to needing to respect MPEG GOP boundaries. In practice that's not a problem, even for editing commercials from off-air recordings.

Enjoy.

Re:Dscaler?

[Minwee]

Running hdparm isn't the problem. It's setting the drive to use DMA that will solve most of your choppy video problems.

There are a number of gotchas that can cause problems such as buggy motherboard support or using the wrong cables. R'ing t FM can help out a lot.

Re:Dscaler?

[evilviper]

If you are using Linux, you must make sure that you can use HDPARM on your drives.

Not at all. hdparm was needed to enable DMA in the past, but since latter versions of 2.4, and with all 2.6 kernels, DMA is enabled by default, if at all possible.

You can run hdparm to enable 32bit transfers as well, but that's not going to make a significant difference, unlike DMA.

I used a PVR-500 and mencoder

[pestie]

I just finished doing exactly this sort of thing, so I'll describe what I did, how, and why.

Some caveats: 1) I like working from the command line. 2) This was not a project for which I wanted ultra high quality - "good enough" was good enough for me.

I have a Hauppauge PVR-500 (a hardware MPEG encoder/TV tuner card - basically, this card is a pair of PVR-250's on one PCI card). This card is well-supported on Linux by the IVTV drivers. I decided to use its composite and audio inputs to convert some old VHS porn (gotta love that 80's-era stuff) to modern digital file formats so I could finally toss out the old VHS video tapes, some of which were quite degraded (they were formerly rental tapes, and some were nearly 20 years old). I used an old-but-decent-quality Sony VCR as the video source and fed its outputs straight into the PVR-500's first set of inputs. Capturing video was as simple as:

cat /dev/video0 >filename.mpg

How's that for simple? Heh... I "retensioned" the tape beforehand (fast forward all the way to the end, then rewind all the way to the beginnig) and made note of how long the tape was. I used a kitchen timer to let me know when the tape was nearly finished playing so I could stop the capture at the approprite time.

After the capture was finished, I used mplayer to find the exact end point (just after the credits faded to black, for example) and to find where to crop the video (most analog captures will end up with black bars on the left/right sides, and old tapes often have distortion at the top or bottom). mplayer's "cropdetect" feature was invaluable for that. I would play the file with a command like this:

gmplayer -vf cropdetect filename.mpg

To use cropdetect, you have to fast-forward into a part of the video where the picture doesn't have any black at the edges (no dark scenes, transition fades, etc.) Then you just look at the terminal window to see what cropping parameters to use (it spits them out continuously). I found that sometimes the default setting wasn't sufficient to eliminate the black bars completely, so I would occasionally use cropdetect=50 to make it a little less conservative about what it detected. That value of 50 was chosen by experimentation, so feel free to experiment yourself. 50 seemed to consistently work well for me. There are no units on that number, it's just a scale from 0 to 255. In the end, I'd have a set of cropping parameters that looked like this:

-vf crop=704:476:12:0

Those numbers are: X dimension, Y dimension, X offset, Y offset. Offsets are measured in pixels from the upper left corner.

Cropping the distorted crap at the top and bottom isn't quite so easy. It's not all black, so cropdetect doesn't detect it. So I had to manually adjust the parameters. The tricky part is the way mencoder/mplayer wants its dimensions specified. It would be much simpler if it used a format of startx:starty:endx:endy rather than the size/offset described above. As it is, if you want to crop pixels off the top or left side, you have to shorten the appropriate dimension by N pixels and then add N pixels to the offset. This sounds like a pain in the ass, but in practice it's not so bad. You get used to it very quickly.

Now that I had my crop values, I'd use mencoder to resize, deinterlace, and transcode the whole thing into h.264 video and variable bitrate MP3 audio. I experimented with AAC audio, but for some reason I kept having much better results with VBR MP3. I think the FAAC codec (the one bundled with Ubuntu Dapper) I have is just too old to be efficient. When Feisty comes out this month and I get around to upgrading, I'll try AAC again. Anyway, this is a complex command line, so I wrapped it in a script:


#!/bin/bash

# Bit rate at which to encode
# Formula for h.264: X * Y * FPS * 0.125
# Common

Re:Canopus AVDC300

[Hercynium]

I can vouch for that. I paid $380 for a Canopus ADVC-300 converter about two years ago and recently re-sold it on ebay for $350.

It enabled me to work wonders on some old home VHS tapes. The built-in TBC fixed the tracking and some nasty color-synch problems. The built-in luma, chroma, and de-noising filters, while sometimes difficult to get 'right' are top-notch and save you that much more time processing the AVI's on your CPU.

I'll also echo what's already been said several times in this thread: Get yourself a decent SVHS deck and use the S-Video cable to connect to the ADVC. I spent countless hours trying to make it come out like the Canopous ads showed using my $40 Toshiba VCR with nothing but frustration. I bought a used JVC SVHS deck for about $230 and it made *all* the difference.

Just for comparison - inputting the signal from the SVHS deck into my friend's cheap-o EZTV (I think that was what it was called) USB-based converter without the ADVC was futile. Canopus makes an excellent video conversion tool.