MKVToolNix v24.0.0 released

[Nico8583]

Hi Mosu,

Does the last mkvmerge is able to create TrackOperation (http://www.matroska.org/technical/specs/index.html#TrackOperation) entries ? If yes, how to do that exactly ?
Is there any improvement about TrackOperation since 2011 ?
Thank you !

[Mosu]

The discussion didn't sound like it would ever get us a simple tag to assign the MVC plane to a track, rather re-implement the entire structures on a per frame basis, which MKV doesn't even have the correct structures for yet. So don't blame us for wanting something that works in 2016 and doesn't require writing a complex handling system for one container, while still keeping the MVC stuff for other containers.

Wanting something generic that works with everything is nice and all, but I prefer to remain realistic.

And those would have been arguments that could have changed the discussion to focus on a solution that's simpler and quicker to implement while leaving a more complex solution for the future. Instead you've added a field that other software started to use already and that is already confusing users and other developers of Matroska-related software.

Please don't take this is assigning blame. I'm not about who's right and who's wrong; that doesn't get us anywhere.

I'd much rather restart the discussion from January/February with some new facts. Could you list some more information about what typical 3D videos use and need today? I'll gladly post those on the relevant mailing lists. Neither Steve Lhomme nor I have a lot of experience with 3D video (if at all), therefore the first step for us is to understand the requirements; both the ones for the common cases as well as the ones for complex cases.

If all you need for 95% of the files is a simple integer field (call it "3D plane" or something like that) that's to be interpreted like a corresponding field from the 3D video specs of some codec then adding that in both the official specs and MKVToolNix is easy; it can be done within a couple of days. Such a system could later be expanded with additional header fields that specify the mode that the "3D plane" field is to be interpreted. But those additional fields don't have to be specced out right away.

Thanks.

[Mosu]

I have an MKV with a video and audio stream. The default flag for each is set to "no" when I open it with MKVMergeGUI 7.8.0 to check it. When I open the MKV with version 9.1.0, I see this:

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.

I'll fix this.

[Mosu]

Why does the : after the drive letter get deleted automatically when I delete the drive letter in the output field?

A couple of weeks ago I've implemented a mechanism for sanitizing the output file name so that characters that aren't allowed within a file name are removed automatically. This includes : which may only occur as the second character in which case the first character denotes the drive letter.

Unfortunately this is indeed interfering with changing the drive letter the way you've just described. I'll look into this and think of a way to improve it. As a workaround you can first select the wrong drive letter and then type the intended letter which will instantly replace the selected text. That way the colon will be preserved.

Also, if I only type an f and forget to add the : because I didn't notice or remember the missing : after the drive letter the job still runs and put the file somewhere. :confused: It doesn't flag the output path as being bad.

That's because such a path isn't bad. It's a relative path instead of an absolute one. It's relative to the GUI's working directory which is your user's profile directory. You should therefore look into e.g. C:\Users\YourUserName\f\… for the resulting file.

[Mosu]

mkvmerge always sets one track of each type to default, unless you explicitly set every track to default:no.

That's not entirely correct. It will also take the state of the "default track" flag from the source containers into account. At the moment the only container to provide such flags is Matroska.

The nit & grit of how mkvmerge decides the flag's states is listed in this FAQ entry (https://github.com/mbunkus/mkvtoolnix/wiki/Default-and-forced-flags-and-default-yes-no-in-the-GUI).

[Mosu]

@hello_hello: Thanks for your detailed observations & requests.

There's a difference between the way the new and old GUI's handle duplicate file names and the old GUI's method was more fun. ;)

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 (https://github.com/mbunkus/mkvtoolnix/issues/) for it; otherwise chances are I'll forget about it again. Thanks.

Unless there's a circumstance under which setting a value of "1" as the maximum number of files is acceptable, might it be an idea for the GUI not to allow you to set "1" via the up/down arrows?

Same as above.

It'd be nice if it could just output one part though, given it's fairly similar to splitting, only without writing the additional parts.

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.

I'm prepared to accept I'm just too silly to work it out, but how do you abort a running job?

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

It might be (dare I say it) an XP thing, but the "Job Queue/Stop Job Queue" menu appears not to function. The "Stop Job Queue" menu has an arrow, indicating it may lead to a sub-menu, but it doesn't open to anything.

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'm a little curious. Why are there no buttons at the bottom of the job queue window? "Start Jobs", Abort Jobs", "Pause Jobs".... that sort of thing.

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.

MKVToolNix has a setting in preferences labelled "clearing settings automatically". I have it set to "remove input files". Sometimes though, I don't want to, for example when remuxing an MKV while adjusting the audio delay, knowing it might require a few attempts to get it right. I wish there was a way to tell the GUI "please don't remove the input files this time". Maybe the "Start muxing" button could have a drop down arrow similar to the "Add source files" button? Maybe the "Add job to queue" button could have a drop down arrow too?

That's not such a bad idea. Can you please open an issue in my bug tracker (https://github.com/mbunkus/mkvtoolnix/issues/) for this one, too? Again with forgetting about it otherwise.

I don't think option B is a good one, but when closing MKVToolNixGUI's only "output file" tab, it seems sensible for it to automatically create a fresh one.

Maybe, maybe not. You could also load an existing setting file. You wouldn't need that extra blank tab in that case.

When I'm ruler of the world, any program using tabs will have to include an option to remove the red "x" from each tab so you can click on a tab without accidentally closing it. The red "x" option would be substituted with middle click. A right click close tab option might be considered on an individual basis.

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.

This is fine for a certain group of users (I'm one of those; I prefer configurabitly and flexibility over convention), but for others it's very off-putting. I'm therefore hesitant to make each and every thing in the program configurable, and not showing the close buttons is one of them for the time being. Sorry.

There's an option in preferences to set a default language when opening certain streams without a language previously set. I'm still struggling with the rules for this one but one annoyance for me is the way AAC audio is handled.

This option is only taken into account if the source container format doesn't provide a language. The MP4 container does; therefore the option isn't used in such cases. This is by design.

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 (https://github.com/mbunkus/mkvtoolnix/issues/). Thanks.

[Mosu]

Is there any improvement about TrackOperation since 2011 ?

No. I haven't worked on this at all yet.

[Nico8583]

No. I haven't worked on this at all yet.
Ok thank you, do you plan to work on this feature in your to-do list ?

[Mosu]

Ok thank you, do you plan to work on this feature in your to-do list ?

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

[Mosu]

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.

New pre-builds (https://mkvtoolnix.download/windows/pre/) are available. Build numbers 01213 and higher contain the fix.

[Nico8583]

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]

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.


(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 (https://github.com/mbunkus/mkvtoolnix/issues/) for it; otherwise chances are I'll forget about it again. Thanks.

Will do. Cheers.

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....

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.

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.

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. :)

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.....

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 (https://github.com/mbunkus/mkvtoolnix/issues/). 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]

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]

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]

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. ;)

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.

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.

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. :)

http://s32.postimg.org/7qzkabd3p/Pale_Moon.gif

[Mosu]

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]

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

[quote]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:

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)
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]

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]

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]

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.

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.

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


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.

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".

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.

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?

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.

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]

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]

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 (https://github.com/mbunkus/mkvtoolnix/issues/1349) 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]

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 (https://github.com/mbunkus/mkvtoolnix/wiki/Detecting-track-language-from-filename) why I won't implement such functionality.

[hello_hello]

I'm sorry, but I have reasons (https://github.com/mbunkus/mkvtoolnix/wiki/Detecting-track-language-from-filename) why I won't implement such functionality.

As briefly as I can, given the amount of wrong to be refuted.... :)

A sample audio extracted with gMKVExtractGUI:
S01E05 Affairs (1992)_track2_eng_DELAY -33ms

How would a muxer know the language is English? Probably the same way it'd know there's not supposed to be an audio delay of 01E, or 05, or 1992.... I suspect.

However you could take it a step further easily enough:
S01E05 Affairs (19912)_track2_[eng]_DELAY -33ms

I'm sure one of the extraction programs does that already. If you can find a legitimately named file including square brackets containing something that could be mistaken for a language code.... well after eating several hats I'd suggest everyone make this a new standard.

S01E05 Affairs_track2_[[eng]]_DELAY -33ms

MeGUI will automatically apply a language when using MKVToolNix for muxing if it's a full word (ie English) or if it's a three letter language code. Unfortunately MKVCleaver currently uses a two letter code if I remember correctly, but I think MeGUI would automatically set the following audio to French:
the_french_connection.ac3
or maybe this:
the_connection_french.ac3
so the current lack of a standard way to do things means very occasionally it does make a mistake. I'm still yet to read a complaint about it in the MeGUI thread though. Given you took the time to write that explanation I suspect you could reduce support questions by implementing the feature rather than not implementing it. You might even be able to reduce questions on the topic to zero as is the case for MeGUI. :)

I wouldn't take the language from a container file name. Only if it's specified for the individual streams, and if it's wrong there.... well if it comes down to that are there many settings that can't be set incorrectly at some stage? Automating a feature doesn't mean the user shouldn't still check things.

Realistically, MKVToolNix already does most of this. As long as it's opening streams in a container such as an MKV or MP4 etc, but if you extract the audio first it's every man for himself. Well these days MKVToolNixGUI will automatically set a language based on your preferences which may or may not be correct.

It does seem a pity the three letter language code would be restricted to English versions..... but there's a lot of English speaking MKVToolNix users out there. I suspect most people would come to recognise their commonly used language codes even if they don't speak English, but they could still set languages manually as they currently would.

Cheers.

[Ripman]

If someone can please confirm the problem I am having, as described below, I
will add the appropriate bug tracker request. Thank you.

mkvtoolnix 9.1.0 / win8.1

----------

Issue overview:
When appending wav files in mkvtoolnix gui to create an mka audio file, the
resultant mka file does not play properly.

----------

Issue process:
- Downloaded 96/24/2ch wav files from hdtracks. The tracks play in vlc.

- Added the first track to the mkvtoolnix gui.
- Selected the option to create chapters.
- Appended the other 18 tracks.
- Ensured the tracks were ordered properly.
- Merged. Resultant mka plays in vlc and has chapters at the appropriate times.

- Using the gui and the Edit Chapters function - opened the mka.
- Edited each chapter name. Changed each chapter's country to the USA.
- Saved the chapters to the mka file successfully.
- Saved the chapters to an xml file.
- mka plays in vlc and has chapters with names at the appropriate times.

- Added merged mka with chapter names to the mkvtoolnix gui.
- Added a title.
- Muxed.
- Resultant mka does not play in vlc. Time does not advance. Mediainfo shows
a one frame difference.

----------

Issue retry:
- Created a bin/cue CD image in roxio nxt2 disc copier. Used roxio nxt2 music
disc creator to extract 16-44-2ch wav's from the bin/cue CD image.
- Added the first wav to the mkvtoolnix gui.
- Appended other tracks.
- Resultant mka does not play in vlc. Time advances in 3-5s increments.

[edit] hdt wavs are extensible. Roxio wavs are 16bit Microsoft compliant.

[Ripman]

If someone can please confirm the following, I will add the appropriate bug
tracker request. Thank you.

mkvtoolnix 9.1.0 / win8.1

----------

Issue overview:
An mkvtoolnix settings file can be saved/created when the gui contains nothing.

----------

Issue process:
- Open mkvtoolnix gui 9.1.0. Add nothing. The gui is completely clear.
- Under the menu, select: "Save Settings." A file-save dialog is presented so
the user.
- Save the settings.

[Ripman]

That's not how it seems to work when you open an MKV with streams that have previously had their default track status set to "no". The MKV I opened in my previous screenshot was such an MKV, and after muxing with the GUI displaying exactly as it was in the screenshot, the resulting MKV had a video and audio track with a default status of "no".

...


Unless I'm completely misinterpreting what the "default track in output" column is telling me, but I'm not sure what else it could be.


My first post on p207 tried to explain this behavior as well. I've yet to post my subsequent reply to Mosu's questions, but I did type it out already.

[Mosu]

An mkvtoolnix settings file can be saved/created when the gui contains nothing.

I'm intentionally not restricting when a configuration can be saved. This is not a bug.

[Mosu]

My first post on p207 tried to explain this behavior as well. I've yet to post my subsequent reply to Mosu's questions, but I did type it out already.

Like I've said (http://forum.doom9.org/showthread.php?p=1767596#post1767596) this was a bug that I've fixed (http://forum.doom9.org/showthread.php?p=1767609#post1767609) since.

[Ripman]

I'm intentionally not restricting when a configuration can be saved. This is not a bug.

Very good; now I know. Thanks for responding.

[Ripman]

Like I've said (http://forum.doom9.org/showthread.php?p=1767596#post1767596) this was a bug that I've fixed (http://forum.doom9.org/showthread.php?p=1767609#post1767609) since.

I may have missed your announcement in that respect. Thanks for fixing that, though.

[Mosu]

Hey,

time for MKVToolNix v9.2.0. It's a somewhat unremarkable release with Several smaller issues having been addressed and no huge changes or enhancements.

One important change for Windows and Mac OS users of mkvinfo is that the change to start the GUI by default has been reverted. Instead a separate executable (mkvinfo-gui) is included for those platforms which starts the GUI by default. The newly introduced option "--no-gui" will remain valid but won't have any effect when used with the "mkvinfo" executable.

There have been no changes for package maintainers since the previous release.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the Windows installer/portable version & Mac OS DMG (http://www.fosshub.com/MKVToolNix.html) and the source code (https://mkvtoolnix.download/source.html).

The Windows and Mac OS binaries are available. Most of the Linux binaries are still being built and will be available in a couple of hours.

2016-05-28 Moritz Bunkus <moritz@bunkus.org>
* Released v9.2.0 "Photograph".

2016-05-20 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: the action "select all attached files" in the popup menu actions for the attached files view has been split up into "enable all attached files" and "disable all attached files". Implements #1698 (https://github.com/mbunkus/mkvtoolnix/issues/1698).

2016-05-15 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix on Windows: removing the drive letter does not cause the colon to be removed automatically anymore. Fixes #1692 (https://github.com/mbunkus/mkvtoolnix/issues/1692).
* MKVToolNix GUI: merge tool bug fix: it's no longer possible to select "1" as the maximum number of files to split into as mkvmerge doesn't accept that value. Fixes #1695 (https://github.com/mbunkus/mkvtoolnix/issues/1695).
* mkvmerge: bug fix: the "interval" chapter generation mode was always creating one chapter too many.
* mkvmerge: bug fix: if a certain number of chapters had been generated with --generate-chapters then mkvmerge wasn't replacing the void placerholder with the actual chapters. Fixes #1693 (https://github.com/mbunkus/mkvtoolnix/issues/1693).

2016-05-14 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool bug fix: the track column "default track in output" wasn't taking into account if the track had its "default track" flag set to "no" in the source file. This would result in the column showing "yes" in certain situations even though mkvmerge would assign "no".

2016-05-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed detection of (E-)AC-3 in MPEG TS files with unusual stream types (e.g. 0x87) but with (E-)AC-3 PMT descriptors. Fixes #1684 (https://github.com/mbunkus/mkvtoolnix/issues/1684).

2016-05-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mkvextract: bug fix: fixed handling of Big Endian PCM with a bit depth other than 16, 32 or 64 bits/sample. Other formats were using the Little Endian codec ID, but their content was actually not byte-swapped to match it. Now those other bit depths are byte-swapped to Little Endian, too. Fixes #1683 (https://github.com/mbunkus/mkvtoolnix/issues/1683).
* mkvinfo: the change to start the GUI by default on Windows and Mac OS has been reverted. Instead a separate executable (mkvinfo-gui) will be included for those platforms which starts the GUI by default. The newly introduced option "--no-gui" will remain valid but won't have any effect when used with mkvinfo.

2016-05-04 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo GUI: enhancement: the window title now includes the file name. Implements #1679 (https://github.com/mbunkus/mkvtoolnix/issues/1679).
* mkvmerge: enhancement: the "bit depth" track header field will be set for DTS tracks from the first DTS core header. Implements #1680 (https://github.com/mbunkus/mkvtoolnix/issues/1680).

2016-05-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: the time zone portion of the "date_local" member of the JSON and verbose identification formats contained the time zone's name instead of its offset on Windows due to the Visual C++ runtime's std::strftime not being C++11 compliant. Additionally this resulted in errors about invalid UTF-8 strings for locales where the time zone's name contained non-ASCII characters.

Have fun :)

[Mosu]

Addendum: Please note that the Windows installers (but not the actual programs) accidentally include a build number from the start of May (20160504-01204). This is a solely cosmetic issue which can be ignored.

[hello_hello]

Thanks for the new version. Just a little spelling error to report.......

--- Errors emitted by job 'merging to file "video.mkv" in directory "D:/"' started on 2016-05-29 19:59:26 ---
Invalid start/end specification for '--split' in '--split parts:00:05:30' (curent part: 00:05:30).

Cheers.

Mosu,
I gave reporting the Qt menu problem a shot, and I created an account for doing so, but reporting it in the right way was all too daunting. I wouldn't even know what category to file it under. The bug reporting system might make sense to someone using Qt to create software, but it's obviously not designed for the end user. I tried though.

[AngelGraves13]

I have an issue remuxing a file with a TrueHD stream that is 96KHz. The output file has no working audio and the timecode for the audio is messed up.

Guessing it's a bug with 96KHz audio files, as MakeMKV fixed the bug on their end a while ago.

[Mosu]

Thanks for the heads-up. Can you please upload such a TrueHD file (the one before remuxing) to my FTP server (see signature)? I'd like to investigate and fix this. Thanks.

[meridius75]

Hi all

Wanted to ask a question as I have been using MKV tool Nix for couple of years and now find that it introduces video errors into the picture when creating a new mkv.

I find this strange since I thought MKVToolNix did not alter the picture ?

I Rip my movies with MakeMKV and then dump the video into MKVToolNix To edit and remove some parts of the video and edit names and when I come to play back some films not all there seems to be video corruption for a spilt second.

I tried the movie that was created with MakeMKV and its perfect but MKVToolNix creates errors in the video picture sometimes.

Now I have noticed this in a few versions and its took months to figure out why some of my videos have these corrupt errors in the video.

Some videos I did years ago and just watched now and see the same thing.

So I kept two files the MakeMKV file and the MKVToolNix file and when I seen the error I went back and redid the video with MKVToolNix since the MakeMKV file was fine and no errors in the same video using MKVToolNix, its just random and happens just sometimes.

Its random when this happens and I don't know why its doing it but its very annoying because I have to redo alot of videos because of this and I don't use MKVToolNix that often now because its not reliable but need to use it.

can anyone help me or can I help you sort this problem out or does anyone know or had the same problem


thanks

[AngelGraves13]

Thanks for the heads-up. Can you please upload such a TrueHD file (the one before remuxing) to my FTP server (see signature)? I'd like to investigate and fix this. Thanks.

Sure, I just have to use mkvcleaver to extract it out of the file. The movie I'm remuxing in question is the remastered My Fair Lady, which comes with a 96KHz audio track. Another film I ran into an issue with was the isolated music track 96KHz TrueHD stream of the film Oblivion.

[Mosu]

Its random when this happens and I don't know why its doing it but its very annoying because I have to redo alot of videos because of this and I don't use MKVToolNix that often now because its not reliable but need to use it.

Please see e.g. bugs 651 (https://github.com/mbunkus/mkvtoolnix/issues/651), 830 (https://github.com/mbunkus/mkvtoolnix/issues/830), 1045 (https://github.com/mbunkus/mkvtoolnix/issues/1045), 1666 (https://github.com/mbunkus/mkvtoolnix/issues/1666).

Kind regards,
mosu

[meridius75]

Please see e.g. bugs 651 (https://github.com/mbunkus/mkvtoolnix/issues/651), 830 (https://github.com/mbunkus/mkvtoolnix/issues/830), 1045 (https://github.com/mbunkus/mkvtoolnix/issues/1045), 1666 (https://github.com/mbunkus/mkvtoolnix/issues/1666).

Kind regards,
mosu

Oh dear no solution in fixing this then as its random. that's a shame as I know its not my hardware as I now use makemkv and I never have any problem with that in all the videos I have done in the past month not one glitch in the video.

there is some sort of fault with MKVToolnix and its random and a nasty bug because of what it does but it is MKVToolnix causing it as MAKEMKV does not have this problem.

I have even redone the same movie a 2nd time using the same machine and same video with MKVToolnix and its been perfect.

I will keep a log of what version does this and what version does not as I have used MKVToolNix for over 4 years and I will try to figure out which version have been doing this.

[Ripman]

Sure, I just have to use mkvcleaver to extract it out of the file. The movie I'm remuxing in question is the remastered My Fair Lady, which comes with a 96KHz audio track. Another film I ran into an issue with was the isolated music track 96KHz TrueHD stream of the film Oblivion.

I originally found the truhd problem in Mmg 64 v8.1 win8.1 portable. I hit the problem while trying to add srt subs to mkvs that I previously ripped, which in this case was Chinatown & Dr. Strangelove.

The reason I didn't post my notes was bc I was still on the road, and bc there is a work-around. Basically, only mux once. So, in my case, prepare the srt subs before ripping, and then add the subs and mux. (Usually I do a post mux to set defaults and track order, and then subsequent muxes to add subs, etc.)

There are also work arounds for the My Fair Lady / Oblivion BDs posted above.
- Use the flac profile in makemkv and rip the truhd track as flac 5.1. It will easier to edit anyway (so you can remove the dead space in the iso scores).
- You could also open the mkv from makemkv in audacity, which will allow you to edit the truhd track - you need to point audacity at the proper ffmpeg bin.
- Lastly, you could use eac3to with the mkv from makemkv as input, specify the track #, and the target format (e.g., flac).
- (Mkvextract should have no problem with the flac tracks.)
- Hi-Rez audio for Previn's My Fair Lady is available on the oop Sony sacd. In this case, the sacd is a mono recording.

If the op can't get a truhd sample uploaded, I'll get one up when I'm back in town.

[Z-95]

Thanks for the heads-up. Can you please upload such a TrueHD file (the one before remuxing) to my FTP server (see signature)? I'd like to investigate and fix this. Thanks.

I've uploaded a small sample file to your FTP server that has TrueHD 96kHz named 96kHz.mkv. I used mkvtoolnix 7.9.0 to cut it since that version seems to handle 96kHz ok.

The same issues happen on 192kHz TrueHD as well--I can upload a sample with that if needed.

[Mosu]

Thanks. I'll be out of town for ~two weeks; therefore I won't have time to look into it right away. I'll keep you updated.