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

hello_hello

24th May 2016, 11:55

Specifically mentioning XP (in case I should), is there a way to tell software to stop complaining and get on with it if the software itself doesn't offer an option to try?

MeGUI drives me a little nutty with this when it's in the middle of an encoding job and there's a few in the queue. The job still finishes, but I have to keep my eye on the x264 process using Task Manager and restart MeGUI's job queue when it's done.

This was a result of my second favourite way to make MeGUI think it's crashed.... by changing the resolution of the output with complex filtering in the script, maybe combined with having done something dumb, then refreshing the preview.
As you can see from the the tasks I initiated after it happened (aside from the running encode), MeGUI appears to be functioning perfectly. I'd like to be able to dismiss the error message or at least change it's "always on top" status so it's not in the way. I'm not sure if it's possible at the moment though.

Thanks.

http://s33.postimg.org/i73xlx3wf/Me_GUI_crash.gif

Barough

28th May 2016, 20:08

MediaInfo 0.7.86
MKVToolNix v9.2.0
QAAC v2.59
x264 r2705

Barough

2nd July 2016, 16:09

FFmpeg v3.1.1 'Laplace' (July 1st, 2016)
MediaInfo 0.7.87

hello_hello

15th July 2016, 19:25

As a result of a discussion here (http://forum.videohelp.com/threads/379213-Keep-aspect-ratio-in-AviSynth?p=2452742#post2452742) I discovered a bit of a problem with MeGUI muxing DVD subtitles into an MP4 container.... sometimes..... but here's a copy and paste of what I wrote in the other thread after a bit of experimenting.

It seems there's an oddity in the way VobSubber extracts subtitles and the way MeGUI adds them to the command line for MP4 muxing in relation to the track number of the subtitle.... or something..... I'm not 100% sure yet. It seems though, automatically adding them via the OneClick encoder mightn't always work.

When I opened the IFO file I was using for testing, VobSubber showed a single English subtitle stream numbered 01. When I checked the "show all subtitle streams" option there was a stream 00 listed, a stream 02 listed, a stream 03 listed etc, but all listed as "not detected".

I extracted the single English stream and MeGUI used the following to add it to the command line for MP4 muxing:
-add "E:\testing\VTS_01_0.idx#trackID=1:lang=eng:na me="
There was an obscure warning in the log file about "track 1 ID not being found in file" and there were no subtitles muxed.
I tried again, but rather than selecting the single subtitle when extracting, I checked "keep all subtitle streams" in VobSubber. Only the stream "01 English" was being displayed. After extracting I tried muxing again and MeGUI created the same command line. This time though, the subtitles were muxed and the warning was replaced with:
VobSub import - subpicture stream 'eng'

I don't quite understand what's happening. When opened with VobSubber, the English subtitle (and the only subtitle) appears to be track one (although the first stream could be track zero). When extracting by selecting the single English stream VobSubber must extract it as track zero and MeGUI can't find it, although why it detects it as track one when adding it for muxing I don't know. I'm making guesses here, but if it's a track identification problem it only effects MP4 muxing as far as I can tell. MKV muxing is fine.

I tried three different versions of MP4Box and I could successfully mux the subtitle file MeGUI didn't mux with MyMP4BoxGUI, so I'm fairly confident Mp4Box is not to blame. Anyone experienced anything similar?

Barough

18th July 2016, 16:32

MKVToolNix v9.3.1
x265 v2.0

hello_hello

24th July 2016, 07:16

Carlo75

29th July 2016, 18:46

I installed this days Windows 10 on my new Computer and have now a problem with MeGui.
Since I have Win10 installed, I can't drag & drop any file into MeGui. For other programs (for example MKVToolNix, MKVExtractGui or TSMuxerGui), there are no issues.

As I know, it has to do with User account control, but disabling UAC should not be the solution. Because drag & drop works in other programs as well, I think there must be another way.

Do you known this issues and is there a solution or you working on a solution?

Greets

Carlo

LigH

31st July 2016, 22:10

The reason is probably that MeGUI wants to create job files below its installation directory.

The most usual solution is to install MeGUI outside of an UAC monitored directory branch (e.g. if you have several partitions, to D:\MeGUI).

To adapt the structure of MeGUI to circumvent the UAC would require some efforts (e.g. storing job files as well as executable tools - to be easily updateable - in %APPDATA%).

Carlo75

1st August 2016, 17:09

I reinstalled MeGui on another patition and now works.
Thank you for support!

Greets Carlo

NyaR

5th August 2016, 02:35

every time user exports preset on megui version > 2525 the output zip is blank

Barough

27th August 2016, 18:56

FDK-AAC v0.6.3 (http://www109.zippyshare.com/v/3nN7qa0W/file.html) (MSYS/MinGW, GCC 6.2.0, 32 & 64bit EXEs)

Changelog :

2016-08-26 nu774 <honeycomb77@gmail.com>
* update ChangeLog [HEAD -> master]
* bump [origin/master]
* Ticket #23: quit supporting MPEG-2 AOT

2016-08-25 nu774 <honeycomb77@gmail.com>
* fix libfdkaac encoder version check for SBR_RATIO availability
* Use our SBR signaling implementation on old libfdkaac

2015-10-10 nu774 <honeycomb77@gmail.com>
* improve MSVC project

2015-09-21 nu774 <honeycomb77@gmail.com>
* fix indents
* update compat layer, mainly for MSVC14 issue

2015-07-22 nu774 <honeycomb77@gmail.com>
* add platformtoolset in vcxproj
* fix build issue on MSVC14

2015-06-12 nu774 <honeycomb77@gmail.com>
* remove an unused variable decl
* remove an unused variable decl
* m4af: move internal struct m4af_itmf_entry_t from header

LigH

27th August 2016, 19:01

Are you allowed to publish it in binary form, according to the license? I doubt...

Barough

27th August 2016, 19:13

An earlier version of it was posted here by Kurtnoise so....... but if it's not allowed so can some1 remove my post.

hello_hello

30th August 2016, 17:42

I'll confess I've never quite got my head around the difference between mpeg2 and mpeg4 AAC profiles, but of the profiles in MeGUI's fdkaac encoder configuration....

The MPEG2 HE v2 profile doesn't work with the previous version of fdkaac I was using (fdkaac 0.6.2, libfdk-aac 3.4.12, according to MediaInfo) and after updating it to the version Barough uploaded (fdkaac 0.6.3, libfdk-aac 3.4.22, according to MediaInfo) my very quick testing indicates it's now bye-bye to all three MPEG2 profiles in MeGUI's encoder configuration (none of them work).

A quick google led to this, which probably explains it, if I found the correct changelog for that version of fdkaac:
https://github.com/nu774/fdkaac/blob/master/ChangeLog
"* Ticket #23: quit supporting MPEG-2 AOT"

There doesn't seem to be any indication the AAC encoding has been improved, or changed, or modified recently, so maybe it's better not to upgrade, at least if you're using fdkaac with MeGUI.

PS. Well while I'm here.... what, for example, would be the difference between mpeg2 LC-AAC and mpeg4 LC-AAC, both being options available in MeGUI's encoder configuration. Anyone know?

Cheers.

SegNin

30th August 2016, 18:27

hello_hello

30th August 2016, 20:55

Ever since it auto-updated some files, MeGUI has been giving me this error:

LoadPlugin: unable to load "C:\Users\J\Desktop\MAIN\OTHER PROGRAMS\MeGUI_2525_x86\tools\lsmash\LSMASHSource.dll", Module not found. Install missing library?

That dll is in the MeGUI_2525_x86\tools folder. I even copied that dll to both System32 and SYSWOW64 folders but it still isn't being recognized.

Is msvcr120.dll in the same folder as LSMASHSource.dll? ie in the tools\lsmash folder? LSMASHSource.dll doesn't belong in the System32 or SYSWOW64 folders, but it sounds like it's needing a missing dependency.

According to the LSMASHSource page it requires the Microsoft Visual C++ 2013 Redistributable Package (which is why MeGUI normally puts msvcr120.dll in the same folder as LSMASHSource.dll), but try installing that. It's a small download. There's a link to it here. http://avisynth.nl/index.php/LSMASHSource

If you haven't, also try rebooting. Every so often MeGUI gives me a similar error because it can't load a plug-in. One that it's been loading for days but suddenly it claims there's a missing dependency. I can use the plug-in in question in a script and successfully open the script with MPC-HC, but not with MeGUI. For whatever reason, rebooting fixes it.

mini-moose

31st August 2016, 11:38

I can confirm this behavior with XP and W7 using FFMS2 2.22 - I have not tried other FFMS2 or OS versions, but L-SMASH works. So it must be related to FFMS2 together with the new wrapper. I cannot do much there. Maybe I can load the video twice when FFMS2 is used as a workaround.

Has there been some workaround for that ffms2 issue? I've been using lsmash mostly, but this mp4 I'm trying now doesn't get to the correct fps with lsmash, so I tried ffms which does produce the correct fps but I can't preview after indexing. I get a black screen...

OS is Win10 not XP.

edit: It seems fpsnum=50, fpsden=1, threads=1 on ffms is what made it keep on correct fps, that bit is not added on lsmash. Still, I can't preview the indexed source under ffms, but can under lsmash.

hello_hello

1st September 2016, 00:35

I reverted back to the old AvisynthWrapper.dll to fix the black preview issue, which was a constant issue using XP.

For the record.... the frame rate conversion issue with ffms2 and AVIs.... the frame rate conversion causing ffms2 to sometimes drop or duplicate frames it shouldn't..... I've witnessed a similar issue several times with MKVs and MP4s when there's frame rate conversion in the script, with both ffms2 and L-Smash.
I think it might be a "jitter" thing and sometimes there's too much, but I've completely reversed my original theory that adding frame rate conversion to a script by default is a good idea. Well it still is a good idea.... if it always worked correctly, but alas....

mini-moose

1st September 2016, 10:51

I reverted back to the old AvisynthWrapper.dll to fix the black preview issue, which was a constant issue using XP.

Thanks for your advice hello_hello.

I found AvisynthWrapper.dll in megui's root. I'm not sure what it does exactly and if it's safe to revert it..will do some research.

One I currently seem to have is v1.0.2626.0. Which one did you revert to?

hello_hello

1st September 2016, 12:58

I think there's the latest one and the old one. I'm not sure I've been using MeGUI long enough to have experienced a prior version, if there was such a thing.

I'm not sure about the version number (it doesn't say) but if you have AvisynthWrapper.dll.backup in the same folder, renaming the current version before removing.backup from the old one should do the job. Unless MeGUI is deleting backup files, in which case I've uploaded it here (http://www.filedropper.com/avisynthwrapper) for you.
Mines got a modified date of 2nd Jan 2009 and it's 57kB.

kuchikirukia

1st September 2016, 14:58

It would be nice if MeGUI would cache avs scripts you queue. More than once I've loaded a script, hit start, gone back to edit the script for the next encode, saved it, and had MeGUI use the new one, because it seems to go back to the .avs after indexing, even though this doesn't show in the log anywhere.

hello_hello

1st September 2016, 15:42

Could you expand on "seems to go back to the .avs after indexing"? Maybe I'm being dumb, but I don't quite understand what you mean.

tebasuna51

2nd September 2016, 20:06

I found another bug (first one (http://forum.doom9.org/showthread.php?p=1761542#post1761542)) related with MediaInfo info and how MeGUI use that info.

With a aac input file like this:
File ........: D:\Internet\movie.aac
Size ........: 130729393 bytes

----------------------------------------- First Frame Info
ID ..........................: 0 (MPEG-4)
Protection absent ...........: 1
Profile .....................: 1 (Low Complexity, LC)
Sample Rate .................: 24000 Hz
Private bit .................: 0
Channels ....................: 6
Original/Copy ...............: 0
Home ........................: 0
Copyright identification bit : 0
Copyright identif. start ....: 0
Aac Frame Length ............: 296
Adts buffer fullness ........: 2047
No raw data blocks in frame .: 0
--------------------------------------------- Revised Info
Total Frames ..... : 129120
VBR min./avg./max. : 12 / 189 / 278 Kb/s.
Duration.......... : 5509.12 sec., (1h. 31m. 49.12s.)
Maybe is HE-AAC at : 48000 Hz. (SBR)
----------------------------------------------------------

The MediaInfo show:

Format: AAC
FormatProfile: HE-AACv2 / HE-AAC / LC *** WRONG ***
FormatSettingsSBR: Yes (Implicit) OK
FormatSettingsPS: Yes (Implicit) *** WRONG ***
SamplingRate: 48000 / 48000 / 24000 OK
SamplingRateString: 48.0 kHz / 48.0 kHz / 24.0 kHz OK
Channels: 2 / 6 / 6 *** WRONG ***
ChannelsString: 2 channels / 6 channels / 6 channels *** WRONG ***
ChannelPositionsString2: 3/2/0.1 OK

Reading ADTS headers (without decode) we can't know if is HE-AAC or LC-AAC but the channel number is well know and I can't understand for what this: 2 / 6 / 6

The problem is when the user select downmix and MeGUI refuse that:
--[Warning] [02/09/2016 18:37:35] channel count mismatch! The input file is reporting 2 channels and the AviSynth script is reporting 6 channels
--[Warning] [02/09/2016 18:37:35] ignoring downmix because of the channel count mismatch *** WRONG ***
--[Information] [02/09/2016 18:37:35] Avisynth script
---[NoImage] LoadPlugin("D:\Programa\megui\tools\lsmash\LSMASHSource.dll")
---[NoImage] LWLibavAudioSource("D:\Internet\movie.aac")
---[NoImage] # detected channels: 2 channels / 6 channels / 6 channels *** WRONG if read 2 channels***
---[NoImage] # detected channel positions: 3/2/0.1

Log:

mini-moose

3rd September 2016, 12:14

Unless MeGUI is deleting backup files, in which case I've uploaded it here (http://www.filedropper.com/avisynthwrapper) for you.
Mines got a modified date of 2nd Jan 2009 and it's 57kB.

Many thanks hello_hello, I'll give it a try. I usually delete the backup files after a while so I don't have the old version.

I couldn't find anything newer than r4352 from 2008 on a web search: http://avisynthwrapper.codeplex.com/releases/view/10429
Seems is was updated by tebasuna51 who is a mod here :)

The dll you kindly provided seems to fix the issue with ffms2. I'm just somewhat unsure exactly what the wrapper does and whether it's important to run a more recent version or not. I can't really find a lot of info about it.

kuchikirukia

4th September 2016, 01:09

Could you expand on "seems to go back to the .avs after indexing"? Maybe I'm being dumb, but I don't quite understand what you mean.

Open avs
click queue
MeGUI starts work
quickly edit avs
save
MeGUI encodes with new avs settings

So it's reloading the avs at some point at the beginning of the encode.

tebasuna51

4th September 2016, 11:27

So it's reloading the avs at some point at the beginning of the encode.

Like you can see in logs:
-[Information] Log for jobX (...)
--[Information] [26/08/2016 14:00:11] Started handling job
--[Information] [26/08/2016 14:00:11] MediaInfo
--[Information] [26/08/2016 14:00:17] Avisynth script
--[Information] [26/08/2016 14:00:20] Job command line: ...
there are a few of steps before send the Job command line than can include the avs file, if you modify the file in this time (9 sec in my sample) the encoder read other file than the analyzed or showed in log.

Recommended workaround: if you edit the avs before this time save it with other name.

kuchikirukia

6th September 2016, 00:58

Like you can see in logs:

It will do it after that. I've had it encode an entirely different video than the script it shows in the log. So at some point it reloads it again without logging.

tebasuna51

6th September 2016, 13:34

So at some point it reloads it again without logging.

Not MeGUI but the encoder, because complete command line is like this:

x264 [parameters] INPUT.avs -o output

then the avs is passed like a filename than x264 must read, if is not the same...

j8ee

14th September 2016, 21:06

Just noticed the muxers doesn't accept matroska input files for audio, whether .mka or .mkv. Megui 2634
(posted this in the wrong thread before)

LigH

15th September 2016, 07:43

They may support only the raw audio inside these containers. That depends on the CLI multiplexers used by MeGUI. Multiplexing to Matroska using mkvmerge should probably accept MKA input, though, that will be worth an investigation. Support by multiplexers to other formats is doubtful, you may have to extract the raw content of the audio streams first.

tebasuna51

15th September 2016, 11:02

MkvMerge (MkvToolNix) accept .mka and .mkv input, of course, but the 'MeGUI ->Tools -> Muxer -> Mkv muxer' filter the audio inputs without accept .mka or .mkv (but accept .m4a or .mp4 and other standalone audio formats).

Also 'MeGUI ->Tools -> HD Stream Extractor' don't support .mka or .mkv with only audio.
You need other tool, MkvExtract or UsEac3to, to extract the audio previously.
Or mux the .mka/.mkv after with MkvToolNix.

igrat

1st October 2016, 15:03

qaac 2.60 was released (https://sites.google.com/site/qaacpage/news/qaacrelease260):

Fix: combination of --adts and --concat was generating invalid AAC file.
Changed 7.1ch rear channel layout in favor of Apple QuickTime.
Support new Wavpack v5 64bit API
Update: libsoxr
Update: taglib

qaac was using 3 front + 2 side + 2 back for 7.1ch rear output. However, it turned out that Apple QuickTime cannot handle this, and only recognizes 3 front + 4 back. OTOH, libavcodec couldn't recognize the latter until this patch http://ffmpeg.org/pipermail/ffmpeg-cvslog/2015-June/090556.html. Anyway it now handles both, so I decided to change 7.1ch rear layout to 3 front + 4 back, which is supported by both of them.

Will this be included in MeGUI development server?

tebasuna51

2nd October 2016, 10:41

WARNING: the qaac 2.60 seems a buggy version.

A standard wav 7.1: FL,FR,FC,LF,BL,BR,SL,SR
encoded to .aac by qaac 2.60 and decoded by itself produce a wrong channel mapping.
BassAudio don't work and faad also do wrong channel mapping.

Decoder Output
------------------ --------------------------
qaac FC,FL,FR,SL,SR,BL,BR,LF
LWLibavAudioSource ok
FFAudioSource ok
BassAudio Abort
faad FC,FL,FR,SL,SR,BL,BR,LF

a .m4a obtained with qaac 2.60 decoded by:

Decoder Output
------------------ --------------------------
qaac ok
LWLibavAudioSource ok
FFAudioSource ok
BassAudio FC,FL,FR,SL,SR,BL,BR,LF
NeroAacDec ok
faad FC,FL,FR,SL,SR,BL,BR,LF

Seems the patch for libavcodec work fine but is not a standard solution.

nu774

3rd October 2016, 04:45

Well, can you explain what exactly got worse on 2.60/2.61 compared to 2.59 ?
It's almost unbelievable that everything on your table has been "OK" on 2.59.

igrat

3rd October 2016, 08:03

Okay, file under "W" for "weird"... this sounds strange, but I've tested it multiple times, even with a clean download of MeGUI and it seems completely consistent.

It appears that MeGUI updates go about twice as fast as normal if you hold down the right mouse button within this part of the window:

http://i.imgur.com/w7x14rb.png

Is this a freak occurrence that only happens on my machine, or does it happen for other people as well?

tebasuna51

3rd October 2016, 11:26

Well, can you explain what exactly got worse on 2.60/2.61 compared to 2.59 ?
It's almost unbelievable that everything on your table has been "OK" on 2.59.
First of all say than all my test with 5.1 seems work fine with all qaac versions, .aac or .m4a output and all decoders.

The problem is only with 7.1.

I checked 2.60 because the change:
Changed 7.1ch rear channel layout in favor of Apple QuickTime.

But you are right the version 2.59 is also buggy.
I can't trust in a encoder/decoder than itself don't preserve the channel order:

qaac260 --adts -o TEST.aac FL_FR_FC_LF_BL_BR_SL_SR.wav
qaac260 -D -o FC_FL_FR_SL_SR_BL_BR_LF.wav TEST.aac

qaac259 --adts -o TEST.aac FL_FR_FC_LF_BL_BR_SL_SR.wav
qaac259 -D -o SL_SR_FC_LF_BL_BR_FL_FR.wav TEST.aac

After many test I can say:

- BassAudio and Faad decoders don't work with 7.1, .aac or .m4a, created by any version of qaac or NeroAacEnc.

- qaac decoder don't work with 7.1 .aac created with any qaac version or .m4a created by NeroAacEnc.

- NeroAacDec work fine with any .m4a created with any qaac version or NeroAacEnc.

- decoders bassed in libavcodec (LWLibavAudioSource, FFAudioSource, Foobar2000, ...) works fine with .aac or .m4a created by any version of qaac or NeroAacEnc.

- I don't know what happen with others soft/hardware decoders.

My final recomendation is don't encode 7.1 to .aac, use always .m4a. The metadata in mp4 container have more chances to be well interpreted than metadata in ADTS headers.

Zathor

3rd October 2016, 12:24

I found another bug (first one (http://forum.doom9.org/showthread.php?p=1761542#post1761542)) related with MediaInfo info and how MeGUI use that info.

With a aac input file like this:
File ........: D:\Internet\movie.aac
Size ........: 130729393 bytes

----------------------------------------- First Frame Info
ID ..........................: 0 (MPEG-4)
Protection absent ...........: 1
Profile .....................: 1 (Low Complexity, LC)
Sample Rate .................: 24000 Hz
Private bit .................: 0
Channels ....................: 6
Original/Copy ...............: 0
Home ........................: 0
Copyright identification bit : 0
Copyright identif. start ....: 0
Aac Frame Length ............: 296
Adts buffer fullness ........: 2047
No raw data blocks in frame .: 0
--------------------------------------------- Revised Info
Total Frames ..... : 129120
VBR min./avg./max. : 12 / 189 / 278 Kb/s.
Duration.......... : 5509.12 sec., (1h. 31m. 49.12s.)
Maybe is HE-AAC at : 48000 Hz. (SBR)
----------------------------------------------------------

The MediaInfo show:

Format: AAC
FormatProfile: HE-AACv2 / HE-AAC / LC *** WRONG ***
FormatSettingsSBR: Yes (Implicit) OK
FormatSettingsPS: Yes (Implicit) *** WRONG ***
SamplingRate: 48000 / 48000 / 24000 OK
SamplingRateString: 48.0 kHz / 48.0 kHz / 24.0 kHz OK
Channels: 2 / 6 / 6 *** WRONG ***
ChannelsString: 2 channels / 6 channels / 6 channels *** WRONG ***
ChannelPositionsString2: 3/2/0.1 OK

Reading ADTS headers (without decode) we can't know if is HE-AAC or LC-AAC but the channel number is well know and I can't understand for what this: 2 / 6 / 6

The problem is when the user select downmix and MeGUI refuse that:

Log:

Hi,

Are you sure that the other and this bug are not MediaInfo problems? If not what should I change in MeGUI?

tebasuna51

3rd October 2016, 12:50

Are you sure that the other and this bug are not MediaInfo problems? If not what should I change in MeGUI?

Of course is a MediaInfo problem, but when there are a conflict MeGUI must trust in AviSynth and continue without abort.

Zathor

3rd October 2016, 18:52

I am just changing it in the way that the MediaInfo from the block will be used which matches the AVS channel count.
E.g. MediaInfo
7 channels / 6 channels
3/2/1.1 / 3/2/0.1
With NicAudio (6 channels in AVS) 3/2/0.1 will be selected, with LWLibavAudioSource (7 channels in AVS) it will be 3/2/1.1.
==> The "channel count mismatch" warning should be gone

May I ask you also to have a look at your post?
http://forum.doom9.org/showthread.php?p=1461787#post1461787
Could you please provide also some information for downmixing the 7 or 8 channel count audio files?

Zathor

3rd October 2016, 19:01

Small bug fix release uploaded.

2641 [AudioEncoder] fixed handling of MediaInfo information for HD audio tracks
2640 [AviSynth] improved debug handling
2639 [Main] removed aspect ratio controls from the video preview control. Bug #843
2638 [Profile] added support to import old export files (regression of 2635). Bug #849
2637 [VobSubber] each track will be demuxed into a dedicated file set to avoid missing tracks when muxing. Bug #845
[VobSubber]+[OneClick] for multiple tracks the source will only be indexed once
2636 [Audio Encoder] cosmetic change. Bug #826
2635 [Profile] fixed import & export of profiles (regression of 2590). Bug #842

Also I have downgraded the AviSynthWrapper for the moment.

tebasuna51

3rd October 2016, 21:55

I am just changing it in the way that the MediaInfo from the block will be used which matches the AVS channel count.
E.g. MediaInfo
7 channels / 6 channels
3/2/1.1 / 3/2/0.1
With NicAudio (6 channels in AVS) 3/2/0.1 will be selected, with LWLibavAudioSource (7 channels in AVS) it will be 3/2/1.1.
==> The "channel count mismatch" warning should be gone
Thanks.

May I ask you also to have a look at your post?
http://forum.doom9.org/showthread.php?p=1461787#post1461787
Could you please provide also some information for downmixing the 7 or 8 channel count audio files?

To downmix to stereo, dpl, etc.?

Easy, apply first function c71_c51() or function c61_c51() and after the downmix 5.1 to stereo selected.

LigH

4th October 2016, 08:10

It appears that MeGUI updates go about twice as fast as normal if you hold down the right mouse button within this part of the window:

Confirmed. Holding RMB there seems to flood the application with Windows messages which seem to make the messaging queue hurry. Someone explain why it appears to idle in normal use.

mini-moose

9th October 2016, 11:07

2637 [VobSubber] each track will be demuxed into a dedicated file set to avoid missing tracks when muxing. Bug #845

Thanks for the updates, Zathor.

However, I find the vobsubber change to be very bad. Personally, I rather have all vobsubs from a DVD in one idx/sub set and not in several idx/sub files with no visible language tag.
I don't always mux the vobsubs as there are many different players with different kinks (some won't play vobsubs at all, some will only play external, some will only play internal etc).

Perheps you can add an option to choose between split streams and one set on the vobsubber dialog or in global megui settings? I've rolled back to the previous version for now.

Informative note: the latest Komisar x264 r2721 build (VLC didn't release an official build since r2705), has a new variation of --preset slow:
http://git.videolan.org/?p=x264.git;a=commit;h=4e5adb87070c82b937c03e0cc030eae3578c251d
Some may notice a difference in performance due to that.

eahm

11th October 2016, 17:32

tebasuna51, did you have a chance to test fhgaacenc and fdkaac for 7.1? Thanks.

hello_hello

12th October 2016, 02:05

Informative note: the latest Komisar x264 r2721 build (VLC didn't release an official build since r2705), has a new variation of --preset slow:
http://git.videolan.org/?p=x264.git;a=commit;h=4e5adb87070c82b937c03e0cc030eae3578c251d
Some may notice a difference in performance due to that.

Thanks for the info.
I use --preset slow a lot and I can't say I noticed a difference in performance (I generally use slow filtering) or a difference in quality, but I had a feeling something was different when I looked at the encoder settings written by x264, but I never investigated further. Now I know why.
Unfortunately it means the advanced settings displayed by MeGUI's encoder configuration are now wrong for --preset slow. I've added it to the bugs list at sourceforge in case Zather doesn't see these posts.
https://sourceforge.net/p/megui/bugs/855/

hello_hello

12th October 2016, 03:27

tebasuna51, did you have a chance to test fhgaacenc and fdkaac for 7.1? Thanks.

The situation for 7.1ch audio is even more of a mess than it was for 5.1ch due to hacks for encoding/decoding. Here's what I worked out a while ago. Someone correct me if I've got any of it wrong.

There's two main 7.1ch speaker configurations:
7.1ch (rear) = L R C LFE BackL BackR SideL SideR (in wave file order)
7.1ch (front) = L R C LFE BackL BackR FrontSurroundL FrontSurroundR (in wave file order)

The first layout is the one we care about (home theatre 7.1ch). The second layout is the default for AAC (cinema 7.1ch), so it gets funky. Instead of side and back surround there's an extra pair of surround speakers at the front between the left and right speakers, with a single pair of side/surround channels (the same as 5.1ch).

AAC encoders/decoders can support 7.1ch (rear) by writing an element to the AAC stream, but before some of them did, 7.1ch (rear) was generally remapped as 7.1ch (front) for encoding then remapped as 7.1ch (rear) for decoding. Unless it's changed quite recently, ffmpeg still decodes under that assumption by default (I don't know if "remapping' is technically the correct description, but rather 7.1ch rear is simply encoded as 7.1ch front and 7.1ch front is decoded as 7.1ch rear, and two wrongs can make a right). If it's not encoded and decoded the same way you end up with the side surround channels in the front surround. That sort of thing.

NeroAAC encodes 7.1ch (rear) as 7.1ch (front), therefore I wouldn't use it for 7.1ch encoding.
FFmpeg's native AAC encoder encodes 7.1ch (rear) as 7.1ch (front).
FhGAAC encodes 7.1ch (rear) as 7.1ch (front). It remaps the channels slightly differently to Nero though so if it's decoded as 7.1ch (front) the result isn't as bad.
FDKAAC encodes 7.1ch (rear) as 7.1ch (rear).
QAAC encodes 7.1ch (rear) as 7.1ch (rear). It didn't always, but it's done so since version 2.35 (https://sites.google.com/site/qaacpage/news/qaacrelease235refalac135).

A few other observations:
Some encoders assume the audio is a certain layout based on the number of channels when it isn't. NeroAAC, FhGAAC & FFmpeg's native AAC encoder can potentially remap channels when encoding and not tell you about it.
FDKAAC is well behaved and rejects layouts it doesn't support. It don't think it ever remaps channels.
QAAC is well behaved and either rejects layouts it doesn't support or remaps channels only when it makes sense (5.1ch wave files with back surround or 5.1ch wave files with side surround are both encoded as 5.1ch surround etc). QAAC Multichannel Handling (https://github.com/nu774/qaac/wiki/Multichannel--handling).

ffmpeg has a "-strict 1" option for decoding 7.1ch AAC so 7.1ch (front) is decoded as it should be (mentioned in the qaac changelog I linked to). Without -strict 1 it assumes 7.1ch (front) is really 7.1ch (rear) and remaps the channels accordingly when decoding.
Foobar2000 uses ffmpeg to decode and has an option to set -strict 1 in it's preferences (Advanced/Decoding). Unless I'm losing the plot, which is quite possible, that option is broken at the moment and has no effect. I'll test it again later.

None of the above specifically answers the question you asked tebasuna51 as I'm not sure I understand what the issue is there. Foobar2000 appears to be decoding 7.1ch (rear) encoded by QAAC 2.59, 2.60 and 2.61 the same way (I only checked m4a files, not raw AAC).
I wrote all of the above to explain why I'd probably avoid FhGAAC for 7.1ch audio. I'm assuming MeGUI and the AVIsynth decoders keep the correct/original channel layout when decoding 7.1ch. I don't use MeGUI for audio encoding much myself.

hello_hello

12th October 2016, 14:47

First of all say than all my test with 5.1 seems work fine with all qaac versions, .aac or .m4a output and all decoders.

The problem is only with 7.1.

I checked 2.60 because the change:

But you are right the version 2.59 is also buggy.
I can't trust in a encoder/decoder than itself don't preserve the channel order:

qaac260 --adts -o TEST.aac FL_FR_FC_LF_BL_BR_SL_SR.wav
qaac260 -D -o FC_FL_FR_SL_SR_BL_BR_LF.wav TEST.aac

qaac259 --adts -o TEST.aac FL_FR_FC_LF_BL_BR_SL_SR.wav
qaac259 -D -o SL_SR_FC_LF_BL_BR_FL_FR.wav TEST.aac

Are you sure that's correct? The channel mappings in red, how are you determining them? Is QAAC supposed to remap to wave file layout when it decodes?
7.1ch (front) should be encoded as (AAC channel order):
Centre FrontSurroundL FrontSurroundR Left Right SurroundL SurroundR LFE
If it's 7.1ch (rear) it'd be (AAC channel order):
Centre Left Right SurroundL SurroundR RearSurroundL RearSurroundR LFE

The output for 2.60 seems to make more sense than 2.59, assuming 2.60 isn't being remapped back to wave file channel order when it's decoded, but I can't quite seem to get my head around your result. It's as though 2.59 is remapping to wave file layout but not correctly (something to do with 7.1ch front being decoded as rear maybe?) and 2.60 is decoding it as 7.1ch rear but not remapping back to wave file layout at all.... or something.

Currently if I decode 7.1ch (rear) in an M4A with foobar2000 it seems okay, but if I extract the audio as AAC, foobar2000 reports it as unsupported. I'm not sure if that's something new or why it's happening.

tebasuna51

12th October 2016, 21:25

tebasuna51, did you have a chance to test fhgaacenc and fdkaac for 7.1? Thanks.
(Sorry I do not have fdkaac.) I found a fdkaac v 0.6.2 from 2016/05/01.

1) I don't like 7.1 audio, for me is a commercial idea to force buy new audio systems.
With only four speakers (FL,FR,BL,BR) is enough to offer a 2D audio surround.
Other question is 3D audio surround with ceiling speakers.
Then, for me is more than enough 5.1 audio.

2) But exist 7.1 audio systems.
Where you put the surround speakers?
The Side speakers at 90-100º and the Back speakers at 140º more or less. That correspond to channel layout: FL,FR,FC,LF,BL,BR,SL,SR
Do you change the speaker position to listen other channels layout?
Nope.
Any other channel layout 7.1 is usseless to end user. Then encode to other channel layout than FL,FR,FC,LF,BL,BR,SL,SR is usseless at all. Maybe for lab test but not for audio movie tracks.

3) Each codec can rename and reorder the channels internally without problems but must guarantee than a pair encoder-decoder preserve the channel order.
At least if I supply a standard 7.1 layout FL,FR,FC,LF,BL,BR,SL,SR to encoder I want the same decoder output.

Seems than AAC 7.1 have many problems about this:
Encoder/Decoder Bass Faad LWlibav NeroDec qaac
--------------- ---- ---- ------- ------- ----
fhgaacenc (1) (2) (3) (3) OK
ffmpeg (1) (4) OK OK (3)
fdkaac (4) (4) OK OK OK
NeroAacEnc (1) (4) OK OK (3)
qaac (m4a) (4) (4) OK OK OK
qaac (aac) (5) (2) OK - (4)

(1) Seven channels with all channels muxed.
(2) Wrong channel map: FC,SL,SR,FL,FR,BL,BR,LF
(3) Wrong channel map: SL,SR,FC,LF,BL,BR,FL,FR
(4) Wrong channel map: FC,FL,FR,SL,SR,BL.BR.LF
(5) Empty

@hello_hello
Yes, I'm sure than it's correct.

m4a from qaac seems work fine with libav patch (LWlibav, Foobar2000) but don't work with the old decoder faad and with last Bass decoder (2015-04-01)

EDIT: Add fdkaac test

Zathor

30th October 2016, 19:48

Pre-Halloween update:

2652 [HD Streams Extractor] for DVD/Blu-ray sources a prefix and suffix is attached to the output file name. Feature request #597
added warning if "Haali Matroska Muxer" is required
2651 [FileIndexer] added IFO as supported input files
improved PGC handling
2650 [OneClick] + for DVD/Blu-ray sources a prefix and suffix is attached to the output file name. Feature request #597
[FileIndexer] pgcdemux will be used in any case as a workaround for multi-angle DVDs
added MPLS as supported input files (OneClick)
2649 [ChapterCreator] added the PGC number to the output as suffix
2648 [VobSubber] added the PGC number to the output as suffix
preselect tracks based on the default language(s)
improved logging
2647 [PGCDemux] changed where the intermediate files are created
2646 [VobSubber] + use the default MeGUI output path if possible. Feature request #597
[ChapterCreator] for DVD/Blu-ray sources a prefix is attached to the output file name. Feature request #597
2645 [VobSubber] added option to demux all tracks in a single file (as before 2637). Feature request #595
2644 [HD Streams Extractor] added IDX/VobSub as unsupported format
2643 [x264] adjusted "--preset slow" settings (requires x264 2721+). Bug #855
2642 [L-SMASH Indexer] blocked the VC-1 codec as it is not properly supported anymore. Bug #851