MeGUI: bug reports and feature requests

[AMED]

Have you tried another decoder in the preferred decoder box in the AAC encoder profile your using?

Try BassAudio or LWLibavAudioSource.

[pilgrim365]

Yes. Sorry I forgot to mention that, I have changed the decoder. I can encode audio but only if I do one of two things: load the original source file into the audio input section, or demux the file and load the audio in directly. So, the issue lies within the indexing it seems.

[hello_hello]

For some reason, time stretching from 25fps to 23.976 produces an encode of a different duration than a time stretch with pitch correction .

My last encode had an original duration of 2:10:18:208. Time stretching results in 2:15:52:128 (which seems to be correct). With pitch correction the result was 2:17:09:728.

I can't test Avisynth 2.5.8 as I no longer have it installed, but the result is the same when using either Avisynth 2.6.0.4 and Avisynth+. I tried an older version of timestretch.dll and the result was the same. Maybe it's an error in the script MeGUI creates? Although it seems okay to me.

TimeStretch(tempo=Float(96000/1001))

I haven't had a chance to test all the slowdown/speedup options but I did test 25fps to 24fps, and with and without pitch correction, the resulting durations are the same.

[hello_hello]

There seems to be a similar oddity when doing a 23.976 to 25fps speedup.

Original duration: 54:31:104
Timestretch: 52:17:088
Pitch correction: 52:25:280

[tebasuna51]

TimeStretch(tempo=Float(96000/1001))

You are right.
The Float(96000/1001) don't work like spected.
AviSynth make first a integer division with a integer output.

Is enough a float term to make AviSynth output a float output:

TimeStretch(tempo=96/1.001)

[Overdrive80]

Don't accept 96000.0/1001.0?? Or

TimeStretch(tempo=Float(96000)/1001))

[LigH]

Both are possible as well. The one tebasuna51 wrote is a briefer one.

Just keep in mind: If numerator and denominator are both integer, an integer division will be calculated, and then it is too late to convert it to float.

[hello_hello]

You are right.
The Float(96000/1001) don't work like spected.
AviSynth make first a integer division with a integer output.

So is the upshot of that.... Avisynth is effectively "rounding"?

I'm not completely following the float/integer thing yet, but would 23.976fps to PAL speedup need "fixing"? It doesn't seem to work correctly either.

TimeStretch(tempo=Float(5005/48))

Does the TimeStretch function behave differently when using Avisynth 2.5.8? I still haven't tested it but if memory serves me correctly, version 2.5.8 has the TimeStretch function "built-in"?

I'm wondering if MeGUI would need to create a different script depending on the version of Avisynth being used.

Just keep in mind: If numerator and denominator are both integer, an integer division will be calculated, and then it is too late to convert it to float.

So does that mean the 24fps to 25fps should be done using a different method? I'm just trying to understand. It seems to work correctly.

TimeStretch(tempo=Float(2500/24))

[LigH]

I don't know what you learned in basic school. I learned the integer division before rational numbers. Integer division means: The result will not have a period and a fractional part. Instead, if you care, you may calculate the rest which doesn't fit into the multiples of the denominator (a.k.a. the modulo).

Numerator : Denominator = Quotient + Modulo/Denominator (rest)

Examples:

5005 : 48 = 104 + 13/48
2500 : 24 = 104 + 4/24

AviSynth assumes: If numerator and denominator are bot integer, then the quotient will be an integer too. The fractional part will be omitted. If you want a more or less precise result, you have to force AviSynth into calculating a floating point division. The integer result is possibly not precise enough. You may get asynchronous results in the progression of the playing time.

If the fractional part was close to 0, it would not make a matter. But the values in the examples above are relevant.

[hello_hello]

I originally thought the 25fps/24fps conversions were working correctly in both directions and I couldn't understand why... hence the question.... but it appears that's not the case so it makes sense now. 2400/25 produces the correct duration, while 2500/24 doesn't.

Original duration: 21:31:307

25fps to 23.976fps: 22:26:465
with pitch correction: 22:39:270 TimeStretch(tempo=Float(96000/1001))

25fps to 24fps: 22:25:111
with pitch correction: 22:25:111 TimeStretch(tempo=Float(2400/25))

23.976fps to 25fps: 20:38:416
with pitch correction: 20:41:641 TimeStretch(tempo=Float(5005/48))

24fps to 25fps: 20:39:654
with pitch correction: 20:41:641 TimeStretch(tempo=Float(2500/24))

[Groucho2004]

Original duration: 21:31:307

25fps to 23.976fps: 22:26:465
with pitch correction: 22:39:270 TimeStretch(tempo=Float(96000/1001))

25fps to 24fps: 22:25:111
with pitch correction: 22:25:111 TimeStretch(tempo=Float(2400/25))

23.976fps to 25fps: 20:38:416
with pitch correction: 20:41:641 TimeStretch(tempo=Float(5005/48))

24fps to 25fps: 20:39:654
with pitch correction: 20:41:641 TimeStretch(tempo=Float(2500/24))
You realize that you're still doing integer divisions, right? The casting of the integer division results to "Float" achieve nothing. Looking at the documentation (http://avisynth.nl/index.php/TimeStretch) might help.

[hello_hello]

You realize that you're still doing integer divisions, right? The casting of the integer division results to "Float" achieve nothing. Looking at the documentation (http://avisynth.nl/index.php/TimeStretch) might help.

Yes, but that's not me. I just copied the divisions MeGUI is using.

I was testing while posting, but I understand the "integer division" issue now. I guess MeGUI will just have to be "fixed" at some stage.

Is Zathor on holiday? I haven't seen him post here for a little while.

[Groucho2004]

Yes, but that's not me. I just copied the divisions MeGUI is using.
Sorry, should have read more of the discussion. Anyway, if this is how megui does it then some RTFM might help.

[LigH]

And regarding the numbers: The fix for a previous speedup is a slowdown, isn't it? Speeding up the speedup (or slowing down the slowdown) won't fix anything, it makes it worse, as you already noticed. You'll have to understand instead of copy&paste... ;)

[hello_hello]

And regarding the numbers: The fix for a previous speedup is a slowdown, isn't it? Speeding up the speedup (or slowing down the slowdown) won't fix anything, it makes it worse, as you already noticed. You'll have to understand instead of copy&paste... ;)

I wasn't trying to speed a file up, then slow it down again and end up with the original duration. I just took a random audio track and applied speedup and slowdown to it, then applied them again while using MeGUI's pitch correction option. I only converted the original file.

The idea was simply to determine if a particular speedup/slowdown resulted in the same duration with and without pitch correction.
As the results show, the only time that happened was when doing a 25fps to 24fps conversion.

I understand now that's because of the "integer divisions".

[LigH]

That may also have been the only time when the modulo was 0.

[Melan]

Is it possible to add an E-AC-3 audio paths as an extension to mkv muxer?

[LigH]

You mean as supported filename extension mask? (*.eac3)

[Melan]

Yes, yes.

[Zathor]

2496 [MainForm] enabled Drag & Drop for folders
2495 [x265] introduced fastdecode & zerolatency tunings
2494 [x265] removed --timinginfo switch. frame rate information is handled automatically now.

Sorry, nearly no time for MeGUI the last weeks and not sure about the next weeks. There are some bugs waiting to be fixed (timestretch and so on). Regarding timestretch it would help if someone gets me the correct commands.

Currently used commands are:

// SpeedUp23976To25:
AssumeSampleRate((AudioRate()*1001+480)/960).SSRC(AudioRate())

// SlowDown25To23976:
SSRC((AudioRate()*1001+480)/960).AssumeSampleRate(AudioRate())

// SpeedUp24To25:
AssumeSampleRate((AudioRate()*25 + 12)/24).SSRC(AudioRate())

//SlowDown25To24
SSRC((AudioRate()*25 + 12)/24).AssumeSampleRate(AudioRate())

// SpeedUp23976To25WithCorrection:
TimeStretch(tempo=Float(5005/48))

// SlowDown25To23976WithCorrection:
TimeStretch(tempo=Float(96000/1001))

// SpeedUp24To25WithCorrection:
TimeStretch(tempo=Float(2500/24))

// SlowDown25To24WithCorrection:
TimeStretch(tempo=Float(2400/25))

[LigH]

Your "simple" SpeedUp / SlowDown functions may even be correct, I see you are doing some numerical tricks to get the integer division done with rounding compensation.

But your functions "*WithCorrection" don't need integer values, because TimeStretch expects float values for the tempo parameter, so there is no need for tricky integer numerics. Simply enforce float divisions by including a decimal. Their values are calculated only once anyway.

// SpeedUp23976To25WithCorrection:
TimeStretch(tempo=10010.0/96.0)

// SlowDown25To23976WithCorrection:
TimeStretch(tempo=96000.0/1001.0)

// SpeedUp24To25WithCorrection:
TimeStretch(tempo=10000.0/96.0)

// SlowDown25To24WithCorrection:
TimeStretch(tempo=96.0)

Disclaimer: This answer is a rather trivial solution. There is possibly a numerically more elegant one, but I am not the greatest expert in numerics.

[Overdrive80]

Maybe like this:


// SpeedUp23976To25:
AssumeSampleRate(AudioRate()*24000.0/25.0*1001.0).SSRC(AudioRate())

// SlowDown25To23976:
AssumeSampleRate(Round(AudioRate()*25.0*1001.0/24000.0)).SSRC(AudioRate())

// SpeedUp24To25:
AssumeSampleRate(AudioRate()*25.0/24.0).SSRC(AudioRate())

//SlowDown25To24
AssumeSampleRate(Round(AudioRate()*25.0/24.0)).SSRC(AudioRate())

[hello_hello]

I've been doing it like this:

TimeStretch(tempo=(96/1.001)) # 25fps to 23.976fps
TimeStretch(tempo=(1001/9.6)) # 23.976fps to 25fps
TimeStretch(tempo=(240/2.5)) # 25fps to 24fps
TimeStretch(tempo=(250/2.4)) # 24fps to 25fps

The slowdown/speedup options without pitch correction seem to work fine as they are.

[LigH]

@ Overdrive80:

No. In AviSynth, Integer/Integer=Integer, never Float. Round() will not help because the term is already "rounded towards 0" (fraction cut off), not to the nearest integer away from *.5; the previously existing functions worked well.

Just to emphasize the difference again:

25/24 = 1
25.0/24.0 = 1.041(6~)

24/25 = 0
24.0/25.0 = 0.96

[Overdrive80]

@ Overdrive80:

No. In AviSynth, Integer/Integer=Integer, never Float.

You are right, in that case:


// SpeedUp23976To25:
AssumeSampleRate(Round(AudioRate()*960.0/1001.0)).SSRC(AudioRate())

// SlowDown25To23976:
AssumeSampleRate(Round(AudioRate()*1001.0/960.0)).SSRC(AudioRate())

// SpeedUp24To25:
AssumeSampleRate(Round(AudioRate()*25.0/24.0)).SSRC(AudioRate())

//SlowDown25To24
AssumeSampleRate(Round(AudioRate()*25.0/24.0)).SSRC(AudioRate())

[Xebika]

Is there a possibility to add DGIndexIM and an option in the settings to determine which indexes to have the first and second priority??

[Zathor]

2500 :D

2500 [x265] added custom command line
[x265] added support for 64bit x265
[x265] removed --no-ssim and --no-psnr as they are disabled by default
2499 [Audio Encoder] fixed TimeStretch support (regression of 2487)
[Audio Encoder] enhanced logging
[Audio Encoder] added 5.1 downmix if necessary (provided by tebasuna51)
2498 [L-SMASH Indexer] use the stream_index argument instead of track if using LWLibav*Source. Part II
2497 [L-SMASH Indexer] use the stream_index argument instead of track if using LWLibav*Source

Is there a possibility to add DGIndexIM and an option in the settings to determine which indexes to have the first and second priority??
For OneClick you can find it already in the settings.

[Xebika]

I doesn't use OneClick, i use the more common way.

[Zathor]

When you use the "more common way" - the manual way - then it should not be a problem to select the indexer manually, should it? At least I do not see the benefit of such a priority option. It will require a few hours of coding and testing on my side with limited savings. But if someone provides a patch I will add it. Otherwise please add it to the feature requests on sourceforge.

[Overdrive80]

@Zathor, review theses posts http://forum.doom9.org/showthread.php?p=1679175#post1679175, please.

[AMED]

Is anybody else having issues with the FFMS2 r892+41 update?

I'm seeing random crashes and errors in MEGUI.

Faulting application name: MeGUI.exe, version: 1.0.2500.0, time stamp: 0x5378a643
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x05ff125d
Faulting process id: 0x1c40
Faulting application start time: 0x01cf77c36e0e4f09
Faulting application path: D:\MEGUI\MeGUI.exe
Faulting module path: unknown
Report Id: 0878dac3-e3d4-11e3-82a3-bc5ff43694e1
Faulting package full name:
Faulting package-relative application ID: switching back to FFMS2 r827+36 and everything is running properly again.

[prijatelj.v]

I had a similar problem after the last update...
You helped me a lot (with the FFMS2 r892+41) because I did not know what it comes:

MeGUI (error) log : http://pastebin.com/JgnJNmTF

http://s13.postimg.org/igo36pw6f/image.jpg

http://s2.postimg.org/8zdql4sy1/image.jpg

http://s22.postimg.org/w4tz80qk1/image.jpg

[vergil666]

hi !
i have a question, i've just update megui from 2418 to 2500
and when i use avs script creator, i use file indexer all woks fine but if i want to another encode the same video, when i use avs sript creator, megui asking again if i want to use file indexer one click etc... and it's very boring

on 2418 it asking just once.
is-there a solution to this probleme ?

[AMED]

@vergil666

When you open the file the second time, don't choose the video file choose the index file. Make sure when you are creating the index file that you are saving it in the same folder as the video.

[rapscallion]

32 bit ver.
Also updated today to 2500 and I now get an error parsing avs file when trying to preview an m2ts stream. Worked just fine in previous version.

"Directshowsource couldn't open file ******no combination of filters could be found to render the stream"

AVS script :
DirectShowSource("D:\BD-Test\title\title.m2ts",audio=false)
assumefps(24000,1001)


Edit: Solved by updating my old versions of Haali Splitter and FFDshow.

[LigH]

Why do people still prefer the generally more unreliable DirectShow system over native AviSynth source filters? MeGUI already supports L-SMASH Source as well as DGDecNV (if registered) in the File Indexer, which can both handle M2TS reliably. DirectShowSource is bound to rely on installed splitter and decoder filters, so you have to know which filters you installed in your Windows system and how they have to be set up.

[vergil666]

@vergil666

When you open the file the second time, don't choose the video file choose the index file. Make sure when you are creating the index file that you are saving it in the same folder as the video.

thanks it works ^^

[Groucho2004]

Why do people still prefer the generally more unreliable DirectShow system over native AviSynth source filters?

People don't know about the alternatives
They think since DSS is basically an integral part of the Avisynth distribution, it must be the right one to use
Too impatient to wait for the indexing.
...

[rapscallion]

People don't know about the alternatives
They think since DSS is basically an integral part of the Avisynth distribution, it must be the right one to use
Too impatient to wait for the indexing.
...

All correct. I've been using it that way for years and until yesterday, never had a single problem. "If it ain't broke, don't fix it" scenario.

Now, having said that, why did the latest update from 2487 to 2500 break it?

Edit : Updated my old versions of Haali Splitter and FFDshow and all is well

[LigH]

@ Groucho:

+ Google finds first "uber guides" outdated for years? ;)
__

@ rapscallion:

There is always a first exception for a rule that was incidently true for trivial material.

[Groucho2004]

@ Groucho:

+ Google finds first "uber guides" outdated for years? ;)

+ Huh?

[LigH]

Well, I wonder why it is so easy to prefer DirectShow. Either the tools default to it, or there are "uber best know-it-all-better guides" out there which recommend it?!

If the former, then I would recommend Zathor to think about altering MeGUI in a way that DirectShowSource is not preferred anymore. But since I know the File Indexer (which is now a lot more reliable with L-SMASH Works support), and never use don't-think-about-it features, I don't even get the idea of preferring DirectShow anymore, so I don't know how a first time user thinks, and why he would start to prefer the "wrong" way.

[Groucho2004]

Well, I wonder why it is so easy to prefer DirectShow. Either the tools default to it, or there are "uber best know-it-all-better guides" out there which recommend it?!
I was thinking about an average user who would download Avisynth and start looking at the documentation. The first choice for "Media file filters" in Avisynth's help is AviSource, followed by DirectShowSource. Naturally, the user would assume that DSS is the right choice for a file that is not supported by AviSource.

You're probably right that most novice users start with "GUIs" and use the default options (which also leads to DSS as the preferred source filter - at least in Megui).

The bottom line is that one has to dig quite a bit into DOOM9's forums in order to figure out that there are better alternatives to DSS.

As for Megui - I don't know why DSS is the preferred source filter, I guess the people who maintain the software have their reasons.

[LigH]

Average users need one-click GUIs. They would never start reading the AviSynth documentation. ;) ;)

[Zathor]

[...]I would recommend Zathor to think about altering MeGUI in a way that DirectShowSource is not preferred anymore. But since I know the File Indexer (which is now a lot more reliable with L-SMASH Works support), and never use don't-think-about-it features, I don't even get the idea of preferring DirectShow anymore, so I don't know how a first time user thinks, and why he would start to prefer the "wrong" way.

In MeGUI's OneClick tool directshow is not used at all. There is only AviSource and this has the lowest priority by default and will only be used when the others cannot be used.

In the AVS Script Creator tool there is this text when opening a non indexed file:
Do you want to open this file with
- One Click Encoder (fully automated, easy to use) or
- File Indexer (manual, advanced) or
- DirectShowSource (manual, expert, may cause problems)?
Depending on the selection the file will be processed with the other tools.

What else should I do? Disable DirectShowSource completly?

[Guest]

What else should I do? IHMO, leave it as is. The warning is a quite reasonable compromise. Anyway, MeGUI is not the only context in which new users run into issues with DirectShowSource(). I view it as something of a rite of passage for learning about desktop multimedia.

[LigH]

:o I am sorry to raise trouble with old habits of other people and little own knowledge about MeGUI... Obviously, you and your tool are not the reason for issues based on times when there were no better solutions.

[rapscallion]

@LigH....before your first time mention of L-Smash as alternative above, I see you asked Zathor to take a look at it a year ago , in this post : Click Here (http://forum.doom9.org/showpost.php?p=1633741&postcount=3284.)

So, it's not like it's been around for some time. I also notice that Megui, by default has the update for L-Smash disabled (development build). So, it's natural for people not to LOOK for it as an alternative. The only reason I've been using ffds, since 2009, was the tutorial by Jamos, in this thread. : Click Here (http://forum.doom9.org/showthread.php?t=135795)

If it's that superior, I'd appreciate some info on how to use it with Megui. I do BD, 2 pass encodes.

[LigH]

Well, yes, those are the details about MeGUI I don't realize anymore since I always use MeGUI so differently compared to a user with a less specific point of view. I may be a quite un-average user. So I should not try so often to assume about the averages... :o

[Zathor]

@LigH....before your first time mention of L-Smash as alternative above, I see you asked Zathor to take a look at it a year ago , in this post : Click Here (http://forum.doom9.org/showpost.php?p=1633741&postcount=3284.)

So, it's not like it's been around for some time. I also notice that Megui, by default has the update for L-Smash disabled (development build). So, it's natural for people not to LOOK for it as an alternative.
Yes, L-Smash has been introduced in MeGUI round about half a year ago. And it is not disabled - the package will be only downloaded when needed and therefore automatically enabled. But FFMS2 is there for years (as this dialogue to not use DirectShowSource).

In the end the only thing which matters is if you have found your use case and the results are fine for you. So stick with your process - if you want to change something try the OneClick tool.