MKVToolNix v24.0.0 released

[Nico8583]

Originally Posted by Mosu

Not really, sorry. I have so many things I'd rather work on for the time being… Patches would be very welcome, though.

Ok thank you, perhaps someone will release a patch. I think MakeMKV use this specification to create MK3D but I'm not sure.

[hello_hello]

Originally Posted by Mosu

I've just verified this. It is a bug, plain and simple. The intention of the column "default track in output file" is to show exactly how mkvmerge will set the flag when muxing taking all the different pieces of information into account that exist: order & types of tracks; existing states of this flag in input files; current settings.

Awesome! Thanks.

Originally Posted by Mosu

(re splitting and duplicate name checking)

I see your points, but I'm currently not that interested in fixing this. It should be fixed in the long run, though. It'd be nice if you could open an issue in my bug tracker for it; otherwise chances are I'll forget about it again. Thanks.

Will do. Cheers.

Originally Posted by Mosu

That's exactly what the "split by parts" functionality was introduced for. If all you need is a single piece of the file (e.g. the first 10 minutes) then use "split by parts" and use the syntax "-00:10:00" as the split points. That way it'll keep everything from the start of the file up to the ten minute mark. mkvmerge won't even append the "-001" splitting suffix in such a case, and you don't have to mess around with "maximum number of files" either.

Thanks. Obviously I haven't been paying enough attention.
Probably because it's previously been easy enough to split "after duration" and then abort the job after the first part is written.
Probably because it never occurred to me there's a "split by parts" equivalent to "split after duration".
I think the penny is droping and I'm understanding the distinction now. I'll play around....

Originally Posted by Mosu

Go to the "job output" tool and hit the "abort" button.

That's the button I expected to find at the bottom of the job queue window... or one of them.
It never occurred to me to look for it there. Thanks. Although...
When there's multiple jobs in the queue and it's running, the Abort button only aborts the current job, then the next one in the queue commences, so maybe I tried it and forgot about it when I realised it didn't stop the job queue from running.

Originally Posted by Mosu

That entry does indeed have a sub-menu with two entries, "stop after all running jobs have finished" and "abort all running jobs and stop immediately" which hopefully should be self-explanatory. If that sub-menu doesn't show up then it may indeed by an XP thing.

I think it's the only problem I've found that might be XP related. I have a Linux PC set up now. It'll be a while before I'm ready to jump ship completely but I probably should wander over there for future testing. I'll install MKVToolNix on it later.
The problem may also be menu timing related. I have XP configured so hovering the cursor over menus doesn't automatically open them unless I hover for a really long time, so in practice menus don't open until I click on them. Very occasionally a particular program is unhappy about that. The rest of the MKVToolNixGUI menus seem to be following the rules, but I'll change the setting later when I can reboot to see if the sub-menu starts working and if it does I'll report back, otherwise I'll assume it's XP's fault.

Originally Posted by Mosu

I've tried to minimize the number of buttons that are shown somewhat. The reason is that the GUI has so many more options than the old one ever had (just look at the context menus for what I mean). The whole idea of the job queue is that you usually don't interact with it that much. Ideally it should sit in the background doing its thing.

I'd wonder if it's at least as equally important to be able to interact with the job queue easily. When there's lots of jobs in the queue that could take a long time to run it's nice to have some simple "pause/stop/abort/continue" control.
To me it just "feels" like that's where buttons should be, rather than in a drop down menu at the top, because that's where I still keep expecting to find them. Probably because you set a precedent by endowing the Merge and Job Output windows with buttons. Just my 2 cents worth from a user perspective, but I'll get used to it.

Originally Posted by Mosu

The GUI is already very flexible regarding its configuration. The cost of this is improved complexity in development, testing and maintenance (including bug tracking!). Another cost is that the preferences dialog becomes more and more complex with each choice a user can make.

I thought I was being a tad optimistic with the tab features but I was on a bit of a roll. I have one more optimistic tab related feature request though. I'll save it for the next post.....

Originally Posted by Mosu

What I may think about is making the option apply to tracks whose language is currently set to "undefined" ("und"), too. Again, please open an issue for it. Thanks.

The M4A files created by QAAC don't appear to have a language set. Opening one in MKVMergeGUI 7.8.0 shows the language as "undefined" and there's no language displayed when opening the M4A with MediaInfo.
I'll wander over to the bug tracker. Thanks again.

Edit: I've added the requested issues to the bug tracker under the ID "this-username-is-already-taken".

Cheers.

[hello_hello]

Tab feature request for the Merge window.....

I'd like to be able to see, by looking at the Input/Output/Attachment tabs, whether any setting under each tab is currently something other than the default. By "default" I mean the default setting for the GUI combined with any user preference that might change those settings.
Something simple would do. Changing the colour of the tab's text, or changing the text to italic etc.
The reason for this request is simply to over-come my being to stupid to always check things for myself.

In the past I'd most often forget to check the File Title. This seems to be less of a problem now as the "remove all files" function resets it, but still it'd be nice to know by glancing at the tabs if I've forgotten to disable splitting, or there's an attachment I didn't know about, or even to remind me I haven't specified a File Title. That sort of thing.

Speaking of the Attachments tab, I'd become quite used to the "enable all" and "disable all" buttons, and what could once be achieved with a single left click now requires 2x menu opening and 4x clicks. Or two clicks if you manually highlight all the attachments first.
While I'd not complain if those buttons were to re-appear, any chance of including "enable all" and "disable all" under the right click menu? I might take the liberty of adding this request to the tracker now, while I'm adding the others. I'll leave the request regarding the tabs until I know I'm not being silly.

Cheers.

[Mosu]

Originally Posted by hello_hello

I'd like to be able to see, by looking at the Input/Output/Attachment tabs, whether any setting under each tab is currently something other than the default.

Sorry, but that won't be implemented. It would be very time-consuming to do, it would be confusing to users (why is that tab displayed differently!?), it's for your special use-case. Consider starting with new settings instead of re-using the existing settings if you're so concerned about forgetting to reset settings.

Speaking of the Attachments tab, I'd become quite used to the "enable all" and "disable all" buttons, and what could once be achieved with a single left click now requires 2x menu opening and 4x clicks. Or two clicks if you manually highlight all the attachments first.

Sorry, won't be implemented either as I consider that to be a duplication of already-existing functionality for the sake of saving two mouse clicks tops.

[Mosu]

Originally Posted by hello_hello

The M4A files created by QAAC don't appear to have a language set. Opening one in MKVMergeGUI 7.8.0 shows the language as "undefined" and there's no language displayed when opening the M4A with MediaInfo.

Each MP4 file can have a language stored in its "mvhd" atom ("movie header"). If if contains a valid ISO 639-2 language code then mkvmerge will use it and the GUI will see that as the container providing the language. If the MP4 file doesn't contain such a valid code or if it's simply empty then mkvmerge won't emit the language tag and the GUI will use the default. I have files here for both cases and have just verified that when adding a file without a valid ISO 639-2 language code the GUI will set the default language specified in the preferences.

The thing is that "und" is a valid ISO 639-2 language code. That's probably what you have in your files. Hence the proposed extension to apply the default if the provided language is "und".

Edit: I've added the requested issues to the bug tracker under the ID "this-username-is-already-taken".

Much appreciated. Thanks.

[hello_hello]

Originally Posted by Mosu

Sorry, but that won't be implemented. It would be very time-consuming to do, it would be confusing to users (why is that tab displayed differently!?), it's for your special use-case.

Fair enough if it'd be time consuming. I thought as much, but you never know if you don't ask. I don't think I'd blame it on the average user being too silly to understand though. Working out when the default flag is going to be applied to a stream has traditionally required years of study by comparison.

Originally Posted by Mosu

Sorry, won't be implemented either as I consider that to be a duplication of already-existing functionality for the sake of saving two mouse clicks tops.

Compared to a single click for the old GUI, it's mostly a difference of.... a right click to open a menu, a left click to "select all", a right click to open the menu again, and a left click to "disable all".
Personally I think the "select all" right click option is somewhat redundant because it would be better split into "enable all" and "disable all" options, unless there's another reason for wanting to "select all" attachments? I don't think there's any other choices though, so you'd have enable/disable options for selected attachments and the same again for all attachments. The latter two wouldn't need to change which attachments are selected, so they could also help out by allowing you to... for example.... select some of the attachments, click the "disable all" option, then the "enable selected" option, which would leave you with just the selected attachments enabled. That sort of thing. I'm pretty sure "select all" could retire.

While resisting writing an essay on duplicated MKVToolNixGUI functionality, I was just wanting to point out the "Enable/Disable all" thing is a step backwards compared to the old GUI, even if it's a minor one in the grand scheme of things.

Originally Posted by Mosu

The thing is that "und" is a valid ISO 639-2 language code. That's probably what you have in your files. Hence the proposed extension to apply the default if the provided language is "und".

With MediaInfo in gobbledygook mode, and looking at an M4A written by QAAC, I found four instances of "language".

Language: 21956 (0x55C4)
Language: 0 (0x00000000) (three instances)

Which means nothing to me, but it probably means something to you. In normal text or html view MediaInfo doesn't display a language field.

Originally Posted by Mosu

Much appreciated. Thanks.

You're welcome.

[hello_hello]

Just a little AAC oddity.....
For some reason MKVToolNixGUI shows LC-AAC audio as having a bitdepth of 16 bits when it's an an M4A/MP4 container. When it's in an MKA container or it's RAW AAC, MKVToolNixGUI correctly shows no bitdepth.

For HE-AAC, which aside from being "HE" would be stereo 44100Hz, MKVToolNix displays it as 22050Hz, 1 channel, 16 bit. It does whether it's in an M4A or MKA container, or whether it's RAW AAC (minus the 16 bit part for MKA or RAW AAC).

Something I've never quite understood.....
When muxing RAW LC-AAC, MKVToolNix offers a warning about not being able to automatically detect if it's HE-AAC, which seems a little odd as every time I've loaded RAW HE-AAC for muxing it's been automatically detected. The old GUI was the same.
The new GUI adds to the fun by displaying "determine automatically" in the field for AAC audio, but for LC-AAC it then offers a warning when muxing that it can't be determined automatically after-all.

Anyway..... would there be any chance of an option to disable the warning regarding muxing RAW AAC and it being muxed the wrong way?
Mind you in a perfect world it'd probably better to know when there's warnings, so would there be a chance of an additional option for the job queue? Currently "remove completed jobs from queue even if there were warnings" stops the warning icon from flashing when muxing is completed. Could there also be an "even if there were warnings" option that doesn't?

Thanks.

[hello_hello]

Re the problem with the "Job queue/Stop Job queue" sub menu not opening:

I changed the menu opening setting in the Windows registry and the menu started working (no reboot required, as it turned out).
I discovered there's another effected MKVToolNixGUI menu too, so there's:
"Job queue/Stop Job queue"
and the right click option in the merge window:
"Select all tracks of a specific type".
Both have sub menus that failed to open for me. I'm guessing this mightn't just be an XP issue, so you may want to check. The registry entry in question is.... (this is the default setting)

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Control Panel\Desktop]
"MenuShowDelay"="400"

That means there's normally a 400ms delay before a sub-menu opens automatically. I had it set to it's maximum value of 65534, so you've either got to be very patient, or a sub menu won't open until you click. That's the part that's not behaving for MKVToolNixGUI (at least on XP). Clicking does nothing. When I reset the registry entry to it's default value, both menus open automatically after a short hover of the cursor (how do people use menus like that, it's so annoying?).
I've reduced the registry value to 5000 for the moment so the rest of the Windows menus are tolerable and I can use those two MKVToolNix sub-menus if I highlight the menus with the cursor and wait five seconds for them to open.

I had a similar problem recently with the fork of the Extension Preferences Menu add-on for Pale Moon. It's menu wasn't following the rules, but the author fixed it for me. He's a very nice fellow.
Prior to the fix the add-ons menu and the arrow to the right were a single menu, and the sub-menu opened whenever the menu was highlighted (the opposite problem). He somehow changed it so the arrow to the right was like the arrow for a drop down arrow next to a button (same as the rest of those menus). I don't understand how any of that works, but the add-ons menu then started behaving like the rest of the Pale Moon menus.
I don't know if any of that will help, but I thought I'd mention it in case it's not just an XP problem, you want to look at it, and it does.

[Mosu]

Originally Posted by hello_hello

I'm guessing this mightn't just be an XP issue, so you may want to check. The registry entry in question is.... (this is the default setting)

I'm sorry, but I don't support changing such things in such a way. I'm using default menu classes from Qt; if they work with your custom setting: great. If they don't then I don't consider this to be my problem.

[Mosu]

[QUOTE=hello_hello;1767895For some reason MKVToolNixGUI shows LC-AAC audio as having a bitdepth of 16 bits when it's an an M4A/MP4 container.[/quote]

What mkvmerge reads and shows is the bit depth header field that's part of the MP4 container.

When it's in an MKA container or it's RAW AAC, MKVToolNixGUI correctly shows no bitdepth.

Correct, and it most likely never will as that information is not easily available by decoding the raw AAC headers themselves.

For HE-AAC, which aside from being "HE" would be stereo 44100Hz, MKVToolNix displays it as 22050Hz, 1 channel, 16 bit. It does whether it's in an M4A or MKA container, or whether it's RAW AAC (minus the 16 bit part for MKA or RAW AAC).

Yeah, and? That's the value signalled by HE-AAC headers: _half_ of the _output_ sampling frequency. This is correct, too.

When muxing RAW LC-AAC, MKVToolNix offers a warning about not being able to automatically detect if it's HE-AAC, which seems a little odd as every time I've loaded RAW HE-AAC for muxing it's been automatically detected. The old GUI was the same.

There are two ways to differentiate between normal AAC and HE-AAC:

1. if the AudioSpecificConfig() element signals it (such an element is only present if AAC is read from certain container formats such as MP4 and Matroska but not in a raw AAC bitstream)
2. if the encoded AAC bitstream contains SBR extension elements

As mkvmerge doesn't decode the whole AAC bitstream it cannot use method 2 and must rely on method 1.

As stated above method 1 doesn't apply to raw AAC bitstreams (ADTS files), though, as they don't contain an AudioSpecificConfig() element. For such raw files mkvmerge employs a simple heuristic: if the signaled sampling frequency is 24.000 or less it assumes the input to be HE-AAC; otherwise it assumes normal AAC. As "heuristic" is just a fancy word for "guessing" mkvmerge may be wrong about particular files; hence the warning.

I don't want to clutter the GUI and mkvmerge with special-case options such as the one you've just described. I may think about getting rid of the warning entirely, though.

[Mosu]

Originally Posted by hello_hello

Personally I think the "select all" right click option is somewhat redundant because it would be better split into "enable all" and "disable all" options, unless there's another reason for wanting to "select all" attachments?

The thing is that enabling/disabling all is in fact not the only thing a user might want to do. She might also just want to disable nine of the twelve attachments; therefore changing "enable selected" to "enable all" would rob her of that functionality.

So can we please drop this particular topic? I'm certain that you've already spent way more time talking to me about that feature than you will ever lose by having to open the context menu twice instead of once. Thanks.

With MediaInfo in gobbledygook mode, and looking at an M4A written by QAAC, I found four instances of "language".

Language: 21956 (0x55C4)

This is where it comes from. In MP4 language tags are stored as two bytes encoding three characters (each character takes five bites). The value 0x55C4 is decoded as follows:

0x55c4 = 0b10101 01110 00100
0b10101 + 0x60 = 0x75 = 'u'
0b01110 + 0x60 = 0x6e = 'n'
0b00100 + 0x60 = 0x64 = 'd'

Your file does have a language tag, it's "und".

[Mosu]

Originally Posted by hello_hello

Mind you in a perfect world it'd probably better to know when there's warnings, so would there be a chance of an additional option for the job queue? Currently "remove completed jobs from queue even if there were warnings" stops the warning icon from flashing when muxing is completed.

That doesn't make any sense. If the job emitted a warning and is removed from the queue why should the warning indicator flash? You couldn't even tell which job caused the warning, never mind check what the warning was about.

[foxyshadis]

I'm not sure why bit-depth is even reported for a lossy audio format at all. It can be decoded to 16- or 24-bit, or float for that matter, as the decoder wishes, it's completely separate from what was fed to the encoder. Only lossless should have a defined bit-depth.

[Mosu]

Due to user requests. And mkvmerge doesn't set those header fields in MP4, it only reports them if they are set.

[hello_hello]

Originally Posted by Mosu

I'm sorry, but I don't support changing such things in such a way. I'm using default menu classes from Qt; if they work with your custom setting: great. If they don't then I don't consider this to be my problem.

Fair enough, but what if I'm not doing something as basic as changing a legitimate registry entry? What if I'm using a different Windows theme and something breaks? I'm just wondering where the line is and what bugs I shouldn't bother trying to track down and report.
For the record, I didn't change that registry entry on a whim. In fact I had no idea which registry entry was involved until I investigated yesterday. TweakUI is an official Microsoft utility. It works for XP, Vista and Windows 7. If it breaks Qt, it probably should be reported as a Qt bug. I can't imagine I'm the only person using TweakUI to tweak Windows, but maybe the other 99.999% of people who think MKVToolNixGUI has broken menus haven't gone to the trouble of working out why and reporting the problem.

Originally Posted by Mosu

What mkvmerge reads and shows is the bit depth header field that's part of the MP4 container.

Correct, and it most likely never will as that information is not easily available by decoding the raw AAC headers themselves.

Lossy audio has no bitdepth. I don't know why there's bit depth information in the M4A container for AAC.
Maybe bitdepth information is compulsory? Maybe it's supposed to indicate the bitdepth of the source? Maybe it's supposed to state the bitdepth to which the audio should be decoded? I don't know, but AAC has no bitdepth.

Originally Posted by Mosu

Yeah, and? That's the value signalled by HE-AAC headers: _half_ of the _output_ sampling frequency. This is correct, too.

It's obviously not correct for the whole audio, and it seems misleading to me. Stereo 44100Hz AAC audio isn't single channel 22050Hz, 16 bit, even if it is HE. Only the HE part is (except it's not 16 bit).

Depending who's writing the file, MediaInfo displays something that's technically correct, or it can get confused, but you've got to give it credit for trying.

QAAC:
Channel positions : Front: L R 
Sampling rate : 44.1 KHz / 22.05 KHz

NeroAAC:
Channel(s) : 2 channels / 1 channel / 1 channel 
Channel positions : Front: L R / Front: C / Front: C 
Sampling rate : 44.1 KHz / 44.1 KHz / 22.05 KHz

Originally Posted by Mosu

As stated above method 1 doesn't apply to raw AAC bitstreams (ADTS files), though, as they don't contain an AudioSpecificConfig() element. For such raw files mkvmerge employs a simple heuristic: if the signaled sampling frequency is 24.000 or less it assumes the input to be HE-AAC; otherwise it assumes normal AAC. As "heuristic" is just a fancy word for "guessing" mkvmerge may be wrong about particular files; hence the warning.

Thanks for the info.

Originally Posted by Mosu

I don't want to clutter the GUI and mkvmerge with special-case options such as the one you've just described. I may think about getting rid of the warning entirely, though.

I admire your belief that every suggestion you wouldn't necessarily use yourself falls under "special case".

Originally Posted by Mosu

The thing is that enabling/disabling all is in fact not the only thing a user might want to do. She might also just want to disable nine of the twelve attachments; therefore changing "enable selected" to "enable all" would rob her of that functionality.

I never said to touch the "enable selected" option, only to split "select all" into "disable all' and "enable all". I even went to the trouble of explaining how they'd probably be more useful than "select all", so I assume you didn't understand what I wrote.

Have a look at the right click options for individual streams in your own MKVToolNixGUI software under the Merge window. It has the "enable all" and "disable all" options I've requested, yet for some reason they're appropriate for multiple streams but not for multiple attachments. I don't understand why, or why you'd prefer a lack of consistency.

Originally Posted by Mosu

So can we please drop this particular topic? I'm certain that you've already spent way more time talking to me about that feature than you will ever lose by having to open the context menu twice instead of once. Thanks.

You can stop discussing the subject any time you like. You're welcome.

You dragged the "way more time" argument out a while ago when I went to the trouble of reporting bugs and making suggestions for the old GUI, making me wish I hadn't bothered. I think I've read that one several times now. It's a strawman argument and comes across as refusing to acknowledge you mightn't be right.
Mind you, I'm sure you could have implemented the requested feature in the time you've spent arguing against it. Does saying that help you see how irrelevant.... and to be honest.... a little offensive.... the "way more time" argument is?

Originally Posted by Mosu

Your file does have a language tag, it's "und".

That's fine, I just didn't know either way, but I thought you might want to confirm that's the case.

Originally Posted by Mosu

That doesn't make any sense. If the job emitted a warning and is removed from the queue why should the warning indicator flash? You couldn't even tell which job caused the warning, never mind check what the warning was about.

What's the Job Output window for? Does a job have to remain in the queue for it to display the warning?
I haven't really looked at the Job Output window too closely yet, but I'll admit I assumed if it contained warnings it'd be obvious which jobs those warnings were for even if they were no longer in the job queue. That's not the case?

Thanks.

[isidroco]

1) Is there a way to generate chapters based on Filename?

2)
I have some problems with mkvmerge help file, it's localized to my language, but parameters in single brackets should NOT be translated. Another issue is that special characters "áéíóúñ" are incorrectly displayed in Command window (it would be better to avoid them). It is VERY important to offer IN ENGLISH a way to display english help, as a portable application I used it in Germany on a lent computer and can't get any command line help as I don't understand german.

--generate-chapters <modo>
Genera capítulos automáticamente según
el modo ('al-unir' o 'intervalo:<duración>').
--generate-chapters-name-template <plantilla>
Plantilla para los nombres de capítulos recién creados
(por defecto: 'Capítulo <NUM:2>').

[Mosu]

Originally Posted by isidroco

1) Is there a way to generate chapters based on Filename?

No.

2) I have some problems with mkvmerge help file, it's localized to my language, but parameters in single brackets should NOT be translated.

I'll forward this to the appropriate translator. Which language is used?

Another issue is that special characters "áéíóúñ" are incorrectly displayed in Command window (it would be better to avoid them).

Non-ASCII characters show up just fine on my German Windows with a German translation as well as with e.g. the Portuguese translation. So this works in general; I have no idea why it doesn't in your case.

It is VERY important to offer IN ENGLISH a way to display english help

That's easy: "mkvmerge --ui-language en --help"

[Mosu]

Originally Posted by hello_hello

Fair enough, but what if I'm not doing something as basic as changing a legitimate registry entry? What if I'm using a different Windows theme and something breaks? I'm just wondering where the line is and what bugs I shouldn't bother trying to track down and report.

Hmm, I don't have strict rules. It's a combination of "how often do users do that", "how much work would it require to fix", "is it a problem in my program or in one of the libraries it uses" and a couple of other soft factors. Another example where I drew the line is third-party theme engines that enforce that progress bars are very wide (they probably assume that a top-level window will always contain a single progress bar only – but MKVToolNix GUI contains two, making the main window unusably huge with such themes). See this issue for an in-depth discussion and how it was discovered.

It works for XP, Vista and Windows 7. If it breaks Qt, it probably should be reported as a Qt bug.

Indeed, that's where it should be fixed.

but maybe the other 99.999% of people who think MKVToolNixGUI has broken menus haven't gone to the trouble of working out why and reporting the problem.

I cannot judge how many people have problems with the menus in MKVToolNix GUI as you're the only one who has reported such issues ever. Therefore I'd guess "not many". The number of people having reported problems with the aforementioned wide GUI due to 3rd party theming issues is higher than that.

Lossy audio has no bitdepth. I don't know why there's bit depth information in the M4A container for AAC. Maybe bitdepth information is compulsory? Maybe it's supposed to indicate the bitdepth of the source?

Me neither That it's the source's bit depth seems like a sound assumption. Users have requested the information to be present, therefore I expose it.

It's obviously not correct for the whole audio, and it seems misleading to me. Stereo 44100Hz AAC audio isn't single channel 22050Hz, 16 bit, even if it is HE. Only the HE part is (except it's not 16 bit).

mkvmerge only reports the raw values from the container; it doesn't interpret them a lot. That's not what I designed it for (and I certainly don't want to turn it into a bad and half-assed MediaInfo clone). For such in-depth information people should use other tools, and that's why the GUI provides an easy way to start MediaInfo for any file added to the GUI.

Depending who's writing the file, MediaInfo displays something that's technically correct, or it can get confused, but you've got to give it credit for trying.

To be honest I don't give MediaInfo much credit for trying as I've had countless reports of confused users who think MediaInfo is always correct and where it turned out that it wasn't, that it was just guessing and users took it at face value etc. I do recognize the usefulness of MediaInfo, but it has been a source of a lot of support requests (and therefore work for me) even though the problem wasn't on my end. But that's my personal beef with MediaInfo; it remains highly useful, of course.

I never said to touch the "enable selected" option, only to split "select all" into "disable all' and "enable all". I even went to the trouble of explaining how they'd probably be more useful than "select all", so I assume you didn't understand what I wrote.

That assumption is indeed correct – I misunderstood you. I'm sorry for not reading your earlier comment properly. Splitting "select all" is useful; I'll implement it.

I admire your belief that every suggestion you wouldn't necessarily use yourself falls under "special case".

I definitely don't think that. My thought process was more along the lines of adding a feature to circumvent a certain warning will only help those that know that the feature actually exists, and I'd prefer a solution that helps more users out of the box. Hence me saying that I'd think about removing the warning altogether – it would remove the need for such an option.

You dragged the "way more time" argument out a while ago when I went to the trouble of reporting bugs and making suggestions for the old GUI, making me wish I hadn't bothered. I think I've read that one several times now. It's a strawman argument and comes across as refusing to acknowledge you mightn't be right.

I'm wrong often enough, and yes, I can be stubborn (as I like being right…). I'm aware of that fault.

In this case the "too much time" argument was meant for one and only one specific feature request: making visible to the user which settings have changed since saving/starting a job. I do have code in place that checks whether the whole configuration has changed since it's been saved – by mis-using the "save merge settings" functionality (I save the current settings to a temporary file and compare that to a saved state from the last save point). However, that functionality is decoupled from the GUI completely, and adding change detection for each and every GUI control would indeed be a lot of work. It would certainly take a couple of days to implement and iron out all bugs.

The other features I've refused to implement are not due to immense amounts of work required.

And I do spend a lot of time answering your posts as you've spent a lot of time writing them. When a user invests so much time in posts & bug reports then (s)he deserves as much effort on my end. Therefore I try to explain my choices and reasons in more detail than for simple requests such as "please implement support for format XYZ kkthxbye".

What's the Job Output window for? Does a job have to remain in the queue for it to display the warning?

The number of warnings and errors displayed in the status bar are from the jobs still present in the queue, yes.

I haven't really looked at the Job Output window too closely yet, but I'll admit I assumed if it contained warnings it'd be obvious which jobs those warnings were for even if they were no longer in the job queue. That's not the case?

The default job output window contains the output of all jobs run in the current session (depending on the GUI's configuration). As soon as you restart the GUI the window will be empty again losing any information about warnings and errors that have occurred during earlier jobs.

However, the job queue defaults to not removing problematic jobs, especially to allow the user to look at results of problematic jobs later and not just while the GUI's still running. The user can then go to the job queue and double-click on the job in question, and a new job output tab is opened solely for this job.

If the warning and error indicators in the status bar would include both jobs still in the queue and ones visible in the default job output tab then it would be confusing which warnings those indicators refer to.

[hello_hello]

Mosu,
Thanks for the reply. I'm not upset or anything. Sometimes communication via forum posts can be a bit frustrating when it comes to getting a point across, but it's all good.
If I do go into "shitty mode" which happens now and then, I've usually forgotten why 10 minutes after I post. Life's too short.

Thanks for reconsidering the "enable/disable all" options.
Any chance I'd be able to wear you down and get you to reconsider some buttons at the bottom of the Job Queue window? I swear they should be there because I keep looking for them. Every single time.
The other button "wish" I have would be for an Abort button at the bottom of the Merge window. I know it's never been there before but the job window automatically opened for the old GUI and presented you with an abort button. For the new GUI I go to click on "Abort"..... wonder for a second where the button went.... ahhh that's right it's under the Job Queue window. Switch to the Job Queue window..... damn..... I think the muxing has finished anyway..... I'll get used to it one day.

The warning messages are no big deal, but I'd hoped there'd be a combination of settings that'd remove jobs with warnings from the queue but still let me know if there were warnings so I could have a look..... to save having to manually delete those jobs while not missing out on anything.
What about something to click on (ie the warning indicator) that'd reset the warnings and delete any jobs with warnings from the queue? Too hard?? It's no big deal anyway. It was just a thought I had at the time.

By the way.... if a feature request is too time consuming to implement.... I get that. I wouldn't expect you to waste a lot of time you could be spending on other things, such as rethinking whether MKVToolNixGUI should check for and set any language written to the audio stream as it does for delays. I still think that'd be a good idea.
MKVCleaver can write the language info now (although it uses the wrong format at the moment). gMKVExtractGUI writes it. MeGUI writes it and will use it when muxing. It'd be great if MKVToolNix could join the party.

I might have a look at reporting the Qt menu bug at some stage (fairly soon). It'd be nice if it was fixed. The default Windows menu settings drive me nutty. If I say "XP" though I might get laughed at, but I haven't got any newer Windows handy yet to check it's the same for Win7. Oh well.....

Cheers.

[Mosu]

Originally Posted by hello_hello

Any chance I'd be able to wear you down and get you to reconsider some buttons at the bottom of the Job Queue window?

I don't think so, sorry

The other button "wish" I have would be for an Abort button at the bottom of the Merge window.

That won't happen either. Due to the queue running asynchronously the currently shown job in the merge tool doesn't have to have anything to do with the currently running one.

But you should give the following setting a try: "Preferences" → "Jobs & job queue" → "Always switch to the job output tool after starting one immediately". Maybe that'll suit your workflow better.

What about something to click on (ie the warning indicator) that'd reset the warnings and delete any jobs with warnings from the queue?

You can already right-click on those indicators and a menu will open with a couple of actions. I might extend that to such a functionality.

On the other hand: please give the option "Preferences" → "Jobs & job queue" → "Remove completed jobs older than x days" a try. It defaults to 14 days, but you might want to try setting it to 1 day and see if that's enough for you to keep the queue tidy without me having to implement anything else.

…such as rethinking whether MKVToolNixGUI should check for and set any language written to the audio stream as it does for delays. I still think that'd be a good idea.

I'm sorry, but I have reasons why I won't implement such functionality.