Frames on VHS capture are hopping?

[zamme]

I'm completely new to the world of restoring VHS tapes and a total rookie at the subject, but I made a purchase for a cheaper capture device (Plexgear Moviesaver) and have been capturing my old family tapes in hopes of being able to get it all ready for Christmas.

All has gone fairly smoothly, but some of the tapes are encountering a problem that they do not have when played through the VHS on the TV.
In those tapes, frames occasionally jumps and glitches as you can see in my attached video

I'm using Virtualdub to capture and process my videos.
I haven't been able to find a filter to correct this and though I've searched for days I've gotten no clues of the reason or if it's fixable.

Any help is greatly appreciated!

Edit: reduced file size of attachment

[metaleonid]

You need TBC.

[sanlyn]

Welcome to digitalfaq.

Well, Christmas is gettin' pretty close. There's no filter for the problem. It has to be corrected during capture with a player's built-in line tbc or an external pass-thru tbc. There are line sync and frame sync errors, so you might need an external frame-level tbc as well. It can't be fixed after capture. The reason your TV plays it more or less correctly is because your TV isn't a digital encoder. Encoders don't see sync errors and noise the same way your TV sees them.

The sample is good enough for showing us the problem, but why is it recompressed to lossy DV-AVI? Thought you said you were capping with VirtualDub. CS6 ought to be able to work with lossless media, but by going thru multiple stages of lossy recompression you're also showing us compression artifacts as well as the biggie problem.You know that DV isn't playable with TV or external boxes, so you'll have another lossy re-encode for a final product. But that's another story.

I had a similar problem with a football tape a few years back. The two attachments below are examples of sync errors and how a line and frame tbc fixed them. A_Sample2_bad.mpg is how the capture device saw the sync errors without tbc. The original "A" frame is slightly reduced so that some of the noise wouldn't be masked by TV overscan. B_Sample2_fix.mpg with tbc is the preliminary fix (still needed a little more cleanup).

There's no repair for this. For digitizing VHS, a line tbc is as basic as a VCR.

[zamme]

Quote:

Originally Posted by sanlyn

Welcome to digitalfaq.

Well, Christmas is gettin' pretty close. There's no filter for the problem. It has to be corrected during capture with a player's built-in line tbc or an external pass-thru tbc. There are line sync and frame sync errors, so you might need an external frame-level tbc as well. It can't be fixed after capture. The reason your TV plays it more or less correctly is because your TV isn't a digital encoder. Encoders don't see sync errors and noise the same way your TV sees them.

The sample is good enough for showing us the problem, but why is it recompressed to lossy DV-AVI? Thought you said you were capping with VirtualDub. CS6 ought to be able to work with lossless media, but by going thru multiple stages of lossy recompression you're also showing us compression artifacts as well as the biggie problem.You know that DV isn't playable with TV or external boxes, so you'll have another lossy re-encode for a final product. But that's another story.

I had a similar problem with a football tape a few years back. The two attachments below are examples of sync errors and how a line and frame tbc fixed them. A_Sample2_bad.mpg is how the capture device saw the sync errors without tbc. The original "A" frame is slightly reduced so that some of the noise wouldn't be masked by TV overscan. B_Sample2_fix.mpg with tbc is the preliminary fix (still needed a little more cleanup).

There's no repair for this. For digitizing VHS, a line tbc is as basic as a VCR.

Thank you for your very comprehensive response!
So I suppose that the only effective method of actually solving the quality issue is to get a TBC, I see the great difference in your clips there. This little restoration project doesn't really have the budget for a device like that, sadly. I guess manually editing the most haunted places and just enduring the overall quality loss is not too bad

So far I have captured the VHS in VirtualDub and editing/recompressing the clips in CS6. I'm still in the process of learning how to best encode and comprocess videos, as I mentioned I'm a fresh rookie in the arts.
Now I have some more clarity in a problem that's been at my neck for some time now. Thanks again!

[sanlyn]

I'm not with you here. If you captured lossless AVI in VirtualDub using a lossless compressor such as huffyuv or Lagarith, why are you recompressing to lossy DV in CS6? That undoes the whole business of capturing lossless in the first place. Each recompression is a lower quality level. There is no "best way" to submit a video to several runs of lossy recompression. It's the worst way, period. What you're saying makes me uncertain as to how you originally captured.

As far as I can tell, PlexGear can't capture VHS to lossless formats, and I doubt that VirtualDub would recognize the capture device -- I don't know, maybe it did. I'm guessing that you captured to PAL-DV, which is not lossless. I noted that your interlac ed sample has top-border tearing and distortion that looks different in each field. Some fields have no distortion, while other field in the same frame does. There's also some bad magenta chroma noise and rainbows (CS6 can't fix that).

The attached mp4 is a deinterlaced version of your test sample version that displays one field at a time from each frame, slowed down to 5fps. You can see that the flagging at the top varies in each field and that recompression is costing some clarity and generating noise. It looks as if you had to mask 40 pixels on each side of the frame -- a proper tbc would prevent the border distortion you seem to be trying to mask.

[zamme]

Quote:

Originally Posted by sanlyn

I'm not with you here. If you captured lossless AVI in VirtualDub using a lossless compressor such as huffyuv or Lagarith, why are you recompressing to lossy DV in CS6? That undoes the whole business of capturing lossless in the first place. Each recompression is a lower quality level. There is no "best way" to submit a video to several runs of lossy recompression. It's the worst way, period. What you're saying makes me uncertain as to how you originally captured.

As far as I can tell, PlexGear can't capture VHS to lossless formats, and I doubt that VirtualDub would recognize the capture device -- I don't know, maybe it did. I'm guessing that you captured to PAL-DV, which is not lossless. I noted that your interlac ed sample has top-border tearing and distortion that looks different in each field. Some fields have no distortion, while other field in the same frame does. There's also some bad magenta chroma noise and rainbows (CS6 can't fix that).

The attached mp4 is a deinterlaced version of your test sample version that displays one field at a time from each frame, slowed down to 5fps. You can see that the flagging at the top varies in each field and that recompression is costing some clarity and generating noise. It looks as if you had to mask 40 pixels on each side of the frame -- a proper tbc would prevent the border distortion you seem to be trying to mask.

This is the process I'm using:
I'm using Capture AVI in VirtualDub 720x576 YUY2, capture filter SECAM_B, through the PlexGear unit from a DVD/VHS combi player (PAL), using composite cables. The result is a file at about 300gb for an average tape.
I edit the .avi in Premiere CS6 and encode it as .wmv for a final product at about 1.3gb, quality seems to be indifferent from what I captured in VirtualDub. I'm definitely going to deinterlace though.

Yes I masked a couple of pixels along the edges, figured it was the easiest way to get around border distortion. A TBC would make my life much easier but sadly it's not an option right now.

[metaleonid]

If you don't wanna buy TBC and capturing in SECAM, I would recommend

http://www.ebay.com/sch/i.html?_from...video&_sacat=0 (only last 2 with Philips chip, not 90)

Should you decide if this is an option, PM me. You will need different drivers and different software. The guy who designed the software was specifically designing it for SECAM capture.

--Leonid

[lordsmurf]

For a small project, less than 50 tapes, just send it to a quality professional service.
We handle things like this all the time. Contact Us if interested.

There's two separate issues going on here.
(1) an external TBC is needed
(2) there seems to be some tearing, meaning that a passthrough TBC is also needed (Panasonic ES10)

Finding units in properly working condition takes times, and will run about $200-500.