Need advice on what vcr to use for capturing older video tapes

[videeo]

Interesting, could a regular DVD/VHS combo unit act as a pass-through full frame TBC?

[Mini-Me]

Some can, yes...but the quality of the TBC in each one varies, especially in terms of how well it performs line TBC duties (to correct geometric distortions like wiggling).

[sanlyn]

I and others have posted and see many other posts that test DVD recorders as pass-thru devices. The Magnavox I mention has been cited, although the older breed of Panasonics and Toshibas are known to do better work. None of them will perform like a $5000 studio unit (of course), but they can surprise you. A Phillips unit had also been tested. The better units have good y/c comb filters that reduce composite dot crawl and other problems when using their composite-in/s-video out. Popular DVD recorders from yesterday are Panasonic Es-10, -15, -20, with the ES-10 being somehow very popular despite some of Panasonic's usual faults. Then there's the Toshiba RD-K2 thru K5 series, and the RD-XX32 thru RD-XS35 HDD units (which were around $500 new in 2005, now some sell used for $800). But you can find these around for much less, sometimes for a pittance. The optical drive were the weakest spots in these, but you don;t need the optical drive for pass-thru. Obviously those will sell pretty cheap.

There are some recent posts of tbc pass-thru that use a lot of test patterns. Test patterns played from tape are informative, up to a point. This is my objection to test patterns: they don't move. Sure, the tape moves, but the test pattern just sits there. In real video, people and objects move, cameras pan, credits scroll, scenes fade in and out (fades are tougher than you think), dirty and corroded and bruised tape moves. Test patterns are too civilized, too cooperative. When you have time, you might browse thru the posts that start here, and there are more that follow in that thread from other users with different devices. These, IMHO, are more meaningful. Jagabo has also tracked some of the older posts (darn, I keep losing them!) which can be very revealing.

It's not just a matter of correcting wiggles or torn frames. Overall video motion, sometimes chroma noise, and even some of the general noise levels seem more calm. Of course, tape is tape. Great in its day, and looks nice on a forgiving CRT TV, but not very compatible with "digital".

[jagabo]

There are some recent posts of tbc pass-thru that use a lot of test patterns. Test patterns played from tape are informative, up to a point. This is my objection to test patterns: they don't move. Sure, the tape moves, but the test pattern just sits there.

Test patterns are for looking at specific issues. Resolution, jitter removal, posterization, levels, colors, etc. Analog video has no memory from field to field or frame to frame so movement isn't necessary for those measurements. Other issues require full motion video, or video that otherwise changes from frame to frame. Things like temporal noise filtering, automatic gain problems, etc. Posteriaztion can be more visible with movement.

[sanlyn]

Agreed. Both techniques are necessary, shouldn't have one without the other.

[videeo]

sanlyn, the version "C" of the Avisynth script, is that one tailored for a specific scene in the capture, or do you think it can be used throughout? Would it need to be changed given the differences you pointed out in the test5.avi (RCA) capture?

[sanlyn]

It's rare that you can use the sme filtyers on every vido or every project. In fact, with tape in particular you'll find one shot right in the middle of others that just looks haywire. Not at all unsual, it's just the nature of analog (and sometimes digital ain't much better). On the otehr hand, I've cut and re-authored hundreds of digital broadcast recordings from my DVD recorder, and never touched a single filter. But with tape, I've even had to break my neck with black-and-white.

The more you work with filters, noise, etc., the easier it gets. And the more your eye can spot problems and know what to do. It's just those first couple of videos that make you climb the walls. You're doin' OK so far.

[videeo]

I tried another capture of test4 on the RCA and it is displaying the same jitter. I looked through it after deinterlace with Avisynth and it looks like the correct duplicate frames can just replace the ones that are not registered properly. Is there an easy way of doing this within VirtualDub? I tried copying and pasting and a web search, but I didn't find a quick solution. Is there a simple avi editor that can do it?

On another note, I also tried to capture again with VirtualDub set for multi-core and enabled GPU assistance and increased the disk I/O buffer. Not sure if that helps with capture, but... It seems like that had helped with capturing the audio in sync. Also just 1 initial dropped frame and no inserted frames as well.

[videeo]

I figured out how to do it with VirtualDub, but it's not very convenient, especially if there are many spots that need fixing. I'm also not sure if it is affecting the audio. Is there a way of automating the process?

[sanlyn]

I tried another capture of test4 on the RCA and it is displaying the same jitter. I looked through it after deinterlace with Avisynth and it looks like the correct duplicate frames can just replace the ones that are not registered properly. Is there an easy way of doing this within VirtualDub? I tried copying and pasting and a web search, but I didn't find a quick solution. Is there a simple avi editor that can do it?

AVI editors won't address this. I think you've spotted the direction for solution, but it's not so simple as "copy and paste". Aside from properly capturing video and doing a touch of basic denoising and color correction, this tape will have other problems that elevate the project into restoration and repair. Frequent visitors in Restoration can give you more information; and getting into restoration at this point will divert you from capture for some time.

Caution: your captured video shouldn't be deinterlaced. I wasn't interlaced to begin with. Here's a web FAQ that explains how you can tell: http://neuron2.net/faq.html

On another note, I also tried to capture again with VirtualDub set for multi-core and enabled GPU assistance and increased the disk I/O buffer. Not sure if that helps with capture, but... It seems like that had helped with capturing the audio in sync. Also just 1 initial dropped frame and no inserted frames as well.

Aged or damaged tapes not withstanding, you shouldn't be having so many VirtualDub capture problems. Maybe you could give us more details about how you're capturing, kind of PC used, some of your VirtualDub settings, etc. I'm not very familiar with your capture device, so in that respect I'd only be guessing about options; others in the capture forum would know more about the 750. I'm afraid I'm stuck in the pleistocene era with ATI All In Wonder analog cards.

I was hoping that either your capture device or DVD/VHS combo would have some kind of built-in tbc, but apparently they don't. Consumer-level TBC's can't solve every problem. But capturing damaged or aged tape without benefit of any kind of tbc is iffy if not really troublesome. With old sources you're bound to encounter these and similar problems, or worse, many times over. Some of the difficulty might have nothing to do with your players, adapter, or capture software.

BTW, does your combo unit have an s-video output?

I figured out how to do it with VirtualDub, but it's not very convenient, especially if there are many spots that need fixing. I'm also not sure if it is affecting the audio. Is there a way of automating the process?

Can't say whether it affects the audio or not. How'd you do it? I never repaired that kind of problem with VirtualDub.

[jagabo]

I figured out how to do it with VirtualDub, but it's not very convenient, especially if there are many spots that need fixing. I'm also not sure if it is affecting the audio.

The audio is copied and pasted along with the video. So if you remove frame 1000 and replace it with frame 999 the audio from frame 1000 will be lost and the audio from frame 999 will be repeated. Of course, you can replace the audio with the original with a simple remux later.

Regarding dropped frames:
https://forum.videohelp.com/threads/104098-Why-does-your-system-drop-frames

And if you haven't tried it already, try pre-allocating the file before capturing, like I recommended earlier.

[sanlyn]

When I do that kind of editing I often save the audio as a separate .wav file. You can join the original audio to the AVI in VirtualDub with the "Audio" menu by selecting "Audio from other file..." and point Virtualdub to the original .wav. That'll work, too.

[videeo]

The laptop I'm using is a Lenovo ThinkPad, it's an Intel Core Duo 2.xGHz and has 2GB of memory. It is meant to be a 3D CAD workstation. It's a few years old, but I figure it should be good enough for video capture. Only thing is the HD is 5400rpm, so that might be the culprit. There are some other things I could try, but now it seems like it is capturing without the initial lag. I am not using any filters during capture, everything is set to default except compression is set to the Huffy codec.

The combo unit unfortunately only has S-Video out for DVD playback, so perhaps this unit does not have TBC onboard.

By deinterlaced, I mean I used the bob function in Avisynth to see all of the progressive frames. When I step through test4.avi, I see there are frames that jump up every once in a while. I guess a better way to do a fix (than with VirtualDub) would be to manually go through the footage and note which frames jump and lump them into two groups: one to replace the frame with the previous frame, and one to replace with the next frame. Then process the deinterlaced video with Avisynth to go and replace all the jumpy frames. Could that be done?

[Mini-Me]

If you're going to go through and manually mark them, why not manually move the jumpy ones down by 1, 2, 3, or whatever lines?

clip = Avisource("whatever.avi", pixel_type = "YUY2")#.AssumeTFF() # Use AssumeTFF if the fields are backward when separated

# Separate fields
sep = clip.SeparateFields()

# Create clips shifted in whatever direction by whatever amount
down1 = sep.SubpixelShift(0.0, -1.0)
down2 = sep.SubpixelShift(0.0, -2.0)
down3 = sep.SubpixelShift(0.0, -3.0)
# etc.
up1 = sep.SubpixelShift(0.0, 1.0)
# etc.

# Replace fields on a piecemeal basis.
# Get ReplaceFramesSimple from http://avisynth.org/stickboy/RemapFrames.zip
sep = ReplaceFramesSimple(sep, down1, mappings = "40 [55 60] 89")  # This shifts down fields 40, 55 through 60 inclusive, and 89 by 1 line.
sep = ReplaceFramesSimple(sep, down2, mappings = "900") # Shift field 900 down by 2 lines
sep = ReplaceFramesSimple(sep, down3, mappings = "901") # Shift field 901 down by 3 lines
sep = ReplaceFramesSimple(sep, up1, mappings = "899") # Shift field 899 up by 1 line...get the idea?

# You may need another AssumeTFF() before Weave?  I can never remember the rules,
# and I have TFF sources, so I just spam AssumeTFF() before any Weave() or SeparateFields() function...
final = sep.Weave()

# Test output to look for jumpy fields...put whatever you want here that helps you see the jitter better.  Example:
# return sep

# Real output, when you're done
return final



function SubpixelShift(clip input, float deltax, float deltay, bool "sharp")
{
    # This utility function is overkill for this particular script, but it's useful for a number of things.
    sharp = Default(sharp, True)
    return sharp ? Spline36Resize(input, input.Width(), input.Height(), -deltax, deltay, input.Width(), input.Height()) : BilinearResize(input, input.Width(), input.Height(), -deltax, deltay, input.Width(), input.Height())
}

I've used scripts just like this in the past. It's easy, but it's tedious.

I now have a plugin/script combo in the works for automatically finding and correcting jitter, but it's a ways off still...

[sanlyn]

Yes, you have to make allowances for slow hard drives.

Hm. s-video for DVD-only. That's a bit unusual, but so be it. The units we talk about used for pass-thru have s-video and y/c comb filters on all inputs, even when not playing or recording. That would make a visible difference and hold detail better.

Replacing frames in VirtualDub is the hard way. I don't even know how to do it (never tried), and as jagabo says you have to consider audio. Avisynth has some stabilizing filters that find and correct many hops automatically. Jitter filters, too, of varying effectiveness. They can work with rainbows, chroma noise, levels problems, halos, DCT ringing (which some of those scenes have), not just grain and other noise. For specific frame replacement there are filters that can do it (you have to tell them which frames/fields you want replaced). None of them affect audio. That's why I suggest dealing with this level of problem videos in the restoration forum. It's a different world from capture.

Mini-me, might have trouble with that script here. The hop is on specific fields, not frames.

[videeo]

Interesting idea, but I'm thinking just duplicating frames is easier since it is telecined and there is a readily available duplicate frame that can take its place. That way if the amount of pixel placement is not consistent, there is no need to measure pixels for each frame. My understanding is when it is inverse-telecined only one of the frames will be used anyway, removing the jumpy frame with its more behaved twin just ensures that when duplicate frames are removed, the good one will be chosen...is that right?

[sanlyn]

IVTC is skipping in that sequence because the sequence is broken during capture, not later. But try it and see how it goes.

[Mini-Me]

sanlyn, note that I used SeparateFields(), not Bob(). Bob does cause problems with reinterlacing, because it separates fields and then resizes to obtain the original field height. Bob(0.0, 1.0) preserves the original lines, but you still have to be very careful when reinterlacing to make sure the original lines (not the generated ones) are used, and it's pretty pointless in this case.

The above script losslessly splits frames into consecutive fields, shifts individual fields (not whole frames), then reweaves the [now correctly placed] fields. In short, it merely lets you undo the jitter the VCR applied to individual fields...no more, no less.

Using Yadif would be a pain, just like Bob(0.0, 1.0): You'd have to shift up/down in multiples of 2, and then you'd have to discard the generated lines. It might be useful to use Yadif or QTGMC(preset = "super fast", lossless = 1) for the sake of temporarily viewing the clip to see which fields are jumpy, but for the sake of correcting jitter, that would be pointless...or worse, if you make a mistake.

Note that the script is meant to be used before IVTC. I've used it before for non-telecined VHS captures, and it works great to eliminate jitter without any image degradation (except for the duplicated line at the top or bottom after moving a field), but I grew tired of stepping through 2 hour movies frame-by-frame and testing each jittery field to see how much it should be moved up or down.

videeo, that's a good point. Your approach won't work if both copies of a field/frame have jitter, or if a non-duplicated field/frame has jitter...but you'd be able to correct most problems in a shorter amount of time without measuring pixels, as you say. You can adapt the above script to your method as follows:

clip = Avisource("whatever.avi", pixel_type = "YUY2")#.AssumeTFF() # Use AssumeTFF if the fields are backward when separated  # Separate fields sep = clip.SeparateFields()  # Create clips containing the last and next fields...Trim2 is from http://avisynth.org/stickboy/jdl-util.avsi
prev = sep.Trim2(0, 1) ++ sep
next = sep.Trim2(1) ++ sep.Trim2(sep.Framecount() - 1, sep.Framecount())

# Replace fields on a piecemeal basis.
# Get ReplaceFramesSimple from http://avisynth.org/stickboy/RemapFrames.zip
sep = ReplaceFramesSimple(sep, prev, mappings = "40 89")  # Replace fields 40 and 89 with the previous field.
sep = ReplaceFramesSimple(sep, next, mappings = "900") # Replace field 900 with the next field. 

# You may need another AssumeTFF() before Weave?  I can never remember the rules,
# and I have TFF sources, so I just spam AssumeTFF() before any Weave() or SeparateFields() function...
final = sep.Weave()

# Test output to look for jumpy fields...put whatever you want here that helps you see the jitter better.  Example:
# return sep

# Real output, when you're done
return final

[sanlyn]

Like I said (as I said ? ?), try it and see. You only live once.

[Mini-Me]

Like I said (as I said ? ?), try it and see. You only live once.

Take another look at the bob'd fields. What looks like jitter is really field hopping (not whole frames). I just counted a 2-pixel field hop in 489, 491, 507, 509, 523, 545, 592, 600, 729, 749, 753, 755, 757, 759, 761, 77, 787, 791, 835, 845, 849, 853, 855, 857. There are more, I just got tired of looking.

I know. That's exactly what my script corrects: Field-hopping...of individual fields, not frames. Separating fields before using ReplaceFramesSimple means that you're only replacing fields, not frames, with displaced versions. Of course, this means you have to use field numbers when you're doing replacements: For instance, frame 489 is composed of fields 978 and 979, and you have to determine which one is jumpy and use that number in ReplaceFramesSimple (with separated clips).

This problem is extremely common with VHS. I've been struggling with it since I first started capturing, and it's been the bane of robjv1's existence as well, from what I've gathered. No existing stabilization script handles it well automatically...yet.

[videeo]

videeo, that's a good point. Your approach won't work if both copies of a field/frame have jitter, or if a non-duplicated field/frame has jitter...but nevertheless, you can adapt the above script as follows:

Cool, I'll try that out as a test on a short clip. So if I understand the script correctly, I just need to specify the clip file/path and put in frame numbers with spaces for the two groups?

After processing the script, how would I convert it to IVTC?

[Mini-Me]

videeo, that's a good point. Your approach won't work if both copies of a field/frame have jitter, or if a non-duplicated field/frame has jitter...but nevertheless, you can adapt the above script as follows:

Cool, I'll try that out as a test on a short clip. So if I understand the script correctly, I just need to specify the clip file/path and put in frame numbers with spaces for the two groups?

After processing the script, how would I convert it to IVTC?

Yes, but keep in mind you're not using frame numbers...you're using field numbers. After you separate the fields, try returning the clip: It will be twice as long (twice as many frames) and half-height. You'll want to step through the separated clip and use THOSE frame numbers (actually field numbers) to specify which fields to replace. (If the motion seems "two steps forward, one step back" in the clip with separated fields, you'll need to use the AssumeTFF line before separating...and possibly before reweaving as well.)

After eliminating jitter, you can save your fixed clip and run an IVTC script on the output, or you can add IVTC calls to the above script. I'm rusty on the best IVTC filter to use though: sanlyn can fill you in.

[robjv1]

Like I said (as I said ? ?), try it and see. You only live once.

Take another look at the bob'd fields. What looks like jitter is really field hopping (not whole frames). I just counted a 2-pixel field hop in 489, 491, 507, 509, 523, 545, 592, 600, 729, 749, 753, 755, 757, 759, 761, 77, 787, 791, 835, 845, 849, 853, 855, 857. There are more, I just got tired of looking.

I know. That's exactly what my script corrects: Field-hopping...of individual fields, not frames. Separating fields before using ReplaceFramesSimple means that you're only replacing fields, not frames, with displaced versions. Of course, this means you have to use field numbers when you're doing replacements: For instance, frame 489 is composed of fields 978 and 979, and you have to determine which one is jumpy and use that number in ReplaceFramesSimple (with separated clips).

This problem is extremely common with VHS. I've been struggling with it since I first started capturing, and robjv1 has as well. No existing stabilization script handles it well automatically...yet.

Indeed, it is the bane of my existence lol

[Mini-Me]

Indeed, it is the bane of my existence lol

LOL, I just edited my post to rephrase like that!

[videeo]

Well, I guess I need to get more hardware. I don't think I want to be stepping through frames if it is more than just this section. Unfortunately I can't currently find the critically acclaimed old hardware that has been recommended such as the ES10.

[Mini-Me]

Just so you know, there is no hardware that will reliably fix this problem. That said, some VCR's will track better than others, and that has made a big difference in my experience. I've also heard that the Panasonic ES-10/ES-15 have some limited ability to correct some jitter, but I wouldn't count on it too much.

[sanlyn]

I think the old Toshiba's are better. Smoother look to the results.

This script fixed almost all of the hop and jitter (except the bad frame with boy's face referred to earlier. was it 593? I don't remember).
I used the test4.avi that has 10 pixels missing at the bottom, so added 10 pixels at the start of the script. You might have to mask a pixel or two of the top or bottom border where stab() moved the fields, use BorderControl in VirtualDub. I attached a copy of Stab.avs. Put it in your Avisynth plugins folder. If you have another version of test4, you'll have to change the border stuff, so try the old test4.avi first if you still have it.

The script uses the yadif plugin (yadif.zip has the yadif dll attached. unzip and put it in Avisynth plugins). If you don't like yadif (I wouldn't know why) try another smart bobber. Don't use Bob().

LoadCplugin("path to Avisynth plugins\yadif.dll")
Import("path to Avisynth plugins\stab.avs")
AviSource("path to source AVI\test4.avi")

## -------------------------------------------------------------
## Input is 720x470. Add 10 p[ixels for a border to get 720x480
## -------------------------------------------------------------
AddBorders(0,2,0,8)
ConvertToYV12(interlaced=false)
Crop(0,0,0,-4)
ConvertToYV12(interlaced=false)

AssumeTFF()
yadif(order=1,mode=1)
Stab()

SeparateFields().SelectEvery(4,0,3).Weave()
Crop(0,4,-2,0)
AddBorders(2,4,0,4)

Later, you can download the whole yadif package here: http://avisynth.org.ru/yadif/yadif17.zip
This doesn't fix the out-of-sequenmce 2:3:2:3 frame, but it stops the jitter and hopping.

[Mini-Me]

Stab() can be helpful sometimes (I've never been happy with it), so it's worth a shot if you want to get rid of some jitter with minimal effort. Keep in mind that the script using Yadif will sometimes use the Yadif-generated lines for output though, not the real lines.

Also, using Avisource() without a pixel_type parameter always imports as YV12 for me. If your movie clip is in YUY2, you will want to use Avisource("blah.avi", pixel_type = "YUY2") to ensure Avisynth doesn't downsample poorly. Then use (interlaced = True) for ConvertToYUY2(), so the conversion doesn't blur chroma over different fields. You may even want to use the colorspace conversion functions from here, because the conversion functions are buggy in some versions of Avisynth.

[sanlyn]

The reason the image is cropped in the script is because stab() needs room to work. I gave it 4 vertical pixels of room, didn't want to crop off too much of the image. When cropping in YV12/YUY2, you're limited with a frame size whose dimensions are divisible by 8. If you're just cropping or adding borders, you need numbers divisible by 2. If you're in RGB, you use any number you want, including 1 (but not zero).

[robjv1]

To comment on the Panasonic ES-10 (and the other models that do the same thing):

For eliminating image distortions (like this: http://www.youtube.com/watch?v=c4M-TQsNjFE) it gets an A+. That's obviously an extreme example, but that's the kind of thing it can handle like a champ.

As far as jitter -- in my experience, it will sometimes complexly fix vertical jitter and other times it will minimize the effect.

Of course, it comes at a cost. The pass-through is not as clean as you'd like like it to be (I've heard this is because it does some sort of real-time encoding and passes it to the output) especially in very dark scenes or scenes with heavy shadows. So fixing that stuff digitally from a lossless capture would be ideal, if it is possible in every scenario.