MKVToolNix v24.0.0 released

[Snowknight26]

Suggestion: when clicking on a track in the Track panel, can the Track name field receive focus, like it used to in the old GUI?

[Mosu]

Most likely not. First of all, the new GUI's track selection works quite a bit differently than the old GUI's: you can select multiple tracks, operate on all of them at once, and the new GUI has good support for keyboard navigation and selection. Focusing another element breaks all of those interactions in a bad way.

Second, focusing does not necessarily cause the panel to scroll back up so that the input is visible. If it isn't visible, then that's bad because the user doesn't realize that input is now focused, and she cannot see what she's typing. However, if I change this to scroll up automatically, then it'll annoy all users that have legtimiate business in the lower parts of the track properties panel because now they have to scroll down again.

Third, if you want to jump to the track name quickly just hit Alt+k (that's the keyboard shortcut for that input field if the GUI's language is English). You're putting your fingers on the keyboard anyway, so why not use that?

Getting such functionality right with the new GUI would be very tricky and therefore prone to annoying the users until I've gotten it right. I wouldn't rule it out completely, but it's a strong "not likely".

[Snowknight26]

Alt+K should work, just have to remember to use it.

[iSeries]

Hi,

I have a concert bluray, which is 1080i 29.97fps. I have re-encoded it to 720p 59.94fps - however using latest mkvtoolnix, muxing the 264 stream and the audio and then checking the file with Mediainfo, it shows a frame rate of 60fps, with an 'original' frame rate of 59.94fps. Even when I specify 6000/1001p in mkvtoolnix, the fps gets changed to 60fps. Any tips?

[sneaker_ger]

Is the file in-sync to the end (and long enough for the difference between 60.0 fps and 59.94 fps to result in perceivable desync)? Then everything is fine and it's probably just MediaInfo misdetecting the fps. Timecodes in mkv have limited accuracy and it is not trivial to detect "correct" fps in every case - especially if only looking at the start of a file instead of parsing it completely.

If not: upload a sample and show mkvmerge command and log.

[iSeries]

Should have played the file first, I guess. You're right - everything is fine :-)

[Ripman]

>v14 wave64 support

Anyone play with this yet in mkvtoolnix?

SoX did a build that supported wave64 with some additional libs -- anyone remember where that is?

Thanks again for wave64 support.

[Mosu]

Here's the brand new version 15.0.0 of MKVToolNix. A lot of work has gone into improving support for new track header elements important for video archival purposes. A couple of bugs have been fixed, too, as usual.

Changes for package maintainers: libEBML v1.3.5 is now required. An option has been added to 'configure' for compiling without the code that checks online for new releases. See below for details.

Deprecation warning

This is a reminder that certain features having been deprecated since v9.7.0. They're scheduled to be removed in the first release of 2018. These features are:

• mkvmerge: the options "--identify-verbose", "--identify-for-gui", "--identify-for-mmg" and "--identification-format verbose" (use "--identification-format json --identify" or its short form "-J" instead)
• all command line tools: the old, proprietary format used for option files (use JSON option files instead)

Here are the usual links: the MKVToolNix home page, the Windows installer/portable version & macOS DMG and the source code.

The Windows and macOS binaries have already been built and uploaded. Linux binaries are still being built and will be available shortly.

Here are the NEWS since the previous release:

# Version 15.0.0 "Duel with the Devil" 2017-08-19

## Important notes

* mkvmerge, mkvpropedit, GUI's header and chapter editors: the programs will no longer add most missing Matroska elements that are mandatory but have a default value in the Matroska specification (e.g. the `TagLanguage` element with a value of `und` if it isn't present in its `SimpleTag` parent). Due to this change libEBML v1.3.5 is now required.

## New features and enhancements

* MKVToolNix GUI: multiplex tool: added a new entry to the "source files" context menu labeled "Set destination file name from selected file's name". It will force the GUI to consider the selected file to be the reference for automatically setting the file name, no matter which file was originally added as the first file. It will also force setting the destination file name once if automatic destination file name generation is turned off in the preferences. Implements part of #2058.
* MKVToolNix GUI: multiplex tool: added an option in the preferences on "Multiplexer" → "Output" labeled "Only use the first source file that contains a video track". If enabled, only source files containing video tracks will be used for setting the destination file name. Other files that are added are ignore. Implements the rest of #2058.
* MKVToolNix GUI: header editor: added support for editing the video colour attributes. Implements the second half of #2038.
* MKVToolNix GUI: header editor: added support for the "video projection" track header attributes. Part of the implementation of #2064.
* MKVToolNix GUI: job queue: selected jobs can now be move up and down by pressing the `Ctrl+Up` and `Ctrl+Down` keys. Additionally, push buttons to move them up & down are shown if the corresponding option is enabled in the preferences. Implements #2060.
* mkvmerge: added support for the "video projection" track header attributes. Part of the implementation of #2064.
* mkvinfo: added support for the "video projection" track header attributes. Part of the implementation of #2064.
* mkvpropedit: added support for editing the video colour attributes. Implements one half of #2038.
* mkvpropedit: added support for the "video projection" track header attributes. Part of the implementation of #2064.

## Bug fixes

* all: selecting the program's language (e.g. via the `--ui-language` command-line option or via the GUI's preferences) did not work on Linux & Unix if the `LANGUAGE` environment variable was set and didn't include the desired language. Fixes #2070.
* MKVToolNix GUI: removed the keyboard shortcuts for switching between the different tools (e.g. `Ctrl+Alt+1` for the multiplexer). They overlapped with basic functionality on keyboards that use an `AltGr` key, e.g. German ones, where `AltGr+7` emits `{`. As `AltGr+key` is implemented as `Ctrl+Alt+key` under the hood, this means that `AltGr+7` is really `Ctrl+Alt+7` which the GUI now took to mean "switch to the job queue" instead of "insert `{`". Fixes #2056.
* MKVToolNix GUI: header editor: after saving the file the GUI wasn't updating its internal file modification timestamp. That lead to the GUI wrongfully claiming that the file had been modified externally when the user wanted to save the file once more, requiring a reload of the file losing all modifications made since saving the first time.
* mkvmerge: DTS handling: some source files provide timestamps for audio tracks only once every `n` audio frames. In such situations mkvmerge was buffering too much data resulting in a single gap in the timestamps of one frame duration after frame number `n - 1` (the second audio timestamp read from the source file was used one output frame too early). Fixes #2071.
* mkvinfo: fixed a null pointer dereference if an `EbmlBinary` element's data pointer is a null pointer. Fixes #2072.

## Build system changes

* configure: added option `--disable-update-check`. If given, the code checking online for available updates will be disabled. The update check is enabled and included in the GUI by default.
* libEBML v1.3.5 is now required.

## Other changes

* mkvmerge: the option `--colour-matrix` has been renamed to `--colour-matrix-coefficients` in order to match the specification more closely. The old option name will continue to be recognized as well.

Have fun

[manolito]

Thanks for the new version...

For hello_hello and all other Win XP users:
The workaround from this post:
https://forum.doom9.org/showthread.p...31#post1813131
still worlks.

Cheers
manolito

[hubblec4]

Hi Mosu

I set the TrackDefaultFlag to true for an audio track(the first track), and a second audio track these Flag is set to false.
After the muxing I load the mkv to the Header-Editor and there is no TrackDefaultFlag Element present. Same in mkvInfo-GUI.
I tried version 14 and 15 of MKVToolNix x64 with the GUI and CLI with the Options.json file.

[Mosu]

Read this fine FAQ entry. The summary is: TrackFlagDefault's default value (= the value a player must use if the element is not present) is "true". As you're setting that flag to "true", mkvmerge does not have to write it and doesn't do so, because its absence means implicitly that it is "true".

[hubblec4]

Ok, fine. I thought I did an issue.

[Nico8583]

Hi,
I've seen some people uses "--clusters-in-meta-seek --disable-track-statistics-tags --engage no_cue_duration --engage no_cue_relative_position" options to improve compatibility. What are the others pros and cons to allways use it ?
Thank you !

[sneaker_ger]

https://github.com/mbunkus/mkvtoolni...y-with-players

If it adds data: more overhead. no_cue_duration/engage no_cue_relative_position: seeking into the middle of a subtitle line works in players that can make use of those (e.g. LAV/MPC-HC).

[hello_hello]

When appending MKVs, MKVToolNix accounts for any existing audio/video delays or gaps etc and maintains sync, unless one of the MKVs being appended contains no audio at all.
For example, if you append three MKVs, and the second MKV contains no audio, in a perfect world it'd be treated as an audio gap and the video/audio sync for the third MKV being appended would be unaffected. What seems to happen though, is the audio in the third MKV is appended to the audio in the first MKV as though individual streams were being appended. I don't know if the same applies to subtitle streams. Is that a bug or intended behaviour?

Cheers.

PS. Keep in mind I'm using manolito's workaround with MKVToolNix version 15 (thanks manolito), given I'm running "no-ding" XP, although I doubt it's related to the problem....

[Nico8583]

Originally Posted by sneaker_ger

https://github.com/mbunkus/mkvtoolni...y-with-players

If it adds data: more overhead. no_cue_duration/engage no_cue_relative_position: seeking into the middle of a subtitle line works in players that can make use of those (e.g. LAV/MPC-HC).

Ok thanks
I don't know if I must use it or not, I can test my players now but in few months perhaps I'll use new devices so I can't know if these options will be supported... Difficult choice

[hubblec4]

Hi Mosu

I have noticed that when I load a UHD-Bluray m2ts or mpls to MTX then all languages are well defined.
In an older version of MTX all languages was set to "und".

Have you improved your UHD-Bluray parser? Where you got this new infos?

[Mosu]

I didn't really change anything regarding languages on Blu-rays. If the language is present in the MPLS/CLPI files, then it is used. Simple as that.

[hubblec4]

Hi Mosu

I have some questions about mpls.

In the identify.json for all streams exists a "stream_id" with a number. This number seems to me not always match with the number in the mpls.

Here is an example of the Terminator 2 Bluray.

mpls 00018: there are 2 DTS-Express audio tracks and a second video track.

Video 2: "stream_id": 6912 -> binary 1B 00
DTS 1: "stream_id": 6656 -> binary 1A 00
DTS 2: "stream_id": 6657 -> binary 1A 01

But I don't found this binary values in the mpls.

Why is the order of the streams in MTX different to the order in the mpls?

Best regards

[Mosu]

Originally Posted by hubblec4

But I don't found this binary values in the mpls.

Why is the order of the streams in MTX different to the order in the mpls?

For mkvmerge the actual content of the M2TS file(s) is relevant, not what's in the MPLS. mkvmerge reads the M2TS files listed in the MPLS file and uses all streams found in the M2TS files. Track IDs are assigned in the order they're found in the M2TS.

It's quite possible those streams are simply not listed in the MPLS.