VHS to x.264 restore produces strange 'moire' on horizontal lines.
 

Hello! :tiphat:

I too got a task to restore 50 or so VHS tapes with precious family memories.:wink2:
They are mostly in fairly bad shape to begin with and capturing them with cheap old VCR and even cheaper easycap device doesn't do them any good either.

However, this is what I have to work with and in last few months I got my workflow process down to this;

1. Capture with AmaRecTV 2.31 with lossless UtVideo (YUV422 BT.601 VCM) codec. (Virtualdub never gave me good enough AV sync, no matter what setting I tried...)
2. Export sound to .wav and remove hiss/hum with Goldwave v6.31. (I use clipboard sample from the beginning or end of the tape)
3. AviSynth Script with help of AvsPmod 2.51 (Trim to separate clips, Crop to remove black borders and dirty tape head part at the bottom, Deinterlace with QTGMC 3.357 script to improve footage and convert to progressive, FadeIn/Out)

4. Encode to x264 encapsulated in mkv format (where I can force viewing aspect ratio with help of MKVToolNix 21.0.0, so VLC shows it correctly) with MeGUI 2828. I use a constant quality set to 24 with medium speed, which yields acceptable size and not much quality loss (at least to my eyes..). (MeGUI Encoder settings; program --output-depth 8 --crf 24 --qpmax 69 --output "output" "input" )

The final result will mostly be played on PC and I plan to delete lossless captures and keep only these mkv files for archival purposes.

The challenge I am facing ATM is 'moire effect' (not sure how to call it, but it reminds me at moire from the old days of CRT monitors =)) If You check source.avi and encode.mkv, You will notice it appearing over the stack of plates (plates.mkv) or skirt of a girl (skirt.mkv). Source AVIs doesn't have it. Plates or dress don't flicker at all.

I tested different QTGMC presets with some other random settings from QTGMC manual and I also tried different x264 encoding presets, but this moire just doesn't go away.

I suspect it is introduced by QTGMC, but I really don't know anymore how to fix this, neither if it is fixable at all? My wife says 'leave it' but after all the time spent on this, learning the ropes, it really annoys me. :unsure:

Any insights what is causing this or how to fix it would be greatly appreciated! :congrats:

Your point is appreciated, but let's face it: you're making the project much more difficult and time consuming than it should be.

AmarecTV will do the job. I'm afraid I have no answer for you with Virtualdub. I've used it to capture with Win98, Win2K, and XP with four graphics cards and and several PC's, and never had a sync problem. I guess if I'd had to fix it I would have a solution, but it's never happened. Some system setups just don't seem to make nice with certain programs. No one has determined why.

Most people would crop off bad borders, but they replace them with clean new ones. Many newcomers think they're improving something by changing the frame size (you'll get black borders on playback anyway, because your monitor will put them there). Unfortunately your playback aspect ratio is wrong, and if encoded for 4:3 the image will be slightly distorted. Your source video VHS plays at 1.3333:1, but the encode plays at a more narrow (squished) 1.25:1, which is the frame aspect ratio of your script's output and is a substandard frame size. Is that what you wanted?

Deinterlacing doesn't improve anything, in fact it destroys some factors, distorts others, and entails a quality loss, the degree depending on the method used. QTGMC is the cleanest method these days. But the problem is due to line twitter and aliasing, to the original camera's shutter design, and to vcr sharpening during playback, not to interlacing. Note also that your script's output frame size isn't mod-8 in all dimensions -- a width of 700 isn't evenly divisible by 8, so you might at least give your players and encoder a decent break with a mod-8 or mod-16 dimension. Most encoders work with 8-pixel blocks. If you ignore the standards, you get odd results.

The bad twitter is inherent in the tape, which was designed for a different technology, and already visible to a lesser extent in the capture. Cheap VCR's don't help. Sadly, digital video and LCD's don't handle motion well, so this kind of moire and stairstepping happens quite often with digital conversion, even with a better VCR. Making the video somewhat less sharp helps, which is what the scripts do that I posted below. The disturbances can't be fixed entirely, but they can be calmed somewhat.

I made extensive notes in the script for the skirt.avi sample, so I'll post that first. Twitter and aliasing aren't the only faults, as there are some bad dropouts and ripples. Red contrast is too wide for the video to handle, so the girl's face and details get wiped out under the red lights. I included code to work with unsafe video levels and other such problems. In the plates.avi sample, fixing mixed color sources and bad clipping during the capture is possible only to a slight degree.

On top of that I'm stuck working with a Dell laptop temporarily. Dell makes the worst laptop screens in the world, so color correction and inspecting for proper nosie reduction is very limited for the time being. Laptops are a disaster checking for noise and color correction is limited. Laptops are disastrous for video work anyway, but this will have to do until some home reconstruction in finished. Meanwhile this Dell doesn't have a/v muxing softare, so the attached samples are m2v encoded with the HCenc encoder and no audio.

The script I used for skirts.avi:
Somewhat less complicated script for plates.avi:
In addition to the two m2v's, I'm attaching the lossless output of the script for the skirt.avi sample, which you can try with your own encoder. The attached skirt_01Ai.avi file is lossless YV12 using the Lagarith lossless codec. VLC can't play YV12 Lagarith well, but Media Player Classic and MPC-BE have their own Lagarith decoder. You should install Lagarith anyway, since your own encoders will need it and it's used everywhere for intermediate working files (huffyuv can't compress YV12). I've included the Lagarith automatic setup .zip file for 32- and 64-bit, or you can consult Lagarith's download site (https://lags.leetcode.net/codec.html).

[EDIT]
Oops! Spotted a script error, one of those infamous typos. In my previous post you'll see this code in the script for the plates.avi sample:

I guess I should have waited for that third cup of coffee before posting. the resize of (768,height) will give you the wrong height. The corrected resize is below:

My bad. :smack:

WOW, @Sanlyn! I could Hug U right now!:beer:
I read many of your quality replies on this forum but still didn't dare to hope I would also get one.
Please allow a few days to comprehend and test/apply everything You wrote and I'll come back with my new findings/results. :wave:

Gosh. Thank you, but with a little experimentation we might get slightly better results. This time I'm posting a 640x480 progressive square-pixel version as 50fps mp4. I still think MPEG2 looks a bit cleaner, but it can't be posted on the internet and can't be encoded as square-pixel. Resizing both width and height for square pixel does have a price in the moire pattern, but it still looks slightly cleaner to me than the earlier version.

The script below is a little different. Note that ReplaceFramesMC works OK to repair some bad dropouts, but the frames it replaces have no audio, so you get choppy audio at the repair points. The "aud" variable in the script below saves the original audio at 50fps after running QTGMC, then restores it near the end of the script. If you save the audio at an earlier point as in the earlier script for interlaced video, the earlier audio runs at the 25fps frame rate.


I'm attaching a copy of the version of RemoveDirtMC that I used. There are several versions, so it's posted as an .avs that you should import explicitly with the import() function.