MeGUI: bug reports and feature requests

[LigH]

For many media formats, MeGUI can't know a "main" audio language because there is no preference defined in the container (even if the container supports it at all, not every author selected one).

And for many people there may be a preference of languages they actually understand, over any other original language the movie was produced in first. So MeGUI offers two "Default languages" in its "Main Configuration"; but it seems there is no choice to "prefer none" and just assume the track with the first number is your preferred one.

[wthreex]

Honestly, I've encode a lot of movies in the form of a folder with OneClick encoder, Most of the films inside the folder contain "English commentary", And if the main audio is the non-English, MeGui Choose the "English commentary" track for the main audio , And since I've automatically encoded a lot of movies, I can not manually select the original audio.
I hope Zathor finds a solution to this problem.

[LigH]

For such cases, you may need a new option to ignore preferred languages from the options and prefer the original order instead...

[Zathor]

Select the languages and the order you want in the OneClick profile settings. If you do not select anything on the left and the option "all" for "Languages to select if selection does not match" it should retain all tracks in the original order. I have never tried that to be honest. Please report back if it does not work and I will change it.

[ratpack]

In the past I've been able to enter a custom sar in the x264 configuration field, and it's generally worked ok.

For a while now, it has no effect. Whatever the 'force sar' setting is will overrule any custom setting.
So having the custom sar in the screenshot attached has absolutely no effect.

It means I'm limited to only being able to use the presets in the force sar drop-down list.

Is this a regression, or has something else changed that I don't know about?

[tebasuna51]

Originally Posted by ratpack

Whatever the 'force sar' setting is will overrule any custom setting.

It means I'm limited to only being able to use the presets in the force sar drop-down list.

Like you can see in command line window there are:

--sar 33:34 --sar 32:27

and always work the last parameter.

Select "Default" in 'Force sar' box when you use a custom sar.

[Zathor]

Thanks for reporting this. The first custom parameter will currently not been detected properly and matched with settings of the GUI.
EDIT: fixed in 2768 (not online yet)

[bilditup1]

I've written some patches to fix various issues with MP4BoxMuxer. Long story short - AppleXML chapters weren't getting written, AppleXML chapters embedded in an mp4/m4v were not getting parsed properly, and due to an apparently undocumented change in mp4box, the par and name options to the '-add' parameter stopped being parsed properly. So, I rewrote the Apple chapters function to work like the other rewritten chapters functions, made a minor change that gets AppleXML chapters to parse the right way, and changed the syntax used to specify par and tracknames for MP4Box. These are IMHO critical so pls take a look soon. Thanks!

https://sourceforge.net/p/megui/patches/70/

[bilditup1]

Originally Posted by tebasuna51

Like you can see in command line window there are:

--sar 33:34 --sar 32:27

and always work the last parameter.

Select "Default" in 'Force sar' box when you use a custom sar.

Originally Posted by Zathor

Thanks for reporting this. The first custom parameter will currently not been detected properly and matched with settings of the GUI.
EDIT: fixed in 2768 (not online yet)

Actually, what I've found recently when using a custom --sar (in my case, 20:11, for an old 352x480 video from some random camera), is that it got ignored by x264 and mp4box even if "Default" is used in the 'Force sar' box. The latest patch fixes this, however. Thanks zathor!

[olmicx]

Originally Posted by Zathor

Thanks for reporting this. The first custom parameter will currently not been detected properly and matched with settings of the GUI.
EDIT: fixed in 2768 (not online yet)

we are waiting for 2768

[bilditup1]

Originally Posted by bilditup1

https://sourceforge.net/p/megui/patches/70/

Thanks to fixes to mp4box in response to bug reports I filed at gpac, one of my patches, the one for tracknames and PAR, should no longer be relevant, as long as you update the version of mp4box to the very latest nightly including those fixes (which isn't out yet). I encourage you to make the switch to this nightly if only this once, because of a different bug, which I described in a bug report here and which can't really be worked around by MeGUI itself. If you don't switch to this build then my fix for tracknames/par remains relevant, though. More about this in a comment I left at the original patch submission at sourceforge, quoted above.

[olmicx]

Hi Zathor.
I am using Megui 2767 version. When you share a new version of Megui.exe, despite the x264 version of the program does not change there is difference in the quality of the encoded video. I only downloaded a new version of Megui.exe. Do you think the difference in video quality is a normal thing?

[LigH]

@ olmicx: You ... downloaded. Zathor uploads.

Apart from that, this complaint is way too vague. Hard to help without any facts and numbers: Complete logs of both encodes, complete MediaInfo reports, possibly even cut-out video samples of comparable scenes with obvious differences...

In general, with the same encoder version and the same script and the same plugins, there should not be a noticable difference. So if there is any, there must also be a reason. Maybe a change in the handling of the material, anything that changes either the generated script content or the command line calling the encoder.

[sneaker_ger]

Originally Posted by LigH

In general, with the same encoder version and the same script and the same plugins, there should not be a noticable difference.

There should be no difference at all (unless you force x264 into non-deterministic mode).

So I agree: something must have changed. Best would be to compare the log files.

[Taurus]

Originally Posted by olmicx

Hi Zathor.
I am using Megui 2767 version. When you share a new version of Megui.exe, despite the x264 version of the program does not change there is difference in the quality of the encoded video. I only uploaded a new version of Megui.exe. Do you think the difference in video quality is a normal thing?

Look at the x264 settings tab if there is something changed during a new MeGui install.
I always make a backup of my favourit settings and store it under a new name. Just in case somethings going wrong .
But the best you can do, post a log file of a known "good" encode
and one from a "bad" encode.
So we might have a look at them.

[stax76]

@olmicx

To share full logs and find and share full log differences you can use www.pastebin.com and www.diffchecker.com, I recommend to use the option to store it only for one month and not post torrent file paths.

[Zetti]

MKVToolNix v14.0.0 is released.

[Zathor]

Originally Posted by Zetti

MKVToolNix v14.0.0 is released.

Thanks, uploaded

[bilditup1]

(I made a minor update to my patch to MediaInfoWrapper - when you get around to trying the patch out, pls use the newer version.)

[wthreex]

Why does megui sometimes change the video framerate? some of my video is out of sync because of it.

I'd like make it as source , what is the avisynth code?