New very slow FFT denoiser

[anubhavrocker]

This is my first encode using fft3dfilter :) So kindly throw in some suggestions and which one seems good to you (source is a .mpg tv capture).

Script1:
LoadPlugin("F:\Encoding\megui\tools\avisynth_plugin\FFT3DFilter.dll")
Import("H:\Recorded TV\Rips\viru.avs")
crop( 16, 74, -14, -90)
LanczosResize(704,416) # Lanczos (Sharp)
fft3dfilter(sigma=1.5, bt=5, bw=32, bh=32, ow=16, oh=16, sharpen=0.4)
http://i46.tinypic.com/2ebadte.png

Script2:
LoadPlugin("F:\Encoding\megui\tools\avisynth_plugin\FFT3DFilter.dll")
Import("H:\Recorded TV\Rips\viru.avs")
crop( 16, 74, -14, -90)
LanczosResize(704,416) # Lanczos (Sharp)
fft3dfilter(sigma=1.5, bt=5, bw=32, bh=32, ow=16, oh=16, ncpu=2)
http://i47.tinypic.com/sobe5v.png

Is there anything else that must be taken care of in the video ?

[manono]

Is there anything else that must be taken care of in the video ?
The logo. Also, with a 1.69:1 ratio the resolution is a bit strange, but maybe that's how they really broadcast it.

[anubhavrocker]

The logo. Also, with a 1.69:1 ratio the resolution is a bit strange, but maybe that's how they really broadcast it.
All the channels here are actually broadcasted in 4:3 resolution so i cropped all the black borders and maximum logo to keep the main video intact.
I will test more with it and then will update here.
I am new to this encoding and i am very much open to suggestions for making my encodes better :)

Thanks

[StainlessS]

Issued July 14 2009 FFTW library v3.2.2 stable

http://www.fftw.org/download.html

Earlier post mentioned 3.2.1 as latest.

[drob]

With those FFTW new build v3.2.2 files, there are many files inside the archive, which ones do i ned? and what exactly to do with them? none of them are named as the older fftw3.dll.
Using one of the dll files and renaming them to fftw3.dll, i get an access violation (using via StaxRip, using the original file gives no problems.

[komisar]

drob, from "32-bit version: fftw-3.2.2.pl1-dll32.zip" you need libfftw3f-3.dll... rename it to fftw3.dll and place to %PATH%...

[drob]

@komisar thank you, works perfectly now.

[netrex]

I've used this before with great success, but now I can't get it working.

I have the fftw3.dll in my system32 folder and I got FFT3DFilter.dll in the Avisynth plugins folder. But when I load my .avs file in VD, it get the message that the fftw3dll could not be loaded.

Avisynth open failure:
FFT3DFilter: Can not load FFTW3.DLL !
(A:\Video\IMGP8058.avs, line 3)

This is the script I'm using, it's the first I've tried now just to see if it worked:DirectShowSource("A:\Video\IMGP8058.avi")
ConvertToYV12
fft3dfilter(sigma=1.5, bt=5, bw=32, bh=32, ow=16, oh=16, sharpen=0.4)

I'm running Windows 7 64 bit. Not sure if it matters that I run 64 bit.

Edit: Just to add some more info.

I used the fftw3.dll from this file fftw3win32mingw.zip, that didn't work, then I tried the three .dll files from the file fftw-3.2.2-dll64.zip one at a time renaming them to fftw3.dll, and that didn't work either.

[komisar]

netrex, you need to place 32-bit fftw3.dll in %SystemRoot%\SysWOW64 path on 64-bit windows...
64-bit fftw3.dll place in %SystemRoot%\System32 (for 64-bit avisynth and 64-bit FFT3DFilter.dll)

[netrex]

netrex, you need to place 32-bit fftw3.dll in %SystemRoot%\SysWOW64 path on 64-bit windows...
64-bit fftw3.dll place in %SystemRoot%\System32 (for 64-bit avisynth and 64-bit FFT3DFilter.dll)

Thank you for the quick reply.

I put the fftw3.dll from fftw3win32mingw in the folder SysWOW64 and now it works.

Is there a big benefit to go with the 64 bit software instead, since I'm already running a 64 bit OS?

[komisar]

netrex, benefit with big memory use and some speedup, but 64-bit avisynth still not so stable :(

[netrex]

komisar, ok, I see. I'll just stick to the version I'm using now then. Thanks for the help!

[redfordxx]

Hi, after long time I came back to video processing. I did successfully use fft3dfilter some before but now I seem to have problem.

I changed computer and now I have Win7 64bit.
I am using MeGui64, x264_64 and Avisynth64.

So I downloaded
FFT3DFilter 3 12 2010.rar from http://www.mediafire.com/?2ymcyfuzzzw
ftp://ftp.fftw.org/pub/fftw/fftw-3.3-dll64.zip

When I loaded my script to MeGui preview, I received this "Can not load FFTW3.DLL" message.

I have renamed libfftw3d-3.dll to fftw3.dll, put it into System32 and SysWOW64 and it still doesnot work. Any ideas? Thanks.

[redfordxx]

Ayayay....shoudn't rename it...
now it works

[DarkT]

What is the benefit of using the newer libfftw3f-3.dll over the older one?

[LigH]

Just a guess: That it works in 64-bit mode at all?

[DarkT]

I have windows 7 64 bits. I am using avisynth 2.6 in MT mode. not 64 bits 2.5.8 ver. in MT mode I gained 300% speed. so, I'll keep using the MT rather than 64bits...

[mastrboy]

Good read related to FFT: http://web.mit.edu/newsoffice/2012/faster-fourier-transforms-0118.html

[dadix]

I like this script but:
1) i want only temporal filter not spatial . bt=0 canceled spatial fileter or not ?
2) please tell one example of this script to use with option "noise pattern". How to do that ?

[AzraelNewtype]

I like this script but:
1) i want only temporal filter not spatial . bt=0 canceled spatial fileter or not ?


bt=0 makes the filter purely spatial, the exact opposite of what you're asking for. I'm fairly certain you can't make it purely temporal, but I could be wrong. There are certainly any number of temporal smoothers if you absolutely do not want spatial smoothing.

[librarian]

This sample script should give a (approximately) Wiener only temporal filter:

avisource("")
clp=last
fq=fft3dfilter(sigma=6,bt=1,plane=0)#Use current frame data only
ft= fft3dfilter(sigma=6,bt=5,plane=0)#bt= 2...5
difffq=mt_makediff(clp,fq,y=3,u=2,v=2)#only luma is filtered then u=v=2
tmp=mt_adddiff(ft,difffq,y=3,u=2,v=2)#but this remove the filtering on current frame too

return tmp

bt=0 is the "Temporal Kalman filter for spectrum data" (see the doc).

[dadix]

thank you

@Fizick
for noise pattern can be implemented to have a option to add a frequency range and multiple areas of frequency range?

[Jenyok]

There are some questions to you.
.
There is a function RemoveGrain(mode=17) .
.
Could I use function FFT3dFilter(...) instead of function RemoveGrain(mode=17) to achive equal result of function RemoveGrain(mode=17) (result FF3dFilter(...) = result RemoveGrain(mode=17)) ?
Which parameters and values of those parameters could I use in function FFT3dFilter(...) to achive this result ?
.
.
There are another similar questions.
.
There is a function RemoveGrain(mode=1) .
There is a function RemoveGrain(mode=2) .
There is a function RemoveGrain(mode=3) .
There is a function RemoveGrain(mode=5) .
.
result FF3dFilter( ??? ) = result RemoveGrain(mode=1) ?
Parameters and values of those parameters to function FFT3dFiler() in this case ?
.
result FF3dFilter( ??? ) = result RemoveGrain(mode=2) ?
Parameters and values of those parameters to function FFT3dFiler() in this case ?
.
result FF3dFilter( ??? ) = result RemoveGrain(mode=3) ?
Parameters and values of those parameters to function FFT3dFiler() in this case ?
.
result FF3dFilter( ??? ) = result RemoveGrain(mode=5) ?
Parameters and values of those parameters to function FFT3dFiler() in this case ?
.
FFT3dFilter( ??? ) similar to and another "mode=" of RemoveGrain() function ?
mode=7
mode=9
mode=11
mode=19
.
Thanks.
.

[Jenyok]

And there is a silence. ??? !!! :readguid:
.
Didee, Gavino, Fizick
.
Where are you, mates ?
.

[aerDNA]

Sorry for necrobumping like this but plugin documentation points to this thread and I wanted to share some insight that might be helpful to new users (if there are any) in setting it up.
This is an excellent denoiser and my no. 1 choice for a long time now. It used to be painfully slow if you wanted to squeeze the most out of it but on today's powerful CPUs it performs ok. I mainly wanted to comment on default/recommended values vs what I use.

- Documentation suggests sigma=1.5-2.5 for digital sources and 3 or more for analog. If detail retention is a priority, my recommendation is not to go above 2, unless you're encoding at low bitrate in which case fine detail is gone anyhow and stronger denoising will help compressibility. I normally use 1.5; it removes a substantial amount of noise without compromising on quality.

- Chroma planes tolerate much stronger denoising than luma so it's a good idea to process them separately. sigma=1.5, plane=0 (luma) + sigma=3, plane=3 (chroma) will be visually indistinguishable from sigma=1.5, plane=4 (all) but it will compress better. If you're afraid it doubles the time required because you need to apply FFT3DFilter twice, don't worry, it takes the same.

- Suggested optimal block size/overlap is bw,bh=32, ow,oh=16. This was written years ago with tolerable speed in mind, I presume. With a modern CPU, use bw,bh=16, ow,oh=8. It produces superior results.

- For 3D Wiener, bt=5 is suggested as best. This is actually the main thing that made me write this post, because I've always been using bt=5 and only today did I do some proper experimenting with this value. After quite a bit of testing, one thing I can objectively say is that bt=5, compared to default bt=3, consistently produces frames that are slightly less compressible. This means it washes out less data, but what is the nature of it in terms of noise/detail? Visual inspection of frames revealed no difference in most cases, and where there was a visible difference, quality seemed to be on the side of bt=3, surprisingly. So my conlusion is that bt=5 actually has slightly worse noise/detail removal ratio. Even if I'm wrong on this, perceptible difference really is insignificant, and considering that bt=5 comes with a pretty massive speed penalty, I say stick with the default.

- On multicore, be sure to set the ncpu= param, you'll get a decent speed boost.

tl;dr - my "best" settings:
FFT3DFilter(sigma=1.5, plane=0, bw=16, bh=16, ow=8, oh=8, ncpu=x)
FFT3DFilter(sigma=3, plane=3, bw=16, bh=16, ow=8, oh=8, ncpu=x)

Finally, use the ICL build (https://www.dropbox.com/sh/6kb3723po5oqd4b/AADbP8gIJ3YrHVoLU3joqJDma?dl=0) by Groucho2004 - it's faster and there's also a 64-bit build for AviSynth+. To use both versions on Win64 (I use 32-bit for scripting/preview in VirtualDub and 64-bit for final encoding) you also need both libfftw3f-3.dll versions from fftw.org. Renamed to fftw3.dll, 64-bit dll goes to Windows\System32 and 32-bit dll goes to Windows\SysWOW64.

[manono]

Thank you very much for the tips. I use the filter a lot and always at the 'best settings', usually with Sigma set for 1.5 or 2.0. I'll try out your suggestions the next time I use it.

[Groucho2004]

To use both versions on Win64 (I use 32-bit for scripting/preview in VirtualDub and 64-bit for final encoding) you also need both libfftw3f-3.dll versions from fftw.org. Renamed to fftw3.dll, 64-bit dll goes to Windows\System32 and 32-bit dll goes to Windows\SysWOW64.
Just a little remark - With the ICL builds I made renaming the fftw DLLs is not necessary, they accept either libfftw3f-3.dll or fftw3.dll.

[feisty2]

Sorry for necrobumping like this but plugin documentation points to this thread and I wanted to share some insight that might be helpful to new users (if there are any) in setting it up.
This is an excellent denoiser and my no. 1 choice for a long time now. It used to be painfully slow if you wanted to squeeze the most out of it but on today's powerful CPUs it performs ok. I mainly wanted to comment on default/recommended values vs what I use.

- Documentation suggests sigma=1.5-2.5 for digital sources and 3 or more for analog. If detail retention is a priority, my recommendation is not to go above 2, unless you're encoding at low bitrate in which case fine detail is gone anyhow and stronger denoising will help compressibility. I normally use 1.5; it removes a substantial amount of noise without compromising on quality.

- Chroma planes tolerate much stronger denoising than luma so it's a good idea to process them separately. sigma=1.5, plane=0 (luma) + sigma=3, plane=3 (chroma) will be visually indistinguishable from sigma=1.5, plane=4 (all) but it will compress better. If you're afraid it doubles the time required because you need to apply FFT3DFilter twice, don't worry, it takes the same.

- Suggested optimal block size/overlap is bw,bh=32, ow,oh=16. This was written years ago with tolerable speed in mind, I presume. With a modern CPU, use bw,bh=16, ow,oh=8. It produces superior results.

- For 3D Wiener, bt=5 is suggested as best. This is actually the main thing that made me write this post, because I've always been using bt=5 and only today did I do some proper experimenting with this value. After quite a bit of testing, one thing I can objectively say is that bt=5, compared to default bt=3, consistently produces frames that are slightly less compressible. This means it washes out less data, but what is the nature of it in terms of noise/detail? Visual inspection of frames revealed no difference in most cases, and where there was a visible difference, quality seemed to be on the side of bt=3, surprisingly. So my conlusion is that bt=5 actually has slightly worse noise/detail removal ratio. Even if I'm wrong on this, perceptible difference really is insignificant, and considering that bt=5 comes with a pretty massive speed penalty, I say stick with the default.

- On multicore, be sure to set the ncpu= param, you'll get a decent speed boost.

tl;dr - my "best" settings:
FFT3DFilter(sigma=1.5, plane=0, bw=16, bh=16, ow=8, oh=8, ncpu=x)
FFT3DFilter(sigma=3, plane=3, bw=16, bh=16, ow=8, oh=8, ncpu=x)

Finally, use the ICL build (https://www.dropbox.com/sh/6kb3723po5oqd4b/AADbP8gIJ3YrHVoLU3joqJDma?dl=0) by Groucho2004 - it's faster and there's also a 64-bit build for AviSynth+. To use both versions on Win64 (I use 32-bit for scripting/preview in VirtualDub and 64-bit for final encoding) you also need both libfftw3f-3.dll versions from fftw.org. Renamed to fftw3.dll, 64-bit dll goes to Windows\System32 and 32-bit dll goes to Windows\SysWOW64.

If you do care about quality, fft3d is really just a pretty bad choice, it's 2017 now and there are denoising algorithms out there MUCH more advanced than simple dumb frequency domain filtering (and also DFTTest is better quality wise in this category).

Some better options:
Motion Compensation (MDeGrain)
NLMeans (KNLMeansCL, TNLMeans)
BM3D (available in vaporsynth)

[aerDNA]

DFTTest is marginally better but much slower. TNLMeans is better but much, much, much slower. When you enable temporal (it's not nearly as good without it) it goes from unacceptably slow to 48hrs./encode slow. KNLMeansCL should be faster but I'm without a discrete GPU at the moment and apparently it lacks temporal mode. I wanted to give MDeGrain a go but it seems I'd have to do some digging through forum just to piece together the right plugin and dependencies that have different versions and mods of their own. I also don't feel like getting into VaporSynth because there's nothing I really need but don't get from AviSynth(+), which I'm accustomed to, so no BM3D for me. I will test KNLMeansCL and if turns out to be a spectacular performance improvement over TNLMeans while offering same quality, I'll gladly go with that. Right now I don't see anything offering me the kind of quality vs speed balance that FFT3D does.

[feisty2]

and apparently it lacks temporal mode.
Apparently the wrong fact.
KNLMeansCL is a 3D NLMeans filter, the "d" parameter is the temporal radius for NLMeans.

[manono]

This is the FFT3DFilter thread, feisty2. You can promote your favorite filters somewhere else. Please.

[johnmeyer]

Yeah, the FFT3DFilter bashing seems to be totally out of place, not only because this is the main support thread for the plugin, but also because there are still situations where it is quite useful (e.g., as a pre-filter to create an estimation clip).

As for this quote:

I wanted to give MDeGrain a go but it seems I'd have to do some digging through forum just to piece together the right plugin and dependencies that have different versions and mods of their own.

pretty much anything you do in AVISynth is going to require that you have a few plugins in addition to the main one. In this case you need MVTools2, along with whatever else it requires. I'll agree that there are a LOT of mods and branches to the MVTools2 development, but I have a package that works well for me, and if you want I would be happy to zip the various things together, along with a couple of denoising sample scripts. My samples are not too much different than the cookbook examples in the MVTools2 documentation, but I have done a few tweaks for speed and also for better performance for the SD (VHS/Beta/8mm) video that I often am asked to restore.

[GMJCZP]

FFT3dfilter is good too for in some cases for repair edges in conjuction with Camembert or TCannyMod.

[aerDNA]

@johnmeyer Thanks, if you have a convenient MDeGrain setup package I'll try it out, but to be honest you probably shouldn't bother because somehow I think I'll be sticking with FFT3DFilter for the time being.
I feel I should explain my rationale and why I'm satisfied with FFT3DFilter. If I denoise, I do so to help compressibility and my usual goal is not to remove all noise but only up to the point where perceptible quality trade-off begins (and by quality I specifically mean detail retention). With FFT3DFilter that point is around sigma=1.5 for my eyes. At near-zero impact on quality, good amount of noise is removed and relatively fast. A more advanced filter will remove more noise but at the cost of speed. On the clip I tested on, FFT3DFilter with params stated above is ~4x faster than DFTTest default and ~15x faster than TNLMeans default. Whatever noise I'm left with I'll just pay for in bitrate, so FFT3DFilter will save me some less bitrate than a more efficient filter would, but it still saved a lot and for a much smaller speed penalty. As feisty2 pointed out, it's 2017. I don't have to target 700MB. Storage/bandwidth is not a problem and I'll gladly have a little bigger output if it means reasonable encoding times.

[StainlessS]

I have been a big fan of (Spatial) VagueDenoiser, and (S/T) FFT3DFilter for some long time.
FFT3D, usually Sigma between about 1.5 and 1.75 (occasionally a little higher), for what it does, is really pretty fast compared to others.

I also like MCDegrainSharp(frames=1), and sometimes use it before a weak FFT3dFilter (sigma= ~ 1.5), usually if some other processing between
the degraining and output.

MCDegrainSharp requires only mvtools2 so not too difficult to set up:- http://forum.doom9.org/showthread.php?p=1508638#post1508638

EDIT: Also see plain MCDegrain() a few posts before above linked.

[feisty2]

@johnmeyer Thanks, if you have a convenient MDeGrain setup package I'll try it out, but to be honest you probably shouldn't bother because somehow I think I'll be sticking with FFT3DFilter for the time being.
I feel I should explain my rationale and why I'm satisfied with FFT3DFilter. If I denoise, I do so to help compressibility and my usual goal is not to remove all noise but only up to the point where perceptible quality trade-off begins (and by quality I specifically mean detail retention). With FFT3DFilter that point is around sigma=1.5 for my eyes. At near-zero impact on quality, good amount of noise is removed and relatively fast. A more advanced filter will remove more noise but at the cost of speed. On the clip I tested on, FFT3DFilter with params stated above is ~4x faster than DFTTest default and ~15x faster than TNLMeans default. Whatever noise I'm left with I'll just pay for in bitrate, so FFT3DFilter will save me some less bitrate than a more efficient filter would, but it still saved a lot and for a much smaller speed penalty. As feisty2 pointed out, it's 2017. I don't have to target 700MB. Storage/bandwidth is not a problem and I'll gladly have a little bigger output if it means reasonable encoding times.

the quality of a denoising algorithm is typically defined as "how good the result looks still after complete removal of the noise" and fft3d is real lame by that definition, I thought you were talking about that definition of quality earlier, anyways, not the point.

I never used fft3d cuz this kind of filters are generally extremely toxic to high frequency components which leads to edge distortion and ringing and crap like that.

with DFTTest you can simply avoid filtering on high frequency components with the "sstring" parameter, not sure if such policy exists in fft3d, if it does not, you can always do it manually.

src = last
fft = fft3dfilter(xxx)
hif = mt_makediff(src, src.removegrain(11).removegrain(11))
fft.removegrain(11).removegrain(11).mt_adddiff(hif)


but also because there are still situations where it is quite useful (e.g., as a pre-filter to create an estimation clip).

apparently he was using it as a main denoiser.

[aerDNA]

MCDegrainSharp requires only mvtools2 so not too difficult to set up:- http://forum.doom9.org/showthread.php?p=1508638#post1508638
EDIT: Also see plain MCDegrain() a few posts before above linked.
I'll try it, thanks.

the quality of a denoising algorithm is typically defined as "how good the result looks still after complete removal of the noise." and fft3d is real lame by that definition, I thought you were talking about that definition of quality earlier, anyways, not the point.
That's filter quality, I was talking about resulting image quality with regard to detail. I figured there was a misunderstanding - my fault.

I never used fft3d cuz this kind of filters are generally extremely toxic to high frequency components which leads to edge distortion and ringing and crap like that.
with DFTTest you can simply avoid filtering on high frequency components with the "sstring" parameter, not sure if such policy exists in fft3d
It does, there's sigma, sigma2, sigma3, sigma4.
I may not understand the math behind filters but I'm the world's leading expert in determining what looks good to me. I spent a lot of time switching betwen different filter outputs and staring at frames like a twonk. If your opinion is based on math and/or calendar instead of actual experience with the filter, you really should refrain from telling people it's a bad choice. It's a good denoiser that sits in quality vs performance sweet spot. NLMeans takes a lot more processing for moderate gains and whatever comes next will be even worse, because we're deep in the zone of diminishing returns here.

[feisty2]

If your opinion is based on math and/or calendar instead of actual experience with the filter, you really should refrain from telling people it's a bad choice.

don't wanna hijack this thread so please continue here (http://forum.doom9.org/showthread.php?p=1794305#post1794305)


but I'm the world's leading expert in determining what looks good to me. I spent a lot of time switching betwen different filter outputs and staring at frames like a twonk.

and I couldn't agree with you on this, I'm also a quality freak, and 10 times slower is okay to me longs as there's 1% of quality improvement.

[aerDNA]

Nah, I'm done here, said what I wanted and plenty more. And frankly I don't like your cocky fanboyish style. Engaging in further discussion wouldn't bring me any kind of satisfaction.

[martin53]

Just made a new thread for an update of the plugin (http://forum.doom9.org/showthread.php?p=1797567#post1797567), so it doesn't get buried in this long thread :)

[orion44]

Sorry for necrobumping like this but plugin documentation points to this thread and I wanted to share some insight that might be helpful to new users (if there are any) in setting it up.
This is an excellent denoiser and my no. 1 choice for a long time now. It used to be painfully slow if you wanted to squeeze the most out of it but on today's powerful CPUs it performs ok. I mainly wanted to comment on default/recommended values vs what I use.

- Documentation suggests sigma=1.5-2.5 for digital sources and 3 or more for analog. If detail retention is a priority, my recommendation is not to go above 2, unless you're encoding at low bitrate in which case fine detail is gone anyhow and stronger denoising will help compressibility. I normally use 1.5; it removes a substantial amount of noise without compromising on quality.

- Chroma planes tolerate much stronger denoising than luma so it's a good idea to process them separately. sigma=1.5, plane=0 (luma) + sigma=3, plane=3 (chroma) will be visually indistinguishable from sigma=1.5, plane=4 (all) but it will compress better. If you're afraid it doubles the time required because you need to apply FFT3DFilter twice, don't worry, it takes the same.

- Suggested optimal block size/overlap is bw,bh=32, ow,oh=16. This was written years ago with tolerable speed in mind, I presume. With a modern CPU, use bw,bh=16, ow,oh=8. It produces superior results.

- For 3D Wiener, bt=5 is suggested as best. This is actually the main thing that made me write this post, because I've always been using bt=5 and only today did I do some proper experimenting with this value. After quite a bit of testing, one thing I can objectively say is that bt=5, compared to default bt=3, consistently produces frames that are slightly less compressible. This means it washes out less data, but what is the nature of it in terms of noise/detail? Visual inspection of frames revealed no difference in most cases, and where there was a visible difference, quality seemed to be on the side of bt=3, surprisingly. So my conlusion is that bt=5 actually has slightly worse noise/detail removal ratio. Even if I'm wrong on this, perceptible difference really is insignificant, and considering that bt=5 comes with a pretty massive speed penalty, I say stick with the default.

- On multicore, be sure to set the ncpu= param, you'll get a decent speed boost.

tl;dr - my "best" settings:
FFT3DFilter(sigma=1.5, plane=0, bw=16, bh=16, ow=8, oh=8, ncpu=x)
FFT3DFilter(sigma=3, plane=3, bw=16, bh=16, ow=8, oh=8, ncpu=x)

Finally, use the ICL build (https://www.dropbox.com/sh/6kb3723po5oqd4b/AADbP8gIJ3YrHVoLU3joqJDma?dl=0) by Groucho2004 - it's faster and there's also a 64-bit build for AviSynth+. To use both versions on Win64 (I use 32-bit for scripting/preview in VirtualDub and 64-bit for final encoding) you also need both libfftw3f-3.dll versions from fftw.org. Renamed to fftw3.dll, 64-bit dll goes to Windows\System32 and 32-bit dll goes to Windows\SysWOW64.

Wow.

This has been really helpful. Thanks for writing this.