MKVToolNix v91.0 released

[Mosu]

Heya fine folks.

The first release of 2025 brings you a handful of bug fixes & one nice improvements for header editor users.

Here are the usual links: the MKVToolNix home page, the downloads section and the source code.

The Windows packages as well as the Linux AppImage are available already. The other Linux packages & the macOS disk image are still being built and will be available over the course of the next couple of hours.

Here are the NEWS since the previous release:

Version 90.0 "Hanging On" 2025-02-08
New features and enhancements

• MKVToolNix GUI: header editor: double-clicking on one of the three flag indicators ("Default track", "Forced display", "Enabled") for a track in the tree view will now toggle the corresponding flag. Implements #3773.

Bug fixes

• mkvmerge: AAC parser: LOAS/LATM streams: fixed use of uninitialized data when the "StreamMuxConfig" element doesn't contain the "audioMuxVersion" element; version 0 must be assumed in such a case. The result was that sometimes certain valid AAC packets were dropped. Fix by Stefan Pöschel.
• mkvmerge: HEVC/H.265 parser: fixed calculation of picture order count calculation that was triggered under rare circumstances. Fixes #3775.
• mkvmerge: Matroska reader: enabled limits for how much data a single Matroksa reader instance might buffer when the muxing core looks for packets for specific tracks, avoiding huge memory consumption in cases where tracks have huge gaps between packets. This might happen when appending files containing forced-only subtitle tracks, for example. Fixes #3771.
• mkvmerge: TrueHD reader: increased the probe range for TrueHD sync frames from 128 KB to 512 KB to avoid mis-detection with certain files with a lot of data between sync frames. Fixes #3783.
• mkvmerge: MP4/QuickTime reader: fixed detection of Big Endian LPCM audio. Fixes #3788.

Build system changes

• The bundled "fmt" library was updated to v11.1.2.
• added a new option to "configure" called "--disable-dbus" to disable looking for & using QtDBus even if it's present on the system. Default remains to probe for its existence. Patch by Anthony Ryan.

Have fun 😁

[tebasuna51]

Without problems with 89.0
mkvtoolnix-gui 90.0 problem in my W10 v1607:

[GeoffreyA]

Looks like a UTF-16 issue with the string table.

[Mosu]

Originally Posted by tebasuna51

Without problems with 89.0
mkvtoolnix-gui 90.0 problem in my W10 v1607:

I've just flipped through all available translations on my Windows 11 installation, and all of them display just fine. I have no idea why it looks like that on your end. It's likely some kind of issue specific to your system's setup/installed software/configuration.

Originally Posted by GeoffreyA

Looks like a UTF-16 issue with the string table.

MKVToolNix uses gettext for translations. gettext stores its data encoded in UTF-8. No UTF-16 in use there.

[lvqcl]

It seems that 14393.10 was released at August 2, 2016, so it's a bit outdated.

[tebasuna51]

Originally Posted by lvqcl

It seems that 14393.10 was released at August 2, 2016, so it's a bit outdated.

More updated versions don't work with my private LAN, maybe I need use MkvToolNix W7 versions

[GeoffreyA]

On my Windows 10 19045, different languages also work fine.

[filler56789]

Originally Posted by lvqcl

It seems that 14393.10 was released at August 2, 2016, so it's a bit outdated.

More probably, it is the Qt framework thing that is excessively ""up-to-date""

[lvqcl]

Originally Posted by tebasuna51

More updated versions don't work with my private LAN, maybe I need use MkvToolNix W7 versions

Makes sense to try.

[jpsdr]

Your issue looks like an issue on the Windows 7 QT6 version. I don't know specificaly, but QT6 on 6.8.1 version changed the way text is displayed, and it's something working only on Windows 10. The QT6 Windows 7 version still need to fix this issue.
It seems it's more than Windows 10 only, it's recent Windows 10 only...
And last version of MKVToolnix,90.0 is QT 6.8.2 if i'm not mistaken, when 89.0 maybe wasn't 6.8.1 yet...

[tebasuna51]

No problem for me, most the time I use mkvmerge.exe (and mkvextract.exe etc.) with .bat in cml mode.

If I want the GUI I can use the W7 version with QT5 than work fine.

[AYColumbia]

@tebasuna51, is your win 10 installed in English or another language? If another language, you might try going to the list of available languages in Windows and install English (US). You don't have to change your language, just have it available/installed. After you restart, do you see the same issue?

[filler56789]

@AYColumbia: tebasuna51 uses a Spanish Windows 10.
But that's not the real problem, please read

https://forum.videohelp.com/threads/...18#post2767003

[Ripman]

Thanks for v90. No issues here with most recent Win10 updates.

QQ: Is there a way to output track language with “mkvmerge -i”?

I basically want the track #s, track type, and language if possible.

Mkvinfo generates more data than I need tbh. I think I tried reducing the verbosity levels but that still generated a lot more than I need.

[Mosu]

Originally Posted by Ripman

QQ: Is there a way to output track language with “mkvmerge -i”?

Use the JSON identification mode with "mkvmerge --identification-mode json --identify yourfile.ext" or its shortcut "mkvmerge -J yourfile.ext". It outputs everything you need, in JSON, which is trivial to process further with every language including PowerShell.

[tebasuna51]

Thanks to all comments about my problem, like maybe there are others users with the same problem I resume it:

I have W10 Version 1607 Build 14393 2016-08-02

Seems that 90.0 new version need at least the next W10 v1709 b16299 2017-10-17

In my LAN software I need HomeGroup, feature removed in next W10 v1803 b17134 2018-04-30

Then only the build 16299 can be compatible with both requirements, I don't know if I can update to that version and if a new QT version need a more updated W10 version.
Seems is better use the W7 compatible version.

[AYColumbia]

Originally Posted by filler56789

@AYColumbia: tebasuna51 uses a Spanish Windows 10.
But that's not the real problem, please read

https://forum.videohelp.com/threads/...18#post2767003

Gotcha, thanks.

[tormento]

@Mosu

Please, could you add the option to have the part suffix as prefix? I.e. 001-whatever.mkv instead of whatever-001.mkv?

I find it more useful when splitting episodes.

The best could be to have a placeholder with a starting number too, such as %000-name.mkv where the number of zeroes defines the padding.

In that case, an option to remember the last part number and automatically increment it for the next queued file would be optimal.

[Mosu]

Originally Posted by tormento

Please, could you add the option to have the part suffix as prefix? I.e. 001-whatever.mkv instead of whatever-001.mkv?

EDIT: You can do that already. See the documentation of the --split option (last two paragraphs). For example, you could use the output file name "C:\Movies\%03d My Fine Movie.mkv".

I don't think I'll add anything in the GUI to include such a pattern in the output filename somewhere by default (or optionally). I find it doubtful that this is really useful. As soon as you have the splitting result of two different movies in the same folder, you will end up with both movie parts intermixed, e.g. 001-the-first-movie.mkv, 001-other-movie.mkv, 002-the-first-movie.mkv, 002-other-movie.mkv etc.

[tormento]

Originally Posted by Mosu

As soon as you have the splitting result of two different movies in the same folder, you will end up with both movie parts intermixed, e.g. 001-the-first-movie.mkv, 001-other-movie.mkv, 002-the-first-movie.mkv, 002-other-movie.mkv etc.

Thank you for your help.

I know that issue and that's why I proposed to have automatically incremented numbers for multiple files in the queue.