MeGUI: bug reports and feature requests [Archive] - Page 58

hello_hello

2nd January 2013, 19:11

That was my question some posts above as well. So should the new SAR setting of the AVS file always result in an aspect error of 0%? Or do we have such slight differences like in the example above?

I guess in an ideal world it should always be 0%, which I thought was originally the reason for disabling it when using anamorphic encoding..... because it should then be pretty much obsolete. Even when resizing using anamorphic encoding it shouldn't matter in theory. You should be able to take a 4:3 DVD and resize it to 9634x208 and still set the aspect ratio to 4:3 without an aspect error..

I had noticed small changes to the input aspect ratio sometimes failed to cause the aspect ratio error to change accordingly. For example an input aspect ratio of 1.83 might show the same aspect error as 1.84 (input and output resolution unchanged), but the aspect error displayed for 1.85 would be different. I figured it must be due to rounding somewhere, so hopefully the new method you're using to calculate the aspect error will fix that too.

And to me (I know you said MeGUI has always done it like this) the way MeGUI increases the height when you crop the width rather than reduce the width when resizing drives me nutty. At least now it turns red it's something of a reminder, but from a user perspective cropping 16 pixels from the side of a DVD should give consistent results. This is where my OCD for consistency kicks in.
Open a DVD for encoding. Enable cropping, crop 16 pixels from the sides, enable resizing and you've got 704x576.
Open a DVD for encoding. Enable resizing, enable cropping, crop 16 pixels from the sides and you've got 720x590.
And my favourite:
Open a DVD for encoding. Enable cropping, crop 16 pixels from the sides and you've got 704x576. Enable "resize to mod" anamorphic encoding and you've got 704x576. Disable "resize to mod" anamorphic encoding then enable it again and you've got 720x590. Switch to "encode non mod16" and you're back to 704x576.... etc. etc.
Yoda adjusts the resolution the same way when you let it automatically resize though so maybe there's a reason for it.

Have you compared MeGUI's results with Yoda yourself? MeGUI has always been a little "out" compared to Yoda (only around 0.05%), and it's that tiny amount which seems to cause aspect errors to be displayed when there shouldn't be any. Given you've changed the way it's calculated though, maybe the problem's now solved.

Thanks.

Please try 2267

I guess I'm posting too slow. I'll be downloading the latest version shortly.

Zathor

2nd January 2013, 19:27

I guess I'm posting too slow. I'll be downloading the latest version shortly.

:p

In theory both calculations should be 100% accurate right now. The display of the error has been corrected which was off by a pixel here and there and also the DAR calculation of anamorphic encodings has been improved. Previously the fraction has been limited to x/100 - now it is x/1000 which should present way better results. In my tests at least everything had an error of 0%.

EDIT: I now had some values with an AR error of 0.000x% using an DAR of 1294:965. I can improve that even more but then we have fractions in the x:10000 area and in my opinion the error is small enough so a change is not necessary.

hello_hello

2nd January 2013, 19:42

and also the DAR calculation of anamorphic encodings has been improved. Previously the fraction has been limited to x/100 - now it is x/1000 which should present way better results. In my tests at least everything had an error of 0%.

Ahhhhh.... I think a few days ago I mentioned anamorphic encodes sometimes seemed a pixel or two off compared to the source (when I thought maybe that might be contributing to the aspect error error). Not enough to worrying about it, but at least it's nice to know I probably wasn't imagining it. :)

Cheers.

hello_hello

2nd January 2013, 20:38

Well MeGUI 2267, and as luck would have it my first test crop still produced a 0.00007% aspect error using any of the anamorphic encoding options. PAL 4:3 DVD, 8 pixels cropped from width and 8 pixels cropped from height. Adjusting the cropping either produces a 0%, 0.00007%, or 0.00008% aspect error.

MeGUI doesn't display the aspect error to as many decimal places as Yoda so it's hard to tell, and I'm really sleepy at the moment so don't have the energy to work out how to calculate it correctly myself, but even now that MeGUI uses more exact aspect ratios, it doesn't always quite agree with Yoda, and it seems when it doesn't agree is when it also displays an anamorphic aspect error. When it agrees, it doesn't.

My above example (8 pixels from width and height) produces a 1424:1065 aspect ratio from Yoda, and 1305:976 from MeGUI. So Yoda: 1.337089202. MeGUI 1.337090164
Now I think the difference between the two is also the 0.00007% aspect error MeGUI is displaying when using anamorphic encoding, but don't hold me to that.... I'm too tired to think.

However, if I change the cropping to 6 pixels width, 8 pixels height..... MeGUI 476:355, Yoda 476:355, MeGUI zero aspect error.
4 pixels width, 8 pixels height.... MeGUI 1233:917, Yoda 1432:1065, MeGUI aspect error 0.00008%.

I suspect MeGUI is still a little over-enthusiastic with the rounding somewhere..... :)
It appears the aspect error calculation might be correct but the aspect ratio on which it's based isn't always exact.

Is this driving you to drink yet Zathor?

Zathor

2nd January 2013, 21:57

Is this driving you to drink yet Zathor? No :cool:

As written above MeGUI will not go over the x:1000 fraction resulting in the slight differences between the two calculators. The question is if higher fractions are really necessary and if yes up to which amount? There may be fractions like 12345678912:2345678911...

Shevek

2nd January 2013, 22:03

Hi Zathor / Kurtnoise,

You are probably already aware, but, just posted here (http://forum.doom9.org/showthread.php?p=1608610#post1608610), eac3to has been updated

Zathor

2nd January 2013, 22:22

Thanks! It is now live on the development update server.

hello_hello

3rd January 2013, 01:17

No :cool:

As written above MeGUI will not go over the x:1000 fraction resulting in the slight differences between the two calculators. The question is if higher fractions are really necessary and if yes up to which amount? There may be fractions like 12345678912:2345678911...

I don't think I've ever seen yoda use more than x:"5 digit" fractions but I don't know if that means x:99999 is it's limit.

I guess the choice is really to use higher fractions, or to ensure the aspect error is fudged when using anamorphic encoding to always display 0%, or to keep letting it be honest and admit the aspect ratio is sometimes off by 0.00007%, or just disable aspect error calculations for anamorphic encoding again.....

The first option would be my first choice, probably followed by the last one, but in reality the aspect error calculation for anamorphic encoding is a little redundant if it's never going to be out by any more than just a tiny fraction of a percent. I guess it always has been in the past, probably more so than now..... but ignorance was bliss. ;)

LigH

3rd January 2013, 01:24

My physics teachers kept preaching: "Use a meaningful precision. If the first decimal doesn't mean a lot to you, there is no sense in displaying even the third."

bilditup1

3rd January 2013, 19:39

Hey guys,
I noticed when you applied my patch for mp4, the commented-out else, which ensures that both the original ogg chapters and new xml chapters are added to the mp4 file in case the iPod or iPhone device profile was selected, was removed (the else is no longer commented-out). I put it back and recompiled it myself, but is there any reason it was removed?

Zathor

3rd January 2013, 20:52

As written here and in the patch ticket on SF - I have not committed the chapter part because I do not know if this breaks compatibility. It is up to Kurtnoise to commit this part.

hello_hello

4th January 2013, 11:10

Well my previous resizing of a 4:3 DVD to 640x480 after cropping, now displays a zero aspect error as it should. And for a 4:3 DVD at least, MeGUI seems to agree with Yoda exactly as far as aspect ratios go when cropping. A square pixel source however....... (MeGUI 2260).

Resizing a 720p video (1280x544) to standard definition (square pixels).

(544/1280)*720=306. Zero aspect error. Yoda acquiesces. MeGUI displays a 0.0250% aspect error.

Switching to anamorphic encoding still reveals a slight aspect error in the display aspect ratio MeGUI adds to the script, although it now displays a zero aspect error.

AR(1280/544) = 2.3529411764705882352941176470588
Yoda (40:17) = 2.3529411764705882352941176470588
MeGUI (2353 : 1000) = 2.353

I know we're well into "what does it matter" territory there, but is it just that MeGUI rounds it's initial aspect ratio calculation too much before it calculates the rest?

The only other little quirk I noticed is when using anamorphic encoding with the acceptable aspect error set to 0%, even though MeGUI always displays a 0% aspect error now, the 0% it displays sometimes changes from black to red to black to red etc as you crop/resize. Well it didn't appear to do so when I opened a 4:3 DVD, but it definitely does when opening the 1280x544 video I referred to above.

Cheers.

Zathor

4th January 2013, 11:49

A square pixel source however....... (MeGUI 2260).
Just to be sure - you wanted to write 2268, correct? Or are you really using 2260?

Resizing a 720p video (1280x544) to standard definition (square pixels).
(544/1280)*720=306. Zero aspect error. Yoda acquiesces. MeGUI displays a 0.0250% aspect error.
For me using MeGUI 2268 it is also 0%. If you are also using 2268 please describe in detail how to reproduce this.
EDIT: It may be related to your input file. If MediaInfo does not report the correct input DAR the result of the calculations may be wrong. I tested with an AVS script where MediaInfo does not calculate the DAR.

Switching to anamorphic encoding still reveals a slight aspect error in the display aspect ratio MeGUI adds to the script, although it now displays a zero aspect error.

AR(1280/544) = 2.3529411764705882352941176470588
Yoda (40:17) = 2.3529411764705882352941176470588
MeGUI (2353 : 1000) = 2.353

For me using MeGUI 2268 it is also 40:17

The only other little quirk I noticed is when using anamorphic encoding with the acceptable aspect error set to 0%, even though MeGUI always displays a 0% aspect error now, the 0% it displays sometimes changes from black to red to black to red etc as you crop/resize. Well it didn't appear to do so when I opened a 4:3 DVD, but it definitely does when opening the 1280x544 video I referred to above.
Correct - that may happen if the value is not 0% but the all shown digits are 0. That is easy to fix but I will not release commit only this - I wait for other things to change.

Once again thank you very much for your feedback!

hello_hello

4th January 2013, 12:10

Just to be sure - you wanted to write 2268, correct? Or are you really using 2260?

Sorry, I'm a little dyslexic with numbers. 2268 is what I should have typed.

hello_hello

4th January 2013, 13:34

Well you got me wondering if I was having a stupid, so I double checked.

Okay..... I'm an idiot. Stupid poster of the day award for me. Well not completely..... I was only 50% wrong.
So after trying the same file on a second PC and getting different results the penny finally dropped and I realised MeGUI had the acceptable aspect error set to 1% on this PC and 0% on the other. Doh!

Now they're both behaving the same way it seems it's somehow tied to the acceptable aspect error setting. I just opened a few different 720p files via DirectShow (different heights) and....

My original 1280x544 file:
1% acceptable aspect error, small aspect error resizing to 1280x544, same anamorphic aspect error, script 40:17
0% acceptable aspect error, small aspect error resizing to 1280x544, zero anamorphic aspect error, script 2535:1000

1% acceptable aspect error, 1280x720 input file, small aspect error resizing to 1280x720, same small anamorphic aspect error, script 16:9
0% acceptable aspect error, 1280x720 input file, small aspect error resizing to 1280x720, zero anamorphic aspect error, script 889:500

1% acceptable aspect error, 1280x534 input file, zero aspect error resizing to 1280x534, small anamorphic aspect error, script 163:60
0% acceptable aspect error, 1280x534 input file, zero aspect error resizing to 1280x534, zero anamorphic aspect error, script 2397:1000

One more try:
1% acceptable aspect error, 1280x690 input file, small aspect error resizing to 1280x690, small anamorphic aspect error, script 128:69
0% acceptable aspect error, 1280x690 input file, small aspect error resizing to 1280x690, zero anamorphic aspect error, script 371:200

Am I going mad??

Kurtnoise

4th January 2013, 13:36

I noticed when you applied my patch for mp4, the commented-out else, which ensures that both the original ogg chapters and new xml chapters are added to the mp4 file in case the iPod or iPhone device profile was selected, was removed (the else is no longer commented-out). I put it back and recompiled it myself, but is there any reason it was removed?
Not tested yet on my part but did you try w/ iTunes or any apple Devices ? Does it work w/ any directshow players (like mpc-hc + LAV splitter) ?

I don't see any reason why that breaks compatibility but who knows...Only cons seems to be the reductant information.

@Zathor : care to update mp4box (http://gpac.wp.mines-telecom.fr/downloads/gpac-nightly-builds/) ? There is also qaac 2.10 (http://sites.google.com/site/qaacpage/cabinet) available...:cool:

Zathor

4th January 2013, 14:36

Am I going mad??
No ;) It is because of:
2268 [AVS Script Creator] use very high accuracy for anamorphic encodings if acceptable aspect error is set to 0%

@Zathor : care to update mp4box (http://gpac.wp.mines-telecom.fr/downloads/gpac-nightly-builds/) ? There is also qaac 2.10 (http://sites.google.com/site/qaacpage/cabinet) available...:cool:
No problem for qaac - I am not sure about mp4box as we had some major problem with some older builds ~2 year ago. But hey, let's see :)
EDIT: done (including a few quick tests with the new mp4box)

hello_hello

4th January 2013, 15:07

No ;) It is because of:
2268 [AVS Script Creator] use very high accuracy for anamorphic encodings if acceptable aspect error is set to 0%

But if my results are anything to go by that's not what it's always doing. In fact setting it to zero seems to reduce the accuracy of anamorphic aspect ratios. Unless I am going mad, or missing something.....

The most obvious example is the 1280x720 video I tried. With the acceptable aspect error set to 1% it's more accurate than 0%.
Without cropping, the acceptable aspect error setting should have no effect on aspect ratio/error because there isn't one, yet at 1% MeGUI uses 16:9, at 0% it uses 899:500 for a 1280x720 video. That's the confusion I was having with the original 1280x544 video I tried. What I don't understand is why the aspect error being displayed doesn't always correspond, and if you look at my examples there's no resizing involved, it was just enabled, so once again there should never be an aspect error, anamorphic or not, regardless of the acceptable aspect error setting.
The only video I've opened so far where everything seems to work as expected is a 4:3 DVD. Anything with square pixels seems problematic, and I even tried some 516x570 4:3 files I have. Same problem there. Zero acceptable aspect error causes MeGUI to add 1333:1000 to the script. Using 1% it's 4:3.

On that subject.....
Should the acceptable aspect error setting still work as it always did? At the moment a zero setting gets MeGUI to more exactly calculate the anamorphic aspect ratio etc (at least in theory), but that kind of makes it more of a "how accurately should MeGUI do the math" setting rather than a "how much can MeGUI fudge the aspect ratio" setting. Maybe it's original purpose has gotten a bit lost during the changes?

For instance given the "acceptable aspect error" name, you'd assume you can open a 4:3 DVD with it set to 3%, and happily crop away while maintaining the original 4:3 anamorphic aspect ratio until the aspect error exceeds 3%. Logically, I guess MeGUI would only adjust the aspect ratio in increments of 3%. Same when resizing to square pixels with "suggest resolution" enabled too... I guess..... maybe. I didn't use it much that way but it's how it seemed to work previously when using anamorphic encoding. Now you can set it to 2 or 3% but it seems if you want 4:3 you've got to crop to 4:3. No more cranking it up a bit to crop a couple of pixels without changing the aspect ratio. In fact playing with the acceptable aspect error I'm not sure I can see the difference between setting it at 1% or setting it a 5% when cropping my 4:3 DVD. Either way, cropping 2 pixels from the height changes the aspect ratio by the same amount.

Just some more thoughts.....

Zathor

4th January 2013, 16:30

The most obvious example is the 1280x720 video I tried. With the acceptable aspect error set to 1% it's more accurate than 0%. I am sorry but I cannot reproduce it. I open a plain AVS script with 1280x720 and it doesn't matter if 1 or 0% accurarcy is enabled.

At the moment a zero setting gets MeGUI to more exactly calculate the anamorphic aspect ratio etc (at least in theory), but that kind of makes it more of a "how accurately should MeGUI do the math" setting rather than a "how much can MeGUI fudge the aspect ratio" setting. Maybe it's original purpose has gotten a bit lost during the changes?
Yes, that's correct. It will be reintroduced in the next build.
EDIT: Please try the build in my next post.

Kurtnoise

4th January 2013, 16:34

I am not sure about mp4box as we had some major problem with some older builds ~2 year ago.
which were ?

EDIT: done (including a few quick tests with the new mp4box)
Does it still have the -psp switch ? Forgot to check this...:o

Zathor

4th January 2013, 16:38

@hello_hello: Please try this build http://www.mediafire.com/?fpdvbtjbq44eh2m

which were?
I believe sync problems.

Does it still have the -psp switch ? Forgot to check this...:o
Me too :( It does not have the switch anymore... Is this switch still needed or should we remove it from MeGUI?

Kurtnoise

4th January 2013, 16:39

PSP is still there as device, though I'm not sure that it's still used...I'll put my own compile online then.

TSoft

4th January 2013, 17:42

After updated MP4box to last version I have this error:

-[Error] Log for job5 (mux, File.264 -> File.mp4)
--[Information] [04/01/2013 17:28:47] Started handling job
--[Information] [04/01/2013 17:28:47] Preprocessing
--[Information] [04/01/2013 17:28:47] MediaInfo
---[Information] File: C:\Users\root\Desktop\Rip\boap0m5d.td5\File.264
---[Information] General
----[Information] Format: AVC
----[Information] FormatString: AVC
----[Information] FileSize: 223872845
----[Information] PlayTime:
---[Information] Video
----[Information] ID:
----[Information] StreamOrder:
----[Information] Width: 480
----[Information] Height: 256
----[Information] FrameCount:
----[Information] FrameRate: 23.976
----[Information] FrameRateOriginal:
----[Information] FrameRateMode:
----[Information] ScanType: Progressive
----[Information] Codec: AVC
----[Information] CodecString: AVC
----[Information] Format: AVC
----[Information] AspectRatio: 1.875
----[Information] AspectRatioString: 1.85:1
----[Information] Delay:
----[Information] Title:
----[Information] Language:
----[Information] LanguageString:
----[Information] Default:
----[Information] DefaultString:
----[Information] Forced:
----[Information] ForcedString:
--[Information] [04/01/2013 17:28:47] MediaInfo
---[Information] File: C:\Users\root\Desktop\Rip\boap0m5d.td5\File - [1] Italian_audio.m4a
---[Information] General
----[Information] Format: MPEG-4
----[Information] FormatString: MPEG-4
----[Information] FileSize: 36284764
----[Information] PlayTime: 01:37:32.928
---[Information] Audio
----[Information] ID: 1
----[Information] StreamOrder: 0
----[Information] Format: AAC
----[Information] FormatProfile: LC
----[Information] FormatSettingsSBR: No (Explicit)
----[Information] FormatSettingsPS:
----[Information] SamplingRate: 48000
----[Information] SamplingRateString: 48.0 KHz
----[Information] Channels: 2
----[Information] ChannelsString: 2 channels
----[Information] ChannelPositionsString2: 2/0/0
----[Information] BitRateMode: VBR
----[Information] Delay: 0
----[Information] Title:
----[Information] Language:
----[Information] LanguageString:
----[Information] Default:
----[Information] DefaultString:
----[Information] Forced:
----[Information] ForcedString:
--[Information] [04/01/2013 17:28:47] Job commandline: "C:\Program Files (x86)\MeGUI_2153_x86\tools\mp4box\mp4box.exe" -add "C:\Users\root\Desktop\Rip\boap0m5d.td5\File.264#trackID=1:fps=23.976" -add "C:\Users\root\Desktop\Rip\boap0m5d.td5\File - [1] Italian_audio.m4a#trackID=1:lang=it:group=1" -chap "C:\Users\root\Desktop\Rip\boap0m5d.td5\File.mkv - Chapter Information.txt" -tmp "C:\\Users\\root\\Desktop\\Rip" -new "C:\Users\root\Desktop\Rip\File.mp4"
--[Error] [04/01/2013 17:28:47] Error starting job
---[Error] [04/01/2013 17:28:47] Exception message: starting job failed with error 'Unknown error (0x36b1)'
---[Error] [04/01/2013 17:28:47] Stacktrace: in MeGUI.core.gui.JobWorker.startEncoding(TaggedJob job)
---[Error] [04/01/2013 17:28:47] Inner exception: null

I used OneClick, usually I have an older MP4Box, but today I wanted to try the update...

hello_hello

4th January 2013, 20:08

@hello_hello: Please try this build http://www.mediafire.com/?fpdvbtjbq44eh2m

Same deal. It's not an XP thing or a dot net crap thing is it? I think both PCs are running dot net version 4 but I'd have to check the other one.

Just so you know I'm not going nutty though, or maybe so you can point out why I am...... same file both times, same PC, only I'm pretty sure they're both wrong now. Shouldn't it be 40:17?

Acceptable aspect error set to 0%

http://i10.photobucket.com/albums/a142/dashpb1/0_zpsc3649fd3.gif

Acceptable aspect error set to 1%

http://i10.photobucket.com/albums/a142/dashpb1/1-2_zpsb25c2ce2.gif

PS Yes I just switched back to the previous 2268 build and for a 1% acceptable aspect error it does use 40:17 for the anamorphic aspect ratio.

Is it possible there's only a certain number of times a person's brain can deal with typing "acceptable aspect error" in forum posts? :)

Zathor

4th January 2013, 21:11

I will have a look at that tomorrow. At a quick glance I notice that the input DAR is detected by MediaInfo as 2.353 and therefore 2353:1000 is better than 47:20 (or 40:17).

MOS-Marauder

4th January 2013, 22:12

Hi Folks.

Well from Time to Time i got problems with MeGui encoding to XVID 2 Pass.

Its performing Pass1 perfectly with approx 450 FPS encode speed and then it crashes starting Pass2. (Log below)

That can this be ? Its most time only on Xvid with 640x272 Resolution.

Mara

-[NoImage] LoadPlugin("D:\Programme\megui-Dev-031-1061\tools\dgindexnv\DGDecodeNV.dll")
---[NoImage] DGSource("O:\Encode\US-Encode\NOW_IS_GOOD\nowisgood.dgi",fieldop=1, resize_w=640, resize_h=272)
---[NoImage] #deinterlace
---[NoImage] #crop
---[NoImage] #resize
---[NoImage] #denoise
--[Information] [04.01.2013 21:45:19] Job commandline: "D:\Programme\megui-Dev-031-1061\tools\xvid_encraw\xvid_encraw.exe" -i "O:\Encode\US-Encode\NOW_IS_GOOD\nowisgood.avs" -pass1 "O:\Encode\US-Encode\NOW_IS_GOOD\nowisgood.stats" -bitrate 803 -kboost 100 -chigh 30 -clow 15 -turbo -max_key_interval 19 -nopacked -vhqmode 4 -imin 1 -pmin 1 -max_bframes 1 -bvhq -bquant_ratio 162 -bquant_offset 0 -bmin 1 -par 1 -threads 8
--[Information] [04.01.2013 21:45:19] Encoding started
--[Information] [04.01.2013 21:50:41] Standard output stream
---[NoImage] xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003
---[NoImage] Tot: enctime(ms) =318045.00, length(bytes) = 954051050
---[NoImage] Avg: enctime(ms) = 2.15, fps = 465.66, length(bytes) = 6441
---[NoImage] I frames: 8289 frames, size = 23064/ 191178992, quants = 2 / 2.00 / 2
---[NoImage] P frames: 70674 frames, size = 8680/ 613474682, quants = 2 / 2.00 / 2
---[NoImage] B frames: 69137 frames, size = 2160/ 149397369, quants = 3 / 3.00 / 3
---[NoImage] N frames: 1 frames, size = 7/ 7
--[Information] [04.01.2013 21:50:41] Standard error stream
---[NoImage] Trying to retrieve width and height from input header
---[NoImage] xvid [info]: Avisynth detected
---[NoImage] xvid [info]: Input colorspace is YV12
---[NoImage] xvid [info]: Input is 640 x 272, 23.976fps (24000/1001), starting from frame 0
---[NoImage] xvid [info]: Number of frames to encode: 148101, Bitrate = 803kbps
---[NoImage] xvid [info]: xvidcore build version: xvid-1.2.2
---[NoImage] xvid [info]: Bitstream version: 1.2.2
---[NoImage] xvid [info]: Detected CPU flags: ASM MMX MMXEXT SSE SSE2 TSC
---[NoImage] xvid [info]: Detected cpus = 8, threads requested = 7, threads in use = 7
---[NoImage] xvid [info]: Threaded input reading active
--[Information] [04.01.2013 21:50:41] Postprocessing
---[Information] Deleting intermediate files
--[Information] [04.01.2013 21:50:41] Job completed
-[Error] Log for job3 (video, nowisgood.avs -> nowisgood.avi)
--[Information] [04.01.2013 21:50:41] Started handling job
--[Information] [04.01.2013 21:50:41] Preprocessing
--[Information] [04.01.2013 21:50:41] Avisynth input script
---[NoImage] LoadPlugin("D:\Programme\megui-Dev-031-1061\tools\dgindexnv\DGDecodeNV.dll")
---[NoImage] DGSource("O:\Encode\US-Encode\NOW_IS_GOOD\nowisgood.dgi",fieldop=1, resize_w=640, resize_h=272)
---[NoImage] #deinterlace
---[NoImage] #crop
---[NoImage] #resize
---[NoImage] #denoise
--[Information] [04.01.2013 21:50:43] Job commandline: "D:\Programme\megui-Dev-031-1061\tools\xvid_encraw\xvid_encraw.exe" -i "O:\Encode\US-Encode\NOW_IS_GOOD\nowisgood.avs" -pass2 "O:\Encode\US-Encode\NOW_IS_GOOD\nowisgood.stats" -bitrate 803 -kboost 100 -chigh 30 -clow 15 -turbo -max_key_interval 19 -nopacked -vhqmode 4 -imin 1 -pmin 1 -max_bframes 1 -bvhq -bquant_ratio 162 -bquant_offset 0 -bmin 1 -par 1 -threads 8 -avi "O:\Encode\US-Encode\NOW_IS_GOOD\nowisgood.avi"
--[Information] [04.01.2013 21:50:43] Encoding started
--[Error] [04.01.2013 21:50:48] Process exits with error: 0xC0000409 STATUS_STACK_BUFFER_OVERRUN (-1073740791)
--[Information] [04.01.2013 21:50:48] Standard output stream: xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003
--[Information] [04.01.2013 21:50:48] Standard error stream
--[Information] [04.01.2013 21:50:48] Job completed

Kurtnoise

5th January 2013, 10:13

After updated MP4box to last version I have this error:

Retry with the last version uploaded today (dev server)...If it's still there, you may try to change your path (boap0m5d.td5 might be the problem).

Zathor

5th January 2013, 10:46

Retry with the last version uploaded today (dev server)...If it's still there, you may try to change your path (boap0m5d.td5 might be the problem).
boap0m5d.td5 seems to be the automatic generated path for OneClick jobs. If this is the problem the paths must be generated in another way. But let's wait for the response.

TSoft

5th January 2013, 12:56

boap0m5d.td5 seems to be the automatic generated path for OneClick jobs. If this is the problem the paths must be generated in another way. But let's wait for the response.

Now it seems to work :thanks:

Overdrive80

5th January 2013, 15:25

Hi Zathor, to update eac3to, megui dont remove some .dll that wont already use.

avcodec.dll
avutil-50.dll

Maybe could create conflicts?

EDIT: Maybe would be useful add to megui application to enviroment variables

@echo off
set Path=%Path%;C:\Program Files (x86)\MeGUI

rem echo %Path%

rem pause

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v Path /t REG_EXPAND_SZ /d "%Path%" /f

Zathor

5th January 2013, 16:25

to update eac3to, megui dont remove some .dll that wont already use.
avcodec.dll
avutil-50.dll
Maybe could create conflicts?
Maybe - but with the current implementation of the MeGUI updater it is not possible to remove files which are not used anymore. This is only possible when the backup behavior is changed so that the backup files are not created in the program folders anymore. Also there are some files like the license file of DGIndexNV which should never be removed.

Maybe would be useful add to megui application to environment variables
Why? And I fear for this action admin access is needed which MeGUI does not have.

Overdrive80

5th January 2013, 21:37

Hi again, I got a error encoding audio files to flac. I think that megui not support oriental language, not?

log -> https://dl.dropbox.com/u/19135067/log.log

Could be possible add option to decode audio files to wav???

Thanks

EDIT: If I edit project, on windows "AudioEncodingWindows" I see a two bottons overlap.

http://s13.postimage.org/96wrxzsab/Captura.jpg (http://postimage.org/image/96wrxzsab/)

Pulp Catalyst

6th January 2013, 08:59

2268 cropping seems a bit off, MeGUI reported a error of -208%, the cropping value for the bottom bar was found 42, however it didn't do the top bar, so it was set to 0,

the output obviously had a black bar running along top... i put in manual 42 for the top bar crop, the error went to 0%... it happened on two out of 7 episodes of midsomer murders series (and it was reproducible)

Zathor

6th January 2013, 12:13

Can you please provide more details? E.g. can you upload a sample file?

Zathor

6th January 2013, 16:03

Is it possible there's only a certain number of times a person's brain can deal with typing "acceptable aspect error" in forum posts? :)
;)

Please try:

2272 [AVS Script Creator] moved "acceptable aspect error" setting into the AviSynth profile (1% by default)
[AVS Script Creator] improved AR chooser
[MediaInfo] improved aspect ratio detection
2269 [MP4 Muxer] restrict "group=1" to the Apple Devices regarding Audio streams

It should be better now as the MediaInfo result will be used to find the correct DAR - but it is not the only source anymore.

stax76

6th January 2013, 16:08

My calculations were similar to GordianKnot in the beginning but were improved constantly for about 8 years,
after a quick research I agree with rel. error = abs. error / real value and changed the code accordingly.

tebasuna51

6th January 2013, 16:23

after a quick research I agree with rel. error = abs. error / real value and changed the code accordingly.

You don't need use absolute_error, with signed_error you preserve the sign in the relative_error:

relative_error_signed = signed_error / real_value
relative_error_signed = (approximated_value - real_value) / real_value
relative_error_signed = (approximated_value / real_value) - 1

stax76

6th January 2013, 17:14

I've meant approximated_value, it was just called abs. error on a german page:

http://www.frustfrei-lernen.de/mathematik/relativer-fehler.html

The code should be fine now however, it returns the same value as discussed before:

((p.TargetWidth / p.TargetHeight) / Calc.GetTargetDAR) * 100 - 100

hello_hello

6th January 2013, 21:36

Well guys, I've given version 2272 a bit of a spin and it looks like my days of typing "acceptable aspect error" in forum posts might finally be over.And just as I'd thought to add a keyboard shortcut to my macro program so to save me the trouble of typing it. ;)
Thanks for the hard work again!

The only thoughts I have on the resizing topic at the moment (aside from the resizing up when cropping) is when opening a video it'd be nice to have the output aspect ratio displayer under the resize area. So with anamorphic encoding there's no need to keep bouncing back and forth between the I/O and script tabs if you're wanting a nice 16:9 output aspect ratio etc, although it'd probably be better if it wasn't displayed as a fraction (unless both would be easy) because then as you crop it's simple to tell if you're cropping in the right direction.
And if you wanted to be really fancy the original input dimensions could be displayed above the cropping area with the input dimensions after cropping displayed below.

Thanks!

hello_hello

6th January 2013, 22:01

On a topic unrelated to aspect ratios for a change....

I was thinking how nice it'd be if MeGUI could become the first encoder GUI on the planet (as far as I know) to correctly convert the colors when converting from HD to SD as very few people seem to know they should do it and it's one of my pet peeves. Maybe implementing automatic conversion according to resolution might be a bit tricky, but having a check box in the script creator might get people using it. Just a method to tell MeGUI you're converting from HD to SD would do. If the box is checked MeGUI could automatically add the appropriate color conversion to the script. ie ColorMatrix(mode="Rec.709->Rec.601", clamp=0). Doing it that way it'd be independent of the method used to open the video.
Given upscaling is far less common than downscaling it'd probably not be necessary for MeGUI to be able to convert the colors in the opposite direction, although I guess a checkbox to tell MeGUI you need to convert the colors and a dropdown box next to it to specify the direction you're going might be a nice touch.

If MeGUI's current Color Correction option is checked it'd probably be nice to tweak that too. Based on my understanding of the way the colormatrix thingy gets it's info from dgdecode and the colorimetry dgdecode reports if the stream doesn't contain colorimetry info, it'd probably convert the colors correctly when converting HD mpeg2 to SD as it is, but I assume it'd still convert the colors when converting HD mpeg2 to HD if MeGUI's color correction option is checked, which would be incorrect.
So maybe if there was a method implemented whereby you could tell MeGUI you're converting from HD to SD, with that option checked the Color Correction currently being added to the script for mpeg2 video could be left as it is, but with it unchecked it could be omitted from the script so no HD to HD color conversion takes place. I can't imagine it'd matter in the slightest if it's not added to the script when converting DVDs as it's pretty much redundant anyway.

Just some thoughts.....

Zathor

6th January 2013, 22:59

Thanks for the hard work again!
Thank you very much for your testing!

The only thoughts I have on the resizing topic at the moment is when opening a video it'd be nice to have the output aspect ratio displayer under the resize area. So with anamorphic encoding there's no need to keep bouncing back and forth between the I/O and script tabs if you're wanting a nice 16:9 output aspect ratio etc, although it'd probably be better if it wasn't displayed as a fraction (unless both would be easy) because then as you crop it's simple to tell if you're cropping in the right direction.
Yes, will be added - but it may take a while. I need to find a place to show those values.

Just a method to tell MeGUI you're converting from HD to SD would do. If the box is checked MeGUI could automatically add the appropriate color conversion to the script. ie ColorMatrix(mode="Rec.709->Rec.601", clamp=0)
Also a good idea. Maybe in the first place I will only add a option to convert between those values.

Overdrive80

7th January 2013, 00:21

@Zathor Do you look at my post?

http://forum.doom9.org/showthread.php?p=1609177#post1609177

Zathor

7th January 2013, 00:52

@Zathor Do you look at my post?

http://forum.doom9.org/showthread.php?p=1609177#post1609177
Sorry, I missed it. AviSynth does not support unicode - or at least some/most plugins do not support it.

Overdrive80

7th January 2013, 02:17

Sorry, I missed it. AviSynth does not support unicode - or at least some/most plugins do not support it.

Not only it, its for buttons overlaps. And support for decoding to wav format.

Betsy25

7th January 2013, 05:26

Hi,

I remember this is not the first time I got this shop-stopping error, it happens every time after the audio per-processing, when the actual audio-encoding starts. This time it happened with QAAC, but I remember it happening when encoding a 6-channel audio file with NeroEncoder also.

Exception message: Abnormal encoder termination 2
Inner exception: null

Logfile : https://dl.dropbox.com/s/z67vkhqc6kpwe3f/Megui-error.log

Kurtnoise

7th January 2013, 06:46

It's pretty clear to me...:rolleyes:

CoreAudioToolbox.dll: The specified module could not be found.

Since 1.00, qaac directly uses CoreAudioToolbox.dll. Therefore, QuickTime installation is no more required. However, Apple Application Support is required.

Apple Application Support is included in recent Apple products such as iTunes, QuickTime, or Safari. Therefore, you can install it via installation of one of these products. However, Apple Application Support itself is actually independently packaged as AppleApplicationSupport.msi. If you want, you can extract it from installer exe file using 7-zip archiver, and directly run AppleApplicationSupport.msi. This way, you can install only necessary modules to run qaac. No iTunes, QuickTime, or Safari needed.

You need recent Apple Application Support package (QuickTime >= 7.7.1, or iTunes >= 10.5). With older version, at least AAC-HE encoder is not usable, and there might be some other problems. Of course, the latest version is desirable.

hello_hello

7th January 2013, 10:11

I had a dream......

In my dream the AVS cutter was integrated into the AVS Script Creator. It had been added to the script creator as an additional tab.
And in my dream (probably because I've been doing this myself when encoding some old video recently) the interaction between the cutter and the script creator was quite clever. If I used the AVS cutter to encode three sections of video, then not only was I editing while encoding, but by selecting one of the cuts under the AVS Cutter tab, the Script Creator would apply any subsequent changes to just that particular section of video. Of course MeGUI automatically applied the same global resizing to each section and the anamorphic aspect ratio was set according to the first section of video, but I could apply different types of noise filtering, crop each differently (and the I/O tab would calculate the aspect error for the selected section individually :)) and I could easily add additional filters to each section by manually adding them to the script.

Just before I awoke, I recall saving the script and going back to MeGUI's main window. I noticed there was now an encoder option to simply copy the audio. I wondered why it was there at first, but then I realised with the Cuts file loaded in the audio section, and when selecting "copy" as the audio encoding method, MeGUI was automatically using the Audio Cutter to split the audio according to my cuts, rejoin each section as a single file, then mux it and the encoded video together when it'd finished.
I recall opening the script MeGUI created for me, but as I opened it my dream ended so I only caught a blurred glimpse, however I'm pretty sure it looked like this:

# Set DAR in encoder to 4 : 3. The following line is for automatic signalling
global MeGUI_darx = 4
global MeGUI_dary = 3
LoadPlugin("C:\Program Files\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("E:\video.d2v")
Load_Stdcall_Plugin("C:\Program Files\MeGUI\tools\yadif\yadif.dll")
Yadif(order=1)
LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_plugin\FluxSmooth.dll")

__film = last
__t0 = __film.trim(0, 13912).FluxSmoothST(7,7).crop(10, 8, -10, -8).Spline36Resize(704,560)
__t1 = __film.trim(24768, 45004).crop(2, 8, -8, -0).Spline36Resize(704,560)
__t2 = __film.trim(59443, 72618).crop(26, 20, -4, -4).Spline36Resize(704,560)
__t0 ++ __t1 ++ __t2

No need to tell me I'm dreaming..... but I still think adding the AVS Cutter as a fourth tab in the Script Creator would be a good idea, along with MeGUI being able to automatically split the original audio rather than re-encode it.