VirtualDub border masking? (not cropping!)
 

i captured some home VHS material and removed the lower border (8 pixels) with VCR noise and resized back to the full size (720x576, PAL). the results looked OK, but i was scolded about doing this on another site, and learned that cropping and resizing is a tabu in this hobby. since then, i spent countless hours searching on ways to remove the noise the correct way. the digitalFAQ guide explains how the border should be masked, but not cropped, but without showing how. then i found this sticky post here: http://www.digitalfaq.com/forum/vide...erly-crop.html

i read it and it's about (...gasp!) cropping and resizing. what am i missing here?

thank you very much (in advance) for clearing my confusion.

BTW, i wanted to try the cropping guide method anyhow, but there there is no "cropping" filter in VD i can find. do i need to download that plugin? i personally used the crop function on capture.

PS. i just tried the border control VD plugin. it masked the noisy line and the clip resolution is unchanged according to the GSpot info. sounds like an easy solution. would this be considered acceptable?

Cutting = NO
Covering = yes

Cover with black border am I doing here with Avisynth or in Edius.
Edius works internally in YUV.

In VDub the filter "border control" means
Unfortunately, most filters operate only in RGB............see screen
----------------

Material is in YUY2 [YUV] and is already cut, then ..

Customize Add Border..exakt

Example is here but in PAL,see screen 2

There's no way I would go along with that guide you refer to. Seen it. No, thanks.

If you removed 8 pixels from the bottom of a 720x576 capture and resized the remainder, you filled the frame but you changed the original image height from 568 to 576 pixels. Other than different aspect ratios, one problem is that resizing is never free: it always costs quality, more or less, and some resizers are just plain bad. Another problem with that full-frame resize is that the usual TV overscan will cover that bottom area anyway (yes, modern TV's still use overscan, unless you've disabled it on yours). So you didn't gain anything in height by altering the image. In fact, you lost some pixels during play.

Another matter you might consider: if your original video was for 4:3 display, there were likely anywhere from 8 to 16-pixels of side black borders as well, either all on one side of the frame or unevenly/evenly placed on each side. A 4:3 capture in most systems, if they comply with all that complicated SMPTE engineering garbage, fills only 704 pixels in a 720-pixel frame. Give or take a few pixels. A 16:9 video will take up more horizontal pixels, with maybe a thin border somewhere along the sides that is negligible. If you let those 4:3 side pixels stay where they were, your video likely doesn't play at exactly 4:3 anyway; it's slightly off. Not much, but off. How do you get around that? You remove the side pixels and encode at 704x576 for "true" 4:3 display -- but if you can see the difference in normal circumstances, well...you're pretty good. For 16:9 you need all the width you can get. In fact, BluRay won't let you get away with 16:9 standard def video in anything but 720 horizontal pixels for PAL or NTSC.

Another reason for not masking and not resizing (other than the fact that resizing always has a quality cost, even if small): Lots of people think Hollywood shot Gone With The Wind, Shane, Casablanca, and all those classic movies from the 1930's thru the early 1950's as 4:3 (1.3333:1) images. Nope. Hollywood never shot movies at 1.3333:1. Only TV movies and shows were shot that way. Hollywood shot movies on 35mm film at 1.37:1, which is slightly wider than 4:3.

Often, then, you'll get classic movies captured with 10 or 12 pixels at the bottom instead of 8 because, in fact, to make that slightly wider image fit inside a 704-pixel width, the image height is just a tad less than "real" 4:3. But, then, you can't be responsible for correcting everything that DVD makers, tape labs and broadcasters do to the original image (unless they totally screwed it up, in which case you'd likely be justified in fixing things the way they should be). And then again, some VCR's just don't get the image correct to begin with. It's a crazy world.

As Goldwingfahrer mentioned, applying that black mask in VirtualDub and most NLE's is an RGB conversion, which eventually has to go back to YUV for encoding to DVD, BluRay, AVCHD, etc. You can avoid that in Avisynth, which is one advantage of Avisynth to begin with. Another advantage is that Avisynth functions let you keep the image more centered in the frame without altering the original content.

If you cover the bottom 8 pixels with a black mask, the image will sit 8 pixels high on playback. No big problem, until you get TV overscan and some of the top of the image gets covered. In Avisynth you can get around it this way:

The original image content hasn't changed. Only the borders are altered, and the image is more centered vertically. Also, you didn't have to convert to RGB and back to YUV for encoding. (NOTE: These functions also work in YUY2 and RGB). You can do the same thing with the excess side borders. Let's say you have the typical off-center 4:3 DAR image with 12 left pixels and 4 right pixels, plus those 8 on the bottom.[/code]The original image content hasn't changed. Only the borders are altered, and the image is more centered vertically. Also, you didn't have to convert to RGB and back to YUV for encoding. (NOTE: These functions also work in YUY2 and RGB). You can do the same thing with the excess side borders. Let's say you have the typical off-center 4:3 DAR image with 12 left pixels and 4 right pixels, plus those 8 on the bottom.
The image is centered, original image content unchanged, frame is 720x576.

You can do that in YUV without an RGB-and-back conversion. Of course, you might have wanted to go to RGB for other processing, in which case Avisynth is a little more careful about it:

interlaced video:
progressive video:
Now, whether you should make that frame size 704x576 without adding the side borders, understand that 704x576 is valid for DVD/BluRay (but at 4:3 only). Many argue about this, although world wars haven't ensued over it. In fact, likely you'll get 4:3 video in a frame that takes up less than 704 pixels of width, it's maybe 702, 700, or 698 wide. Solve that by removing excess pix on the sides and then adding back a few more pix to get 704x480. Or add pix until you get 720 wide, it's still valid for the standard.

There nothing wrong with the guide at this site. It's 100% accurate.

I responded to questions about it here: http://www.digitalfaq.com/forum/vide...html#post39273

The "border control" plugin for VirtualDub is not as accurate. There's more fine control with the method outlined here.

If you were "scolded" on another site, then I would suggest that the members of that other site were
(a) not reading, but rather skimming your post
(b) not experienced with VirtualDub
(c) simply not very knowledgeable about video in general

"Masking" is, in essence, crop-then-pad. Virtual does this true method. Others just dummy it up, and have added a "mask" function in the software.

There is not "cropping filter" in VirtualDub. It's not a filter. It's a base function of the software, and is a button inside the Video Filters window. But again, it's not a filter.

sanlyn prefers Avisynth. That's fine. Sometimes I do too. It's just another way of doing things. :)

Understand better?

i really like that solution (even though i've never used avisyth before and don't have that much time to master it). one of the reasons i'm sort of stuck with VD i purchased the neat video filter.

how about this:
1. i capture 720x568 in VD using the crop on capture function, video capture card settings to fix the colors/brightness isssues, and huffyouv compression.
2. i edit the video in VD using neat video filtering (i know, it will be slow).
3. then i run the avisynth script to resize to 720x576 and recenter the video (you are right about the side border problem, but lets ignore it for a moment).
4. then i go on to use the final AVI file in my DVD authoring software (i had good luck with nero vision express so far). i don't need to worry about the YUV->RBG conversion at this point, do i?

thanks you all for help. this is not exactly easy or intuitive (at least for me).

I use NeatVideo often myself.

The problem isn't masking as much as resizing is. Don't resize in avisynth, just add border pixels top and bottom. For YUY2 interlaced, you must add pixels in 2's, so 4 at top and 4 at bottom will restore the frame height without resizing.

AddBorders() is an Avisynth built-in function, you don't need to add any plugins. The syntax for the function is AddBorders(left,top,right,bottom). So the code would be:

The border pixels will be black by default.

You can save time by typing this script before opening the video in VirtualDub:

Open that .avs script in VirtualDub using "File" -> "open video file...", find the .avs script, and you can run NeatVideo at the same time on the results, and save the avi.

thanks! i think i understand it now. i had to look up how one makes those scrips to finally get it:
http://avisynth.nl/index.php/First_script

a final question. why the conversion to RGB upfront? just curious.

is it because doing any processing in VD requires RGB conversion?

VirtualDub processes in RGB and outputs uncompressed RGB by default unless you specify colorspace/compression otherwise. Vdub usually gets RGB correct from YUY2, but Avisynth is a bit more careful with it. Notice that YUV->RGB is processed differently for interlaced and progressive video. Some NLE's screw it up.

The three lines of Avisynth text I posted would be the entire .avs script for what you want to do. Tell you what, you wouldn't even have to crop during capture. The same script can do it for you. The Crop() function is also built-in and has similar syntax. The oddity with crop is that you use negative numbers for the pixels you want to remove from right and bottom, positive numbers from left and top (Long story about that. We'll be here all night). In this case the syntax is Crop(left,top,-right,-bottom). So....

http://avisynth.nl/index.php/Crop
The same articles are in Avisynth's online help. Click Start -> All Programs -> look for the Avisynth program group, expand the group and click "Avisynth documentation". The first page has an alphabetic matrix in the left-hand table of contents that links to functions and commands that begin with those letters.

I almost never use NeatVideo, as it's too harsh with filtering. I find various Avisynth and VirtualDub filters to be more nuanced. There is more fine control.

Avisynth will not mask with Crop() alone. It need to be followed immediately by a AddBorders(). I saw some funny-looking scripting up there, and wanted to point it out. You need both, not just one or the other.

The reason I hate Avisynth masking is because the numbers are easy to transpose. It reminds me of coding shorthand CSS. I prefer the visualization of VirtualDub. I've also caught Avisynth doing some weird stuff over the years, when stacking filters, including this one. I like to KISS the scripts (keep it simple, stupid).

You need AvsPmod to use Avisynth with a preview.

The 720/704 thing seems quaint in the HD era, seeing as how major networks screw up so much geometry on a regular basis. (The problem was 720 and 704 were not handled uniformly by hardware and software.)

sanlyn, i could use a clarification here.

after that initial conversion to RGB, followed by masking and neatvideo filter (that is my routine now), and saving back compressed with huffyuv, is the video kept in RGB color space after i open it later for further editing in VD? is that OK for DVD authoring?

Saving in huffyuv can be either YUY2 or RGB, depending on what you tell VirtuaLDub to do. Two separate steps are involved:
(a) specify an output colorspace. The default is RGB.
(b) specify a compressor. The default is uncompressed.

What do you mean by "editing"? If you apply VirtualDub filters -- or use the default "full processing mode" with or without VDub filters -- the incoming video will be converted to RGB whatever its incoming colorspace is. If all you're doing is cutting and joining, use "direct stream copy" to save the output as whatever colorspace and compression the video used on input.

Video cannot be authored for DVD until it is encoded as MPEG. MPEG for DVD is YV12. DVD isn't anything else. Authoring is a separate step altogether. The authoring step has nothing to do with encoding or converting colorspaces -- that's supposed to be set up before you get to the authoring step. If you've been using a one-stop-shopping NLE for everything from edit thru authoring, you mainly just clicked buttons without realizing what was going on under all the icons.

And converted out to whatever:

Attachment 5170

Matching the in/out can be important.

In this image, I have 4:2:2 in (Huffyuv), process RGB native in VDub, output YUY2. Part of the issue here is that the YUY2 output could possibly be turned into YV12. But then I don't know how MainConcept handles input. It may expect 4:2:2 at not 4:2:0 YV12. I can tell the difference.

So, as I often say, I'm not overly worried about colorspace conversions. It's only something to stay cognizant of when you see something wrong. Or when dealing with a studio, that demands certain specs be met (however, I'll tell you that this is rare).

Don't call those NLEs. They're "all-in-one" junk, geared towards newbies. Most of them are Chinese software sold for $50, and not even worth 50 cents. The only decent AIO is/was ConvertXtoDVD.

right, i checked this AM and the default is 24bit RGB (888). so, i'm probably OK here using the default.

exactly, just cutting. i'll make sure to use the stream copy. maybe i'll try to do audio compression at this stage as i see no option for AC3 in the NeroVisionExpress i use (it burns a DVD with uncompressed audio in PCM).

i'm guilty of using the one-stop-shopping NeroVisionExpress. it takes AVI files compressed in hyffyuv and encodes them to mpeg2 before burning the disk. it's convenient and easy to use. what would be an advantage of separating encoding and authoring?

thanks again.

Quite simply.... better Encoding, for example, with
Canopus Procoder, TMPGEnc or HCEnc....

Nero is a fuel programme with bad EnCoder.
As an Authoring Ulead DVD power tools 2. xx... or Ulead Movie Factory 4
or TMPGEnc Authoring Works.

i was not aware of the bad encoder part. what's bad about it?

i started looking for it. does it have to be exactly version 4? I found version 3.5 on ebay.

Edit: Never mind. I did find and purchased Ulead Movie Factory 4SE. Would that be capable of transforming PAL captures into NTSC DVD?

Nero has changed the "Merit" in the system
On DVD the protections have been burnt by the "IFO" and BUP" in blocks side by side.
.... these blocks must be burnt far apart on the DVD.
ImgBurn is able to do this cleanly

Nero is not able.
Closed all GOPs.... only the first GOP

properly put from M=3 and N=12 [PAL]
M=3 and N=15 [NTSC]

adapt from "intra DC precision on 9 or 10 or 11," je after bit rate.

Here a few years ago we had made in Europe 2 big comparative tests with different mpeg2 Encoder.
We saw result...... with bit rates of 6000 kbps no big differences with
CCE [Cinema Craft Encoder] Canopus Procoder, TMPGEnc and HCEnc.
CCE was the quickest.

There were differences, however, with interlaced material with deep bit rates.
There the winner Canopus Procoder was in the mast's ring mode.

I work here with the German version of Ulead power tools 2.
In English the tool Ulead DVD Movie Factory is called.
Is already very old from 2004, me, however, much rather than TMPGEnc Authoring Works or Encore of Adobe.

To the testing I had the last week on a PC the English version of Ulead Movie Factory 4.
Under Win 7 64 there were no problems with the Install.
Problem is only. mine in English is with 1%

Ulead Movie Factory can carry out no norm change.

Norm change of NTSC to PAL or vice versa goes in big videotools like
Of MediaComposer Sony Vegas 13, Adobe premiere and Edius only with "Blends"

I make norm change with Avisynth or with the Capturen with Kramer SP-11D

http://www.hdtvsupply.com/kr-sp11d.html

Give me sometimes a test clip.

goldwingfarher,
thanks for your comprehensive help on this project. while i'm waiting on that Ulead MF4SE disc, i'll experiment with avstodvd/imgburn for authoring in both PAL and NTSC. it was recommended on this and some other forums.

I've never liked Ulead Movie Factory, but some here have reported success with it in the past.

Never use Nero. It's a burning program. Using it to convert video is like going to the oil change gas station to order lunch. That's just not at all what it should be used for.

Hi everyone,
I came back with an update. Using the knowledge acquired here 2 years ago, I captured 4 VHSc and burned one slick DVD with avstodvd/imgburn. I had material for a few more, but project got interrupted by health issues and family emergencies (quite a few too many). Fast forward 2 years, I decided to restart the project, but was set back by forgetting the details and the capture rig failed from old age and had to be rebuilt. I did some searches that lead me back to this very thread.

Now, even though I know the major principles and I'm proficient at using the main tools, I still have lack of clarity what happens behind the scenes.

I'm a bit concerned about that YUV and RGB conversions happening with my filtering/processing. Here are my followup questions:
1. I've heard somewhere on this forum that huffyuv is not lossless when YUV to RGB conversion (or the opposite) happens. Is it true?
2. From reading how NeatVideo works: Neat Video converts an RGB input frame to the YCrCb working color space, the initial capture is in YUV, mind you. Later, that's converted back to RGB at the end (I'm saving filtered clips in huffyuv RGB). So, basically, it's YUV->RGB->YUV->RGB per cycle of neat video in VD, and later -> YUV on DVD. Is all that somehow problematic for the quality?

There might be some more questions later, but these are the main ones I remember now.
Anyone willing to answer them?
Thanks!

Huffyuv has nothing to do with RGB -> YUV colorspace changes. Those conversions are external to huffyuv. Codecs like huffyuv, Lagarith, and UT Video are lossless, period, and they don't in themselves make colorspace conversions. Those conversions are made by video applications and the people who use them.

Like every other VirtualDub filter (and like NeatVideo plugins for programs like Adobe Premiere Pro, Vegas Pro, After Effects, Final Cut Pro, etc.), Neat Video expects RGB input. Internally it does work in a proprietary YCbCr colorspace. I use NeatVideo myself for specific purposes, but it's not a cure-all, doesn't affect many noise issues, destroys detail and causes posterization effects when carelessly used, and should never be used at its default settings.

Input into Virtualdub and most other editors automatically converts to RGB for display. Depending on the processing mode, that RGB conversion occurs for filtering and is kept as the output unless you instruct Virtualdub or other processor apps to either convert it to something else on output, or to not filter processing at all. In VirtualDub, "full processing mode" always converts to RGB, even if you save the results as something else and even if you don't apply VirtualDub filters. To avoid a colorspace change you can use another processing mode, such as "fast recompress" or"direct stream copy" (if you use those Virtualdub processing modes, any filters you've loaded will not be applied and no "real" RGB conversion to the original signal occurs).

The YUV colorspace isn't always YUY2. It could be any number of other variations, most often YV12 used for video encoding and for most Avisynth filters. It's lower-resolution color like YV12 to RGB that causes problems after a successive chain of conversion back and forth -- due to numeric rounding errors in computing the interpolation between one colorspace and the other. Most editors screw up YV12->RGB or YV12->YUY2 and back again in one way or another and to a certain degree -- probably not enough to notice with a single conversion but the errors accumulate. Errors also accumulate with YUY2-> RGB, but they're not as noticeable as lower-to-higher-resolution and back again.

I always use huffyuv for analog capture because of huff's speed and reliability with YUY2. But the misgiving I have with huffyuv is that a great deal of Avisynth processing works with YV12, and huffyuv can't compress YV12. So if you want to save a YV12 job with huffyuv compression, you have to convert to YUY2 or RGB. Do that often enough and you'll start to see subtle color shifts and other changes that you don't like. For post-processing I use Lagarith to avoid unnecessary YV12-YUY2-RGB colorspace conversions and to exercise more control over multiple processing stages. I don't always use Virtualdub filters for cleanup, so I don't have an RGB conversion issue, and when I do need that conversion I do it in Avisynth. Eventually, for most encoding, I use Avisynth for saving a file as YV12 for MPEG or h.264 encoding.

Normally, colorspace conversions don't cause a great deal of trouble. This assumes, however, that your YUV luma and color levels are within the preferred YUV spec of y=16 to 235. Expansion of out-of-spec YUV values when converting to RGB causes clipping of dark and bright details that can't be recovered later. With proper YUV levels you won't see much difference between a YUV->RGB conversion or two. But after several such conversions you'll undoubtedly encounter accumulated interpolation errors.

Sanlyn,
Thanks a lot for taking your time to explain this again.

I continue to use NeatVideo as this gives me the best noise filtering results from all the different things I tried and it's user friendly. I used to use settings below the default, but that slipped my mind and now I used default settings (adaptive, auto, 0% adjustment of noise level, 60% luma and 100% chroma noise reduction, 0% sharpening). Yes, there is a subtle loss of details in busy textures, but the awful noise of old and tired VHSc is gone. I see no posterization whatsoever.

Thanks for clarifying the YUY2 vs YV12 difference. So far I used YUY2 or RGB only in the process, so it should be OK.

Based on your post today, I started using Logarith/RGB for compression after the masking and Neatvideo. It runs slower than hyffyuv, but not a huge difference. I'll try later if that's acceptable for my later encoding/authoring/burning steps.

in summary this is my most current workflow:
1. capture entire cassette with huffyuv/YUY2
2. VDub cutting into smaller clips (direct stream copy)
3. using your above .avs script for masking in Vdub combined with NeatVideo and save into Logarith/RGB
does it look right to you?

Lagarith is a bit slower than huffyuv -- which is why I don't use Lagarith for capture -- but Lagarith usually makes smaller files. I noted that you save Virtualdub output as RGB. You can save it as YUY2 if you wish. You have to keep VirtualDub in "full processing mode" to apply its filters, but you can set the output color depth to YUY2 and the compression to Lagarith on output. In my case, I know that the final output will be encoded to MPEG or h.264, which are YV12. So I save the final output as Lagarith YV12, a much smaller file. That final output colorspace is yet another old debate.

The workflow looks OK to me. Again it comes down to preference. I use NeatVideo often, but not for everything and sparingly at that. Most of my denoising is in Avisynth, color correction in Virtualdub. There are many problema and defects that NeatVideo can't touch, and many that VirtualDub won't fix either. The more problematic the source, the less I can do with NeatVideo. Below are some examples.....

The images are from a 1991 tape recorded off an underpowered cable signal overmodulated with a cheap RadioShack analog cable amp, with a cheap Sears RCA 2-head VCR at 6-hour speed (Yes, I could be shot for what I didn't know back then!). The noise is horrific, the color is putrid. I couldn't use my AG-1980 for playback, as the output had green or pink color bars across the top that came and went. The AG-1980 just didn't like that tape. So I used a rebuilt Panasonic PV-S4670 SVHS, an ES10 tbc pass-thru and an AVT-8710 frame tbc, into my AIW 9600XT card, to huffyuv YUY2.

Below, from the original capture: Note the white spot on the right side and the greenish rainbow tint across the middle, plus discolored magenta and cyan blotches in the background and floor. There are about 12 of those bright white spots all over the frame during the short AVI sample I've attached to this post. Neither NeatVideo nor CamcorderColorDenoise could fix these uglies:
http://www.digitalfaq.com/forum/atta...1&d=1501173496

Problems mostly fixed with QTGMC, dfttest, MDegrain2, RemoveSpotsMC, and color correction:
http://www.digitalfaq.com/forum/atta...1&d=1501173568

Below, at the bottom there's a two-headed sudden bright flash on the floor, plus cyan and magenta noise in the floor and background, and a "floating" cyan stain in the upper background. NeatVideo/Virtualdub, no help here:
http://www.digitalfaq.com/forum/atta...1&d=1501173631

Spot "flash" and color fixed with the same Avisynth plugins plus some clean detail patches borrowed from other frames and overlaid onto the bad original:
http://www.digitalfaq.com/forum/atta...1&d=1501173712

Below, note the green rainbow that flashed across the upper middle for two or three frames, plus the usual blotches in the floor and upper background.
http://www.digitalfaq.com/forum/atta...1&d=1501173784

Rainbow and blotches about 90% fixed with the same Avisynth filters, plus VDub color correction:
http://www.digitalfaq.com/forum/atta...1&d=1501173839


The Attached Avi sample "GB_Liv7C1_ivtc_spots_and_noise_L.avi" is lossless Lagarith YUY2. It's from the original capture, has been inverse telecined to remove duplicate fields but is otherwise unfiltered. I couldn't get NeatVideo to play nice on this, but you can give it a run. As you play this crummy original note also the bad left-hand image flutter and the flickery noise across the top third of the frame. A lot of unstable noise here. The murky greenish color is really bad, down to the dark blue that's missing from the tuxedos. Anyone who wants to tackle this one, go right ahead. Took me about 4 hours.

I also zipped a NeatVideo .dnp noise sample (device noise profile) from a clear neutral area in another part of the same original movie, attached as "F09_616a_dnp.zip". This is a challenging test for NeatVideo as a one-stop-shoppping cleanup filter.

The imperfect result I got with Avisynth (with no NeatVideo) is attached as "GB07b_Avisynth_results.mp4".

Your problem is different from mine. My issue is home recordings with lots of fine to medium grain (analog) luma and some chroma noise. NeatVideo was the only filter that effectively eliminated that. The only quality issue that I have left is a few random horizontal lines and dropouts from time to time. I understand those lines are the "Static Lines" as per http://www.digitalfaq.com/guides/vid...tore-video.htm

I'm currently researching ways to deal with that, maybe VirtualDub Median filter, maybe RemovedirtMC in AviSynth, but I don't want this to be a never-ending project even though those family recordings are precious.

As for the saving intermediate files in RGB, it's a default in VirtualDub and I didn't want to force yet another conversion. But if YU12 is all it's needed for authoring, I may need to consider that.

BTW, when I remember again how to save frames from VD, I'll post some examples.

PS: Maybe I found a solution for lines and dropouts: http://forum.doom9.org/showthread.ph...hlight=depulse
need to figure out how to use it and test it.

Admittedly the AVi sample is an extreme case of horrible cable transmission, cheap recording, and aging tape. The concept is that many defects, including the static lines you mention (dropouts) can be fixed. The sample is full of dropouts, large and small, as well as other nasties. As you say, it depends on your picture of what you want as a final product. In this case the movie takes me back to another time and place, so it becomes something of importance and extra effort. Not everything goes through this process. No one has forever for this. When something assumes such importance, it's a good idea to suit the tool to the job. In this case my old standby NeatVideo didn't fill the bill.

Fortunately most of my old tapes don't look like this. Thank heaven.
:)

I guess I'll keep this thread as a witness to my journey through video editing.
Below are test frames from my current project. VHSc from 24 years ago. this is about the worst frame in the end of the tape sequence where there are more tape problems (tape reused numerous times). however, the video noise is similar everywhere and dropouts every second or two.
vertical median filter is best for 1 line dropouts (lower part of the frame) while NeatVideo controls noise.

None of these are much of an improvement and would be indiscernible during normal play. Across how many consecutive frames do these dropouts persist? One might get entirely different impressions if you had included a video sample from the original capture.

Another aspect of median averaging is that it assumes defects like dropouts will look different each time the tape is played. That's seldom possible: a dropout is physical damage that is in the same location on every playback, so it will look pretty much the same way on each play most of the time. That's why it works OK with some problems, doesn't work well with other problems, and doesn't do anything at all on others. In this case, the Virtualdub version is not a true multi-sample averaging filter like Avisynth's median, but an attempt at averaging motion analysis of several different frames from the same capture, not an averaging of several different versions of the same frame from multiple captures. This means that these two "medians" are two entirely different processes, not one and the same.

However, your post is essential documentation and a further example of results with the methods discussed.

In the past, in many cases, I solved the problem by playing the tape in a better player.

The improvement is real, see the attached short MP4 samples.
My current working plan is to capture 768x576 saved as huffyuv/YUY2 and then later mask/transform to RGB in that AviSynth script you gave me together with NeatVideo and vertical median filter from JPSPR (as needed only) and save to Logarith/YV12.
Tomorrow I will try some authoring, wish me luck. Can you combine PAL and NTSC clips on the same PAL (or NTSC) DVD?

NeatVideo has destroyed a lot of gradient detail, which is a hallmark of it.

Yes, true, it is better than the source in some ways, but is now worse in others.

Using Avisynth and VirtualDub, it could be cleaned up better ... and more. Perhaps when I get more time, I can show you a sample of what I'd do.

I don' know what you man by "real". Some comparisons of your Median/NV1 fix and what I was able to eek out of the lossy "raw" sample:

Noise, frame 268, VirtualDub Median/NV1 fix:
http://www.digitalfaq.com/forum/atta...1&d=1501411445

Noise, frame 268, Avisynth fix:
http://www.digitalfaq.com/forum/atta...1&d=1501411500

Levels, Color, Definition: frame 5, Median/Nv1:
http://www.digitalfaq.com/forum/atta...1&d=1501411551

Levels, Color, Definition: frame 5, Avisynth/gradation curves/ColorMill:
http://www.digitalfaq.com/forum/atta...1&d=1501411616

Try the attached Raw_fix_PAL.mp4 and let us know if you think it's a little cleaner: http://www.digitalfaq.com/forum/atta...1&d=1501411730

Allow, if you will, a bit of objective summary about some basic operations that could be improved:

No, you can't. It will have to be all of one or the other. You can take 25fps PAL and use Avisynth or an NLE to convert it to 29.97 NTSC but it some PAL parts will playback a little clumsily (not noticed by most viewers). A worse quality hit would be blending or decimation to convert NTSC to PAL.

Something else you can't do is make DVD from 768x576. DVD and standard definition BluRay are anamorphic formats, not square-pixel. If you feed 768x576 into an NLE or authoring program, it's going to be resized to something PAL can accept (720x576 or 704x576) or something NTSC can accept (720x480 or 704 x480). Resizing costs. Always. You're wasting your time capturing 768x576. If you post it on the net it'll be resized by the website to a standard frame format like 640x480. Don't use oddball frame sizes. You're just making problems for yourself.

The top sample that you posted is not a "raw" format. It's a high-loss, low-bitrate, low-accutance encode that's very nearly unusable for effective restoration, with a large-GOP structure that's unsuitable for clean edits. It has illegal luma levels with brights so badly blown out that it's impossible to restore the full dynamic contrast range of the source video. Black levels are artificially high and look under saturated and washed out. The NeatVideo sample looks grossly over filtered and denuded of fine detail and texture, so that it looks foggy and plastic. You can't seriously promote this as quality work. It looks like a demo of typical YouTube missteps. You seem bright enough to do better.

[EDIT] oops, in my haste I encoded that fixed PAL mp4 with an audio sampling rate of 44.1KHz. Oh, well, a little too early in the day to keep it all 100% straight. 44.1K would work for the web, though.
:smack:

Look, I appreciate your time helping out on this forum, but pointing out that you can do better pissing contest is not helping. For all i know you might be a professional doing it all your life, and i'm just a beginner who becomes more and more frustrated with this project as time goes on.

Thanks, I vaguely remembered that some authoring software allowed to switch PAL/NTSC. Maybe I remembered wrong.

You are right, I f...ed up and set up wrong resolution in the capture step. I should have double checked my guide i put together way back. Wasted countless hrs (I captured 3 hrs worth of video that way and did quite a few edits, not no mention filters).

Right, wrong term. It was compressed with huffyuv on capture and later mp4 for upload here.

You mostly lost me here with all that jargon.

I don't promote any claims here. Like I said before, this is the best I can do myself based on my extensive study of this or similar websites over long time and my own trial and error. If you have any pointers rather than just criticism, I'm all ears.

I remember you mentioned elsewhere that it should be 48 kHz? However, my capture guide reads: Audio->Raw capture format, select "PCM: 44100Hz, stereo, 16-bit" and OK

I looked at those frames closely and the upper still is from frame 266 and the lower possibly 268, not entirely sure as chroma was missing in that frame. don't get me wrong, there seems to be great improvement in your filter, but lets compare apples to apples.

I'm glad you pointed out that frame mis-count. I noted on closer inspection that when your Media/NV1.mp4 is opened in some video apps, the first 2 frames are black, and the overall frame count is 2 to 3 frames more than the frame count in other editors and in your "raw" mp4. Using the accuracy of Avisynth's FFMS2 file opener, it appears that whatever you're using to smart render that mp4 isn't so smart about properly marking frames in some GOP's. So the frame numbers I was looking at earlier were a couple of frame numbers off.

So to keep that comparison kosher, let's compare three frames with the proper frame numbers, with your mp4 fix on top and the Avisynth mate for each below it:

frame 266:
http://www.digitalfaq.com/forum/atta...1&d=1501460580
http://www.digitalfaq.com/forum/atta...1&d=1501460589


frame 267:
http://www.digitalfaq.com/forum/atta...1&d=1501460675
http://www.digitalfaq.com/forum/atta...1&d=1501460683

frame 268:
http://www.digitalfaq.com/forum/atta...1&d=1501460778
http://www.digitalfaq.com/forum/atta...1&d=1501460792

Nope. A hobbyist. I just used different filters.

Sorry for the technical jargon and details. I made invalid assumptions based on most readers who show up in forums such as this in order to learn more about video and how to get better results. We don't usually get readers who are looking for the opposite. My error.

Get scripts from 'VirtualDub border masking? (not cropping!)' thread?
 

While searching for one thing on DigitalFAQ, I always run into something else interesting and then go down that rabbit hole. Today, I found the thread "VirtualDub border masking? (not cropping!)" that started on 08-13-2015 and ended on 07-30-2017. The masking discussion was interesting but the topic that really woke me up was Sanlyn's restoration examples on page 2. Wow! I'm very impressed with his changes to a 1991 tape and the noise eliminated in the baby clip. I have seen similar issues with the VHS tape captures I am doing.

I'm back to learning how to use AviSynth effectively and am studying the filter settings Sanlyn suggested for some terrible 16mm captures I have. To further my education, are the scripts for the clips in the "VirtualDub border..." thread available? I believe they would be great examples of how I should approach my captured VHS tapes.

Thank you very much for your extensive help in this and other threads,
Steve

Thread/post merged.
PM sanlyn, as for his input (here in this thread) since those are his scripts. :wink2:

Thank you. I hate videos like that. Sometimes they can't be repaired.

The script for the 1991 movie is archived somewhere, I'll need more time to dig it up and fix it for posting.

Meanwhile the script for the baby video mp4 in post #29 of this thread has long since disappeared. However, I reworked the script and added a tweak or two.

The source video is the lossy compressed "raw.mp4" in post #27 (http://www.digitalfaq.com/forum/atta...masking-rawmp4). Apparently the owner doesn't have the original capture. Referring to h.264 encodes as "raw" isn't really correct. Raw is a specific format, definitely not h.264. When working with lossy encodes don't expect the same results one would get from a lossless capture. Lossy video means unrecoverable loss as well as compression artifacts that are difficult to deal with. In this case, the mp4 source has severe dropouts or "rips" that require destructive filters -- which is why, if drastic repairs are required, lossy samples are a very very very poor choice.

The source mp4 was resized to a 768-pixel width while still interlaced, which makes the dropout distortion look worse. Apparently the 768x576 width was used to get a 4:3 square-pixel image. This is often used (incorrectly) with web posting in mind and to help inferior playback systems that can't handle anamorphic video. Keep in mind that resizing for this 4:3 result makes no improvement whatever and exacerbates problems with video that hasn't been denoised. The result is also unsuitable for web posting because it is still interlaced; any website on which it is posted would deinterlace it using the quickest and worst means possible, and the video would be resized anyway to something more standard such as 640x480. As-is, the mp4 sample is unplayable on a website.

The script below is approximately the same script I used for the "fix" mp4 posted as "Raw_fix_PAL.mp4" in post #29. The results of the below script are attached as "Raw_fix2_25p.mp4". Because the FixRiptsP2 filter is a very slow memory-intensive plugin, I used a two-step process with two scripts for the total job.

Script details for Step 1:

##-- open video only with FFMS2 - no audio --##
ffVideoSource("Drive:\path\to\raw.mp4")
Avisynth's FFMS2 plugin is used to decode the video-only track of the source video. FFMS2 is also known as FFMpegSource and has many functions. http://avisynth.nl/index.php/FFmpegSource

ColorYUV(off_y=-25,gamma_y=-5,off_u=3,off_v=-2)
Tweak(sat=1.3,dither=true,coring=false)
#-- test for levels --
#Crop(12,0,-12,-12)
#Histogram("Levels")
#return last
#-- end levels test --
This section of code corrects obviously high black levels which look washed out and which results in bad clipping of bright details. Tweak() is also used to correct low saturation and color density loss. The lines that begin with "#" show some test code that is disabled as comments-only for the final output version. Note that Crop() is used to avoid borders that would affect the YUV histogram. When enabled, the YUV histogram that appears for the original, uncorrected images looks like the histogram below, with high gamma and bright clipping beyond y=-235:

baby video original YUV levels
http://www.digitalfaq.com/forum/atta...1&d=1537321065

The corrected image produces this YUV histogram:

baby video corrected YUV levels
http://www.digitalfaq.com/forum/atta...1&d=1537321108

AssumeTFF()
SeparateFields()
FixRipsP2()
Weave()
FixRipsP2 is a last-resort plugin script designed for the kind of severe dropouts in the source video. It's a slow and destructive filter that involves compromise; in high-motion scenarios it can produce bizarre distortions and can make objects disappear entirely. In this case motion wasn't so hectic that the filter couldn't do some work. But you will see signs of minor distortion. FixRipsP2 should not be used on interlaced video, so SeparateFields() is used, then Weave() is used to restore interlacing. Given the bad dropout problem, a full deinterlace would look horrible.
FixRipsP2.avs is here:http://www.digitalfaq.com/forum/atta...d-fixripsp2avs.
FixRipsP2 requires the following:
DePan_Tools v1.13.1. http://www.digitalfaq.com/forum/atta...1&d=1531396979
RgTools.dll http://avisynth.nl/index.php/RgTools (also supplied with the QTGMC package). Also required:
Microsoft Visual C++ 2015 Redistributable Package (x86 / x64). https://www.microsoft.com/en-us/down....aspx?id=53587
MVTools 2.27.21.x or later. http://www.digitalfaq.com/forum/atta...s2_27_21_22zip (also supplied with the QTGMC package).

Crop(12,0,-12,-12).AddBorders(12,6,12,6)
##----------- Return video only. -----------##
##-- Save as "Raw_Step 1.avi" using Lagarith YV12 --##
return last
This code crops away uneven borders and bottom border head-switching noise, then adds new black borders and centers the image. The original left border also has 2 pixels of noisy "stuff". The "return last" line outputs the results of the last operation, which is the Crop() line. The script was run in Virtualdub, so VDub was set to save the file as YV12 using Lagarith lossless compression using the filename Raw_Step 1.avi.

Details of Step 2 script:

aud = ffAudioSource("Drive:\path\to\raw.mp4")
vid = Avisource("Drive:\path\to\Raw_Step1.avi")
The first line uses FFMS2 to decode the original lossy audio (low quality audio that can't be used on then 'net). The audio data is saved in memory as an entity that I named "aud". It will be used later at the end of the script. AviSource() is used to decode the Step 1.avi that came from the Step 1 script. The video portion is saved in memory to a video clip that I named "vid".

vid
AssumeTFF()
QTGMC(preset="medium", border=true, fpsDivisor=2) #<- creates progressive 25fps output.
source=last
The first line directs Avisynth to focus operations on the video clip named "vid". AssumeTFF() sets proper field polarity and overrides Avisynth's BFF default. QTGMC is used to deintelace using its "medium" setup parameter, which includes some denoising, motion smoothing, and some anti-aliasing. The border=true parameter helps prevent top-border twitter. The fpsDivisor=2 parameter drops alternate fields after creating new interpolated frames from both fields, resulting in 25fps progressive video. If this parameter is omitted, QTGMC's output would be 50fps double-rate progressive. The choice is up to the user, but motion will be smoother at 50fps or as interlaced 25i. Many websites will drop alternate fields anyway, so you may as well let QTGMC do a much cleaner job of it. The last line saves the deinterlaced result in memory as a new clip arbitrarily named "source".

The QTGMC plugin package with its support files is at http://www.digitalfaq.com/forum/atta...g-qtgmc_newzip.

chroma=source.Loop(8,265,0)
chroma=MergeChroma(source, chroma)
ReplaceFramesSimple(source, chroma, mappings="[266 272]")
Chroma_A=last
This group of lines plays tricks with chroma, borrowing chroma from one frame to overlay its colors onto other frames. There are several consecutive monochrome frames in the source video that suffered chroma loss through poor tracking. This code attempts to borrow the chroma values from frame 265 and apply that chroma to frames 266 thru 272 in the source. The line chroma=source.Loop(8,265,0) copies frame 265 eight times over the original video starting at frame 265, and creates a new video clip in memory called "chroma". With chroma=MergeChroma(source, chroma) the "chroma' video is then modified to merge the chroma-only of the "chroma" clip with the luma-only of "source". Thus, the "colors" in frame 265 are now used to overlay all of the frames in the new "chroma" clip. But we really want borrowed colors only in frames 266 thru 272. So ReplaceFramesSimple(source, chroma, mappings="[266 272]") replaces frames 266 to 272 in the "source" video with frames 266 thru 272 of the "chroma" video.

The results of the borrowed and replaced chroma are saved in memory as a new clip named "Chroma_A".

Merge function: http://avisynth.nl/index.php/Merge
Loop function: http://avisynth.nl/index.php/Loop
ReplaceFramesSimple (in RemapFrames): http://avisynth.nl/index.php/RemapFrames

chroma=source.Trim(275,275)
chroma=chroma.Loop(377,0,0)
chroma=MergeChroma(source,chroma)
ReplaceFramesSimple(Chroma_A, chroma, mappings="273 274")
The first line chroma=source.Trim(275,275) creates a new version of "chroma" that contains only frame 275 from the "source" clip. Then "chroma" is expanded to contain a loop of 377 copies of frame 275 (which is frame "0" in the new clip). You'll need a clip that is at least 377 frames long in order to match the frames in "Chroma_A". ReplaceFramesSimple(Chroma_A, chroma, mappings="273 274") replaces the monochrome frames 273 and 274 in "Chroma_A" with borrowed chroma frames 273 and 274 in "chroma". The next few lines will perform operations on the results.

ReplaceFramesMC(267,2)
RemoveDirtMC(30,false)
ReplaceFramesMC is used to interpolate new replacement frames for the noisy remnants in frames 267 and 268. There's not much motion in those two frames, so any distortion created by the interpolation will be minor. The two new frames for 267 and 268 will be created based on information in the preceding and following frames, which are frames 266 and 269. Then RemoveDirtMC(30,false) is used for mild denoising of some of the lossy compression grunge that remains in the video.

RelaceFramesMC.avsi is here: http://www.digitalfaq.com/forum/atta...ceframesmcavsi. It requires MVTools 2.27.21.x or later (see above). MVTools is also supplied with the QTGMC plugin.
RemoveDirtMC.avs is here: http://www.digitalfaq.com/forum/atta...emovedirtmcavs. The filter requires RemoveDirt_v09 (http://www.digitalfaq.com/forum/atta...ovedirt_v09zip). It also requires the RemoveGrain package (http://www.digitalfaq.com/forum/atta..._v1_0_fileszip) or use the RgtTools plugin mentioned earlier.
If you are using Windows 7 thru W10, you might also need some VC++ support files. Read here: http://www.digitalfaq.com/forum/vide...s-running.html.

MergeChroma(aWarpSharp2(depth=20).aWarpSharp2(dept h=10))
LimitedSharpenFaster(edgemode=2)
GradFun2DBmod(thr=1.5,mask=false)
AddGrainC(1.25,1.25)
Chroma_B=last
The aWarpSharp2 code tightens some color bleed around edges and smooths some ragged lines. The code sharpens chroma only, not luma. LimitedSharpenFaster(edgemode=2) sharpens inner detail between edges and is limited so as not to produce more edge halos. GradFun2DBmod is used to mollify some of the muddy posterizing effects that come from low-bitrate lossy encoding in the source sample, often called "clay-face' effects. AddGrainC adds small amounts of very fine film-like grain to help mask hard gradient edges in large smooth expanses such as the background walls. Finally, the result of all of the preceding code is saved as a new video clip named "Chroma_B".

GradFun2DBmod: main page and download link are at http://avisynth.nl/index.php/GradFun2DBmod.
It requires GradFun2DB (http://avisynth.nl/index.php/GradFun2db). It also requires AddGrainC, MaskTools2, and RGTools, which are all included with QTGMC (see above notes).

LimitedSharpenFaster is in LimitedSharpenFaster.zip (http://www.digitalfaq.com/forum/atta...arpenfasterzip). It requires aWarpSharp2 (http://www.digitalfaq.com/forum/atta...sharp2_2015zip). It also requires MaskTools2 and RemoveGrain, which are included with QTGMC (see earlier links for the QTGMC package).

AudioDub(Chroma_B,aud)
return last
The last two lines join the video in "Chroma_B" with the audio in "aud", and then the results of the "last" operation are output.
AudioDub function: http://avisynth.nl/index.php/AudioDub

There are links to some other popular Avisynth filters in this post: http://www.digitalfaq.com/forum/vide...html#post55834.

Here are details of the Avisynth scripts and VirtualDub settings used for the restoration samples in this thread's post #22 (http://www.digitalfaq.com/forum/vide...html#post50385). Perhaps someone can use some of the convoluted workflow tips contained herein. This was a difficult project for repair of a 1991 VHS recording from a bad cable tv signal using really cheapo equipment and an even cheaper RadioShack analog cable amp (cable wasn't digital back then!).

The original recorder no longer exists, which is just as well -- there is no way I would use it for capture. The bad and noisy cable signal, cheap wiring, and cheap gear produced recordings with a horrible noise level. I made multiple captures, each having their own set of defects and problems. The players used were a Panasonic AG-1980 and a 1996 Panasonic PV-V4670 (with a Panasonic Es-10 for tbc pass-thru with the 4670). Both are SVHS machines with s-video output. The capture version used for different processing segments depended on which player gave me fewer tracking problems with dried-up, poorly stored tape. To this day I can barely tell which player produced which capture.

The cables used were BlueJeans Cables YC-2 s-video (https://www.bluejeanscable.com/store/svideo/index.htm) and Belden 1694-A for audio (https://www.bluejeanscable.com/store/audio/index.htm). With both players the bad tape and noisy signal gave false Macrovision effects, so my trusty old AVT-8710 frame-level tbc from 2004 was used in the chain. For a UV LED meter to check signal levels, I used a SignVideo PA-100 proc amp with no color correction applied (I saved color work for post processing). YUV levels were double-checked in VirtualDub Capture with image borders temporarily cropped and then restored before starting capture to YUY2 using huffYUV lossless compression and uncompressed PCM audio. The capture card used for this particular capture was an ATI All In Wonder 9600XT AGP. After reviewing the original capture, I cut it into several segments (cable tv commercials removed) into Lagarith YUY2 files archived on an external hard drive.

I use file naming and coding conventions that are pretty much standard for my workflow -- including oddball file names that help identify the source video and the processing stage. For example, the file name "GB_Liv7C1_ivtc.avs" identifies the file as an Avsinyth script. The "GB" is a group of work and output files from groupings starting with "A" thru "K". These are working groups from a long capture split into 8 to 10-minute segments. "Liv7C1" identifies the original lossless source capture name. "ivtc" indicates that the script performs inverse telecine. That script would produce a lossless AVI named "GB_Liv7C1_ivtc.avi", which matches the name of the script.

One of several sequential .avs scripts that worked on the ivtc'd source is called "GB07_Liv7C1_ivtc_Q_vd.avs". This name identifies the work as belonging to the "GB" group and would be script number 07 in the series that splits the ivtc'd source into several smaller output files. The source capture has many problems that vary scene by scene, so several scripts are often used on a 10-minute source, breaking the source into many smaller sections. The sections are joined later for encoding. "Liv7C1_ivtc" identifies the source as the ivtc'd file. "Q_vd" indicates that QTGMC is used in the script and that VirtualDub filters ("vd") are applied to the script's output. The VirtualDub settings for that script are saved as "GB07_Liv7C1_ivtc_Q_vd2.vcf" using a name that identifies the matching script and a "2" to indicate version 2 of the VDub settings. The lossless file produced is named "GB07_Liv7C1_ivtc_Q_vd.avi" to match the name of the script.

And so on.

I haven't attempted to change the path names shown in the scripts but I removed many of the superfluous "#" comments and disabled lines.

Script #1 is the inverse telecine script for the source capture segment Liv7C1, which was a 22-minute segment of the original 86-minute capture archived on an external hard drive ("J:"). The script starts at frame 14898, using the last 7.5 minutes of the original file.

An edited but otherwise unimproved short section of the ivtc'd lossless output is attached to post #22 as
"GB_Liv7C1_ivtc_spots_and_noise_L.avi" (http://www.digitalfaq.com/forum/atta...and_noise_lavi). The sample is losslessly compressed YUY2 using the Lagarith codec.

The first cleanup stage used on the last part of the sample scene is the script below. The script begins by loading a specified set of Avisynth plugins that allow using QTGMC in a YUY2 colorspace and allows use of some 16-bit processing later in the script with the GradFun3 function. The script also begins with a "Loop" function to add frames to the end for fade-in and fade-out, but I don't recall exactly how I figured that out and wouldn't want to do it again.

Input from the ivtc'd source file is YUY2 progressive at 23.976 fps film speed. This script isn't the final cleanup for this scene.

The output was saved from VirtualDub as Lagarith YV12, after VDub filters were applied. As noted at the end of the script, some frames are manipulated so that a fade to black is applied in VirtualDub to Avisynth's output. This is noted in the script because the settings for VDub's FadeFX filter can't be saved in a .vcf file (phooey!). The settings for two other VDub filters were saved in GB07_Liv7C1_ivtc_Q_vd2.vcf, which is attached. The two filters were gradation curves and ColorMill. As for the Avisynth plugins, I always thought I restored too much original film grain.

There were still a ton of dropouts, blobs, blotches, and odd "flashes" in difficult places, as shown in the images in post #22. So a third Avisynth run with special "patching" routines was required. By this I mean that because there was so much motion, the usual de-spot filters didn't work and complete frame replacement with ReplaceFramesMC wasn't feasible because of the gross movement distortion involved. So small square "patches" had to be created from clean areas of the frame and overlaid onto the trouble spots. Input to the script below was Lagarith YV12 output from the previous script:

The audio portion previously saved as "aud" is remuxed at the end because ReplaceFramesSimple interrupts audio each time it's used. Additional filters are used in VirtualDub's output, including ColorCamcorderDenoise, gradation curves, and a mild NeatVideo 3.0. The settings and the NeatVideo .dnp and .nfp configuration files are attached as "GB07_Liv7C1_ivtc_Q_vd_MVCnv.zip".

A sample of how the "patches" work:
[code]
b0=a11
b01=a11.ReplaceFramesMC(436,3).Crop(142,66,-490,-404)
b02=Overlay(b0,b01,x=142,y=56)
a12=ReplaceFramesSimple(a11,b02,mappings="436 437 438")
/code]

Line #1 saves the previously repaired "a11" clip as "b0", to be used later in line 4.

Line #2 creates a frame with some motion distortion but the undistorted portion is in a small square patch with frame coordinates x=142 y=56 on the upper left corner of the clean area. The size and location of the patch was found by copying the "bad" frame into Photoshop (you could also use MSPaint) and moving the cursor around the 4 corners of the area that contains the "bad" glitch. The new frames are cropped to include only the square patch area in each frame, and the clip created is saved as "b01".

Line #3 Overlays all of the newly created patches from b01 onto the original b0, thus covering up the bad spots at x=142. This new overlaid clip is saved as "b02". What b02 contains is actually hundreds of copies of the same small patch at x=142. That's not what we want. All we want are 3 frames with cleaned patches.

Line #4 replaces frames 436 thru 438 in the previous "a11" with the same cleaned frame numbers from b02. The new clip is saved as "a12".

Does this stuff take patience and a long time? Yes. Did I have many tapes that were as godawful as this? Not many. In the meantime this 1954 movie has been released on DVD, so why not just ditch the tape? Well, as some of you might know, ugly things can have strong sentimental value. Besides, when you're working with pristine VHS tapes that need very little work, you don't learn anything about processing. It also helps to be a little nutty.

Wow! (maybe I should trademark wow since I'm using it so much)

Another excellent demonstration of what can be done with AviSynth and VirtualDub.

Thank you for taking the time to find the old information, posting it and explaining it.

Steve

Thank goodness every capture doesn't need that much work!