FrameRateConverter (Official)

[hello_hello]

This doesn't relate to my animation problem as such, but while playing around with various settings I had a couple of thoughts....

MaskThr=0 disables artefact masking according to the help file, but the script is very insistent on SkipThr being lower than MaskThr, yet the range for each is stated as being 0-255. It turns out setting SkipThr to -1 bypasses the error (hopefully that's all it does), but I wondered if it might be an idea to limit settings when it's required? For example if you set MaskThr=100, the script would ensure SkipThr doesn't exceed 99, even if you specify something larger.

IMHO it would be awesomely awesome if the debug info included the current frame number, for those times when you have two instances of a script open with slightly different settings (I do that quite a bit using multiple instances of MPC-HC). And also because the debug info and Info() both want to display in the upper left hand corner....

Cheers.

[hello_hello]

MysteryX,
I've played around some more, but so far I don't think I've come up with anything that does a better job than your new animation tuning, so I think I'll just go with that for the moment.

Thanks.

PS. You've probably had a good look at the inner workings of Interframe. If so, do you know what the difference between the default tuning and the animation tuning might be? I ask, because the default tuning does a reasonable job on my animation sample (not as good as FrameRateConverter though, aside from the fade-out problem), whereas the animation tuning is just horrible. Stuff wobbles around all over the place near any object that's moving. I can't imagine when it'd be an improvement over the default tuning, or when you'd want to use it.

Thanks again.

[MysteryX]

Yes, it's shader.dll. Somehow it's not loading. Are you using Windows XP? AvisynthShader requires Windows Vista or above.

BlkSize=6 is valid; but MRecalculate with BlkSize=3 isn't. That's the problem. You can only use BlkSize with Preset="faster" where MRecalculate is disabled.

Why would you set SkipTrh to 0? If you want to disable scene change detection, set SkipOver=0

To get or set current frame number, in MPC-HC or VirtualDub, press CTRL+G. I often find it easier to compare in VirtualDub.

From my test the new animation settings work pretty well, only exception being the woman "warping out" after the planet moves to the right. If I end up implementing a "dynamic blending threshold", it might help with cases like that with still backgrounds and high-artifacts motions.

As for Interframe's Anime tuning, AFAIK, it mostly tunes the settings way down. I don't know the details.

[hello_hello]

Yes, I'm using XP.

I wasn't wanting to set SkpThr to zero as such, but I wanted to try disabling MaskThr by setting it to zero and if you do that, this line kicks in, effectively preventing you from setting MaskThr=0.

Assert(SkipThr < MaskThr, "FrameRateConverter: SkipThr must be lower (stronger) than MaskThr")

Plus it seemed to me it might be better for the script to automatically reduce SkpThr if required according to the MaskThr value, but either way, if you set MaskThr=0, the specified SkipThr range of 0 to 255 will always result in an error.

There's a similar relationship between SkipOver & BlendOver (from memory) I thought could maybe be handled in a similar manner rather than result in an error. Plus the error states SkipOver must be greater than BlendOver, but it doesn't tell you what BlendOver is. ;)

Ctrl+G isn't quite the same thing as having the frame number constantly displayed. The latter just makes it a little easier to compare two videos when stepping through frames. I created a little function called FrameNum() a long time ago and it's easy enough to stick it at the end of the script, but I thought adding the frame number to debug mode might be a nice touch.

The main reason I prefer to use MPC-HC for previewing/comparing scripts is it has a fullscreen mode, and from memory there's no way to prevent VirtualDub from locking scripts when it opens them. If you disable MPC-HC's internal AVS source filter it doesn't lock them. I'm quite used to a script displaying in MPC-HC while I edited it with Notepad and save the edited version, then use CTRL+E to re-load it.
There's probably advantages to VirtualDub I'm unaware of as I've not used it much.

I think I know what you mean about the woman "warping out", or something similar. For frame 241 the slowest preset doesn't distort the planet at all, but the guy "warbles in", whereas the slow preset seems to blend the planet movement, but the guy "appears" nice and cleanly. Some sort of dynamic handling might be nice for that sort of thing, but I don't know how hard it'd be to implement. Mind you it's only a single frame so it passes quite quickly and isn't the end of the world.

I guess this frame interpolation stuff isn't easy. :)

Preset="slow", BlendOver=40, SkipOver=140
https://image.ibb.co/bu3Roa/slow.jpg

Preset="slowest", BlendOver=40, SkipOver=140
https://image.ibb.co/dEi3ZF/slowest.jpg

[MysteryX]

For "anime", use preset=slow (DCT=4) because DCT=0 generally gives crap. Slowest only inserts some of that crap back in. If you want to see the output without artifact masking, use Output="flow"

[hello_hello]

If you want to see the output without artifact masking, use Output="flow"

No problem.

Although I still think it'd be an idea to change this in the script, given it's impossible to set MaskThr to 0 without it resulting in an error (or unless you also set SkipThr to -1)

@ MaskThr - The threshold where a block is considered bad, between 0 and 255. Smaller = stronger. 0 to disable artifact masking. (Default = 120)

Thanks.

[pinterf]

BlkSize=6 is valid; but MRecalculate with BlkSize=3 isn't. That's the problem.
It can be valid if the source is 4:4:4 (YV24). BlkSize=3 for YV12 format means that chroma block size is 1 (3/2) which is not supported.

[urukazuto]

Hello I'm trying to encode 720p anime by using megui with this setting:
x264 = CRF 23, Very Slow Preset at 8 bit.
Avisyth :

SetMemoryMax(512)
SetMTMode(3,4)
PluginPath = "D:\Program Files (x86)\MeGUI_2715\tools\avisynth_plugin\"
LoadPlugin(PluginPath+"FrameRateConverter.dll")
LoadPlugin(PluginPath+"mvtools2.dll")
LoadPlugin(PluginPath+"masktools2.dll")
LoadPlugin(PluginPath+"GRunT.dll")
Import(PluginPath+"FrameRateConverter.avsi")
<input>
SetMTMode(2)
<deinterlace>
<crop>
<denoise>
<resize>
FrameRateConverter(NewNum=60, NewDen=1, Preset="Anime")


And When I trying to encode, the speed encode is only 1 fps... is this normal?

is there a way to increase speed without changing the preset / setting on framerateconverter?

Edit:
I'm kind of new to this things, i will try to tweak setting a bit.

My Specs:
Intel Core i5-4690 3.5Ghz
MSI Geforce GTX 960 2048MB DDR5 - Gaming 100ME - Limited Edition
8GB DDR3 RAM
Windows 10 Pro 64 Bit (Build 14393)

and yes the Avisynth i'm using is x86 one... version 2.6.0 from Official Builds : https://sourceforge.net/projects/avisynth2/
and after that using the MT one from here : https://forum.doom9.org/showthread.php?t=148782

For filters i dunno which version I'm using....

[burfadel]

Whether it is 'normal' depends on the other filters used that you haven't listed, in addition to the versions of the filters and Avisynth, and in particular, your system specs. I see you are using x86 Avisynth, that isn't 'ideal' for performance. Also is there any reason specifying SetMemoryMax? Is your system short on memory?

[MysteryX]

I also use x86, AFAIK it doesn't make much of a difference.

However, for Anime you're using DCT=4, which isn't working well with MT. Not only are you getting slow performance, but it will crash as well at some point. Currently all presets from Normal to Slowest use some DCT=4 or DCT=1 (it remains to be tested whether MRecalculate DCT=4 has the same issues as MAnalyze... probably)

So you're limited to single-threaded mode. You can however run several instances at once. On a 8-CPU system, I get best performance by running 4 instances in parallel. However, cutting the video in segments and running these segments in parallel isn't something MeGUI supports :)

[hello_hello]

So you're limited to single-threaded mode. You can however run several instances at once. On a 8-CPU system, I get best performance by running 4 instances in parallel. However, cutting the video in segments and running these segments in parallel isn't something MeGUI supports :)

Not automatically, but it's fairly easy.

I use the AVS Cutter under the tools menu to add cuts to divide the script into sections, then make the appropriate number of copies of the script and edit each to remove all but one Trim() range.

You can add each copy of the script to the queue and run them simultaneously but don't forget to check "stitchable" in the x264 encoder configuration (under the Misc tab) so you won't have any problem appending the encoded segments, which of course you'll have to do yourself with something like MKVToolnixGUI.

[bblogoss]

Is there a way to only skip scene changes or sudden lightning change? I want the smoothest output possible like the output="flow" and only skip the frames that the debug info indicates SKIP.
I have been tweaking the SkipOver argument with no success.
In brief , I want frame interpolation only except for scene changes or when it becomes absolutely awful like a sudden flash lightning between 2 frames.

Thanks for this wonderful script by the way. Results even better than Premiere Pro optical flow which tend to add some blur to the interpolate frame.

[MysteryX]

yeah even SVP gives better results than Premiere Optical Flow.

Set BlendOver=0 to disable frame blending.

[bblogoss]

I have also tried with blendover=0 without succes too

Here is a zoom sample with BlendOver=0 (pretty much the same as default settings)

https://image.ibb.co/dzGcJa/blendover0.jpg

And here it is with output="flow"

https://image.ibb.co/jmieWv/Output_Flow.jpg

[MysteryX]

Oh, you want to disable artifact masking?

Set MaskTrh=0; but I believe someone reported a validation bug with that. Alternatively, setting MaskTrh=255 will also ensure it doesn't trigger.

[bblogoss]

I managed to get something near what I want with

MaskThr=255, SkipThr=0, BlendOver=0, SkipOver=220

Thanks for the help.

[Fabulist]

Can someone explain how to use this tool? Is it a live converter like SVP?

[rsd2015]

Can someone explain how to use this tool? Is it a live converter like SVP?

I defer to the gurus on this board, everything you need to know is in this thread. FRC is meant for encoding video, not playback like SVP. Load the plugin, import the script and specify the frame rate variables you need, e.g. FrameRateConverter (NewNum=60, New Den=1) for 60 FPS.

[Fabulist]

I defer to the gurus on this board, everything you need to know is in this thread. FRC is meant for encoding video, not playback like SVP. Load the plugin, import the script and specify the frame rate variables you need, e.g. FrameRateConverter (NewNum=60, New Den=1) for 60 FPS. I see, thanks, I was hoping it is a playback tool like SVP.

[Magik Mark]

MysteryX,

Can you recommend a good setting for:

1080p HD videos 23.976fps to 29,970fps no or minimum soap opera effect, action movies / drama?

I use staxrip, how do I integrate awarsharp2?

[MGarret]

MysteryX

I would really like to try your filter but I keep running into errors. I've installed everything required, latest MaskTools2, MvTools2 (pinterf) but latest error I'm getting now is:

Avisynth open failure:

mt_inpand: wrong colorspace, only YV12 and I420 allowed
(FrameRateConverter.avsi, line 165)

I checked with Info() and the colorspace is YV12. How can I fix this?
I assume I'm missing some additional updated plugins?

[burfadel]

Latest Avisynth+ r2508 as well?

[manolito]

Does "FrameRateConverter.dll" no longer work under plain vanilla AviSynth 2.6 ?

On my Win7-64 computer FrameRateConverter crashes with the latest DLL version introduced with v.1.1. The changelog had this: - Updated Avisynth headers in DLL
Replacing the DLL with the version from FRC 1.0 (from the first post of this thread) fixed it.


Cheers
manolito

[hello_hello]

manolito,
version 1.2 is playing nice for me and Avisynth 2.6 on XP.
Not that it helps you, but I assume it means it's not an Avisynth related problem.

[Groucho2004]

Does "FrameRateConverter.dll" no longer work under plain vanilla AviSynth 2.6 ?
1.1 and 1.2 work fine for me on AVS 2.6 and XP. Run the script with AVSMeter and see if that produces errors.

[manolito]

Thanks guys, AVSMeter revealed the (stupid and unnecessary) problem:

I mixed the FRC script v1.0 with the DLL v1.2, and this caused the crash. In addition to updating the AviSynth headers MysteryX also decided to change the shortcut for "Threshold" from "trh" to "thr" and hardcoded it into the DLL. The DLL version needs to match the script version, if it doesn't it will crash.

For me this is a prime example of sloppy programming. Nothing in the docs says that the DLL is version specific and requires a certain version of the script. In the future please document such changes and maybe include the version number in the DLL name... :devil:


Cheers
manolito

[burfadel]

The trh to thr was because of a spelling mistake 'treshold' instead of 'threshold'. It's typical of any program that you can't mix files, it doesn't really need to be clarified. Putting versions in file names isn't ideal, many people will then end up having multiple versions of the same file.

[hello_hello]

For me this is a prime example of sloppy programming. Nothing in the docs says that the DLL is version specific and requires a certain version of the script. In the future please document such changes and maybe include the version number in the DLL name...

I guess you missed my post a while back. :)
https://forum.doom9.org/showthread.php?p=1817518#post1817518

I'm a little on the fence about giving dlls version numbers in the name. I usually add them myself before putting them in the Avisynth plugns folder anyway, but if a script calls a plugin specifically such as deblock1.2_deblock(), you can't replace deblock1.2.dll with deblock1.3,dll without breaking the script, although admittedly that's only been an issue for me once that I can think of off the top of my head.

It'd be nice to be able to discover the dll version using the Explorer right click/properties menu though.

[manolito]

Sorry if my post came across being a little harsh, but I still think that the problem I encountered should not have happened.

A plugin DLL has one or more functions, there is an interface how the plugin functions have to be called, and this interface needs to be documented. I think we all agree on this.

The script command which caused the crash was this one:
EMstp = C.StripeMask(blksize=BlkSize, blksizev=BlkSizeV, str=min(SkipThr*2+20, 255), strf=min(SkipThr+10, 255), thr=23)

The variable "thr" in the StripeMask function of the DLL had a different name "trh" in the older DLL version.

But this variable is not exposed in the FrameRateConverter.avsi script which calls this function. Users have no way to read the documentation and edit the variable name other than editing the script itself (at line 212).


My specific situation was that I did not care for the script changes between FRC v1.0 and v1.2, I wanted to stick with my (modified) v1.0 script. Seeing that MysteryX had updated the DLL with newer AviSynth headers I figured that it would be a good idea to update the DLL to the latest version, but obviously this was not a good idea at all... :eek:


Cheers
manolito

[MysteryX]

All changes, including the parameter changes, are very well documented in the change log.

Why would anyone expect 2 files of different versions to work together, and why would anyone do that? Replace any files of your drivers by a version from older versions and you'll get a blue screen of death. Nothing unexpected about that.

[Ben_Nicholls]

Looks promising, honestly kind of surprised... I always felt SVP was quite a way ahead of MVTools.

It might just be that to use any kind of MVTools convetion in real time you have to set use awful quality settings, SVP does seem to be better optimised.

I would point out that (in my opinion) SVP only comes into its own when the artefact masking is set to maximum (and shader complexity is set to 23). I know InterFrame's default settings don't really bring out the best in SVP in many cases. Also v4 is showing big quality improvements over v3 (while the program's GUI isn't free any more the core SVPflow DLLs are still free to use in scripts).

Will do some side by side comparisons shortly.

[Hotte]

I was recently testing FRC in oder to replace Interframe/SVP for editing. I am converting 2K or 4K from 25/29.97 to 50p.

I am looking for the best motion compensation and avoid any object- or frame-blending. The only way to achieve this with FRC was to set output="flow" AND blksize=8. With any larger blocksize, FRC would start to blend moving objects in the frame. Quality="fast" was good enough to replace interframe in most cases. Very good work really!

However, I am wondering why I am getting blending free results only with the smallest blocksize and why output="auto" with various other parameter settings leads to blended rather than "morphed" objects in almost any cases.

Any ideas ?

[manolito]

If you want to avoid any artifact masking by blending, skipping or whatever you might want to try the core jm_fps script from here:
https://forum.doom9.org/showthread.php?p=1800439#post1800439

FRC is based upon this script with additional artifact masking (which is often beneficial, but sometimes it is not...)


Cheers
manolito

[mark0077]

Hi guys, I have been using SVP for many years. I now see this thread, looks great. So whats everyone using it with, avisynth or avisynth+. Which gives better performance? I'll give it a go using whatever is recommended parameters to see if my system can handle it vs SVP (Using Interframes Film / Medium settings).

[MysteryX]

AVS+ is better but either way it should work just fine with default settings. There are various presets. You get better performance with "faster" preset and better quality with "slower" preset.

[Hotte]

Thanks manolito, this is a good basic script with all the functions I need. Quality is good. The only thing I missed was scene change detection. Do I have to go back to FrameRateConverter to get it ?

Also in your script, blksize determines inframe object movement behaviour. Small blksizes like 8 or 12 will morph, higher blksizes will more and more blend the movement. But in any case small movement will be handled differently than big movement. I understood this is a common concept. It´s simple to handle with only one parameter to change for different situations. Not bad, really.

[MysteryX]

Thanks manolito, this is a good basic script with all the functions I need. Quality is good. The only thing I missed was scene change detection. Do I have to go back to FrameRateConverter to get it ?

You can handle scene changes using thSCD2. Setting it to 255 disables scene change detection if I'm not mixing things up.

Flow = MFlowFps(C, super, bak, fwd, num=NewNum, den=NewDen, blend=false, ml=200, mask=2, thSCD2=255)

[mark0077]

So is anyone using this in realtime? Trying to get it running in real time here, not sure if its a runner. I'm trying the fast preset first (Using core i7 6700K at 4.5GHZ, GTX 980). I'm running this script via ffdshow which is how I also use SVP.

For ffdshow settings itself, I have it set to "Add ffdshow video source" disabled. Buffer back/ahead set to 0/15. Again this is what works well for SVP.

Heres my script so far but its definitely not smooth :) I assume it needs tweaking to work in ffdshow and maybe the buffer settings in ffdshow arn't optimal. I havn't seen anyone give a full example of use with ffdshow.

Setmemorymax(1024)
SetMTMode(5,16)
LoadPlugin("C:\Program Files (x86)\SVP\FRC\FrameRateConverter.dll")
LoadPlugin("C:\Program Files (x86)\SVP\FRC\mvtools2.dll")
LoadPlugin("C:\Program Files (x86)\SVP\FRC\masktools2.dll")
#LoadPlugin("C:\Program Files (x86)\SVP\FRC\GRunT.dll")
Import("C:\Program Files (x86)\SVP\FRC\FrameRateConverter.avsi")
Input = ffdshow_source()
SetMTMode(2)
FrameRateConverter(Input, Preset="fast")
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last

[hello_hello]

mark0077,
To the best of my knowledge the ffdshow Avisynth section ignores some AviSynth functions, and I'm fairly sure changing the frame rate is one of them. It makes sense, because if you change the frame rate and it in turn changes the duration, the audio won't stay in sync.
Plus the renderer or other filters down the line probably need to know the frame rate and changing it might cause issues there.

Try putting something simple like ChangeFPS(20,1) in ffdshow's Avisynth section.

SVP is probably a different story, but I can't say I've used it for more than 10 seconds. Doesn't it install stuff for controlling it outside of ffdshow?

Do you per chance use Potplayer? Many of ffdshow's filters have been borrowed and added to Potplayer, and it should let you change the frame rate. In fact I think it comes with scripts for doing just that. Have a look in Preferences/Video/Avisynth.

[mark0077]

Thanks hello hello. Actually I use SVP DLLs without any of the additional tray icons or software and I think madVR always says the frame rate is the original rate. Not the converted rate but all still says in sync. I am hoping to replicate the same pattern with FRC. Has anyone used it via ffdshow in real time?

[hello_hello]

My bad... I appear to have remembered wrong. ChangeFPS() works in the ffdshow Avisynth filter, but AssumeFPS() doesn't, so FrameRateConverter should work, assuming it's not too slow.

[iG0R]

MysteryX
Hi. Could you give some advises how to speed up the conversion cause 4-6fps is too boring on 4790K@5GHz and 1080ti? Is it possible somehow to use also GPU for this process?
Thank you for such quality filter.

[burfadel]

MysteryX
Hi. Could you give some advises how to speed up the conversion cause 4-6fps is too boring on 4790K@5GHz and 1080ti? Is it possible somehow to use also GPU for this process?
Thank you for such quality filter.

I can answer that one :). In terms of using the GPU for processing, the answer is unfortunately no. For speed, it all depends on how you currently have things set up. If you use the latest (currently rev 2544) 64-bit Avisynth+ with the latest Masktools, MVTools, as well as other filters in your script, it will help with speed quite a bit!

[iG0R]

I can answer that one :). In terms of using the GPU for processing, the answer is unfortunately no. For speed, it all depends on how you currently have things set up. If you use the latest (currently rev 2544) 64-bit Avisynth+ with the latest Masktools, MVTools, as well as other filters in your script, it will help with speed quite a bit!
Thank you for the answer.
Yes, I'm using the latest Avisynth+ (AvisynthPlus-r2544-MT.7z), MaskTools (masktools2-v2.2.10.7z), MVTools (mvtools-v2.5.11.22.zip) and FRC (FrameRateConverter-v1.2.zip) but the speed is still awful :( - with Preset="slowest", BlendOver=40, SkipOver=140 fps is around 1-1.2 and with Preset="Anime" fps is about 4-6.

[MysteryX]

What CPU usage are you getting? Are you using MT mode, and if so, how many threads are you using?

[iG0R]

What CPU usage are you getting? Are you using MT mode, and if so, how many threads are you using?
Screenshot:
https://snag.gy/QwAs7F.jpg
The internal AviSynth Portable r2508 of MeGUI doesn't support MT though it says that it does (Error message for your reference: Script error: There is no function named 'SetMTMode') so I tried to use AviSynth MT from this post https://forum.doom9.org/showthread.php?p=1817809#post1817809, but after some time of processing, encoding is crashed so I decided not to use it and tried AviSynth r2544MT, I don't know why MeGUI doesn't support it and switches to internal portable r2508.
Here is my script:

SetMemoryMax(6000)
PluginPath = "C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\"
LoadPlugin(PluginPath+"FrameRateConverter.dll")
LoadPlugin(PluginPath+"mvtools2.dll")
LoadPlugin(PluginPath+"masktools2.dll")
LoadPlugin(PluginPath+"GRunT.dll")
Import(PluginPath+"FrameRateConverter.avsi")
<input>
<deinterlace>
<crop>
<denoise>
<resize>
FrameRateConverter(NewNum=60, NewDen=1, Preset="slow", BlendOver=40, SkipOver=140)

PS. Sorry for such stupid question but what is the "spoiler" tag for this forum? I tried to insert screenshot as an image but didn't find the spoiler tag and without this tag my screenshot is too big to publish it in the message.

[Groucho2004]

Screenshot:
https://snag.gy/QwAs7F.jpg
The internal AviSynth Portable r2508 of MeGUI doesn't support MT though it says that it does (Error message for your reference: Script error: There is no function named 'SetMTMode') so I tried to use AviSynth MT from this post https://forum.doom9.org/showthread.php?p=1817809#post1817809, but after some time of processing, encoding is crashed so I decided not to use it and tried AviSynth r2544MT, I don't know why MeGUI doesn't support it and switches to internal portable r2508.
According to your screen shot you're attempting to use Avisynth+ 64 Bit with Megui. Apparently, Megui does not support 64 bit Avisynth and therefore switches to the "portable" 32 bit version.

The MT error message is quite clear, Avisynth+ does not have a "SetMTMode" function. Multi-threading in AVS+ is implemented differently, see here (http://avisynth.nl/index.php/AviSynth%2B#MT_Notes).

[iG0R]

According to your screen shot you're attempting to use Avisynth+ 64 Bit with Megui. Apparently, Megui does not support 64 bit Avisynth and therefore switches to the "portable" 32 bit version.

The MT error message is quite clear, Avisynth+ does not have a "SetMTMode" function. Multi-threading in AVS+ is implemented differently, see here (http://avisynth.nl/index.php/AviSynth%2B#MT_Notes).

Could you advice another tool like MeGUI that supports 64bit AviSynth+? Hybrid doesn't support 64bit AviSynth+ too :(
Thank you, now I understand what was wrong with AviSynth+.

[Groucho2004]

Could you advice another tool like MeGUI that supports 64bit AviSynth+?Staxrip. I think there's also a 64 bit version of Megui.

[StainlessS]

Think Current ver$ of Staxrip support ONLY 64 bit [Win7+). (JFYI)

EDIT:
http://staxrip.readthedocs.io/intro.html#about

Requirements

Windows 7 x64 or Windows 10 x64, StaxRip is x64 only
.NET 4.7
Intel Skylake or newer for HEVC/H.265 hardware encoding
NVIDIA Maxwell gen2 card or newer for HEVC/H.265 hardware encoding
AMD Polaris card or newer for HEVC/H.265 hardware encoding
AviSynth+ x64, the installer is bundled with StaxRip or alternativly VapourSynth which requires Python



EDIT: On searching StaxRip Docs (builtin StaxRip search) found no mention of MeGUI [at least for current version, x64].
http://staxrip.readthedocs.io/search.html?q=megui&check_keywords=yes&area=default