Stabilize VHS video captured without full-frame TBC?

[benzio]

Hello everyone,
I have a very old VHS, very ruined, with valuable content but almost garbage quality.

I have a good hardware:
VCR Panasonic HS1000 with line tbc
Full Frame TBC AVT8710
ATI All in Wonder capture card
Blue Jeans S-video cables
I capture with virtualdub

I captured many vhs with these tools (tbc included).
But there is this vhs that, with every combination of timing option in virtualdub, generates a lot of error that make it unwatchable despite 0 frames dropped and 0 frames inserted. The problem is that the tbc correctly stabilize the video frame but causes the video go ahead some frames (variable), then come back one frame, and then go ahead again, resulting in a strange jagged video playing.

I tried capturing that vhs multiple times with the tbc with different options but the problem is always the same.

Then I tried to capture without tbc and the order of the frames and the fields is now correct, but the image is not very stable and it's trembling.

Meanwhile the quality of the vhs dropped capure after capture. Every time I play there is degradation.

I wonder how could I stabilze the video. Could you suggest me something?
Is there some Avisynth filter to manage that?
Thank you

[dpalomaki]

Quote:

Originally Posted by benzio

...The problem is that the tbc correctly stabilize the video frame but causes the video go ahead some frames (variable), then come back one frame, and then go ahead again, resulting in a strange jagged video playing....

Sounds like the TBC is repeating frames when the input is too unstable for it to use until it receives a usable frame. Any chance you could try other VCRs to see if they can play it better?

Can you provide a short sample?

[lordsmurf]

If that's a BLACK AVT-8710, and not the GREEN one, that's your problem. That TBC model is defective, and those problem being described is exactly what it does.

- freeze frames
- back-and-forth frames (time skip and jump)

It's simply a defective TBC.

If you had a JVC VCR, instead of Panasonic, the "JVC test" would quickly show the problems.

(FYI: I have some TBCs available for sale, but my supply is almost gone. PM me if interested. None of mine have any such issues, and one of these is actually still new.)

Trying to capture without the TBC will cause lots of dropped/inserted frames. And other various timing/sync issues, like the wobbling/trembling that you're seeing.

[benzio]

Oh yes. I have that model :-( I would like to buy a non-defective unit but I cannot invest money right now. Maybe next salary/ next month. I hope you will still sell a good unit next month.

For now I tried to handle the issue with avisynth.
The issue caused by the defective tbc is that the captured video has duplicate FIELDS in different nearby frames in random positions.

For instance if a couple of letters is a frame and each letter is a field I can find something like that:
AB AC DE FG HI JK LM LN OP QR QS TU VW XW YZ


So I thought to act this way:
1) Separate the fields. Now in each field there are some random duplicate frames.
2) Substitute all the second duplicates with black frames in the two fields
3) Then I deinterlace the field doubling the frame rate.
4) From the deinterlaced video I remove all the black frames
5) I re-interlace the progressive video dropping out the interpolated lines.
6) Now IN THEORY I should have the clean video.

The VHS now is almost gone. The new TBC will be needed for the future VHSs but for this I have to keep this mess of capture, trying to correct the error of the defective tbc.

Another user in another forum helped me with a procedure in AVISYNTH for my passages 1) 2) 3)

avisource("1.avi")
ConvertToYUY2()
AssumeTFF()
SeparateFields()

even = SelectEven()
odd = SelectOdd()

black = even.coloryuv(off_y=-256, cont_u=-256, cont_v=-256).colorYUV(off_y=16)

even = ConditionalFilter(even, even, black, "YDifferenceFromPrevious()", "greaterthan", "2")
odd = ConditionalFilter(odd, odd, black, "YDifferenceFromPrevious()", "greaterthan", "2")

interleave(even,odd)

But it gives me an error:

"Plane Difference: only planar images (as YV12) supported!"

Then I tried to write ConvertToYV12() instead of ConvertToYUY2() but the result was the same.


I attach a sample of the captured video with the defective TBC.

[benzio]

I've figured out how to handle the problem due to the the capture with defective tbc.
Every improvent is appreciated.

I tried these three alternative:
1) Transform the second duplicates fields in black fields
2) Transform the second duplicate fields in black fields, then deinterlace, remove the black frames and reverse-interlace
3) Trasform the second duplicate fields in a motion-estimated interpolation of the near fields.

The third alternative is the best and it is resolutive for me.

This practice allows me to correct (the best as I can) the errors of my defective TBC AVT8710.
This is a temporary solution: the only true solution to the problem would be to buy a non defective TBC!

In my case it was compulsory to adopt this solution because the VHS was acquired with the defective TBC multiple times (because I tried to correct the errors in various unsuccessful ways). It was very degraded before and after every playing it was sensibly more degraded.
So now a working TBC would be unuseful for that VHS!

The avisynth code that handle this situation is this:

avisource("1.avi")
ConvertToYV12(interlaced=true)
AssumeTFF()
SeparateFields()

even = SelectEven()
odd = SelectOdd()

function DoubleFPS2(clip source){
super = MSuper(source, pel=2, hpad=0, vpad=0, rfilter=4)
backward_1 = MAnalyse(super, chroma=false, isb=true, blksize=16, searchparam=3, plevel=0, search=3, badrange=(-24))
forward_1 = MAnalyse(super, chroma=false, isb=false, blksize=16, searchparam=3, plevel=0, search=3, badrange=(-24))
backward_2 = MRecalculate(super, chroma=false, backward_1, blksize=8, searchparam=1, search=3)
forward_2 = MRecalculate(super, chroma=false, forward_1, blksize=8, searchparam=1, search=3)
backward_3 = MRecalculate(super, chroma=false, backward_2, blksize=4, searchparam=0, search=3)
forward_3 = MRecalculate(super, chroma=false, forward_2, blksize=4, searchparam=0, search=3)
MBlockFps(source, super, backward_3, forward_3, num=2*FramerateNumerator(source), den=FramerateDenominator(source), mode=0)
}

evenr = even.DoubleFPS2().SelectOdd()
oddr = odd.DoubleFPs2().SelectOdd()

even = ConditionalFilter(even, even, evenr, "YDifferenceFromPrevious()", "greaterthan", "2")
odd = ConditionalFilter(odd, odd, oddr, "YDifferenceFromPrevious()", "greaterthan", "2")

a = interleave(even,odd).killaudio()
a
weave()

ConvertToYUY2()

QTGMC(Preset="Placebo")

i've found the function DoubleFPS2() in another forum

[sanlyn]

Quote:

Originally Posted by benzio

I've figured out how to handle the problem due to the the capture with defective tbc.
Every improvent is appreciated.

I tried these three alternative:
1) Transform the second duplicates fields in black fields
2) Transform the second duplicate fields in black fields, then deinterlace, remove the black frames and reverse-interlace
3) Trasform the second duplicate fields in a motion-estimated interpolation of the near fields.

The third alternative is the best and it is resolutive for me.

I wouldn't invest the time to run scripts like this nor put up with all the ugly artifacts created. Easier, faster and cleaner to recapture using a decent frame-sync tbc and get rid of the bad AVT-8710. Better solution: recapture using the player and gear and software you mentioned, but replace the AVT with a Panasonic DMR-ES10 or DMR-ES15 DVD recorder used as a pass-thru device between the player and the capture card. Turn off the Panasonic's dnr. It's a good line-level and frame sync tbc although it won't defeat macrovision. And don't let anyone tell you that any minor side effect of Panasonic's pass-thru processing is anywhere near as bad or as inconvenient as the kind of wholesale frame interpolation defects you're producing now.

[benzio]

Sanlyn, I do not understand a thing:
A pass through a Panasonic DMR-ES10 dvd recorder has the same result as passing through an external tbc like an AVT or a DatavideoTBC?

[sanlyn]

Quote:

Originally Posted by benzio

A pass through a Panasonic DMR-ES10 dvd recorder has the same result as passing through an external tbc like an AVT or a DatavideoTBC?

Effectively, yes, for basic frame sync cleanup -- except that pass-thru devices like this won't defeat macrovision. If copy protection is a problem, you're stuck with standard external tbc's. I'm surprised you haven't heard of pass-thru earlier. People have been using and discussing it for years, including posts in this forum, videohelp, and avs forum.

[benzio]

It's not a long time I decided to digitalize my vhs collection. I read a lot of stuff in this forum and I bought proper hardware, but the pass through technique is new to me. Since all the vhs I want to digitalize are tv recordings maybe the pass through will suffice.

But I see that LordSmurf has arguments in favor of the importance of the tbc, even if you don't need to break any copy protection.

I'd like to hear even his point of view relatively to my situation.

Thanks!

[sanlyn]

pass-thru frame sync in a pass-thru unit and the same thing in an external tbc are very similar. Lordsmurf is correct in that a pass-thru tbc won't clean copy protection errors but it otherwise works like other tbc's. The two Panny units are recommended because they are more powerful than later units, most of which can't be used for pass-thru at all.

If you're satisfied with the frame interpolation workaround then OK, but who wants all that distortion and hard processing when it's avoidable?

[benzio]

Surely now I'll buy a ES10 before, because its a cost <100$ vs a cost of about 400$ for a working tbc!

[lordsmurf]

Quote:

Originally Posted by sanlyn

I wouldn't invest the time to run scripts like this nor put up with all the ugly artifacts created.

Indeed!

Quote:

Originally Posted by benzio

Sanlyn, I do not understand a thing:
A pass through a Panasonic DMR-ES10 dvd recorder has the same result as passing through an external tbc like an AVT or a DatavideoTBC?

A framesync TBC (referring specifically to DataVideo, Cypress/AVT) captures an entire frame to memory, and outputs it as a new frame. But if you have any line/field issues, those remain unchanged. The line/field TBCs are what clean the image. The framesync cleans the imperfect signal. Whole frames can sometimes jitter, which is why jitter can be corrected. And some other issues. But it's mostly for dropped frames.

The ES10 is not exactly a framesync TBC, or even necessarily a TBC at all. To be honest, I've always had a hard time pegging it down. I need to go back and read my VCR theory book sometimes, but the ES10 is close to be a field TBC (multi-line TBC). And with the frame buffer -- but one with "holes" to allow the artificial video error known as "copy protection" (Macrovision) to pass through. The problem, of course, is that legit non-fake errors too often trip up the so-called "copy protection".

Quote:

Originally Posted by benzio

Surely now I'll buy a ES10 before, because its a cost <100$ vs a cost of about 400$ for a working tbc!

If your source will cooperate, go for it.