[dREV]

Originally Posted by hello_hello

Lsmash taking an hour or two to index seems completely mental, unless it's indexing a large number of files first before MeGUI encodes.

That was on the one included in MeGUI and it's from 2017. It takes that long because I use trim to look for banding scenes per episode could be a lot. I've had files where I had to encode over 75 times to get all the banding scenes maybe cuz I'm being too much of a perfectionist.

Originally Posted by hello_hello

If I add maa2() to a script in MeGUI's Script Creator and preview it, when I close the Script Creator MeGUI invariably complains about an error and wants to close. MeGUI doesn't use Avisynth+ 3.4 as it's portable Avisynth yet and I haven't tested 3.4 as I still have Avisynth 2.6 installed, but it happens when using Avisynth 2.6 too. If I comment out maa2() before loading a script to add it to the job queue (as from memory, the same thing happens) then uncomment maa2() before running the encoding job, it's usually fine from there. I'm not using MeGUI's OneClick encoder. I'm running XP.

Maybe there's some weird problem with maa2() that only effects MeGUI, but I have no idea what could cause it. Have you tried opening a script containing maa2() with another program such as MPC-HC to see if there's still an access violation, assuming you have Avisynth installed? You can tell MeGUI to use the installed Avisynth to see if anything changes. I'm pretty sure for me, opening the script with a different program is not a problem, but don't quote me on that because I haven't used maa2() for a while and my memory is terrible.

What I did was take the AviSynth+ dll from either the System32 folder or the SysWOW64 folder (dunno which one) and put it in the MeGUI root folder and in the MeGUI/Tools/avs folder to replace the old one. Open MeGUI go to the log tab under Versions it should say this:

--[Information] [12/16/2019 4:46:35 PM] AviSynth+: 3.4 (20-10-2019) (inactive)
--[Information] [12/16/2019 4:46:35 PM] AviSynth+ portable: 3.4 (20-10-2019) (active)

There might be more AviSynth dll's in MeGUI in other folders so may wanna use the search function to find em.

No, I haven't opened it in MPC-HC cuz I dunno how you guys do that. I've seen YouTube videos do that but no steps exactly what they did to get it to be viewed on MPC-HC. I'm using k-lite too codec pack. Would like to know how to do it on AVSPmod as well.

Originally Posted by FranceBB

Well, you were filtering with 16bit precision, however maa2 works in 8bit planar only. The thing is that there's a "trick" to avoid losing 16bit precision when using an 8bit filter. Instead of either truncating or dithering down to 8bit, use maa2 and then bring it back to 16bit, we can do the following:

s16 = last

With this command we're basically gonna tell Avisynth to store into our variable "s16" our 16bit stacked output that we've received from f3kdb.

Now we're going to brutally truncate everything to 8bit planar so that maa2 can work, but don't worry, we're NOT gonna use it directly!

DitherPost (mode=-1)

Ok, now that we have a truncated 8bit planar result, we can use maa2 since it only supports this bit depth:

maa2()

Now that we have filtered with maa2, we're gonna bring it back to 16bit stacked.

Dither_convert_8_to_16 ()

Now, here's the tricky part.
If we go on with our filterchain like this we would lose precision 'cause we have brutally truncated our original 16bit stacked to 8bit planar in order to use maa2, so the 16bit stacked we ended up with at the end is "fake" in the sense that it has gone through a loss of precision.
But... remember what I wrote at the very beginning? We stored our original 16bit stacked BEFORE the anti-aliasing in our variable "s16". So now the idea is to tell Avisynth "Hey, take the original 16bit stacked clip, compare it with the anti-aliased 8bit planar one that we brought to the "fake" 16bit stacked and subtract the changes". This way it's as if we applied anti-aliasing with 16bit precision.

Isn't that what I did with my script? It sounds like it.

Also, I worked out the error as I was confused how to implement dither_convert_8_to_16() with Gradfun3 deband filter as I need that. I had no idea that f3kdb(input_depth=8, output_mode=1, output_depth=16) can replace dither_convert_8_to_16() in avspmod and did a test encode and worked out. It's basically the same as above just the removal of the first dither 8 to 16 code.

f3kdb(input_depth=8, output_mode=1, output_depth=16) 

#Debanding - Gradfun3 16bit lsb with mask=0
#misc filter(s) 16 bit lsb - only if needed like smdegrain
s16 = last
DitherPost(mode=-1)

#line darkening (sometimes)
maa2()

dither_convert_8_to_16()
s16.Dither_limit_dif16 ()
ly = GradFun3mod(thr=0.35,yuv444=true, resizer="DebilinearM", lsb_in=true, lsb=true)
lc = nnedi3_resize16(1280*2, 720*2,lsb_in=true,lsb=true,kernel_d="Spline36",kernel_u="Spline36",src_top=0.0,src_left=0.50,nlsb=false)
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)

DitherPost(mode=-1)

ConvertBits(bits=16) #I want this here to get more bitrate but at first I did some tests using what you wrote
ConvertToStacked()

# grain
ConvertFromStacked().ConvertToDoubleWidth()

What do you think now? Is it 16 precision fully even with the HDB 16 code after resize? I wasn't certain if this is what you were telling me a page ago of your first critique of my script. Would it matter if I add dither mode 6 in the DitherPost? Overall I got more bitrate with the above combination then the previous and looking forward to doing some more testings.

Originally Posted by FranceBB

That's exactly what I'm saying: since you're using 32bit Avisynth+ on a 64bit OS, you can allocate 4 GB maximum, however if you use MPPipeline you can allocate 4GB per process so if you split your script in as many processes as the filters you have, you can allocate 4GB per scrip, so if you have like 3 filters you can allocate 12 GB of RAM instead of 4GB.

I'll take a better look at it when I can. Thanks hoping for good things from it.