MKVToolNix v24.0.0 released

[Mosu]

Hey,

I've release v6.7.0 of MKVToolNix. It contains tons of bug fixes all over the place, but also a couple of enhancements. The most important bug fix is probably the change to how MPLS files are handled (see below).

This is the first release for which I'm providing 64bit binaries for Windows as well. They offer the same functionality as the 32bit binaries. Versions can be distinguished in their version number output as well as mmg's »about« dialog.

Please note that the Windows installer and portable archive do not contain the word »Unicode« anymore. That's not because they don't support Unicode; they do. It's just that the last release without Unicode support was v2.something quite a lot of years ago, and there's simply no reason to point out the Unicode-awareness anymore.

There's one change for package maintainers: Ruby 1.9.x is now required for building. I don't support 1.8.x anymore. This should not be a problem for current distributions anyway.

Here are the usual links:

...to the source code:
http://www.bunkus.org/videotools/mkvtoolnix/source.html

...to the binaries:
http://www.bunkus.org/videotools/mkvtoolnix/downloads.html

Here's the full ChangeLog since release 6.6.0:

2014-01-08 Moritz Bunkus <moritz@bunkus.org>
* Released v6.7.0.
* build system: Ruby 1.9.x is now required.

2014-01-05 Moritz Bunkus <moritz@bunkus.org>
* all: enhancement: The architecture (32bit/64bit) is mentioned in the version information of all programs.

2014-01-02 Moritz Bunkus <moritz@bunkus.org>
* build system: bug fix for 64bit builds on Windows (x86_64-w64-mingw32): use the correct processor architecture via separate Windows manifest files. Fixes mmg and mkvinfo not starting due to »error 0x0000007b«.
* mkvmerge: bug fix: Fixed a potential endless loop due to an integer overflow in the code removing AVC/h.264 filler NALUs.

2014-01-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed reading uncompressed PCM audio tracks from QuickTime/MP4 files in certain situations. Fixes #950 (https://www.bunkus.org/trac/ticket/950).
* mmg: enhancement: Made the »scanned files« list box sortable by all columns. Fixes #954 (https://www.bunkus.org/trac/ticket/954).

2013-12-31 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: The »additional parts« dialog will now show the files that make up an MPLS playlist. This is for informational purposes only and doesn't allow changing the playlist itself.
* mkvmerge: bug fix: Reading from an MPLS playlist file is now done as if the second and following files referenced in that playlist had been appended to the first file from that playlist. Before they were treated as if they were additional parts. Fixes #934 (https://www.bunkus.org/trac/ticket/934).
* mmg: enhancement: a couple of fixes to tooltips: 1. Content correction for »splitting by chapters«; 2. no ugly re-formatting with wxWidgets 3.0.0 on Windows.

2013-12-30 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Improved the AAC, AC3 and MP3 header decoding error handling so that the corresponding parsing routines won't get stuck in endless loops when encountering certain garbage data patterns.

2013-12-29 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: unified codec names output by mkvmerge's identification mode for all file format readers.
* mkvinfo: bug fix: when setting the language with --ui-language a few strings were still translated using the system's default language.
* mkvextract: bug fix: if the track headers were located at the end of the file (e.g. after modification with mkvpropedit or mmg's header editor) then mkvextract was writing files with a length 0 bytes.
* mmg: bug fix: the »playlist items« list box in the »select playlist file to add« dialog was showing the items in reversed order. Fixes #952 (https://www.bunkus.org/trac/ticket/952).

2013-12-28 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: the »select playlist file to add« dialog can now be resized, minimized and maximized. It also remembers its position and size during runs. Fixes #951 (https://www.bunkus.org/trac/ticket/951).

2013-12-27 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: The user can select the default subtitle character set to use for newly added subtitle tracks in the preferences dialog as requested in bug #948 (https://www.bunkus.org/trac/ticket/948).

2013-12-24 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: fixed the tooltip for the subtitle character set drop-down box to match mkvmerge's actual behavior. Fixes #948 (https://www.bunkus.org/trac/ticket/948).

2013-12-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: implemented reading DTS audio tracks from MP4 files (with ESDS object type ID == 0xA9 (decimal 169) or FourCC == 'DTS ' or 'dtsc').

2013-12-18 Ralph Giles <giles@mozilla.com>
* mkvmerge: enhancement: allowed muxing Opus to WebM files.
* mkvmerge: bug fix: Fixed the mapping of the Opus element »seek pre-roll« and »pre-skip« to the Matroska elements »track seek pre-roll« and »codec delay«. Remuxing Matroska files without Opus created with earlier versions of MKVToolNix is enough to fix such a file.

2013-12-15 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixing the bitstream timing information of h.264/AVC writes clean values for 25000/1001 frames per second video (e.g. de-telecined PAL @ 29.97).

2013-12-07 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: fixed a crash in during drag & drop operations in mmg's chapter editor.

Have fun.

[sneaker_ger]

Remuxing Matroska files without Opus created with earlier versions of MKVToolNix is enough to fix such a file.
Without or with?

[Mosu]

»With«, of course.

[nautilus7]

Hi, thanks for the update.

Shouldn't the 64bit version install to "Program Files" folder instead of "Program Files (x86)" by default?

[Chumbo]

Thanks Mosu.

[Overdrive80]

Hi, thanks for the update.

Shouldn't the 64bit version install to "Program Files" folder instead of "Program Files (x86)" by default?

Yes, I think the same.

[Mosu]

Hi, thanks for the update.

Shouldn't the 64bit version install to "Program Files" folder instead of "Program Files (x86)" by default?

Yes. That will be fixed for the next release.

[fryk]

I use mkvtoolnix 6.7.0 64bit in Win 8.0 x64

All works fine but I cannot start mmg. Error message is:

http://img716.imageshack.us/img716/2299/0c0v.png

[Mosu]

Does the 32bit version work for you? How soon does this message occur (do you ever see the GUI pop up or not)?

[fryk]

The 32bit version works. And no, I can't see the GUI window, the error msg box comes immediately.

PS: Issue is solved. I use the portable version and have to add myself to the mkvtoolnix program folders permissions. Even if I "installed" the program files (made the folder and copied the files). This wasn't necessary ever before, sorry.

[Mosu]

Please do the following:

Download and install this build (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-amd64-6.7.0-build20140109-571-4768784-setup.exe) with debugging options
Start mmg. It will likely fail in the same way.
Navigate to the folder C:\Users\YourUserName\AppData\Local\Temp
Locate the file mkvtoolnix-debug.log and send it to me to moritz@bunkus.org; we'll do the rest by email

[Snowknight26]

Is having zlib compression enabled for PGS streams supposed to remove the forced flag on individual subtitles?

[Mosu]

zlib is lossless compression algorithm. It doesn't modify the PGS stream at all.

[Snowknight26]

zlib is lossless compression algorithm. It doesn't modify the PGS stream at all.

Figured as much. Had to rule mkvmerge out as both eac3to and LAV Splitter have issues with this particular PGS stream.

[Selur]

Thanks for the update, any news regarding H.265 support?

[Chumbo]

I use mkvtoolnix 6.7.0 64bit in Win 8.0 x64

All works fine but I cannot start mmg. Error message is:

http://img716.imageshack.us/img716/2299/0c0v.png
Does the 32bit version work for you? How soon does this message occur (do you ever see the GUI pop up or not)?
I'm running Windows 8.1 Pro 64bit and have no problems with the 64bit version. I do install to a custom location, i.e., outside of the standard Program Files, but I uninstalled it and reinstalled to default location and it also worked fine. If the log doesn't shed any light, try [fryk] using SysInternals' Process Monitor to see what gets flagged when mmg is loading.

[EDIT] @fryk, you can also check the application log in the event viewer which may provide Mosu with some helpful info.

[Mosu]

fryk told me in an email that he had some permission problem on his end resulting in said error. The 64bit version is working just fine for him now, too.

[Mosu]

Thanks for the update, any news regarding H.265 support?

I've actually started work on that before the 6.7.0 release. The commits by DivX/Rovi have been merged and updated to compile with the latest code. The next steps are actually testing that it (still) works, creating tests, documentation and source code cleanups. My current plan is to have this in for the next minor release, 6.8.0.

[smok3]

Thanks, small request;
"options/mmg/Check online for the latest release"
should be disabled by default (at least in Debian edition) for two reasons;
a. The way repos work makes it unnecessary
b. Software calling home would/could be considered unsafe/buggy (imho)

[Mosu]

I disagree.

Debian's (and Ubuntu's) official releases are always notoriously out of date. So it does make sens, even for repository-based installations. If you're using my own repo then that is mitigated, but I still don't care enough to actually invest any work into it.

Second, I would consider »calling home« to be something to be concerned about if there was actually any transfer of information from your computer to my server. As it is implemented the application only does a simple HTTP GET request for a single XML file without any additional parameters/HTTP headers/customization[1] (https://github.com/mbunkus/mkvtoolnix/blob/master/src/common/version.cpp). The URL is always http://mkvtoolnix-releases.bunkus.org/latest-release.xml[2] (https://github.com/mbunkus/mkvtoolnix/blob/master/src/common/version.h).

If you feel strongly about these points then you have several options:

Compile your own package and disable the curl support completely (add »--without-curl« to configure). That way none of the programs does have any internet access. It's easy (http://www.bunkus.org/videotools/mkvtoolnix/source.html#debian_ubuntu_package).
Disable that setting in mmg's preferences. mmg is the only one that does this check on its own. All other applications require a parameter to be passed to them before they'll execute said check.
File a bug report at Debian. There's one already for Ubuntu (https://bugs.launchpad.net/ubuntu/+source/mkvtoolnix/+bug/1014229) already, but it doesn't seem like they care that much either.
Don't use mmg at all.

[smok3]

Thank you for your consideration & no I don't feel strongly about that, just a suggestion.

[[ReX]]

Mosu, is the translated "File" string meant to be shown with "mkvmerge --identify-verbose"?
For me, it shows "Ficheiro" (pt-PT) in Windows (pt-BR).

Edit: it also shows "contentor" instead of "container".

Edit 2: Also, did you forget about "A_REAL/*" in codec.cpp?

Edit 99999: VP9 is duplicated in codec.cpp.

[Mosu]

The output of »--identify-verbose« is supposed to be translated, yes. You have two options:

Use the undocumented option »--identify-for-mmg« instead of »--identify-verbose« which results in untranslated identification output but translated error messages
Use the documented option »--ui-language en« along with »--identify-verbose«


I did indeed forget about A_REAL/* – as in »I thought about them, put them on hold while I still had other issues to sort out with codec_c, and promptly forgot about them again« :)

Thanks for pointing it out (the VP9 duplication, too).

[Stereodude]

What's the main difference between "append" and "additional parts" when I have multiple sequential .264 files (encoded with --stitchable) that I want to put into a mkv container as if they were one continuous file. The mkv seems to play fine when I try it either way, but which method is the right one to use?

[Mosu]

For raw .264 both methods should be equivalent. Same for most other raw formats that can only contain a single track, that don't have global file headers and that do not have timestamps (raw AAC, AC3, MP3, MPEG-1/2 ES).

For formats in which each has their own headers (AVI, MP4, Matroska, FLAC, TTA, Ogg, IVF…) or in which multiple tracks can occur (MPEG TS…) appending is the appropriate choice.

The only place where »additional parts« is the appropriate choice and »append« would be wrong is where a file has been cut into multiple files at an arbitrary position. This is the case for VOBs on DVDs. Think of having one giant 4 GB VOB file that's been treated with WinSplit (or the Linux equivalent »split«).

However, if you want to append VOBs from multiple sources (from two different DVDs) then »append« may be the appropriate choice. So you cannot say »always use additional parts for VOBs« either.

The worst part is that you cannot really autodetect it reliably (not even close). For DVD-like named files mmg/mkvmerge does it, but that's about the only place. Heck, I even got it wrong for Blu-rays and just fixed it in 6.7.0 (see the change regarding how MPLS files are treated).

Summary: If in doubt use »append«.

[Stereodude]

Thanks for the quick and detailed explanation.

[Snowknight26]

Just out of curiosity, any reason you're using strange angle quotation marks?

[Mosu]

They're called Guillemets (http://en.wikipedia.org/wiki/Guillemet), and I'm German.

[[ReX]]

Use the undocumented option »--identify-for-mmg« instead of »--identify-verbose« which results in untranslated identification output but translated error messages

I knew there was a switch that wasn't supposed to be translated, but I was mistakenly remembering it as "--identify-verbose".
Thanks for the answer. You probably answered this same silly question several times, sorry about that.

[Brother John]

The next steps are actually testing that it [HEVC] (still) works, creating tests, documentation and source code cleanups. My current plan is to have this in for the next minor release, 6.8.0.
Is there a way already to experiment with HEVC muxing? The 583-559b275 Windows pre build doesn’t recognise an x265 HEVC elementary stream as a valid file type and I couldn’t find any HEVC/H.265 references in the Github commit messages. (I might be completely blind though, it’s happened before. ;))

[mikeyakame]

I just noticed today that I was getting the following output from mkvmerge 6.7.0 (x64 windows build)


mtx ex: Unknown error (type: N3mtx5mm_io13end_of_file_xE)


and


mtx ex: No error (type: N3mtx5mm_io13end_of_file_xE)


These warnings/output seem to be harmless as the exit value is 0 and the resulting mux seems to be fine.
It only appears to output this when remuxing matroska files.

Should I be concerned about them at all?

[Mosu]

Is there a way already to experiment with HEVC muxing? The 583-559b275 Windows pre build doesn’t recognise an x265 HEVC elementary stream as a valid file type and I couldn’t find any HEVC/H.265 references in the Github commit messages. (I might be completely blind though, it’s happened before. ;))

Not with my mkvmerge. The development's happening in a different branch from which the releases aren't built.

[Mosu]

I just noticed today that I was getting the following output from mkvmerge 6.7.0 (x64 windows build)


mtx ex: Unknown error (type: N3mtx5mm_io13end_of_file_xE)


Known issue due to a compiler bug. See https://trac.bunkus.org/wiki/Troubleshooting for details.

[Anakunda]

HI!!
I'd have some question about occasional spontaneous applying of positive delay for audio tracks. I noticed that (only sometimes) media info reports effective audio delay present on audio track even if I use none user value for muxing (empty delay field). Regardless if I use GUI or console. Reported as
Delay relative to video : 24ms
or similar. For this I'd be thankful to know when and why is mkvmerge using implicit delay and from what the value which looks to me like completely random it's derived (P.S. the respective audio tracks filenames contain no time or delay expression).

[sneaker_ger]

This can happen if the source container signals a delay. Because mkvmerge deletes frames before zero both negative and positive delays in the source container can result in a positive delay (i.e. first time code >0) in the output mkv file. Are your source files by chance mp4 containers with aac audio? Common aac encoders signal their encoding delay by writing certain tags and mkvmerge reads and applies them automatically.

[Mosu]

First off read https://trac.bunkus.org/wiki/FAQ%3ADelayNotShownInMmg. It touches on this subject and is rather important to understand.

Now. mkvmerge does not apply arbitrary delays. It does, however, try to keep the timestamps of all packets. MP4 files, for example, can have the audio start later than the video (or the other way around), and mkvmerge simply these relative offsets but shifts them down to 0.

Let's take a notional MP4 file with three tracks: one video, two audio. Let's assume that you only copy audio track 2, not audio track 1. Let's further assume that the smallest timestamp of the video packets is 12ms, the smallest timestamp in audio track 1 is 0ms and the smallest timestamp in audio track 2 is 40ms. When you mux this into a Matroska file then mkvmerge will take the minimum of all the timestamps read from the tracks of this file (this would be either 12ms from the video track or 40ms from audio track 2 – audio track 1 is not muxed and therefore disregarded; ergo the minimum is 12ms) and subtract it from all timestamps in that source file (this is the shift to 0).

So in the output file the smallest video timestamp will be 12ms - 12ms, and the smallest audio timestamp will be 40ms - 12ms = 28ms.

And that's what MediaInfo will show you: audio starts 28ms after the video starts.

Edit: sneaker_ger's right. In addition to the normal timestamps in an MP4 file mkvmerge also applies the encoder delay stored in the MP4 file headers to those timestamps.

[Anakunda]

Just that no because the used tracks are always either AAC (in m4a) or AC3. But it's susrprising that the AAC file can signal any delay if it's converted with no delay flags (--no-delay)

edit: okay Mosu's reply seems to clear things up

[jkauff]

I'm having a problem with 6.7.0 64-bit on Windows 8.1 64-bit. Files load OK, but muxing immediately produces a return code of 3. Same files work perfectly on 6.6.0.

Anyone else experiencing this?

[Mosu]

See https://trac.bunkus.org/wiki/Troubleshooting; it's a known & fixed problem.

[Caroliano]

I finally discovered the source of the problem I was having since I moved to windows 8.1: http://forum.doom9.org/showthread.php?p=1655957#post1655957

How to reproduce:
- Create a new windows user named "Cloé".
- Try running mmg from that user (you may download a portable version to make it easier)
- Nothing happens.
- Now create a new user named "Mike" and log in with him, mmg will work.

Even if you use the "rename user" option for "Cloé", mmg will refuse to work, probably because the "C:\Users\" folder will still be named "Cloé", and there is no safe way to change it. So, please fix this bug. This is the only program where I had this kind of problem (thankfully!).

[Mosu]

Cannot reproduce:

http://www.bunkus.org/misc/mmg-670-win81-chlo%C3%A9.png

Edit: changed IMG tag to normal URL as the screenshot is rather large.

[Caroliano]

Strange. I can consistently reproduce the working/non-working of mmg just by switching between the two new fresh windows users I created (one accentuated and one non-accentuated name being the only thing differing between them).

By the way, in version 6.7.0 it now gives this error screen on both 64 bit and 32bit portable versions, and the debug version that you posted two pages ago. (http://forum.doom9.org/showthread.php?p=1661325#post1661325) I will use the same image link as the previous user that got this window:
http://img716.imageshack.us/img716/2299/0c0v.png

Here the contents of the mkvtoolnix-debug.log:
2014-01-15 19:34:24 +0ms Current file & line: src/mmg/mmg.cpp:331
2014-01-15 19:34:24 +1ms Current file & line: src/mmg/mmg.cpp:333
2014-01-15 19:34:24 +2ms Current file & line: src/mmg/mmg.cpp:335
2014-01-15 19:34:24 +5ms Current file & line: src/mmg/mmg.cpp:205
2014-01-15 19:34:24 +12ms Current file & line: src/mmg/mmg.cpp:210
2014-01-15 19:34:24 +13ms Current file & line: src/mmg/mmg.cpp:217
2014-01-15 19:34:25 +1244ms Current file & line: src/mmg/mmg.cpp:337

[Mosu]

Already fixed. Read https://trac.bunkus.org/wiki/Troubleshooting.

About the issue with mmg not starting: no idea what's wrong, and without being able to reproduce it I don't stand a chance of debugging it - not to mention fixing it.

[Caroliano]

I tried the builds linked at that troubleshooting link and still get the same "***Caught unhandled unknown exception; terminating" error on both 32 and 64bit, portable and installer. There is no new debuging build that can see where it hangs on my computer, because I can reproduce here.

[Mosu]

I somewhat doubt that you're really executing the correct mkvmerge.exe executable and not some older version. I cannot reproduce the exceptions with either of the four builds linked in the troubleshooting article on my Windows 8.1. With the release builds I was able to reproduce them quickly and deterministically.

Anyway. Things I cannot reproduce remain impossible to diagnose, so I'm sorry but I cannot help you at the moment.

[shinchiro]

I tried remove some font attachment using with mkvpropedit. The fonts had been removed but the size still no reduced. Is it normal? I need remux the file again to see the size decrease..

[Mosu]

Yes, that is normal. Attachments don't have to be stored at the very end of the file. Instead they can be stored anywhere within it. mkvmerge stored them after the track headers before the first cluster. mkvpropedit will only overwrite them with an EbmlVoid element if they're not located at the end.

[shinchiro]

I see. Thanks for the clarification

[DragonQ]

I've finally gotten around to archiving some TV recordings (1080i/25 AVC) from the past couple of months after being lax about it. However, every single MKV file that I've made so far has dodgy timestamps and thus doesn't play back correctly in many places (MadVR shows frame drops, EVR shows graph oddities). I've tried changing everything I can think of to find where the problem lies:

- Happens with both MadVR and EVR in MPC-HC
- Happens with both MPC-HC and MediaPortal
- Happens with LAV Filters 0.60.1 and 0.58.2
- Happens using DXVA2 Native and ffmpeg decoding
- Happens using both MKVToolNix 6.0.0 and MKVToolNix 6.7.0
- Happens when muxing the original TS file as well as the cut TS file created by TS-Doctor

The original TS files play back perfectly whether cut or not. Can anyone identify what the problem might be? I can't imagine the broadcast stream format has changed over the last couple of months since that'd probably break lots of hardware out there.

Here's a sample: TS file (http://www.aotplaza.com/Files/HTPC/Samples/MKV%20Dodgy%20Timestamps%20Sample.ts) | Dodgy MKV file (http://www.aotplaza.com/Files/HTPC/Samples/MKV%20Dodgy%20Timestamps%20Sample.mkv)

[Simon88]

@DragonQ: You might try VLC 2.1.2 or K-Lite Mega those two has worked great for me on problematic streams. For cutting of *.ts stream, Avidemux 2.6.7 works great for me as the MKV produced by it is fine, BUT I re-mux again using latest MKVTools, "just in case"..