MKVToolNix v24.0.0 released

[Z-95]

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.

Rgr, did a bit more research into it to help narrow it down--it works in 8.6.1 but is broken in 8.7.0

[kuchikirukia]

Any idea where to find technical info on MKV segment linking? How hard linking should be implemented vs soft linking?

Oh, and didn't MKVToolNix used to auto-load the UIDs under Segment Linking when a mkv was loaded? I no longer see any UIDs when I drop in one of my linked mkvs.

[sneaker_ger]

There are two different ways to do segment linking. One is via the "File/segment linking" options. The other is via ordered chapters:
http://mod16.org/hurfdurf/?p=8

[Mosu]

I've uploaded a small sample file to your FTP server that has TrueHD 96kHz named 96kHz.mkv.

I've just fixed this in the latest pre-builds (https://mkvtoolnix.download/windows/pre/). Please give them a try, both with 96 kHz as well as 192 kHz. Thanks.

[Z-95]

I've just fixed this in the latest pre-builds (https://mkvtoolnix.download/windows/pre/). Please give them a try, both with 96 kHz as well as 192 kHz. Thanks.

Tested with 96 kHz and 192 kHz and both work with the latest build--thanks!

[Mosu]

Thanks for the confirmation.

[hubblec4]

Hello Mosu

Can you have a look from here (http://forum.doom9.org/showthread.php?p=1772244#post1772244)?

What is with the country code "uk"? It's not present in the MTX-GUI.

[Ripman]

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


Problem had to be on my side since no one could confirm.

Problem was with vlc 2.1.5. Upgraded vlc to 2.2.4 and the problem was resolved. I posted the same on GitHub.

[Z-95]

Quick question about whether something is possible to do with MKVToolNix--is it possible to get the timecode of the first cluster of an MKV file without scanning the entire file?

I currently have a personal tool written in Java that uses a modified version of jEBML to only read to the first cluster and extract the timecode and then resync the file if the first cluster timecode is not 0 using mkvmerge --sync. (I do this because mkvmerge when splitting by chapters on MPLS from blu-rays will sometimes produce files with non-zero timecodes that cause some players to not seek or display chapters correctly). However, since jEBML is unmaintained and I like to learn new things, I am considering porting my tool to python and would like all mkv operations to be done through external calls to MKVToolNix utils.

I know I could fully read the file with mkvinfo, but I have a SAN of ~56TB of MKVs that currently only takes about 90 minutes to scan while fully scanning the files would take days.

I was looking at mkvextract timecodes as well, but you must supply a track number so I wonder if the earliest timecode for the video track would match the actual cluster timecode?

[Mosu]

The first frame's timestamp is not necessarily 0 (e.g. think of a video with B frames in a file where audio starts somewhat after the video). Therefore I'd suggest you start mkvinfo as an external process and parse its output on the fly. Let mkvinfo parse the very first cluster and use the minimum of all timestamps in that cluster as your point of reference. Once the first chapter's been parsed shut down the mkvinfo process. That way you're relatively sure you actually have the minimum timestamp (instead of the first one which might not be the minimum) and you don't have to scan the whole file.

[Z-95]

Yea, I wouldn't want to use the first frame/simpleblock's timecode in case others are earlier; currently I pull the cluster timecode (the level 2 one) and treat that as the offset to pass to --sync and don't look inside the cluster's blocks. I rarely run into having to use it since it only happens with discs where 3+ episodes are all in one large M2TS but still check files for it for sanity.

I hadn't thought about killing the mkvinfo process once it spits out the first cluster timecode--that should work as long as the kill actually terminates relatively immediately (which depends on the language and OS I suppose--Java docs say it may remain alive after destruction for a short while for instance). Will have to test--even short waits is better than nothing.

Thanks for the idea!

[Mosu]

Here we go, MKVToolNix v9.3.0. It implements several enhancements requested by users, and of course it contains the usual list of bug fixes. Nothing major, mind you. But see below.

Dear package maintainers: please note that MKVToolNix v9.3.0 requires the recently released libEBML v1.3.4 and libMatroska v1.4.5.

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.

Here's the full ChangeLog since v9.2.0:

2016-07-13 Moritz Bunkus <moritz@bunkus.org>
* Released v9.3.0 "Second Sight".

2016-07-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, MKVToolNix GUI: new chapter generation feature: two new placeholders have been introduced when generating chapters for appended files, <FILE_NAME> and <FILE_NAME_WITH_EXT>. The former will be replaced by the appended file's name without its extension; the latter with its extension. Implements #1737 (https://github.com/mbunkus/mkvtoolnix/issues/1737).
* MKVToolNix GUI: merge tool enhancement: when opening a saved configuration (via the menu as well as via drag & drop) the current tab will be replaced if it is empty ( = in the same state it is in right after creating new mux settings). Implements #1738 (https://github.com/mbunkus/mkvtoolnix/issues/1738).
* mkvmerge, MKVToolNix GUI: added an option for specifying how much of a MPEG PS or TS file is probed for tracks (--probe-range-percentage). Implements #1734 (https://github.com/mbunkus/mkvtoolnix/issues/1734).

2016-07-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: MPEG TS: considerable parts of the module have been rewritten. Due to its convoluted structure didn't buffer PES packets properly before trying to parse the PES header leading to invalid memory accesses in certain cases.

2016-07-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed overly long file type detection in some cases when text subtitle type probing read a lot of data due to there being no carriage returns near the start of the file.
* mkvmerge, mkvextract, MKVToolNix GUI: bug fix: several fixes to the handling of country codes. The list has been updated to reflect the currently valid top level domain country codes. Deprecated codes such as "gb" for "Great Britain" are now mapped to their updated values ("uk" for "United Kingdom" in this case). Fixes #1731 (https://github.com/mbunkus/mkvtoolnix/issues/1731).
* mkvmerge: WavPack4 bug fix: relaxed the stream detection criteria to only require the major version to be 4 and not to check the minor version. Fixes #1720 (https://github.com/mbunkus/mkvtoolnix/issues/1720).

2016-07-02 Chao Chen <tochenchao@gmail.com>
* mkvmerge, mkvinfo: new feature: added flags to support the Colour elements in the video tracks of Matroska containers. Users can use those flags to specify the colour space, transfer function, chromaticity coordinates etc. These properties are useful for correct colour reproduction of high dynamic range / wide colour gamut videos.

2016-07-02 Moritz Bunkus <moritz@bunkus.org>
* configure: fixed the Qt detection with Qt 5.7.0 which now requires the compiler to be in C++11 mode.
* build system: libEBML v1.3.4 and libMatroska v1.4.5 are now required due to the usage of new elements introduced in libMatroska v1.4.5. The copies included in the MKVToolNix source code have been updated to those releases as well.

2016-06-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: MP4 bug fix wrt. DTS handling: mkvmerge will re-derive parameters such as number of channels and sampling frequency from the DTS bitstream circumventing invalid values in the track headers (e.g. a channel count of 0). Fixes #1727 (https://github.com/mbunkus/mkvtoolnix/issues/1727)/1728.

2016-06-27 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: TrueHD bug fix: fixed detection of 96 kHz sampling frequency.

2016-06-24 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo's GUI: fix a crash due to wrong usage of referenced temporary objects. Fixes #1725 (https://github.com/mbunkus/mkvtoolnix/issues/1725).

2016-06-05 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: the default track languages to set can now also be set whenever the language in the source file is 'undefined' ('und'). This is now the default and can be changed back to the old behavior (only set if the source file doesn't contain a language attribute) in the preferences. Implements #1697 (https://github.com/mbunkus/mkvtoolnix/issues/1697).

2016-06-04 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: menus have been added to both the "start muxing" and the "add to job queue" buttons. The menus let the user override the preferences regarding clearing merge settings after starting to mux and after adding a job to the queue respectively. Implements #1696 (https://github.com/mbunkus/mkvtoolnix/issues/1696).
* mkvmerge: the warning about not being able to determine whether a raw AAC file contains HE-AAC/AAC+/SBR has been removed. Implements #1701 (https://github.com/mbunkus/mkvtoolnix/issues/1701).
* MKVToolNix GUI: enhancement: all file names are now displayed with their native path separators (e.g. "C:\some\where\output.mkv" on Windows). Implements #1298 (https://github.com/mbunkus/mkvtoolnix/issues/1298), #1456 (https://github.com/mbunkus/mkvtoolnix/issues/1456).
* MKVToolNix GUI: merge tool bug fix: the GUI now takes into account whether splitting is activated when looking for and warning due to existing destination files. Fixes #1694 (https://github.com/mbunkus/mkvtoolnix/issues/1694).
* mkvmerge: bug fix: the parser for the --default-duration argument was wrongfully handling arguments of the form "123/456i" (only this specific syntax and only with "i" as the unit; other formats and units were fine). This is part of #1673 (https://github.com/mbunkus/mkvtoolnix/issues/1673). Additionally the parser doesn't use the "double" data type internally anymore fixing loss of precision and failing test cases on certain 32bit platforms. This fixes #1705 (https://github.com/mbunkus/mkvtoolnix/issues/1705).

Have fun :)

[Perenista]

Now I can't append files that were split into multiple parts. It's always returning the "probe percentage" error.

Tested with the 9.3.0 version.

P.S. Tested with old version, and this is not happening. It's exclusive from 9.3.0..

[Mosu]

What "probe percentage" error are you talking about (post a screenshot, please)?

[Jamaika]

I'm sorry that I butting. This is a simple recompile MKV. File names must be in English because otherwise no export.

[me7]

Same problem here. The Error message says: The probe range percentage '3.71878e-316' is invalid.

[mbcd]

What "probe percentage" error are you talking about (post a screenshot, please)?

Hi Mosu,

getting the same problem, muxing failes with every file:

Der Prozentsatz der zu untersuchenden Daten »4.03371e-316« ist ungültig.

I am using the 64bit Version for Windows (Installation)
Value in Settings is at 0,3, tried to exchange the comma to a decinal point, but the GUI is not accepting it in this field.
It doesnt matter what value I input there, the errorvalue (4.03371e-316) is always the same, looks like some limit or wrong formatconversation.

And again:
Thanks for your continouing hard work !!!!!

[Mosu]

I hate floating point numbers :(

As a workaround you can try opening the preferences, go to "merge", set "probe range percentage" to e.g. 0.4 (which is different from the default value of 0.3) and close it again.

Edit: changed the proposed value to try to 0.4.

[Mosu]

I'm sorry that I butting. This is a simple recompile MKV. File names must be in English because otherwise no import.

I don't really understand what you're trying to say. Do you mean that when you try to add a file to MKVToolNix GUI it fails if the file's name contains any non-ASCII character? If so I cannot reproduce that here. I've tried characters like German Umlauts (ä ö ü ß etc.), guillemets (» «) and others. In all cases both adding the file as well as muxing it works fine.

[me7]

For me, the input only accepts the European ',' comma. Can you tell me where the settings file is stored? I'd like to try to edit it manually.

[me7]

I just had a breakthrough setting it to '2,0'

[Mosu]

@mbcd & @me7:

At the moment I cannot reproduce triggering the issue, though I have a pretty good understanding what the problem is. I'd just like to have a way to reproduce it so that I can actually test any fix I'm going to implement for this.

If you haven't entered the preferences dialog yet, can you please send me your mkvtoolnix-gui.ini file to moritz@bunkus.org? See here (https://github.com/mbunkus/mkvtoolnix/wiki/Location-of-settings-and-the-job-queue) where it's stored.

Can you please also tell me if this is a stored config you've loaded, if it's a job that has already been sitting in the queue from before the upgrade, or if this is a new configuration you've created with 9.3.0? Thanks.

Value in Settings is at 0,3, tried to exchange the comma to a decinal point, but the GUI is not accepting in in this field.

That's to be expected as Qt (the GUI library I'm using) is using the OS's locale setting for displaying the decimal point. Internally the GUI and both are both only using the "." regardless of the locale. This is definitely not an issue; the issue is that somehow a very, very small floating point number that is not exactly 0.0 is finding its way into the GUI's processing. This shouldn't happen; if the value isn't present in the stored settings then the default 0.3 should be used. However, it obviously does happen.

Thanks for your continouing hard work !!!!!

You're welcome :)

[Mosu]

For me, the input only accepts the European ',' comma. Can you tell me where the settings file is stored? I'd like to try to edit it manually.

Like I said in my other post: the comma is definitely not a problem. I'm running the GUI on a German Windows here, too, and for me the GUI's control uses a comma, too, but mkvmerge is still being called with the point as the decimal point instead of the comma. It's definitely something else. Please don't focus on the comma being present there. Thanks.

[Jamaika]

I've tried characters like German Umlauts (ä ö ü ß etc.), guillemets (» «) and others. In all cases both adding the file as well as muxing it works fine.
I have a letter "ó" in polish and don't want to export a. I had to replace the name on 111.mkv

[Mosu]

Sorry, Jamaika, but I still don't get it. I've just named a file "rękopiśmiennych.avi" and muxed it successfully to "główną rolę w rozwoju książki.mkv". No, I don't understand those words, I just copy them from Wikipedia, but my point is: I cannot reproduce a problem with non-ASCII (non-English) characters here. And your English doesn't seem to be good enough to explain clearly what you perceive to be the problem.

[Jamaika]

Sorry, but there are some exceptions and I can't clarify. "Wybór.mkv". It's worry the others.

[Mosu]

Same problem here. The Error message says: The probe range percentage '3.71878e-316' is invalid.

Alright, I can finally reproduce this :) Will be fixed.

[Mosu]

I've fixed the issue causing the probe range percentage errors and uploaded new pre-builds for Windows (https://mkvtoolnix.download/windows/pre/). I'd appreciate some testing, and if the feedback is positive I'll release v9.3.1 ASAP.

Thanks for the quick feedback so far! I highly appreciate it.

[MGarret]

Just tried new 32bit pre-build and it works as it should. I tested 9.3.0 just few minutes ago and it failed on many files. Thanks for the quick fix :)

[mbcd]

I've fixed the issue causing the probe range percentage errors and uploaded new pre-builds for Windows (https://mkvtoolnix.download/windows/pre/). I'd appreciate some testing, and if the feedback is positive I'll release v9.3.1 ASAP.

Thanks for the quick feedback so far! I highly appreciate it.

"Made in Germany" - Quality ... your fix works like a charm. :thanks:
I deleted my old config-file and now it works with the standard "0.3" -value.

We have to appreciate your hard work, you spend a lot of your lifetime for us ... for free ... thanks again Mosu !

[Ripman]

Issue:
If I mux an mkv file with a DTS-HD MA audio track @ 192KHz, the resultant DTS-HD MA audio track has a sample rate @ 48KHz. v9.3.0/win8.1.

Process:
1. Used MakeMkv 1.9.10 to rip a blu ray audio disc that contains a DTS-HD MA 5.1 audio track sampled at 192KHz.
2. Used Mkvtoolnix 9.3.0 to mux. Mkvtoolnix shows the DTS-HD MA 5.1 audio track as 192KHz. (Included files: screen shot of audio track showing sample rate, options-log files.)
3. Used Mkvtoolnix 9.3.0 to open the muxed file. DTS-HD MA 5.1 audio track now at 48KHz. (Included files: screen shot of muxed audio track.)

I tried creating a sample that could be uploaded, but the split doesn't work (same reason as described above). What tool can I use to cut a sample (if needed)?

pre-mux: dts-hd ma 5.1@192khz
https://www.dropbox.com/s/7g24fznde9ms8m6/02%20mkvtoolnix%209.3.0%2C%20DTS-HD%20MA%20%40%20192khz.jpg?dl=0

post-mux: dts-hd ma 5.1@48khz
https://www.dropbox.com/s/yfe2y01obwuxpou/04%20mkvtoolnix%209.3.0%2C%20DTS-HD%20MA%20%40%2048khz.jpg?dl=0

I'll add this to the GitHub in a week or so if someone else cannot confirm. Thanks for the new version too.


options

--ui-language
en
--output
C\c\\1\\Part_II_t00_30secs.mkv
--language
0\ceng
--compression
0\cnone
--language
1\ceng
--track-name
1\cSurround\s5.1
--default-track
1\cyes
--compression
1\cnone
--language
2\ceng
--track-name
2\cSurround\s5.1
--compression
2\cnone
--language
3\cmis
--track-name
3\cSurround\s5.1
--compression
3\cnone
--language
4\cmis
--track-name
4\cSurround\s5.1
--compression
4\cnone
--language
5\cmis
--track-name
5\cSurround\s7.1
--compression
5\cnone
--language
6\cmis
--track-name
6\cSurround\s5.1
--compression
6\cnone
--language
7\cmis
--track-name
7\cStereo
--compression
7\cnone
(
C\c\\1\\Part_II_t00.mkv
)
--split
timecodes\c30s
--title
Part_II
--track-order
0\c0,0\c1,0\c2,0\c3,0\c4,0\c5,0\c6,0\c7


log

--- Output of job 'merging to file "Part_II_t00_30secs.mkv" in directory "C:/1"' started on 2016-07-13 21:41:10 ---
mkvmerge v9.3.0 ('Second Sight') 64bit
'C:\1\Part_II_t00.mkv': Using the demultiplexer for the format 'Matroska'.
'C:\1\Part_II_t00.mkv' track 0: Using the output module for the format 'AVC/h.264'.
'C:\1\Part_II_t00.mkv' track 1: Using the output module for the format 'DTS'.
'C:\1\Part_II_t00.mkv' track 2: Using the output module for the format 'DTS'.
'C:\1\Part_II_t00.mkv' track 3: Using the output module for the format 'DTS'.
'C:\1\Part_II_t00.mkv' track 4: Using the output module for the format 'DTS'.
'C:\1\Part_II_t00.mkv' track 5: Using the output module for the format 'DTS'.
'C:\1\Part_II_t00.mkv' track 6: Using the output module for the format 'DTS'.
'C:\1\Part_II_t00.mkv' track 7: Using the output module for the format 'PCM'.
The file 'C:\1\Part_II_t00_30secs-001.mkv' has been opened for writing.
The cue entries (the index) are being written...
The file 'C:\1\Part_II_t00_30secs-002.mkv' has been opened for writing.
The cue entries (the index) are being written...
Muxing took 7 minutes 45 seconds.

[Sparktank]

I've fixed the issue causing the probe range percentage errors and uploaded new pre-builds for Windows (https://mkvtoolnix.download/windows/pre/).

I have a remuxed clip from my Interstellar Bluray stored for testing various things.
It was remuxed using: mkvmerge v8.9.0 ('Father Daughter') 64bit

The pre-build works whereas the official build fails for probe.

using: mkvtoolnix-64bit-9.3.0-build20160713-01262-0b20466

Thanks for the pre-build fix. :goodpost:

[Mosu]

Thanks for the feedback. A new release with the fix included will be out later today.

[Mosu]

Issue:
If I mux an mkv file with a DTS-HD MA audio track @ 192KHz, the resultant DTS-HD MA audio track has a sample rate @ 48KHz. v9.3.0/win8.1.

Thanks for the report; so far I'm not aware of such an issue.

Please do create an issue on Github for and, and please upload a sample DTS file to my FTP server. You can create one with MakeMKV and split the resulting MKV with e.g. WinSplit — it shouldn't matter that the resulting file is missing certain Matroska structures; the important ones (segment header, track headers) should all be at the beginning.

[Mosu]

"Nothing major, mind you" I said. Maybe I shouldn't have ;)

Yesterday's release v9.3.0 contains a rather nasty one causing a lot of errors from mkvmerge about an "invalid probe range percentage". As this affects everyone I've fixed the issue and am now releasing v9.3.1.

Apart from that fix it's the same as v9.3.0. It implements several enhancements requested by users, and of course it contains the usual list of bug fixes. Nothing major, mind you. But see below.

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.

Here's the full ChangeLog since v9.2.0:

2016-07-14 Moritz Bunkus <moritz@bunkus.org>
* Released v9.3.1 "Mask Machine".

2016-07-13 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool bug fix: the GUI v9.3.0 was often creating an invalid syntax for the --probe-range-percentage parameter for mkvmerge due to uninitialized memory. Fixes #1741 (https://github.com/mbunkus/mkvtoolnix/issues/1741).
* Released v9.3.0 "Second Sight".

2016-07-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, MKVToolNix GUI: new chapter generation feature: two new placeholders have been introduced when generating chapters for appended files, <FILE_NAME> and <FILE_NAME_WITH_EXT>. The former will be replaced by the appended file's name without its extension; the latter with its extension. Implements #1737 (https://github.com/mbunkus/mkvtoolnix/issues/1737).
* MKVToolNix GUI: merge tool enhancement: when opening a saved configuration (via the menu as well as via drag & drop) the current tab will be replaced if it is empty ( = in the same state it is in right after creating new mux settings). Implements #1738 (https://github.com/mbunkus/mkvtoolnix/issues/1738).
* mkvmerge, MKVToolNix GUI: added an option for specifying how much of a MPEG PS or TS file is probed for tracks (--probe-range-percentage). Implements #1734 (https://github.com/mbunkus/mkvtoolnix/issues/1734).

2016-07-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: MPEG TS: considerable parts of the module have been rewritten. Due to its convoluted structure didn't buffer PES packets properly before trying to parse the PES header leading to invalid memory accesses in certain cases.

2016-07-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed overly long file type detection in some cases when text subtitle type probing read a lot of data due to there being no carriage returns near the start of the file.
* mkvmerge, mkvextract, MKVToolNix GUI: bug fix: several fixes to the handling of country codes. The list has been updated to reflect the currently valid top level domain country codes. Deprecated codes such as "gb" for "Great Britain" are now mapped to their updated values ("uk" for "United Kingdom" in this case). Fixes #1731 (https://github.com/mbunkus/mkvtoolnix/issues/1731).
* mkvmerge: WavPack4 bug fix: relaxed the stream detection criteria to only require the major version to be 4 and not to check the minor version. Fixes #1720 (https://github.com/mbunkus/mkvtoolnix/issues/1720).

2016-07-02 Chao Chen <tochenchao@gmail.com>
* mkvmerge, mkvinfo: new feature: added flags to support the Colour elements in the video tracks of Matroska containers. Users can use those flags to specify the colour space, transfer function, chromaticity coordinates etc. These properties are useful for correct colour reproduction of high dynamic range / wide colour gamut videos.

2016-07-02 Moritz Bunkus <moritz@bunkus.org>
* configure: fixed the Qt detection with Qt 5.7.0 which now requires the compiler to be in C++11 mode.
* build system: libEBML v1.3.4 and libMatroska v1.4.5 are now required due to the usage of new elements introduced in libMatroska v1.4.5. The copies included in the MKVToolNix source code have been updated to those releases as well.

2016-06-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: MP4 bug fix wrt. DTS handling: mkvmerge will re-derive parameters such as number of channels and sampling frequency from the DTS bitstream circumventing invalid values in the track headers (e.g. a channel count of 0). Fixes #1727 (https://github.com/mbunkus/mkvtoolnix/issues/1727)/1728.

2016-06-27 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: TrueHD bug fix: fixed detection of 96 kHz sampling frequency.

2016-06-24 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo's GUI: fix a crash due to wrong usage of referenced temporary objects. Fixes #1725 (https://github.com/mbunkus/mkvtoolnix/issues/1725).

2016-06-05 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: the default track languages to set can now also be set whenever the language in the source file is 'undefined' ('und'). This is now the default and can be changed back to the old behavior (only set if the source file doesn't contain a language attribute) in the preferences. Implements #1697 (https://github.com/mbunkus/mkvtoolnix/issues/1697).

2016-06-04 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: menus have been added to both the "start muxing" and the "add to job queue" buttons. The menus let the user override the preferences regarding clearing merge settings after starting to mux and after adding a job to the queue respectively. Implements #1696 (https://github.com/mbunkus/mkvtoolnix/issues/1696).
* mkvmerge: the warning about not being able to determine whether a raw AAC file contains HE-AAC/AAC+/SBR has been removed. Implements #1701 (https://github.com/mbunkus/mkvtoolnix/issues/1701).
* MKVToolNix GUI: enhancement: all file names are now displayed with their native path separators (e.g. "C:\some\where\output.mkv" on Windows). Implements #1298 (https://github.com/mbunkus/mkvtoolnix/issues/1298), #1456 (https://github.com/mbunkus/mkvtoolnix/issues/1456).
* MKVToolNix GUI: merge tool bug fix: the GUI now takes into account whether splitting is activated when looking for and warning due to existing destination files. Fixes #1694 (https://github.com/mbunkus/mkvtoolnix/issues/1694).
* mkvmerge: bug fix: the parser for the --default-duration argument was wrongfully handling arguments of the form "123/456i" (only this specific syntax and only with "i" as the unit; other formats and units were fine). This is part of #1673 (https://github.com/mbunkus/mkvtoolnix/issues/1673). Additionally the parser doesn't use the "double" data type internally anymore fixing loss of precision and failing test cases on certain 32bit platforms. This fixes #1705 (https://github.com/mbunkus/mkvtoolnix/issues/1705).

Have fun :)

[filler56789]

Released v9.3.1 "Mask Machine"

Thanks :thanks:

[Mosu]

Nothing like releasing a new version while eating breakfast ;) Now I have to hurry to work. Have fun with it, and here's to hoping nothing else rears its ugly head.

[Ripman]

Thanks for the report; so far I'm not aware of such an issue.

Please do create an issue on Github for and, and please upload a sample DTS file to my FTP server. You can create one with MakeMKV and split the resulting MKV with e.g. WinSplit — it shouldn't matter that the resulting file is missing certain Matroska structures; the important ones (segment header, track headers) should all be at the beginning.

I'm having a tough time splitting the source mkv so I can upload a sample. I tried using ffmpeg 2.2.2, and the split works, but the DTS-HD MA track also comes out at 48khz. Since ffmpeg yields a similar "issue," I'm inclined to believe that the source out of MakeMKV is problematic even as it shows as 192khz.

Either way, the first step is generating a sample, so I'm still working on that.

[hello_hello]

Thanks for the updates.

There's one very minor thing, and maybe it's just my brain nitpicking and everyone else will think I'm mental, but there's a couple of right click menu items that slow me down because my brain always does a double-take.
Every time I right click on an input file in the Merge pane to remove it, my brain initially ignores the "Remove files" option until it's checked the menu for "Remove file", and then double-checked the input files to ensure I only have one selected. Could the remove option be singular all the time, or singular when right clicking on a single item and plural for multiple items? Would it be better if it was simply "Remove"? I'm in the Merge pane and clicking on an input file, so I'm pretty much expecting to remove an input file.

In my defence, the old GUI had a button for removing input files instead of a right click menu and it was labelled "Remove", not "Remove File" or "Remove Files". I think it's the button labelling convention causing the right click menu to confuse my brain.

My brain usually does a similar double-take when it has to use "Remove jobs" to remove a single job from the queue. I'm certain I know when I'm only removing one job until the GUI confuses me. ;)

In closing, I'd like to point out the right click option in the Job queue labelled
"Edit in corresponding tool and remove from queue"
isn't called
"Edit jobs in corresponding tool and remove from job queue".

Thanks.

[hello_hello]

I don't switch to the Job Queue pane very much. I create a muxing job, start it, then while it's running I work on the next job and click start so it automatically runs when the first one finishes, and so on.... and from that perspective a little more control over jobs from the Merge pane would be nice. I can add jobs to the queue, start them automatically, but not stop them or stop the job queue etc.

So I thought.... the section down the bottom of the Merge pane where currently some information about running jobs is displayed.... to me it's crying out to function as a kind of "minimised" version of the Job Queue pane, and it's a fair way toward that already, but.....

It displays the progress of the current running job without telling you what it is. Would it be hard to display the name of the currently running job just above where the statistics and progress are displayed? From there you could add a Stop button to stop the currently running job (because now you know what it is) and also an Abort button to stop the whole job queue. Then you'd have all the basic job queue control at the bottom of the Merge pane and switching to the Job Queue pane would only be needed for more "refined" editing of the job queue.
What if the right click "show job queue" menu item opened a sub menu showing you the names of the jobs in the queue instead of just switching you to the Job Queue pane? Maybe you could delete jobs in the queue that way or change their status etc, all from the Merge pane?

One last thought.... the drop down arrows next to the "start muxing" and "add job to queue" buttons are a nice addition.... thanks.... but the arrows are such a tiny little target. Would it be possible to also open the same menu items by right clicking on the buttons, or maybe by holding down the Shift key while clicking on the buttons, or something similar?

Thanks.

[Mosu]

Could the remove option be singular all the time, or singular when right clicking on a single item and plural for multiple items?

I'll look into changing the texts based on the number of items selected. I won't shorten those entries to a simple "remove", though. I actually did use "remove" once upon a time, but users (beta testers? Don't remember exactly) were sometimes confused. Therefore I opted to make the entries state explicitly what they'd operate on.

Contributing to the decision were the translators who had sometimes had problems with a simple "remove" (and similar actions, e.g. "add"). They wanted or even needed to translate those differently depending on what those actions would work on. Using the more explicit "remove tracks" solved that issue, too.

The GUI's not entirely consistent in this regard, though. You've already pointed out one example:

In closing, I'd like to point out the right click option in the Job queue labelled "Edit in corresponding tool and remove from queue" isn't called "Edit jobs in corresponding tool and remove from job queue".

In this particular case I opted for skipping "job" as the entry was very long already.

That being said there are probably still entries that aren't consistent with the ideas mentioned above. "Open in MediaInfo" is one such example; it's used in both the file's and the track's popup menu.

[Mosu]

So I thought.... the section down the bottom of the Merge pane where currently some information about running jobs is displayed.... to me it's crying out to function as a kind of "minimised" version of the Job Queue pane

I'm sorry, but that's not a direction I want to take the GUI in.

[Boulder]

I have some Matroska files with srt subtitles that have problems with the Scandinavic characters. If I've understood correctly, this is because the character set has been set incorrectly when muxing. If I demux the subtitle track and open it in Notepad++, it detects the files as UTF-8 encoded.

Is there a way to remux or fix the Matroska files in some automated way or will I need to demux and then open the subtitle file in Notepad++, copy-paste the contents to a new file and then tell mkvmerge to expect UTF-8 encoded files?

[agressiv]

trying to compile 9.3.1 on arch linux (multiple systems) - all get the same errors:

/usr/bin/ld: cannot find -lmagic
/usr/bin/ld: cannot find -lmatroska
/usr/bin/ld: cannot find -lebml


libmatroska 1.4.5-1,libebml 1.3.4-1, and file 5.28-1 are installed but I don't really know how to troubleshoot the rest. Any tips on pointing me in the right direction?

[Mosu]

Huh… For what it's worth it works fine on my Arch (my primary development system is actually Arch Linux); I just compiled it successfully.

Maybe run ldconfig, make sure that the libraries are actually present in /usr/lib and that the symlinks are correct. If in doubt paste the output of "ls -l /usr/lib/lib{magic,ebml,matroska}*" and attach config.log to your post.

[Mosu]

Is there a way to remux or fix the Matroska files in some automated way or will I need to demux and then open the subtitle file in Notepad++, copy-paste the contents to a new file and then tell mkvmerge to expect UTF-8 encoded files?

If they've all been broken in the same way (e.g. encoded from non-UTF-8 to UTF-8 twice) then it is possible to fix that automatically with a hearty dose of mkvextract (for extracting the affected tracks), iconv (for converting from UTF-8 to the other character set once), mkvmerge (for putting the original file and the modified subtitle track together again) and Perl scripting (or any other scripting language; for automating the whole process for any given number of files).

If you want to go down that road you should probably look at mkvmerge's JSON identification mode (e.g. "mkvmerge --identification-format json --identify source.mkv"). The output is trivial to use in any scripting language for which JSON modules are available, and it can be used to easily determine which tracks are actually text subtitle tracks.

However, if you're looking for a turnkey solution to such a particular problem then I don't know of any. The individual tools are all there, though, and the fact that all of them can be automated with nothing more than freely available scripting (or other programming) languages is one of the greatest strengths of such tools: you can make them do way more than their authors ever thought of themselves.

[Boulder]

It seems that the troublesome files are muxed with mkvmerge v8.6.1. At one point, I had to recover all my encoded files from my DVD archives, demux them (to encode the FLAC audio tracks to Opus to save space on my server) and batch mux them again. V8.6.1 was the latest mkvmerge version at that time. The archived version does not have the problem.

I'll take a look at your suggestion, thanks. I do some stuff with scripts so maybe I'll get things working at least semi-automatically.

[Mosu]

The character set handling hasn't really changed over the last year, it's almost the same in 8.6.1 and 9.3.1. Therefore I guess that either your sources were different (e.g. one set of sources did use BOMs while another didn't) or you used different settings in each case.

That being said, there's one particular bug fix that stands out and that might apply to your situation and explain what you're experiencing (though you haven't given enough details to know for sure). Citing the ChangeLog:

2016-03-09 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: bug fix: the --sub-charset option is now ignored for
text subtitle files that start with a byte-order mark (BOM)
bringing the behavior in line with the documentation. Fixes #1620.

[Mosu]

…demux them … and batch mux them again

Just to point this out once more. You don't have and most likely never should demux all tracks if you're aiming to put them into Matroska later anyway. Valueable meta information is almost lost that way (e.g. timestamps, tags, track names, track language etc. etc.). Always only demux those tracks that you intend to re-encode, not the others.

Additionally the risk of the content being modified in undesired ways (such as your encoding issue) as there's no character set conversion involved at all when you mux from Matroska to Matroska.

[Boulder]

Just to point this out once more. You don't have and most likely never should demux all tracks if you're aiming to put them into Matroska later anyway. Valueable meta information is almost lost that way (e.g. timestamps, tags, track names, track language etc. etc.). Always only demux those tracks that you intend to re-encode, not the others.

Additionally the risk of the content being modified in undesired ways (such as your encoding issue) as there's no character set conversion involved at all when you mux from Matroska to Matroska.Thanks, I'll keep that in mind in the future (but hopefully never ever have to recover everything again) :)

I think I demuxed all tracks because the order is not always the same, or there are PGS subs or SRT subs etc. I probably couldn't find a decent way to automate things so I went the easiest way.

One thing about those character sets. I recall that you changed some default behaviour related to that at some point, not so long ago, but reverted the change later. Do you happen to remember if that could have anything to do with the problem?

EDIT: Found the thing. The change was made in v8.6.0, then reverted back in v8.7.0. It affected all text files output by the tools, which probably caused my issue. I just happened to have bad luck there to use one of those versions with the change.