MKVToolnix -- Cross-platform tools for Matroska

Frequently asked & answered questions

Muxing

Features

Distribution

Muxing

Is it possible to create byte-identical files if the source files and the mux settings are identical?

Technically, it is possible, but mkvmerge does not allow this in an easy way. There are several elements in a Matroska file that differ with each muxing, even if everything else is the same between different mux runs. These include but are not limited to the muxing date (DateUTC) and all unique IDs (track UIDs, attachment UIDs, segment UIDs, chapter UIDs etc etc).

If you use different builds of MKVToolNix then you'll also have the WritingApp differ as it contains mkvmerge's version number and build timestamp.. This may be the case e.g. if you want to mux on two different machines.

mkvmerge knows a switch that will use fixed values for all of the elements listed above. However, files created this way have serious issues: they violate the Matroska specifications, may cause problems during playback (especially with advanced features like segment linking, ordered chapters etc) and are not future-proof. The only reason this switch exists in the first place is that it is used for regression testing during mkvmerge's development. For this reason I will not name the switch here.

There is a solution if you're willing to run other software directly after the muxing process. What most people do if they want to have byte-identical files is mux the two files with identical settings and then use a file synchronization tool for copying only the differences between the two files. This is a pretty fast process as the amount of bytes the two resulting files differ by is very small.

There are several OpenSource programs that are suited perfectly for this job. On Linux/Unix/Mac people usually use rsync. On Windows people usually use a native port of rsync called DeltaCopy. Another alternative is Unison.

Can the tools use FIFOs, pipes or standard output/standard input for reading/writing?

No. All of the tools in the MKVToolNix package rely on their input and output files being fully seekable. FIFOs, pipes and standard input/output are not. Therefore they cannot be used.

At the moment there are no proper error messages if you try to use a FIFO as an input or output file. However, the resulting files are most likely cut off or incorrect.

Why does the language "eng" (English) not show up in the output file even though I've selected it in the GUI?

The Matroska specifications know a feature called "default values". These default values have been in place since the beginning in 2002. The meaning of the default value is that any application reading a Matroska file must use the default value if the element itself is not present in the file. For example, if the track headers for a track do not contain a "language" element then this means that the value "eng" must be used by the reading application.

Starting with version 4.0.0 mkvmerge does not write elements to output files whose value equals their default value. This mostly applies to the "language" and "default track flag" elements. If an application does not show "eng" as the track's language even though you've selected it in the GUI then please file a bug report for that application.

Why does audio not play anymore since v4.1.0 (MP3, AC3, DTS audio tracks)?

The Matroska specifications know a feature called "header removal compression". This allows a muxer to keep a certain number of bytes that are identical for each frame in the track headers removing them from the individual frames. This reduces the size of the tracks significantly without altering the content as a demuxer can add the bytes found in the track headers to each frame during demuxing.

Starting with v4.1.0 mkvmerge uses header removal compression for a couple of track types by default. These include AC3, DTS and MP3 audio tracks as well as Dirac and MPEG-4 part 2 (aka. XviD/DivX) video tracks. The user muxing a file may disable it by explicitely selecting 'none' as the compression scheme for such a track.

If your player has difficulties playing such files then it is a bug in that player or in the demuxer but not in mkvmerge. This feature has been part of the Matroska specification since more than six years, and there's no excuse for refusing to add support for it.

The proper solution is to ask the vendor of your player to support this feature. A temporary solution is to re-mux such files turning off extra compression for all tracks.

Here's a list of hardware and software players that do not implement this part of the specification. This list is most likely outdated as updates are released by the authors and manufacturers.

Features

Will there be a batch muxing feature in mmg?

Sorry, but such a feature will never be implemented. There are excellent shells out there that can do this easily. For example, with a bash you could convert all .avi files into Matroska with these commands:

find -type f -name '*.avi' | { while read filename ; do mkvmerge -o /path/to/output/dir/"`basename "$filename" .avi`.mkv" "$filename" ; done ; }

I do realize that using shells is not everyone's thing. However, implementing a powerful and flexible batch remuxer requires countless hours of work. If I cut down on the hours then either the flexibility or the number of features would be severely reduced and therefore the work would not be worth it because too few people could actually use it in such a state.

The short version is that it's way too much work and that I don't have that amount of free time. So the answer is "no". Sorry.

When will mkvmerge/mmg support MPEG transport streams (.ts or .m2ts files)?

Adding support for a whole container format is one of the most time-consuming activities. Adding support for MPEG transport streams in particular even more so due to the number of different implementations and problems that exist around them. This is time I don't have at the moment, and therefore I don't have concrete plans for implementing this feature.

This does not mean that I will never implement it. I totally agree that it would be a nice feature to have, and I will gladly accept patches that implement this kind of support if someone were to write them. It's also possible that I will find the time and motivation to work on this myself, but please don't hold your breath.

Distribution

Is MKVToolNix compatible with Windows 7?

Yes. Starting with v3.0.0 it even displays the muxing progress in Windows 7's taskbar, but earlier versions were working just fine as well.

Is MKVToolNix compatible with 64bit versions of Windows?

Yes. The Windows builds I distribute are 32bit, but they're fully compatible with 64bit Windows installations. There are several reasons why there are no special 64bit builds, but the most important of them is that MKVToolNix does not gain anything from being compiled with 64bit. Its 32bit version fully supports files of any size, arbitrary time codes, and needs a lot less memory than the maximum that a 32bit operating system provides.

Is there a virus in your installer for Windows?

Short answer: no, and there never has been one.

Longer answer: no, and here's why.

Several times in the past users have reported that their virus scanner detected a virus in the installer for Windows available on my site. I could verify that some virus scanners did indeed detect something, but most others did not. There are several reasons why I'm 100% certain that this was a false positive:

  1. The build process for the installer runs exclusively on Linux. MKVToolNix itself is built on Linux with a mingw cross compiler, and the installer itself is built with a Linux version of the NSIS compiler. Afterwards the installer is uploaded to my Linux-based webserver by the Linux program Unison.
  2. Even on my Linux machine I run an anti virus software which has never detected a virus.
  3. The installer software I use (NSIS -- the Nullsoft Scriptable Installation System) has been the victim of being falsely detected as being virus infected in the past. Those cases have all been false positives.
  4. When this problem occured the first time I sent the installer to Kaspersky for verification. Kaspersky replied quickly and confirmed that it was indeed a false positive.