MeGUI Bug-Report Thread

[Rumbah]

Okay, I posted the bug with the framerate in the DGIndex forum:

http://forum.doom9.org/showthread.php?p=859757


As dngnta has the same problem, it really seems to be a DGIndex bug with the command line processing.

[dngnta]

Is the split acting on mp4 or mkv? In mkvmerge you have to specify units or it'll use bytes, so I guess mp4. Oh yeah, I see the command in mp4box now. Actually it's only 700*1024 though, or 716800. (Since kB is already assumed.)
Yeah, I'm using mp4. And yes, you are correct, the files now became a bit too big when I used 734000. Thankfully I was able to stop MeGUI before it deleted the temporary files ;-) With -splits 716800 the files fit on a 80 minute data CD (700 MiB or ~735 000 000 bytes max). However, they're slightly too small (parts 1 and 2 are under 729 million bytes and I get a 3rd part which is about 10 MB).

Using -splits 722000 I get two files that are neatly sized, the first part is 734,4 million bytes and the second part is 733,5.

So MeGUI should at least be modified to use x*1024 in the command line (where x is the value set in the dialog). But it appears mp4box isn't entirely exact in this regard, so problems will remain anyhow.

[foxyshadis]

mp4box always splits at less than the requested size, at the start of the last GOP. But since you could still split them under 700MB but larger than when you actually ask for 700MB, that sounds like a definite bug. Hrmph.

[bourtzovlakas]

Is megui able to load .mp4 files, generated by nero recode, in the Avisynth script creator??

I tried to load such a file and the program crashed 3 consecutive times, with different error messages...

1)"Out of memory" error
2)See the screenshot...
http://zavlakas.googlepages.com/259.JPG
3)The "submit to M$" error

Here is the .mp4 file...
http://zavlakas.googlepages.com/gla_nova_chicken_thief.rar

[Teegedeck]

Relative paths to the CQMs used in the XviD profiles don't seem to work. If you open the source file after selecting a profile MeGUI will look for the CQM in the source's directory; but even if you do it the other way round and MeGUI searches in the correct path it won't load a CQM.

Thanks for including the presets BTW! :)

[elguaxo]

Relative paths to the CQMs used in the XviD profiles don't seem to work.
Same problem here, MeGUI 0.2.3.2185. The relative paths to the CQMs in Teegedeck's presets used to work in earlier versions of MeGUI.

[Teegedeck]

So... Was it good, old me in the end who b0rked the archive? When did you download your copy of the presets?

Or did something change in MeGUI core?

[elguaxo]

So... Was it good, old me in the end who b0rked the archive? When did you download your copy of the presets?

Or did something change in MeGUI core?

I think it is MeGUI. I am using your presets before they were included in MeGUI's auto-update and I haven't updated them. They worked fine, but yesterday (MeGUI 0.2.3.2185) I got this error for the first time:
Error opening input file extra\Didees SixOfNine.cqm

Changing the path to the full path solved it.

[Sharktooth]

no... it's due to the relative paths in the profiles.

[Zeest]

There is some serious issue with meGUI's commandline for mkvmerge's latest version. I've tried over 4 times and it always fails at that step.

Here is meGUI's commandline for mkvmerge v1.7.0 ('What Do You Take Me For') built on Apr 28 2006 17:19:57

-o "blah2.mkv" -A -S "blah.mkv" --language 0:eng -a 0 -D -S "blah_audio.ac3" -split 700MB --no-clusters-in-meta-seek


And this is how it should look

-o "blah2.mkv" -A -S "blah.mkv" --language 0:eng -a 0 -D -S "blah_audio.ac3" --split size:700M --no-clusters-in-meta-seek


Please fix the shortcomings in megui's commandline for latest version of mkvmerge. Its making the AutoEncode Process a pain in the ass.

[cyberbeat]

1) Actually, just pressing PREVIEW before clicking on AUTOCROP will cause it to crash.
I got around this by adding the following code:
In "private void previewButton_Click(object sender, System.EventArgs e)" around line 1000 in AviSynthWindow.cs before the line "player.disableIntroAndCredits();"
reader = player.Reader;
One thing I am not sure about is when you press the PREVIEW button after a CROP, it will show a cropped preview. If you AUTOCROP at this point, it will have new values based on the cropped preview instead of the original footage. (At least, I think that is what is going on.) Would it not be better to have AUTOCROP always use uncropped footage and only let the Mod16 items affect it?

2) AutoCrop seems to have an issue with one scenario. I use the "Non mod16 encoding" so there is no resizing or excess cropping. I then click on AUTOCROP to remove the borders. More often than not it will but "0" for the left border and "2" for the right border. This causes a problem with non Mod16 encoding because the width has to be a multiple of 4 or you get an error. I encode MP4 video with MP4 AAC audio into the MP4 container. I just change the right side to 0 most of the time.

I got around this by adding the following code: (was not sure if this would be appropriate or if it should be a part of VideoUtil.cs)
In "private void autoCropButton_Click(object sender, System.EventArgs e)" around line 1446 in AviSynthWindow.cs after the line "cropBottom.Value = final.bottom;"

if (Mod16Method == mod16Method.nonMod16)
{
while ((cropLeft.Value + cropRight.Value) % 4 > 0)
{
if (cropLeft.Value > cropRight.Value)
{
if (cropLeft.Value > 1)
{
cropLeft.Value = cropLeft.Value - 2;
}
else
{
cropLeft.Value = 0;
}
}
else
{
if (cropRight.Value > 1)
{
cropRight.Value = cropRight.Value - 2;
}
else
{
cropRight.Value = 0;
}
}
}

Can somebody verify that these two items are bugs? Will the included code be suffice to add or can you fix them? They both seem like very quick fixes. So, if they are bugs, can somebody include the fixes in one of their commits to SVN?

Thanks,
cyberbeat

[check]

I can confirm #1, didn't test #2 as I lack croppable sources within close reach.

[sjchmura]

(from my knowledge gained in another thread).

Autocrop will choose NON-mod16 cropping values (1920x1088->1910x1078 for example for the battlestar galactica HD streams). EVen if you "resize" to mod16 (1280x720) you still get the "green lines' at the bottom of the encode (confimred by others).

So can we make the crop value "force" mod16 in teh avisynth creator or at least suggest a "non-green line" resolution :)

THanks. I jsut with NicAudio was more forgiving like besweet on the ac3 streams :) I have Ac3filter working GREAT to encode to ac3 in realtime so I have to disable that to encode alot of stuff with "force directshow"

[Doom9]

@Zeest: I already fixed that yesterday

[berrinam]

(from my knowledge gained in another thread).

Autocrop will choose NON-mod16 cropping values (1920x1088->1910x1078 for example for the battlestar galactica HD streams). EVen if you "resize" to mod16 (1280x720) you still get the "green lines' at the bottom of the encode (confimred by others).
This doesn't happen to me. Are you saying that you crop (non-mod16), resize in AviSynth and you still get green lines? That sounds like an AviSynth bug, but as I said, this doesn't happen to me.

If you are saying that you just crop and encode, and you get green lines, well, something's up there. However, if you aren't resizing, then you should be using anamorphic encoding, and then you can set it to 'overcrop to mod16'. Problem solved!

[Doom9]

@cyberbeat: I can't reproduce your number 1. Probably because you forgot to mention that you need to close the preview and re-open it by pressing the preview button..
Would it not be better to have AUTOCROP always use uncropped footage and only let the Mod16 items affect it?Considering the code, the best thing is if the user follows the gui top-down like it's meant to be used.. the crop button has no knowledge whatsoever about what kind of script was used.. not even the videoreader or its child the avsreader has that info.

With regards to your second point, I think the point of the non mod16 setting is that there will be no additional check and that whatever crop values are found will be used. Now you want to introduce a mod4 on the vertical axis... that's not the same as non mod16.. that's mod4 vertical, a whole new option.

[Doom9]

I had a look at what ToS_Maverick described. First of all, the instructions to reproduce cannot be followed.

You cannot select HQ-Slower, then disable P4x4 and then select the AVC Level to 3. MeGUI will complain about the bitrate being too high. So what exactly did you do in the config window?

Despite the description I believe I have found what you're refering to in the end. If I create the HQ-Slower-CRF profile, then in fact, the current profile (HQ-Slower) gets the settings of the new profile... after the profile is added, it is selected, and a change in the selected profile triggers an update of the previous profile.. so in the end, HQ-Slower-CRF and HQ-Slower have the same settings. If you then select another HQ profile with 2 passes, then in the end your HQ-Slower-CRF becomes a 2 pass profile, and HQ-Slower is CRF.. I think that's why you meant there's a displacement by one.

[Doom9]

@PhAtfiSh: I've had a look and we do indeed have a rather serious problem in the calculator. First no distinction is made between VBR and CBR MP3 and then the audio overhead is calculated for a single frame.. not the number of frames the source has.. so basically the audio overhead is being ignored.

One note though: you cannot readily compare the results of gknot and megui in gknot's default xvid mode.. the xvid vfw considers the AVI overhead so the bitrate you enter is the bitrate of avi plus container, whereas in megui bitrate = bitrate of the raw bitstream, not including the container. To be able to compare the results, you must force gknot to take the frame overhead into account (which will then result in missing the target size if you're encoding from within gknot or any other software using the xvid vfw).

[spunch]

I was wondering if there's any point of further improving the automatic deinterlancer in MeGUI.

MeGUI has a great automatic deinterlancer. I have no idea how it works but for the most part it manages to do a great job, it's just sometimes it picks the entirely wrong deinterlacer, making the clip look worse than the interlaced original.

I know nothing is perfect but i noticed some problematic clips can deinterlace fine with just slight modifications to the avisynth script.

I could provide you with many short clips that seem to have this problem. Let me know if it is practical.
I certainly would like some examples where it doesn't work. If you can narrow it down to a 1-minute sample, that would be great, but if not, then I can make do with bigger samples. PM with details about the clips if you want. Thanks
Ok I sent berrinam some of the problematic clips two weeks ago but he does not appear to be responding so I'll post them here.

Here are a few examples of short clips that do not work very well with the automatic deinterlacer in MeGUI.

http://65.121.137.150:8080/deinterlacer_probs1/

You should see a directory tree.

If you have spare time, please also check this:

http://65.121.137.150:8080/artifacts_at_right/

It's another artifact I don't understand but see quite often. It makes a few pixels flash incoherently on the far right of the clip. I think it's something related to the automatic deinterlacer as well.

I included the encoded x264 file, the original VOB and a log file noting what MeGUI was thinking at the time.

Let me know if there are any problems, thanks.

[cyberbeat]

@cyberbeat: I can't reproduce your number 1. Probably because you forgot to mention that you need to close the preview and re-open it by pressing the preview button..
Considering the code, the best thing is if the user follows the gui top-down like it's meant to be used.. the crop button has no knowledge whatsoever about what kind of script was used.. not even the videoreader or its child the avsreader has that info.

@Doom9: First off, I appreciate you taking the time to look at the issues that I was talking about. On my copy (and I just tested version 2187). I only have to click PREVIEW and then AUTOCROP and it will crash. My preview window automatically comes up when I load a video source. Then, I click PREVIEW and then AUTOCROP and it will crash. I never have to click PREVIEW for the most part, but I was expanding on an error that somebody else reported.
You mention that it is best to follow the GUI top-down. If that is the case, then why not disable the AUTOCROP until it should be pressed. Otherwise, it is a bug or at least something that the end user should not be getting.


With regards to your second point, I think the point of the non mod16 setting is that there will be no additional check and that whatever crop values are found will be used. Now you want to introduce a mod4 on the vertical axis... that's not the same as non mod16.. that's mod4 vertical, a whole new option.
@Doom9: I understand the logic that you intended with "non mod16" and that is why I use it. The problem is that I had scripts that MEGUI was erroring out on when I tried to start the encode. I took some advice on here and used Zoom Player to test the AviSynth script for errors. It gave me the following errror "YV12 images for output must have a width divisible by 4". After testing it, that was definitely the problem I had, hence my suggestion of having the horizontal crops be a multiple of 4. In the regular mod16 modes, this is not an issue because any mod16 is also a mod4. In the non mod16 mode, this is a problem and is the reason I mentioned it. I do not know formats, I just know the error that was created when running an AviSynth script that is non mod4.
I am not sure what you are referring to by me wanting to introduce a mod4 to the vertical access. I was refferring to the horizontal crop values and just wanting to eliminate a problem with using "non mod16". So, in essence, it would be a "non mod16" but just does an extra check to make sure the script generated will work.

Thanks,
cyberbeat

[foxyshadis]

Ah, it seems MeGUI isn't making it mod4 - we should use Didee's m4() or the more generic one I made.


function m4(float x) {x<16?16:int(round(x/4.0)*4)}

[cyberbeat]

Ah, it seems MeGUI isn't making it mod4 - we should use Didee's m4() or the more generic one I made.


function m4(float x) {x<16?16:int(round(x/4.0)*4)}


@foxyshadis: If I am reading this right, it would cause the value of 'x' to be 0, 4, 8, or 12, providing that 'x' is less than 16. Would this be done on the left and right side individual crop values or on the combined left and right total values? Where would you put this at in the code?

Thanks,
cyberbeat

[foxyshadis]

I mostly mentioned it so I wouldn't forget (or whomever works on it), but if you want to fix it, place it somewhere in the script, and add this after the crop:
lanczosresize(m4(width),m4(height))
It should never change the aspect ratio more than .5%. Technically the height only has to be mod2, though. That's why I like mine:

function m(int r, float x) {return(x<16?16:int(round(x/float(r))*r))}
lanczosresize(m(4,width),m(2,height))

If you don't want to resize, you can also use this to force an overcrop.

[Doom9]

My preview window automatically comes up when I load a video source. Then, I click PREVIEW and then AUTOCROP and it will crash.Don't tell me you consider this a normal way of using a program.. you have a preview window on screen.. there's no point at all in pressing preview again, is there?
Either way in my local copy, pressing preview will do nothing at all if there's a preview window (it should tell the user to to think hard about what he's doing and realize it makes no sense ;) and then pressing autocrop will work. Closing the preview, reopening it and pressing autocrop will also work. I think I should move the crop above resize though as this corresponds to the workflow that should be used.

[Sharktooth]

Swapped Resize and Crop controls position in 2188.

[iMaGe]

Here's a bug that I've encountered with the latest build. It involeves Chapters and AutoEncode

I decided to try AutoEncode with x264/mkv. So I load up my avs file then AutoEncode. In the Automatic Encoding window, I set the options and check "Add additional content", then Queue. The MuxWindow comes up, and I fill everything including chapters.

After I'm done, I double check all the settings by hitting load in the queue tab. When I load the mux job, it says that there is no Chapter file loaded. I re-add the chapter info file and update, and it sticks.

I'm not too sure if this is just a cosmetic bug or if chapters will not be encoded if I run it straight through. I imagine that it won't though.

[Doom9]

Another bug at the avs creation (0.2.3.2177): after analyzing for deinterlacing option, just the megui-offered setting can be saved in the generated avs script. (If you select anything else or switch off the deinterlicing opzion: nothing happen, the offered option will be saved.) I tried it with 0.2.3.2151 too.I cannot reproduce this with 0.2.3.2189.. I analyzed a source, turned off deinterlace and turned on the noise filter, then saved, the resulting clip looks like this:

DGDecode_mpeg2source("D:\DVDs\DVDVolume\VIDEO_TS\re-trailer.d2v",info=3)
ColorMatrix(hints=true)
#Not doing anything because the source is progressive
#crop
#resize
Undot() # Minimal Noise

In autoencode: When an AC3 file is selected, the language doesn't appear to be set for audio in the final commandline to mkvmerge.Hmm.. I do see the language being set, as well as the track name. The only thing I'm not sure about is the track ID.. megui sets it to 0, unless the audio file is an mp4 in which case the track ID is set to 1.

So for an audio stream with language English, the following elements would be added to a mkvmerge commandline:
--language 0:eng -a 0 -D -S "audio.ac3"

In case this should be incorrect, can you suggest which commandline to use?

* In autoencode: When an idx subtitle is selected and the default language isn't changed from Abkhazian it causes a crash. If the language is changed to English it will queue but an intermediate AVI is inserted for some reason and won't insert the subs in the final mux. You really shouldn't need to set the language at all with idx inputs; it should parse all tracks and languages from the file just as mkvmergegui does.I have identified what causes the crash and have fixed it. I don't quite get what you want to be done with the audio languages though... megui has a 5 subtitle stream limit.. what exactly should happen if an idx is being selected? (down to the mkvmerge commandline you expect) Reading the manpage I see nothing that would indicate mkvmerge is somehow able to automatically set the language based on idx input, but if there's such an option, please tell so that I can implement it.
I've also spotted the avi mux job and I'm currently looking into that.

@update: found a fix for the avi mux job in the mkv output + vobsub input scenario. Megui thinks mkvmerge can't handle vobsub input, and since divxmux can handle vobsub as well, megui creates a vobsub -> avi, avi + avi-in-mkv -> mkv mux series (behold the awsome power of automatic muxpath finding.. you get something workable even if the author made an error someplace).

[Doom9]

@iMaGe: I've identified and fixed the problem. Turns out the automatic muxpath finding never considered chapter files, and when you load the mux job, you go to a specific muxer window where the whole path finding isn't done and streams are just added as-is. My next commit will include the fix.

[Doom9]

There seems to be something weird happening when you select an audio file with delay on the main MeGUI input screen. I create my AVS script for my video and have it save and load it to the main screen. I then select my audio track from the same directory. When I click on config, the delay time has not updated. If I reload the audio file, it then seems to work even while changing profiles. On my next encode, when I load audio from a different directory, it seems to keep the setting of the last file. Is this intended behavior that I have missed while lurking through the discussions or should it be updating always? I am encoding right now. So, if you need more details, I will try to get some more information on what is causing it.I'm not able to reproduce this, but I've found something else which you might mistake for what's actually going on:

If I load a file with a delay, the delay is taken into the codec settings. If I then change the codec, the settings of the new codec do not include the delay. Going back to the original settings, the delay is there. If I load a file, then switch codec, then load the file again, the settings of both codecs now containt the delay. Now If I load another file, then go back to the first codec, that one will have the delay of the first file configured.

So the bottom line is: the delay is only written into the settings of the currently active codec when you load a file.. if you change the codec, the delay is not being propagated.

It'll take some doing to change this as the delay should be moved away from the settings to the substream.. that will also make it possible to specify delays when muxing (e.g. for AC3 or DTS streams).

[Sharktooth]

And again...
MeGUISettings.cs(23,17): error CS0246: The type or namespace name
'AutoEncodeDefaultsSettings' could not be found (are you missing a using
directive or an assembly reference?)
MeGUISettings.cs(473,16): error CS0246: The type or namespace name
'AutoEncodeDefaultsSettings' could not be found (are you missing a using
directive or an assembly reference?)
SettingsForm.cs(116,17): error CS0246: The type or namespace name
'AutoEncodeDefaultsSettings' could not be found (are you missing a using
directive or an assembly reference?)
... there are 2 missing files in the SVN:
AutoEncodeDefaults.cs
AutoEncodeDefaultsSettings.cs

;)

[Doom9]

Alright, tortoise is officially a POS. The fact that it ruins the file menu in windows explorer just further underlines the point. The first menu point in a file menu needs to be new.

[cyberbeat]

I'm not able to reproduce this, but I've found something else which you might mistake for what's actually going on:

If I load a file with a delay, the delay is taken into the codec settings. If I then change the codec, the settings of the new codec do not include the delay. Going back to the original settings, the delay is there. If I load a file, then switch codec, then load the file again, the settings of both codecs now containt the delay. Now If I load another file, then go back to the first codec, that one will have the delay of the first file configured.

That explains the problem I was seeing, exactly. Thanks. Would it not be easier for the delay setting to not be stored with profile and not updated via the profile switching or would moving it to the substream have that effect?

cyberbeat

[Doom9]

I've uploaded a fixed version. The whole delay thing works differently now: delays are not taken into the settings until the point where you actually encode.. but they are being kept in memory until that point and even if you can't see them, the delay is there and will be taken into account for any encoding session. But you can now swap between the streams, change codecs and profiles without any interference (delays weren't the only problem.. the settings of the two audio streams were never quite decoupled).

[Doom9]

I'm getting a pretty big bug using the latest version of MeGUI (0.2.3.2177). I'm using the MKV container and the "AutoEncode" method of muxing additional files. When muxing the AC3 file, the delay information is not read from the filename (or whereever its supposed to be from). Therefore, if the AC3 track has delay, the audio sync is off.That's taken care off in 0.2.3.2191 now.

I've gone back about 2 months reading through this thread and I'm hoping people get around to testing my recent fixes and mention if something is still off.. I think I pretty much got everything that's really a megui problem.

[cyberbeat]

I've uploaded a fixed version. The whole delay thing works differently now: delays are not taken into the settings until the point where you actually encode.. but they are being kept in memory until that point and even if you can't see them, the delay is there and will be taken into account for any encoding session. But you can now swap between the streams, change codecs and profiles without any interference (delays weren't the only problem.. the settings of the two audio streams were never quite decoupled).

Does that mean there is no way to override a delay that is wrong without changing the filename? I still see the delay options in the audio profile configuration screen, what happens when a value is set in the profile? I am looking at version 2191. I just want to make sure I have an understanding of the new functionality.

Thanks,
cyberbeat

[cyberbeat]

And again...
... there are 2 missing files in the SVN:
AutoEncodeDefaults.cs
AutoEncodeDefaultsSettings.cs

;)

I am getting the following missing file error when I try to compile the latest version (2191).

Resource file "AutoEncodeDefaults.resx" cannot be found.

cyberbeat

[Sharktooth]

svn update

[Doom9]

Does that mean there is no way to override a delay that is wrong without changing the filename?Yes there is.. once the job is in the queue, select it, press load, and reconfigure. But that's the ONLY way. If DGIndex gets the delay wrong, then you should head over to the DGIndex forum and let neuron2 know.

I still see the delay options in the audio profile configuration screen, what happens when a value is set in the profile? Profile = settings + name.. that's the way megui is built and it applies to every profile type. And since the delay is a setting, it will always be in every profile. But, you select your audio file, megui gets the delay from the filename.
Then you select your profile with 0 delay.
Then you queue. Now MeGUI will see that it found a delay upon opening the file, and will apply the delay found.

In case the filename contains no delay, the delay from the settings will be taken at the moment where you press queue.

I strongly suggest that you do not put any delays into any profile.. that's a property that has no business being set in a profile as its source specific.

[cc979]

using 0.2.3.2192 i've found a bug with the avs script creator - i used to autocrop and resize then hit preview to see the new size and aspect ratio, but if i hit preview after autocrop i get a white preview screen and if i close that preview it shows a fatal error - if need the error screen i will post it

[Doom9]

I can only partially reproduce this.. I never get a crash. But here's how it works properly: load source, crop (or autocrop), resize, close preview, press preview to see the results.
Keep in mind that the preview you get when loading a source is a source preview.. it goes only as far as cropping.. anything else and you have to close it and open another preview (the window may look the same but its something completely different).

I have improved this in the new build I'm working on. It'll work like this:
1) you open your source and get a preview of it
2) you crop
3) you press preview.. at this point all cropping controls are blocked - this is necessary as making any crop changes at this point will result in the preview showing a crop of the already cropped source in the preview

You can then press preview as many times you like to see all the changes.. but cropping has to be done when you see the source, and only then (cropping being the first operation on the source after all).

[clutch]

Could someone point me to how to solve this problem. I keep getting a "Error opening input file extra\Didees SixOfNine.cqm"
in the logs.

I don't see this file on my system.

Clutch

[cyberbeat]

I have improved this in the new build I'm working on. It'll work like this:
1) you open your source and get a preview of it
2) you crop
3) you press preview.. at this point all cropping controls are blocked - this is necessary as making any crop changes at this point will result in the preview showing a crop of the already cropped source in the preview
One thing that I have noticed, since the inclusion of mod4 cropping, is that the values on the screen do not reflect the programmatic values being used. This seems to affect the mod16 overcropping too and it may have been around since before that version. The "private CropValues Cropping" section seems to adjust the overcrop and mod16 values, but the controls on the form are never updated to reflect it. I found two ways around it, but not sure if either would be the best. I did not know if there is a way to keep an event from firing other than the way shown. Disabling the control did not work.

1st way was to edit "private CropValues Cropping" in AviSynthWindow.cs to look like the following ("+" precedes added lines):

private CropValues Cropping
{
get
{
CropValues returnValue = new CropValues();
if (crop.Checked)
{
+bool updateCropValue = false;
returnValue.bottom = (int)cropBottom.Value;
returnValue.top = (int)cropTop.Value;
returnValue.left = (int)cropLeft.Value;
returnValue.right = (int)cropRight.Value;
if (Mod16Method == mod16Method.overcrop)
{
ScriptServer.overcrop(ref returnValue);
+updateCropValue = true;
}
else if (Mod16Method == mod16Method.mod4Horizontal)
{
ScriptServer.cropMod4Horizontal(ref returnValue);
+updateCropValue = true;
}
+if (updateCropValue)
+{
+ this.cropLeft.ValueChanged -= new System.EventHandler(this.crop_CheckedChanged);
+ this.cropRight.ValueChanged -= new System.EventHandler(this.crop_CheckedChanged);
+ this.cropTop.ValueChanged -= new System.EventHandler(this.crop_CheckedChanged);
+ this.cropBottom.ValueChanged -= new System.EventHandler(this.crop_CheckedChanged);
+ cropBottom.Value = returnValue.bottom;
+ cropTop.Value = returnValue.top;
+ cropLeft.Value = returnValue.left;
+ cropRight.Value = returnValue.right;
+ this.cropLeft.ValueChanged += new System.EventHandler(this.crop_CheckedChanged);
+ this.cropRight.ValueChanged += new System.EventHandler(this.crop_CheckedChanged);
+ this.cropTop.ValueChanged += new System.EventHandler(this.crop_CheckedChanged);
+ this.cropBottom.ValueChanged += new System.EventHandler(this.crop_CheckedChanged);
+}
}
return returnValue;
}
}


2nd method which is a lot shorter, but not sure if it has any side effects. Edit "autoCropButton_Click" event in AviSynthWindow.cs to have the part listed below modified with the extra lines ("+" precedes lines that were added). Then you would delete the IF and ELSE IF statements listed below from "private CropValues Cropping" section of AviSynthWindow.cs.

if (!error)
{
+ if (Mod16Method == mod16Method.overcrop)
+ {
+ ScriptServer.overcrop(ref final);
+ }
+ else if (Mod16Method == mod16Method.mod4Horizontal)
+ {
+ ScriptServer.cropMod4Horizontal(ref final);
+ }
cropLeft.Value = final.left;
cropTop.Value = final.top;
cropRight.Value = final.right;
cropBottom.Value = final.bottom;
if (!crop.Checked)
crop.Checked = true;
}

Of course, you may have already changed all of this in the version that you are updating the AUTOCROP functionality on. I was just puzzled that the values on screen still looked wrong after clicking on AUTOCROP for mod4.

Great job with all the new work!

[Doom9]

The "private CropValues Cropping" section seems to adjust the overcrop and mod16 values, but the controls on the form are never updated to reflect it.I think that's pretty much desired behavior.. you don't have to keep the actual crop values somewhere deeply hidden from the user and more importantly, you still give the user the ability to mess around with cropping values, and still get the mod16/mod4/whatnot on top of those values (that's something the user cannot be expected to do on his own).

[cyberbeat]

I think that's pretty much desired behavior.. you don't have to keep the actual crop values somewhere deeply hidden from the user and more importantly, you still give the user the ability to mess around with cropping values, and still get the mod16/mod4/whatnot on top of those values (that's something the user cannot be expected to do on his own).
I can see that to a certain extent, but if the user wants to have the program AUTOCROP, then it should show the correct values when that is pressed. Otherwise, if the user is making adjustments, then do nothing. Since it is putting wrong values in the controls when you press AUTOCROP, can we have it at least update during that scenario and then ignore when the user does it manually? It saves a lot of uncertainty and questions in the future for people that do not know the values look wrong, but are okay.

[Doom9]

Since it is putting wrong values in the controls when you press AUTOCROPIt's not wrong... it shows whatever is found during autocrop.. and in the script, you get to see what the script will look like. And, the entire existing code would not work if the script value was shown as the actual value.

[fight2win]

MP4 Muxer in MeGUI does not supports aac audio created by ct-aac encoder via behappy, as it is of .m4a extension...

[Sharktooth]

rename it to .aac

[FalconIA]

In AVS creator, it puts ColorMatrix before <deinterlace>.
That may produce some small horizontal lines in a few frames or partial of a frame before IVTC(TIVTC, IT or etc...)
Putting Colormatrix after <deinterlace> or adding interlaced=true(didn't test) fixed it.

http://falconia.ca/images/ColorMatrix_Before_TFM.png
http://falconia.ca/images/ColorMatrix_After_TFM.png

[Sharktooth]

I will fix it as soon as Doom9 commits his changes and they will be included in the refactor.
I've also noticed MeGUI has a bug in the Level Checking phase:
If you have an unrestricted profile with parameters out of any level restriction and switch to a profile (inside the codec config window) with level restrictions, MeGUI will pop up a messagebox telling the settings are not compatible with the selected level (even if they are) and will reset it Unrestricted.
For example, enter the codec config window and select the HQ-Slowest profile then the SA-HD-DVD profile and the msgbox will pop up... while pressing the OK button look at the Level dropdown...

[cc979]

using 0.2.3.2192 ive found a problem with audio delay, i used 1.4.8 dgindex to create a .d2v which has a delay of 48ms in the filename (rots_full_trailer_1080p MPA PID 024 DELAY 48ms.mpa) but on loading it into the audio section on megui it gets detected as 360ms - is this a known bug?