MKVToolNix v24.0.0 released

[Z-95]

Originally Posted by 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.

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]

Originally Posted by Z-95

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. Please give them a try, both with 96 kHz as well as 192 kHz. Thanks.

[Z-95]

Originally Posted by Mosu

I've just fixed this in the latest pre-builds. 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?

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

[Ripman]

Originally Posted by 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, the Windows installer/portable version & Mac OS DMG and the source code.

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

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

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

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.

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.
* mkvmerge: the warning about not being able to determine whether a raw AAC file contains HE-AAC/AAC+/SBR has been removed. Implements #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, #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.
* 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. 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.

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]

Originally Posted by Mosu

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]

Originally Posted by Jamaika

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.