Stabilize VHS video captured without full-frame TBC?
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 |
Quote:
Can you provide a short sample? |
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. |
1 Attachment(s)
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) Code:
avisource("1.avi") "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. |
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: Code:
avisource("1.avi") |
Quote:
|
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? |
Quote:
|
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! |
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? |
Surely now I'll buy a ES10 before, because its a cost <100$ vs a cost of about 400$ for a working tbc!
|
Quote:
Quote:
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:
|
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.