MKVToolNix v6.6.0 released


I’ve released MKVToolNix 6.6.0. I’m trying to get back on a release cycle of roughly six weeks between minor versions (minor being the middle part of the version number). So releases may happen more often than over the summer but contain few changes.

This release fixes a couple of bugs and greatly improves the compatibility to the newly released wxWidgets 3.0.0. A new translation into Portuguese has been added, and you can now re-order chapters in the chapter editor with the usual drag & drop operations.

Nothing has changed for package maintainers compared to the previous release, v6.5.0.

You can download the source code or one of the binaries.

Here’s the full ChangeLog since release 6.5.0:

  • 2013-12-01 Moritz Bunkus <>
    • Released v6.6.0.
    • mmg: new feature: implemented drag & drop in the chapter editor. Implements #929.
  • 2013-11-24 Moritz Bunkus <>
    • mmg: bug fix: fixed an assertion in wxLogMessage() due to wrong format string/argument data types caused by changes in wxWidgets 3.0.0. See Debian bug #730273.
    • mkvmerge: bug fix: improved resilience against MP4 files with obviously wrong entries in the ‘sample size table’ (STSZ) atom.
    • mkvmerge: bug fix: improved VC1 frame type detection so that it works even for streams without entry points.
  • 2013-11-14 Moritz Bunkus <>
    • mkvinfo: bug fix: at most the lower 32bits of the track numbers and track UIDs elements were output, even if the element in the file used more bits. Fixes #935.
  • 2013-11-02 Moritz Bunkus <>
    • mkvmerge: bug fix: fixed accessing invalid memory in the memory handling core routines. May be triggered by the code to remove filler NALUs introduced in v6.5.0. Fixes #931.
  • 2013-10-26 Moritz Bunkus <>
    • mmg: bug fix: fixed the tracks list box on the input tab being invisible/0 pixels high with wxWidgets 2.9.x/3.x.
    • all: integrated the Portuguese translation. Although the translation files themselves had been added back in 6.3.0 that translation wasn’t available for selection due to forgetfulness on my part.
    • mkvmerge: bug fix: The file detection code in the MPEG elementary stream reader had a logic error. Fixes #928. In practice this logic error didn’t have any consequence.

Have fun.

22 thoughts on “MKVToolNix v6.6.0 released

  1. David

    Testing the new version, Mosu. Thanks for improving the chapter marking capabilities. Hopefully the automatic sorting will come up next!

    1. mosu Post author

      I don’t quite understand your question.

      If you want mkvmerge to remove the source file after muxing has completed successfully: there’s no option for that.

      If you want to output to the same file you’re currently reading from: that is technically impossible. mkvmerge contains some code for preventing it by checking source/output file names.

      1. Lucas

        For example, when the process was killed – is it possible to corrupt the source file?

        Also I’m not sure how to use the CLI version. I tried
        mkvmerge -o new.mkv source.mkv –no-subtiles –audio-tracks 1
        But the output is exactly the same as the input

  2. Bob

    Hey, looks like Trac is down; I get a 502 Bad Gateway.

    Anyway, I just downloaded the latest Windows release. I’m trying to get the complete IDs for linked chapters with one command, but I cannot figure out how.
    I’ve tried “mkvinfo.exe –ui-language en test.mkv”
    This gives me the complete “Segment UID”, but the “ChapterSegmentUID’s” are truncated no matter what I try. Also, even though I used –ui-language, I see for example “ChapterSegmentUID: Länge 16, Inhalt:”.
    If I use “mkvextract.exe chapters test.mkv” I do get the complete “ChapterSegmentUID”, but the “Segment UID” is missing.
    Also, could mkvinfo export the details as XML, like mkvextract does?

    Apart from that, great tool :)

    1. mosu Post author

      Trac’s up and running again.

      I don’t know why selecting the interface language doesn’t work for you. It does for me.

      A ChapterSegmentUID is a binary element (from the point of view of the specs), and mkvmerge only outputs the first 16 bytes for binary elements because they can become arbitrarily long. For example, CodecPrivate elements can be easily a couple of KB big, and you wouldn’t want to see a hex dump of that each time you run mkvinfo.

      The segment UIDs are stored in a different place than the chapter segment UIDs (in the »segment information« element, to be precise). At the moment mkvextract cannot extract the segment info section at all.

      So no, it’s not possible and most likely never will be to extract all that stuff in exactly the format you want with a single execution of one of the tools.

      mkvinfo cannot output XML and most likely never will be able to. I’ve thought about how that could be accomplished and have therefore a very thorough understanding of the amount of work required to re-write huge portions of mkvino for such a purpose. Way too much work for pretty much no gain to myself.

      1. mosu Post author

        And trac’s down again… Don’t know what’s up with it. Will have to investigate.

  3. Bob

    > I don’t know why selecting the interface language doesn’t work for you. It does for me.
    Oh, it’s not all the output. Just that line isn’t in english, the rest looks fine. Sorry for not being more clear.

    > A ChapterSegmentUID is a binary element (from the point of view of the specs), and mkvmerge
    > only outputs the first 16 bytes for binary elements because they can become arbitrarily long.
    Hm, from your experience, would it be ok to rely on those 16 bytes only to identify a linked chapter? Not for a player, but only for a informational purpose, like saying “hey, you’re missing a linked chapter file”.
    So if the ChapterSegmentUID can be a few kB, the segment UID can be too, right? Because they have to match for a successful linking.

    1. mosu Post author

      Even though segment UIDs are binary elements (which can be arbitrarily long) the specs actually say that they’re exactly 128 bits long. See 128 bits = 16 bytes.

      Now the chapter segment UIDs are supposed to reference existing segment UIDs, so they as well will be 16 bytes long, and therefore the answer to your question is of course »yes«.

      As to that one line being displayed in a different language: that I would really like to see. Would you mind sharing a screenshot of mkvinfo’s output showing that particular and its surrounding lines? Please also post the exact command line. Thanks.

          1. Bob

            One last thing: a Segment UID is according to the Matroska specs always 128 bit long (as you said above too), so would you consider to display the 16 bytes of the ChapterSegmentUID when using mkvinfo? Currently it truncates the UID after 10 bytes. Then it would be possible to get all UIDs required for finding linked chapter dependencies with a single call.
            That should be quite simple.

          2. mosu Post author

            I’ve just committed a change so that mkvinfo outputs the first 16 bytes for EBML binaries instead of the first 10. Builds 557 and higher will have it included. Upload should be finished in ~5 minutes.

  4. kassandro

    Upgrading from version 6.0 to 6.6 I noticed, that support for transport streams as an input format has been added to mkvmerge. That’s very nice. Usually such transport streams originate from digital tv transmission, whence they easily may contain errors. So far mkvmerge doesn’t seem to spot these errors, which may also cause A/V sync problems. It would be nice, if mkvmerge would recognize such errors and report where they occure.

      1. kassandro

        I thought, that this is only a matter of checking the checksums of the GOPs, but I don’t know the details.

Comments are closed.