MeGUI: General Questions and Troubleshooting Thread

[Inspector.Gadget]

LeXXuz, he was referring to "dedicated" as in "purpose-built": Nicaudio is better than DSS in this case. No money necessary.

[MrVideo]

I believe in Megui (or more specifically in x264) SAR means Sample Aspect Ratio, so perhaps your entire post is based on wrong assumption. I'm sorry if I did not clearly stated what I mean by SAR.

I've done some Googling to track down all these damn definitions. So, hopefully I have a better handle on it.

When I say I encode 16:9 NTSC DVD I mean 'I take a ripped DVD, run it through dgindex, create avs file and feed it to x264. It's not like I encode something --to-- DVD and than talke that and encode with MeGUI'. Again, sorry if that wasn't clear.

Then why didn't you say you were using the content of a ripped DVD? :D

I think that has been beaten to death many times, cropping does not change Sample Aspect Ratio.

After finding that formula, which I didn't have before and the wrong definition of SAR, I agree.

Cool. Where exactly do I do that in MeGui?

I was thinking of the scripts that I have written to automate conversion of MPEG-2 promos into H.264 versions. I have no idea how to change the command line that MeGUI ultimately uses to do the encoding. I don't even know how to append to a MeGUI command. Sorry about the major brainfart there.

So could someone knowledgeable comment on why MeGUI calculates those starnge SAR values?

That is indeed a great question that Sharktooth should be answering.

Sorry about going down the wrong path. I certainly learned something from this.

[jmnk]

I've done some Googling to track down all these damn definitions. So, hopefully I have a better handle on it.



Then why didn't you say you were using the content of a ripped DVD? :D



After finding that formula, which I didn't have before and the wrong definition of SAR, I agree.



Oh crap, I was thinking of the scripts that I have written to automate conversion of MPEG-2 promos into H.264 versions. I have no idea how to change the command line that MeGUI ultimately uses to do the encoding. I don't even know how to append to a MeGUI command. Sorry about the major brainfart there.



That is indeed a great question that Sharktooth should be answering.

Sorry about going down the wrong path. I certainly learned something from this.
@MrVideo: thanks for clarifications. We all just learn here..

[clumba]

http://s47.radikal.ru/i116/0907/e3/0c4f1f7bc12a.png

[alwa]

Hi,

since a few days, encodings done with the iPhone/iPod/iPod 5.5G profiles are not accepted by my iPod touch anymore - iTunes gives a message that the playback would not work on my device and so no transfer is being done.

That's because MeGUI currently fails to restrict the Baseline-Profile properly and doesn't deactivate the B-Frames. x264 uses by default --bframes 3 and the Baseline-Profile doesn't allow that. You can fix that for now if you add as "Custom Command Line": --bframes 0

[nurbs]

Alternatively you can add --profile baseline as a custom command line option. That should override all options that aren't baseline conform.

[Sharktooth]

a fix is coming soon.

[tehownt]

Some handheld players are quite weird regarding the supported formats and only allow h.264 playback in an .avi container with mp3 sound...
This is really wierd but can be obtained with mencoder (-ovc x264-oac mp3lame -lameopts cbr:br=128 -o video.avi). The problem with MP4-Encoder GUIs is that they will not allow (by a way of dropdown menus) to have x264 in an avi container eventhough it's a possible combination.
I know this is really uncommon but would it be hard to change the GUI so that it allows any mix of container/content even if it's not the "cleanest" combo ? Is there a way to configure MeGUI so that profiles allow this type of arrangement ?

[Sharktooth]

those handheld are crappy.
h.264 in AVI is an ABOMINATION.

[tehownt]

You are absolutely 100% right that it's an abomination, but once the disgust has worn off, it's still easier to get the community-supported encoder to do the dirty job than to get the handheld firmware changed...
Hence the "feature" request (it could come with a warning about non-standardness though) ;)

[Sharktooth]

well... i wont add AVI support for h.264 in megui.
you can just use my GUI for avc2avi: http://mirror05.x264.nl/Sharktooth/x264/utils/avc2avi_r594+gui1.2.7z

[tehownt]

Ok well thanks for the util...
Would you overcome your apprehension to the idea and accept a patch to the GIT if I were to overcome my apprehension towards C# ? ;)

[Sharktooth]

uhm... dont waste your time...
is not that hard to implement avc to avi muxing in MeGUI (once it was there...) but i dont think i will accept any patches in that regard.

[tehownt]

Hmmm, OK...
Which MeGUI rev had the avc to avi muxing ?
Was there a specific reason to have it removed from MeGui (aside from the "abominational" POV) ?

Btw thanks for the help despite the awkward request ;)

[Sharktooth]

well... i dont remember exactly what version it was... but it was removed coz it was identical to the avc2avi gui i've linked you in one of my posts.
the problem is there was no audio support and no one of us needed h.264 in avi. the point is by not supporting avi, hardware manufacturers will be forced to add support for other containers.
that's the secondary reason why we will not add avi to megui and behind that, the main reason is that avi is as old as windows 3... if not older.

[jmnk]

@jmnk: MeGUI will encode with the original AR found on the DVD (that depends on how it was authored...). if the video gets resized MeGUI will correct the AR accordingly.
If I may ask - what kind of logic MeGUI uses to detect how DVD was authored? I thought the only thing it could use is what dgindex file says - which is going to be video resolution and Display Aspect Ratio flag.

You also mentioned that MeGUI uses ITU values. So for NTSC 16:9 DVD it should be 40:33, right? Always, no matter how much I crop the video, right? Why is it than that MeGUI comes up with these 4 digit SAR values, and more often than not varying from one job to another.
Please note that these are theoretical questions - the aspect ratio of MeGUI encoded files are correct (more/less) - just wanted to know why it does not use 40:33 every single time.
Also, if we agree that ITU values should be used - should MeGUI automatically crop any 16:9 NTSC DVD input file from 720 to 704, or at least suggest that the user does it? Because if that is not done than the resulting file (assuming no cropping, no resizing, 720x480 input file resolution) plays at like 720*40/33 = 872 by 480 - which is not really ideal. Not too much of a difference to really complain, but still....
@Sharktooth. Sorry to bump this question - but could you please elaborate on why MeGUI calculates these strange 4 digit SAR when the input file is plain DVD type resolution and aspect ratio content?

[Sharktooth]

megui "reads" the SAR from the source. since not all content is from DVD, there is no "hard" limit on the SAR on megui.

[jmnk]

megui "reads" the SAR from the source. since not all content is from DVD, there is no "hard" limit on the SAR on megui.
sure, fair enough. But --if-- the input --IS-- from DVD - wouldn't it make sense to use one of those standardized SAR values?

[Sharktooth]

at a certain point, megui doesnt know if the input is from DVD or not.

[jmnk]

at a certain point, megui doesnt know if the input is from DVD or not.
Completely agree. That's why I try to limit this discussion to only those cases where avs script is created based off d2v file - so it is safe to assume it is DVD, and you know what resolution is, and what aspect ratio flag should be.
Again, this is not a huge deal, the values are 'almost' correct. Although it is a bit strange that calculated SAR values vary depending on how much I cropped from left and right side. I mean if I start with 720x480 16:9 NTSC DVD and let MeGUI calculate SAR, it will be one value when I do not crop, another when I crop 8 pixels left and 8 pixels right, another when I crop 16 pixel left and 16 pixels right, and so on. All these values do in the end result in video being more/less 16:9 DAR - but it just seems there's too much logic there. Just use SAR=40:33 for 16:9 NTSC DVD - and be done with it.
I would also think that if avs script is created off d2v file which indicates that input is from DVD, MeGUI should use 32:27 as SAR for 16:9 NTSC. Or it should tell the user to crop 8 pixels left and right so the input resolution is 704 pixels - and than SAR 40:33 will result in 16:9 DAR. As it is now 720x480 resolution flagged with MeGUI calculated SAR results in 872x480 - which is a bit too wide.
Finally, although that is really a cosmetic issue - how do I make MeGUI --not-- to use any SAR when I enter my own SAR on the command line in advanced options? As of today the command line passed to x264 would have two SAR options: one calculated by MeGUI, the other whatever I entered. I'm assuming x264 takes the far right values for a given parameter so that does not really affect anything in practice.

In other, non-DVD-input case I have no idea how MeGUI could possibly know what SAR to use at all - so I'm not even trying to address that. It would seem that the only logical choices would be:
1) pop out a box asking a user to enter desired SAR. Flexible, but perhaps too much for most of the users.
2) assume SAR 1:1

again, thanks for great tool.

[squid_80]

Assuming a source is a DVD just because a script is using a .d2v file is definitely not something you want to do.

[jmnk]

Assuming a source is a DVD just because a script is using a .d2v file is definitely not something you want to do.
fair enough. Let me make a more correct statement, although I've already stated many times my only beef is with how MeGUI deals with those sources that --are-- DVD, and that are recognizes as such by MeGUI:

"if avs script is created out of d2v file (or any other file that provides resolution and DAR) and MeGUI recognizes its 'Input DAR' as one of the common DVD types, than it should just use commonly known SAR values if no resizing is done".

Wouldn't you agree with that?

[Sharktooth]

patches are welcome

[elguaxo]

All major bugs in x264 configuration and commandline generation should be fixed by now even if some options will still be redundant...

Megui is not adding --slow-firstpass when you don't want to use Turbo on the first pass. I'm using version 0.3.1.1050.

[Sharktooth]

i know. but that's not a showstopper. implementing --slow-firstpass requires some more time.

[mavinashbabu]

Hello,

I am having problem with "x264 Unrestricted 1pass Lossless" profile while container is .MKV from a retail DVD9 that i own.



[Error] Log for job4 (video, VTS_01_1_1.avs -> VTS_01_1_1.mkv)
-[Information] [7/19/2009 2:30:14 PM] Started handling job
-[Information] [7/19/2009 2:30:14 PM] Preprocessing
-[NoImage] Job commandline: "C:\Program Files\megui\tools\x264\x264.exe" --profile high --qp 0 --ref 1 --no-mixed-refs --bframes 0 --nf --subme 1 --trellis 0 --partitions p8x8,b8x8,i4x4,p4x4 --no-8x8dct --thread-input --sar 1:1 --output "C:\VTS_01_1_1.mkv" "V:\ROCKY_SCN\VTS_01_1_1.avs"
-[Information] [7/19/2009 2:30:16 PM] Encoding started
-[Error] An error occurred: x264 [error]: high profile doesn't support lossless
-[NoImage] Standard output stream
-[NoImage] Standard error stream
-[Information] [7/19/2009 2:30:17 PM] Job completed


I had used the same profile like a week back or so without any issues.

Can i get help please :thanks:

[nurbs]

x264 has changed recently that's why you are getting the error. You need to get rid of the --profile high in your command line. I don't have megui on this computer, but I think in the first tab of the x264 configuration there is a dropdown where you can select the profile. You need to set it to Unrestriced or something like that (not baseline, main or high). If this is not available then you have to wait for megui to be changed to support it or to your encodes directly with the CLI in the meantime.

[Kurtnoise]

this has been fix in the last build but it requires an update of the preset as stated in the changelog...

[mavinashbabu]

Thanks nurbs and Kurt, able to do it now

I have chosen "autoguess" since i could not find "unrestricted" in AVC profiles, and quantizer as Lossless "checked".

I hope i did it right?

[rack04]

Since partitions p8x8,b8x8,i4x4,i8x8 are default I think the x264 command line can be cleaned up a bit.

[luckfun]

Hi I updated MeGUI to latest.
Then I cannot import any file(d2v,avi), MeGUI says that "external component has thrown an exception"

But to check my script is correct I tried whether media player can open just the following simple script.
AviSource("z:\N\x264.avi")

Unfortunately I couldn't open it.... So does anyone have somethig advice to me or should I re-install OS?

Something strange... because I just updated to latest...

Edit : Sorry but just avisynth's bugs. I uninstalled avisynth and re-installed that then it worked fine! Thank you.

[MADAJ]

hi
[Error] Log
-[Information] Versions
--[NoImage] MeGUI Version : 0.3.1.1051
--[NoImage] OS : Windows XP Professional x86 SP3 (5.1.196608.2600)
--[NoImage] Framework used : 2.0 SP1 (2.0.50727.3082)
-[Information] Hardware
--[NoImage] CPU : Intel(R) Core(TM)2 Quad CPU @ 2.40GHz
-[Error] Log for job9 (video, ENCODE.avs -> )
--[Information] [7/20/2009 5:59:14 PM] Started handling job
--[Information] [7/20/2009 5:59:14 PM] Preprocessing
--[NoImage] Job commandline: "C:\Program Files\megui\tools\x264\x264.exe" --pass 1 --bitrate 1300 --stats "C:\Documents and Settings\Owner\Desktop\ENCODE.stats" --partitions p8x8,b8x8,i4x4,i8x8 --me umh --thread-input --sar 1:1 --cqmfile "Select file..." --output NUL "C:\Documents and Settings\Owner\Desktop\ENCODE.avs"
--[Information] [7/20/2009 5:59:15 PM] Encoding started
--[Error] An error occurred: x264 [error]: can't open file 'Select file...'
--[Error] An error occurred: x264 [error]: x264_encoder_open failed
--[NoImage] Standard output stream
--[NoImage] Standard error stream: avis [info]: 1280x720 @ 23.98 fps (35367 frames)
--[Information] [7/20/2009 5:59:16 PM] Job completed


what is cqmfile ? why do I need it?

EDIT:

ah... sorry, my mistake...

[Kurtnoise]

I have chosen "autoguess" since i could not find "unrestricted" in AVC profiles, and quantizer as Lossless "checked".

I hope i did it right?
yes

Since partitions p8x8,b8x8,i4x4,i8x8 are default I think the x264 command line can be cleaned up a bit.
done

[MrVideo]

I realize that it isn't (I hope) meGUI's fault for the commandline options to x264 to drastically change.

I have a script written that directly runs the x264 program and now my scripts are broken.

To put it bluntly, that is not user friendly.

To be user friendly, at least in the Unix world, if an option is deprecated, it is not removed. A warning is displayed indicating that the option is either no longer used, or replaced by another option and lists that option. The program should not bail. In the future, say 6 months, then the option can be removed.

Give the poor user a chance to modify the scripts/programs, instead of blind siding them.

Obviously meGUI had to change as well.

Now to figure out what changed.

[Dark Shikari]

I realize that it isn't (I hope) meGUI's fault for the commandline options to x264 to drastically change.

I have a script written that directly runs the x264 program and now my scripts are broken.

To put it bluntly, that is not user friendly.

To be user friendly, at least in the Unix world, if an option is deprecated, it is not removed. A warning is displayed indicating that the option is either no longer used, or replaced by another option and lists that option. The program should not bail. In the future, say 6 months, then the option can be removed.

Give the poor user a chance to modify the scripts/programs, instead of blind siding them.

Obviously meGUI had to change as well.

Now to figure out what changed.First of all, I warned everyone a week in advance on doom9.

Second, if I didn't remove options, you would have had scripts that appeared to work--and then generated invalid output.

For example, options that previously worked on iPod would generate non-iPod-compatible video because the defaults changed.

It's better for scripts to break loudly than it is for them to break silently.

[MrVideo]

First of all, I warned everyone a week in advance on doom9.

Never assume that everyone that uses these programs are a constant reader of postings here on Doom9. With so many places to read, it is impossible to read them all. The BEST place to warn users is via the program itself, via issuing non-bailing warnings.

Second, if I didn't remove options, you would have had scripts that appeared to work--and then generated invalid output.

The ones that I've found at the moment are --progress. --no-simm and --no-psnr

The removal of --progress wasn't necessary. It sounds like that is now the default and --no-progress turns it off. A deprecation warning would have been perfect for this option, instead of bailing. The other two have to data with the options. A warning, without bailing, would have been nice with those as well. An encoding is now taking place, but I suspect that I should probably do one with meGUI and see what the options are now with the encoder, in case new ones were added.

Where did I get these options? From the log output of meGUI when doing what I wanted to do in a script and then transferring the commandline options to my script.

As mentioned, if an option is no longer being used, output a warning about the option. If the option has been completely removed, don't bail. issue a warning and continue. If the option has been replaced, issue a warning and apply the option to the new option. If the option has data to do with it, supply the data to the new option, if the data is viable. Modify it is possible and say so in the warning.

Be a little more user friendly. Not everyone is as deep into this as you are. Many of us are casual users. Really casual uses meGUI, less casual, more heavy hitter, writes scripts.

It's better for scripts to break loudly than it is for them to break silently.

They wouldn't break silently is warnings were displayed during the output, even if all warnings were listed, and it waited 5 seconds before continuing. so that the user would see them.

As mentioned, I do not know if anything new was added, but I just played back the encoded file and there is nothing blatently wrong with it, if anything.

[Guest]

Drop it, MrVideo. We don't want a debate about it here now. You missed your chance when the proposed changes were thoroughly discussed. Followup to PM please.

[Dark Shikari]

...So basically, you want us to implement a psychic algorithm that figures out if the user really wanted to encode for an iPod or not, and warns the user that his video won't work on an iPod in such a case?

ESP devices are welcome, PM me for shipping address.Never assume that everyone that uses these programs are a constant reader of postings here on Doom9. With so many places to read, it is impossible to read them all. The BEST place to warn users is via the program itself, via issuing non-bailing warnings.We expect that users who insist on using bleeding-edge x264 builds--and do so without a frontend--will at a minimum read the changelogs, particularly those that coincide with API updates.

If you don't want to do that, don't use bleeding-edge x264.

[MrVideo]

So basically, you want us to implement a psychic algorithm that figures out if the user really wanted to encode for an iPod or not, and warns the user that his video won't work on an iPod in such a case?

You missed the point. Adding new options, that my script doesn't use, won't break my encodes, as it won't use them.

The three options, is this case, were benign. Easily flagged as warnings, indicated that there were deprecated and will be removed in the future. Then ignore them and keep going. At least the job I was working on would finish. Then, I could look into what changed.

The idea is that the user would be able to continue without crashing.

We expect that users who insist on using bleeding-edge x264 builds--and do so without a frontend--will at a minimum read the changelogs, particularly those that coincide with API updates.

That still doesn't stop developers from being a little more user friendly with options that are being deprecated, especially with the three options that were removed that I happen to be using (because meGUI did before.

All I'm asking for is a little more consideration. You can be bleeding edge, but still be user friendly. I have LOTS of things to read and can't get to them all. A warning message says that "hey, I've changed, go find out why."

Now to go read the PM that was posted before your response.

[Dark Shikari]

You missed the point. Adding new options, that my script doesn't use, won't break my encodes, as it won't use them.

The three options, is this case, were benign. Easily flagged as warnings, indicated that there were deprecated and will be removed in the future. Then ignore them and keep going. At least the job I was working on would finish. Then, I could look into what changed.

The idea is that the user would be able to continue without crashing.We believe that silently giving the user output that he did not expected is worse than terminating with an error.

Furthermore, warning about deprecated options like --progress and --no-psnr does nothing to inform the user about the actual potential problem with his encoding settings.

You may disagree with the idea that failing loudly is better than failing silently, but you aren't an x264 developer, so quite honestly, I don't care, and I'm not going to bother responding to stupid posts like this anymore. If you don't like our interface decisions, feel free to write your own H.264 encoder.

[nurbs]

Adiing new options and changing the defaults might not break your encodes, but it can easily break other peoples encodes if they aim for hardware compatibility. The idea is that the user doesn't spend hours encoding a video just to find out that it won't play on his iPod or whatever in the end. Most people probably don't look at the log until encoding has finished.
I don't really get what you are complaining about. You don't seem to be using the --preset and --tune system and apart from that there haven't been any major changes. Nothing stops you from using an old version of x264 until you can change your scripts.

[MrVideo]

I don't really get what you are complaining about. You don't seem to be using the --preset and --tune system and apart from that there haven't been any major changes. Nothing stops you from using an old version of x264 until you can change your scripts.

neuron2 is probably going to kill me, but I shouldn't be the only one to "drop it."

The constructive post that I made obviously wasn't taken that way. I admit it was worded a little harshely. While I do not write x264 code, I do write code in the Unix world (my job). As such, I try to be considerate of those that use what I produce. I come from a programming world where these kinds of changes are done less harshly to the user.

If an option has changed drastically, such that there is no way to really continue with it, bail. The three that tripped up my script were benign. One even being replaced with the inverse sense. The old one could have been left there, with a warning issued.

Just because I, and others, do not develop any of the programs produced here, doesn't mean that suggestions can't be made.

I know nothing about --preset or --tune. As indicated, I obtained the information to use in my script from the meGUI logs. It isn't used there either. Encoding H.264 is a complicated process (D'Oh!). I can only go by examples from those who know. In this case, the meGUI author, and its contributors. They didn't use them, so I didn't either.

Yes, this stuff is bleeding edge. The users of this type of programming cannot possibly read every possible post here on Doom9. There are lots of things going on in people's lives. This is only a fraction of what I do. So, a suggestion gets met with hostility. So be it. It is Dark's program.

As for using previous versions, not really. meGUI automatically updates the tools that it uses. It is a great feature of meGUI. Because of that, programs like x264 are updated as they are released, or at least the next time I run meGUI.

As for users missing warning messages, it is really hard to do, considering they show up right in the location where you ran the program. I use the cygwin suite, which essentially is Unix for Windows. My scripts are Z-shell scripts, run in an Xterm. All messages appear right there. The output from x264 isn't massive, so it is hard not to miss warnings, if one looks.

Time for bed.

[Kurtnoise]

I know nothing about --preset or --tune. As indicated, I obtained the information to use in my script from the meGUI logs. It isn't used there either in public releases.
fixed for you...:D

[roozhou]

As for using previous versions, not really. meGUI automatically updates the tools that it uses. It is a great feature of meGUI. Because of that, programs like x264 are updated as they are released, or at least the next time I run meGUI.


This is not x264 developer's fault but meGUI's fault. If you do use scripts outside meGUI, you should not rely on meGUI's auto update but instead download from x264's official site and read the changelog carefully.

[Kurtnoise]

you can turn off auto-update from megui. So, stop your zealotry...

[Gabriel_Bouvigne]

While I do not write x264 code, I do write code in the Unix world (my job). As such, I try to be considerate of those that use what I produce. I come from a programming world where these kinds of changes are done less harshly to the user.
If there were any x264 releases, I would agree with you. However, here we are talking about an encoder which never had any public release. The so-called "releases" are just compilations directly done from the source code repository.
Considering that developpers have not yet released version 1.0 (and that does not imply they will), you should really not expect stable interfaces.

[Guest]

neuron2 is probably going to kill me, but I shouldn't be the only one to "drop it." You keep throwing gas on the fire after I asked you to drop it. To avoid a third 16 strike, I suggest you follow the instructions you were given.

[Dark Shikari]

If there were any x264 releases, I would agree with you. However, here we are talking about an encoder which never had any public release. The so-called "releases" are just compilations directly done from the source code repository.
Considering that developpers have not yet released version 1.0 (and that does not imply they will), you should really not expect stable interfaces.And yet despite that, we keep an explicitly defined API version number which changes when the interface changes. All you need to do in order to avoid changes is to stick to versions with the same API version number.

[Neillithan]

Error Encoding Lossless H.264

I updated MeGUI and I believe I have discovered an issue with it. I went to encode a video using the x264 lossless preset and it gave me an error that says, "High profile doesn't support lossless".

So, I did a force reinstall of the x264 presets and it still gave me the same error.

I went into the preset config for that particular preset and I noticed it was set to "High" underneath "AVC Profiles". I changed it to "Autoguess" and it allowed me to check "Lossless" afterwards. I saved the config and queued up the video to be re-encoded and it worked without error.

So, there you go, problem and a solution. lol

-Neil

[ckmox]

i got this error on using x264 of megui
An error occurred: x264 [error]: ratecontrol_init: can't open stats file
An error occurred: x264 [error]: x264_encoder_open failed

this is the log file

[Error] Log
-[Information] Versions
--[NoImage] MeGUI Version : 0.3.1.1051
--[NoImage] OS : Windows XP Professional x86 SP3 (5.1.196608.2600)
--[NoImage] Framework used : 2.0 SP1 (2.0.50727.3053)
-[Information] Hardware
--[NoImage] CPU : AMD Athlon(tm) 64 Processor 3000+
-[Information] AutoEncode job generation log
--[NoImage] Split Size : null
--[Information] Eliminating duplicate filenames
---[NoImage] Video output file: C:\Documents and Settings\Administrator\My Documents\Videos\Assorted\Gundam00Preview.264
---[NoImage] File already exists. New video output filename: C:\Documents and Settings\Administrator\My Documents\Videos\Assorted\Gundam00Preview_1.264
---[NoImage] Muxed output file: C:\Documents and Settings\Administrator\My Documents\Videos\Assorted\Gundam00Preview-muxed.mkv
---[NoImage] Encodable audio stream 0: C:\Documents and Settings\Administrator\My Documents\Videos\Assorted\Gundam00Preview.ogg
-[Information] Log for job4 (audio, Gundam00Preview.mkv -> Gundam00Preview.ogg)
--[Information] [7/25/2009 12:28:13 AM] Started handling job
--[Information] [7/25/2009 12:28:13 AM] Preprocessing
--[NoImage] Avisynth script
---[NoImage] DirectShowSource("C:\Documents and Settings\Administrator\My Documents\Videos\Assorted\Gundam00Preview.mkv", video=false)
---[NoImage] EnsureVBRMP3Sync()
---[NoImage] Normalize()
---[NoImage] 6==Audiochannels(last)?GetChannel(last,1,3,2,5,6,4):last
---[NoImage] return last
--[NoImage] Commandline used: -Q --ignorelength --quality -2.0 -o "{0}" -
--[Information] [7/25/2009 12:28:14 AM] Encoding started
--[Information] [7/25/2009 12:28:14 AM] Encode thread started
--[Information] [7/25/2009 12:28:14 AM] Avisynth script environment opened
--[Information] [7/25/2009 12:28:14 AM] Script loaded
--[Information] Output Decoder
---[NoImage] Channels: 2
---[NoImage] Bits per sample: 16
---[NoImage] Sample rate: 48000
--[NoImage] Commandline: C:\Program Files\megui\tools\oggenc2\oggenc2.exe -Q --ignorelength --quality -2.0 -o "C:\Documents and Settings\Administrator\My Documents\Videos\Assorted\Gundam00Preview.ogg" -
--[Information] [7/25/2009 12:28:14 AM] Encoder process started
--[Information] [7/25/2009 12:28:16 AM] Postprocessing
---[Information] Deleting intermediate files
--[Information] [7/25/2009 12:28:16 AM] Job completed
-[Error] Log for job5 (video, Gundam00Preview.avs -> Gundam00Preview_1.264)
--[Information] [7/25/2009 12:28:16 AM] Started handling job
--[Information] [7/25/2009 12:28:16 AM] Preprocessing
--[NoImage] Job commandline: "C:\Program Files\megui\tools\x264\x264.exe" --pass 2 --bitrate 300 --stats "C:\Documents and Settings\Administrator\My Documents\Videos\Assorted\Gundam00Preview_1.stats" --deblock 1:1 --psy-rd 0.6:0 --partitions p8x8,b8x8,i4x4,i8x8 --me umh --thread-input --aq-mode 0 --sar 1:1 --aud --output "C:\Documents and Settings\Administrator\My Documents\Videos\Assorted\Gundam00Preview_1.264" "C:\Documents and Settings\Administrator\My Documents\Videos\Assorted\Gundam00Preview.avs"
--[Information] [7/25/2009 12:28:16 AM] Encoding started
--[Error] An error occurred: x264 [error]: ratecontrol_init: can't open stats file
--[Error] An error occurred: x264 [error]: x264_encoder_open failed
--[NoImage] Standard output stream
--[NoImage] Standard error stream
---[NoImage] avis [info]: 592x336 @ 23.98 fps (346 frames)
---[NoImage] x264 [info]: using SAR=1/1
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Slow
--[Information] [7/25/2009 12:28:17 AM] Job completed


someone help please