Transfering VHS Tapes to a Computer

I recently just took a couple of weeks off work, and as part of my current quest of making things in my life more efficient I decided to digitise the old family video tapes.

There are a couple of reasons why you may want to do this.  Firstly, the quality of VHS and camcorder tapes aren't going to get better with age, slowly they will degrade and the information will be lost.  However, if you digitise the video you effectively take a snapshot of the information preserving it, preventing further degradation.  Secondly you have to consider how long the equipment to play back the tapes will be accessible and still operational.  VHS players will be around at garage sales for years to come, but camcorders are a different matter.  Mine is nearly 20 years old and eventually it'll die.  As it was, I had enough trouble with the last tape and probably could have done with a head cleaning tape (fat change finding one of those).  So now I can save space by not needing to keep a camcorder, VHS player and tapes.  Digitising the video in raw mode takes around a GB a minute so, even without compression you can fit around 5 VHS tapes on a 1 TB drive, with compression, around 80 tapes, that's a pretty significant space saving.

I spent a week looking at all the different hardware solutions that were available.  As I was using my laptop, PCI capture cards were out of the question, so USB it was.  There were options ranging from 30 dollars up to around 120 dollars, and from forums I had seen trouble with all of them, and basically decided to just go with the cheapest option and cross my fingers.  So I picked up a Leadtek VC100U for about 31 dollars from MSY, my friendly neighbourhood computer store, and was pleasantly surprised for a device, I'm pretty sure is a couple years old.

Leadtek VC100U

Once the software was installed I hooked it up to the VCR via the RCA cabels and was good to go.  The interface was reasonably easy to use, and it didn't take long to start capturing video.

ArcSoft ShowBiz

For the first few attempts at capturing video I used MPEG-2 compression.  Turns out that the on-board compression was pretty woeful, so capturing uncompressed and processing the video later was the only option.  Configuring the device properly then took a bit of research.  Firstly I had to make sure that the video source was set as PAL/B video for Australia.  This means that the video has 576 active horizontal scan lines and is transmitted at 25 frames per second (fps).  From this it becomes obvious that the vertical capture resolution is best if set to 576 pixels.


The next part becomes a little tricky.  Analog TV in my opinion is partly digital from a signal processing perspective.  Although each scan line is represented with an anlaog waveform, the image it is discretely sampled in the vertical direction.  So the vertical resolution is easily obtained from the number of scan lines, but the horizontal resolution is based upon the bandwidth of the analog signal, which in the case of PAL/B is 5MHz.  To completely reconstruct a band-limited signal, it needs to be sampled at the Nyquist rate which is twice the bandwidth, ie 10MHz or 0.1 microseconds per sample.  The active video portion of a scan line lasts about 52 microseconds, which means that there needs to be 520 samples per scan line.  The device has options for the horizontal resolution of 480 or 720 pixels.  Given that the source is from long play video tapes, the bandwidth of the video signal should be well below 5 MHz, which means that sampling at 720 pixel is just oversampling and storing more than is needed. So we should be able to get away with 480 pixels which is OK up to 4.6 MHz.  There may be some subtle flaw to my interpretation of how this all works, but testing both resolutions and playing them back showed no perceptible quality difference.  I think if I was recording from a high quality source I would probably go with the 720 option, but not in this case.


You may now be thinking that the aspect ratio is all wrong.  The video is sampled at 576 pixels high and 480 pixels wide, giving an aspect ratio of 0.83 when the source is 4/3 or 1.33.  This doesn't matter at all.  As long as the software displaying the video knows that it will need to be displayed at a particular aspect ratio, it will interpolate the data itself and display it properly.  One point to note is that the AVI container doesn't actually have this ability.


So several boring hours later I had captured all the videos I needed to.  One thing to note that confused me at first is the file size. One file was 4,330,983,188 bytes and was 309 seconds long.  At a resolution of 576x480 at 25 fps that gives 2.027 bytes per pixel.  The 0.027 is the container and audio overhead, which leaves 2 bytes per pixel for the image, I was expecting to see 3, a byte for each of the red, green, and blue components of the image.  Turns out I didn't understand how video is handled.  I'm used to dealing with images of RGB, I haven't had much to do with video.  Video is transmitted in in YUV format instead.  The Y component is the luminance which is the same as black and white, the U is the blue luminance difference, and the V is the red luminance difference.  The historical reasons why it is done like this are quite fascinating (warning, my idea of fascinating may be mind numbingly boring to you).


Turns out that the luminance of an image is more important than the chrominance (UV) of it for our vision system to perceive it as a quality image.  So with a given amount of bandwidth, to get the best image you just have to have proportionally more information about the luminance than chrominance channels. This is what chroma sub-sampling does. It samples the chrominance channels with half the resolution of the luminance channel.  In my case, every pixel gets a luminance sample and chrominance sample.  However the chrominance sample alternates between the U and V channels.  This is called YUV 4:2:2, and gives 2 bytes per pixel.