MKVToolNix v24.0.0 released

[Sparktank]

Good news, everyone! The author of MKVExtractGUI2 has just posted on my bug tracker that he's updated his GUI:

That's wonderful news! :D
I was holding off on doing anything until there was news of anything updating.

I figured it would be a week or so lol.

Thanks for the info.

[Mosu]

Doesn't work for me. Extracting the second track (audio) works fine but extracting the first one (video) gives me this when using mkvtoolnix 5.2.1:

http://i43.tinypic.com/s6onle.png

(Note that my renaming of the exe isn't the issue; it happens with its default name too.)

Don't post this HERE. The author doesn't read the thread. And I don't support any of the mkvextract GUIs as they're not my products.

[Selur]

Got a small (?) feature request for mkvmerge&mkvextract: add the possibility to cut 'from-to' where from and to can be times or chapters.

It's a bit like the splitting by timecodes option.
When using mkvmerge to split by timecodes and feeding it with something like 01:20:10.000,01:23:12.400 I would end up with 3 files (middle one is the one I want) since mkvmerge would create one from 00:00:00.000 to 00:20:10.000, one from 00:20:10.000 to 01:23:12.400 (start chapter 11) and one that goes from 01:23:12.400 (start chapter 12) to the end of the clip.
I know I could abort mkvmerge after the file I want is created (to avoid the last file to be created), but the first file will still be created, which is a pain if the source file is long&large,...

Cu Selur

[Mosu]

Yeah yeah, has often been requested, will be implemented sometime this decade. Implementing stuff like that is a pain, too.

[Selur]

No hurry, I just stumbled over this scenario a few times in the last few days.
(will probably request it again, when enough time has elapsed and I run into the scenario again :))

Cu Selur

[Mosu]

:)

There's also a bug report for such a feature request already: https://www.bunkus.org/bugzilla/show_bug.cgi?id=518

[Selur]

Oh, didn't know that. I didn't look in the bugzilla since it's not really a bug but more a missing feature in my eyes. ;)

[Mosu]

Oh it certainly is, but I also use Bugzilla for tracking feature requests.

[Selur]

Ah, okay, good to know for the future. :)

Cu Selur

[Selur]

Just wondering,.. If I have a bunch of mkv files with multiple audio and video streams in them, and I want to check if one or more of these streams was 'streched' to be synch, how do I do that? (ideally get the strech factor)
Is there some indication, about the streching in a mediainfo, mkvmerge, mkvinfo output I overlook atm., or is the only may to extract, remux and see which streams are asynch after the remux?
(another way maybe to extract the time codes for each track and compare them,..)

Cu Selur

[HeartWare2]

The Matroska files do not contain track IDs. They contain track numbers and track UIDs.

Would it be possible to update both MkvMerge and MkvInfo so that they both display this UID for each track, thus making it possible for external programs to synchronize the output from these two programs?

[Mosu]

Just wondering,.. If I have a bunch of mkv files with multiple audio and video streams in them, and I want to check if one or more of these streams was 'streched' to be synch, how do I do that? (ideally get the strech factor)

A stretch factor is applied directly to the timecodes before they're output. It is not stored separately somewhere. As stretching could really be applied to any track (a lot of people try to apply it to audio tracks even though this often does not render good results upon playback) it would be rather difficult to guess that factor automatically somehow.

[Mosu]

Would it be possible to update both MkvMerge and MkvInfo so that they both display this UID for each track, thus making it possible for external programs to synchronize the output from these two programs?

mkvinfo already does that. I'll update mkvmerge accordingly for its verbose identification mode.

Which piece(s) of information from mkvinfo do you need that mkvmerge's verbose identification mode doesn't provide? I'll most likely add those to mkvmerge as well so that people will not have to parse two program's outputs and correlate them.

[Selur]

A stretch factor is applied directly to the timecodes before they're output. It is not stored separately somewhere. As stretching could really be applied to any track (a lot of people try to apply it to audio tracks even though this often does not render good results upon playback) it would be rather difficult to guess that factor automatically somehow.
Okay, so if I for example have a video stream that is 25fps.
and two audio streams with timecodes like:
for the first track:
# timecode format v2
0
40
80
120
160
200
240
280
and for the second track:
# timecode format v2
5
37
69
101
133
165
197
229
261
293
since the first time codes match my frame rate (25fps -> 40ms per Frame) and the second stream timecodes do not I conclude that the second stream is 'stretched'.

But you are right, guessing the stretch factor is problematic,... :/

Okay, so the best thing I can to is automatically detect if a stream is stretched.
(Which should be when ever the timecodes of the audiostreams to not match the timecodes of the videostream and do not use steps that match 1000/(average video frame rate).)

-> reencoding or remuxing such clips is a real pain :/

Cu Selur

Ps: I suspect it might be possible to 'guess' an approximate stretch factor by comparing the original file length with the length of the extracted audio stream,..

[sneaker_ger]

Timecodes of different tracks don't match each other, audio tracks have their own frame sizes (like 32 ms for ac3 for example). You could just read the last timecode (and any delay) and guess if it has been stretched for formats with constant frame sizes. But if the audio has gaps even that wouldn't always work, though probably mostly it will.

[Mosu]

What sneaker_ger said. Audio timecodes depend on the number of samples per audio packet (which in turn has nothing to do with video frames). For AC3 and AAC it's simple as there are always 1536 (AC3) and 1024 (AAC) samples per packet. For other formats it's way more complicated: ranging from "it depends on the layer, the version and the sampling frequency" (MP3) to "it depends on the headers and actually changes in every packet" (Vorbis with its sliding window approach).

Add to that that timecodes are usually rounded to ms precision in a Matroska file (they can have way higher precision but for mixed audio/video content no one actually bothers to use higher precision) and you end up with a task that is at best difficult and imprecise and completely garbage at worst.

[Selur]

Okay, so extracting all audio streams and comparing the original files playtime with the extracted audio stream file size is the only kind of working way,.. :/

[sneaker_ger]

File size? For CBR maybe, but looking at the last (and first for delay) timecode seems more straight forward.

[HeartWare2]

mkvinfo already does that. I'll update mkvmerge accordingly for its verbose identification mode.

Thank you...

Which piece(s) of information from mkvinfo do you need that mkvmerge's verbose identification mode doesn't provide?

Display Resolution (or if it already provides that, then Physical Resolution) so that a Display Aspect Ratio can be calculated.

Duration (runtime) of file (not tracks) in hh:mm:ss.nnn format.

FPS of video track.

SBR/LC of audio tracks (may be encoded in the CODEC value, if you use same CODEC values as MKV Info).

The amount of time (if any) of delay of the track (isn't provided by MKV Info at the moment, but if you are updating MKV Merge to display more info, this one would be appreciated).

The resolution of PBS/VOBSUB subtitles (again, an addition that would be nice to have).

Offset of attachments within the file.

Chapter information (chapter position, language and name at least).

Those are what springs to mind right off the top of my head.:D

[Mosu]

Display Resolution (or if it already provides that, then Physical Resolution) so that a Display Aspect Ratio can be calculated.

Pixel width/height has been added a few days ago already.

Duration (runtime) of file (not tracks) in hh:mm:ss.nnn format.

Will do, but all numbers will be unformatted.

FPS of video track.

Track headers don't have FPS information as Matroska doesn't store that. There's only the "default duration" and that is already output.

SBR/LC of audio tracks (may be encoded in the CODEC value, if you use same CODEC values as MKV Info).

What do you mean with "CODEC value"? Codec ID, Codec Private? "SBR/LC" is not stored in the headers. Codec Private content will not be included in the output either.

The amount of time (if any) of delay of the track (isn't provided by MKV Info at the moment, but if you are updating MKV Merge to display more info, this one would be appreciated).

The resolution of PBS/VOBSUB subtitles (again, an addition that would be nice to have).

Such information is not stored in Matroska's headers and cannot be output.

Offset of attachments within the file.

Chapter information (chapter position, language and name at least).

Attachment position is possible, though I honestly don't know why you'd need it.

Chapter information will not be included in mkvmerge's output as they can be nested etc. For that you'll still need mkvextract/mkvinfo.

[HeartWare2]

What do you mean with "CODEC value"? Codec ID, Codec Private?

Codec ID (I think). The one with "A_AAC/SBR". At the moment, MkvInfo outputs the above value (or something very much like it - I don't have a sample file at hand right now), and my PopCorn MKV AudioConverter (http://www.networkedmediatank.com/showthread.php?tid=20887) needs this information in order to know if the audio track needs to be converted (normal, stereo AAC audio tracks needn't be converted, but SBR or LC audio tracks may need to).

[Mosu]

A_AAC/SBR is an old format for AAC. Newer files use A_AAC whether the AAC data is SBR or not. You cannot base a decision on it.

I'll add the CodecID to the output though.

[HeartWare2]

Such information (delay) is not stored in Matroska's headers and cannot be output.

How about outputting the time stamp for the first sample of a given track? Wouldn't that amount to the delay value you get when you execute MkvInfo(?) with v2_timecodes (or whatever it's called)? At the moment, I need to use the aforementioned option, even though I only need the time stamp for the very first line, and it may take a very long time to process a 13 Gb file over a 100 Mbit network, so if a quick way to get the delay for a track would be appreciated.

I need it to be able to apply the same delay as the original track has, when I ReMux the converted audio track back into the .MKV file.

[HeartWare2]

A_AAC/SBR is an old format for AAC. Newer files use A_AAC whether the AAC data is SBR or not. You cannot base a decision on it.

Rats!:sly:

Any other way to detect if an AAC audio track is SBR or not, then?

[Mosu]

Oh and here's the ChangeLog entry from back when that change was implemented (and for good reason!):

2006-11-10 Moritz Bunkus <moritz@bunkus.org>

* Released v1.8.0.

* mkvmerge: Changed the CodecID for AAC audio tracks to "A_AAC" by
default. The CodecPrivate contains the same initialization data
that are stored in the ESDS in MP4 files for AAC tracks. The old
CodecIDs (e.g. "A_AAC/MPEG4/SBR") can be turned on again with
"--engage old_aac_codecid".

[Mosu]

If CodecPrivate is 5 bytes long or longer then it uses SBR. If it's only 2 bytes then it doesn't.

[Mosu]

How about outputting the time stamp for the first sample of a given track?

No, sorry. That would in general require way more time to process the file than I want mkvmerge to take (think of e.g. subtitle tracks with very, very few entries in between). Your case is special, and you will most likely still have to run mkvinfo on the source file for that.

I don't want to make mkvmerge slow for 100% of all users when only 1% or fewer would actually need such an option.

[Mosu]

Here's a build with three more fields in file identification mode: UID, CodecID (even though that's now duplicate information in the line), codec private data size and content (the latter as a hex dump).

As for the other stuff you've requested:

File duration has already been present in the container line.

I will not add attachment offsets within the file. This leads to reading/writing directly in the file and I don't want to make this easy. Use mkvextract if you need access to the attachments (or continue parsing mkvinfo's output if you insist on fiddling around in the internals of a Matroska file).

The codec private data can be used for AAC in order to find out what kind of AAC it is. For code how to parse such data look at e.g. the "parse_aac_data()" function in https://github.com/mbunkus/mkvtoolnix/blob/master/src/common/aac.cpp

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-5.2.1-build20120107-397-setup.exe

[Selur]

File duration has already been present in the container line.
Would it be possible to include the stream duration (due to the 'stretch' option, the extracted stream duration can differ from the file duration)?
And/Or is there a way to calculate the raw/demuxed length of an audio stream inside a mkv container without extracting the stream?

Cu Selur

[Mosu]

A track's duration is not stored in the track headers, hence mkvmerge cannot display it.

And I assume that by "without extracting the stream" you also mean "without running mkvinfo on the whole file and parse its output".

[Selur]

I'm willed to run mkvinfo with:
mkvinfo -v "Path to file" (or what ever is necessary)
if you can point me in the direction how to calculate the raw stream length from that. :)

[Mosu]

How about "Track duration = last timecode + duration of last packet - first timecode"?

[Lincoln Burrows]

I am having a problem with MKVExtractGUI here. I have downloaded the last version, 2.2.2.7, and tried to extract a subtitle from a Matroska file converted from a DVD. It failed, since ended right after started, generating no file. The same issue is happening with other MKV files from the bonus material.

I should add that all (yellow) subtitles can be displayed with no issues in Media Player Classic.

When I use MKVToolnix to save the MKV file, by removing all streams and only letting the subtitle, it saves using .mks extension. If I add this file into another MKV, it will report this error:
* Warning: matroska_reader: Could not keep the track UID 3 because it is already allocated for the new file.

The subtitle format is S_VOBSUB. And I never had this problem before. Maybe there's something special about this one?

P.S. I checked the new MKV, and despite this warning *, the subtitle from the mks file was inserted. However, if we need to edit the subtitle, it would be necessary to extract into idx/sub. SubResync is one example of software that can easily do this task.

And I was able to extract this subtitle from the new MKV, but only one IDX file was generated, not IDX/SUB. SubResync is not working with this IDX. So I guess the subtitle is different in a way that is being rejected by MKVExtractGUI from the start.

[Mosu]

Pleae, please read the page(s) leading up to this. It has been discussed in depth.

Hint: it's a bug in mkvextract GUI. It uses the wrong track IDs.

Also: If mkvmerge says "Warning:" then it is not an error. I thought that was obvious.

[Lincoln Burrows]

Pleae, please read the page(s) leading up to this. It has been discussed in depth.

Hint: it's a bug in mkvextract GUI. It uses the wrong track IDs.

Also: If mkvmerge says "Warning:" then it is not an error. I thought that was obvious.Well, let's see. I tried another title (in the previous case I solved by inserting the "mks" files, they already had all subtitles I needed for) that has nothing to do with this one. And this is a DVD.

http://i.imgur.com/Nc56j.png

As you can see, two tracks, DD 2.0 ENG and PT, two subtitles, PT/ENG + chapters.

When attempting to extract:

1) Video = extracts a MPG file. OK
2) ENG track = extracts AC3 file. OK
3) PT audio track = extracks SUB file. FAIL.
4) PT subtile track = extracks SUB file. OK
5) EN subtile track = FAIL. Nothing happens.
6) Chapters = extracts file, OK.

And when attempting to extract all 6 combined = FAIL, nothing happens.

And I need to extract exactly 3), the PT audio track.

Any ideas?

Edit: I managed to extract this portuguese AC3 track with tsMuxerGUI. The title I have tested was The Adventures of Baron Munchausen (1988), Region 4-Brazil. Maybe this disc was decrypted by me in a different way or it was authored in a different way that prevented from working with your software. I also remember it was decrypted about 2-3 years ago.

[Selur]

@mosu: Will you also adjust mkvinfo to the TrackIDs mkvmerge&mkvextract use since 5.2.1+?

mkvinfo v5.2.1 ('A Far Off Place') built on Jan 7 2012 21:56:27
+ Segment tracks
+ A track
+ Track number: 1
+ Track UID: 3986723374
+ Track type: video
+ Forced flag: 1
+ Lacing flag: 0
+ MinCache: 1
+ Codec ID: V_MPEG4/ISO/AVC
+ CodecPrivate, length 39 (h.264 profile: High @L3.1)
+ Default duration: 40.000ms (25.000 fps for a video track)
+ Language: ger
+ Name: tvp-farscape-s01e01-720p
+ Video track
+ Pixel width: 960
+ Pixel height: 720
+ Display width: 960
+ Display height: 720
+ A track
+ Track number: 2
+ Track UID: 1274075454
+ Track type: audio
+ Forced flag: 1
+ Codec ID: A_AC3
+ Default duration: 32.000ms (31.250 fps for a video track)
+ Language: ger
+ Audio track
+ Sampling frequency: 48000
+ Channels: 6
+ A track
+ Track number: 3
+ Track UID: 2195572176
+ Track type: audio
+ Default flag: 0
+ Codec ID: A_DTS
+ Default duration: 10.667ms (93.750 fps for a video track)
+ Audio track
+ Sampling frequency: 48000
+ Channels: 6
mkvmerge v5.2.1 ('A Far Off Place') built on Jan 7 2012 21:56:27
Track ID 0: video (V_MPEG4/ISO/AVC)
Track ID 1: audio (A_AC3)
Track ID 2: audio (A_DTS)

-------------------------------------------


How about "Track duration = last timecode + duration of last packet - first timecode"?
Wouldn't that just give me the length of the stream inside the container?

1st entry for Track 3: SimpleBlock (key, track number 3, 8 frame(s), timecode 0.000s = 00:00:00.000)
-> first timecode = 0
last entry for Track 3: SimpleBlock (key, track number 3, 8 frame(s), timecode 2885.846s = 00:48:05.846)
-> last timecode = 2885.846

"duration of last packet"
is this:
a. distance between the last entry for Track 3 and the next entry in the container?
b. distance between the last entry for Track 3 and the length of the clip as a whole?
c. none of the above,.. (what?)
if I extract track 3 I get a length of 00:50:07.700. (3007.7)

Cu Selur

Ps.: Here's (http://forum.gleitz.info/attachment.php?attachmentid=97102&d=1326070663) the mkvinfo -v output for the file,..

[sneaker_ger]

@mosu: Will you also adjust mkvinfo to the TrackIDs mkvmerge&mkvextract use since 5.2.1+?

He won't. The TrackNumber (http://matroska.org/technical/specs/index.html#TrackNumber) is hard-coded into the file. This is not the same as the "TrackID"s mkvmerge and mkvextract use, those are made up and can thus be subject to change. Maybe he could also generate the "TrackID" into the mkvinfo output, in the same way that mkvmerge and mkvextract do it, if that is wanted.

How about "Track duration = last timecode + duration of last packet - first timecode"?
Wouldn't that just give me the length of the stream inside the container?

Correct.

1st entry for Track 3: SimpleBlock (key, track number 3, 8 frame(s), timecode 0.000s = 00:00:00.000)
-> first timecode = 0
last entry for Track 3: SimpleBlock (key, track number 3, 8 frame(s), timecode 2885.846s = 00:48:05.846)
-> last timecode = 2885.846

"duration of last packet"
is this:
a. distance between the last entry for Track 3 and the next entry in the container?
b. distance between the last entry for Track 3 and the length of the clip as a whole?
c. none of the above,.. (what?)

I'm also wondering about this. It's not b, I'd say. Maybe one is supposed to calculate it from the frame size, which would be format depended? For this DTS frame it would be 10.67 ms (one third of the 32ms ac3 length), but I have no idea if this info can be derived otherwise (and for sources with e.g. Vorbis).

if I extract track 3 I get a length of 00:50:07.700. (3007.7)

The "extracted length" would be [number of frames] * [frame duration] (or more precisely sum of [frame duration]s). Again, no idea how to read that for e.g. Vorbis. Maybe calculate from frame size (and bitrate, which mkvinfo does not show)?

Ps.: Here's (http://forum.gleitz.info/attachment.php?attachmentid=97102&d=1326070663) the mkvinfo -v output for the file,..

Please use "-r output.txt" instead of "> output.txt". The latter results in "[CR][CR][LF]" somehow, don't know if this is a bug in mkvinfo or not. Mosu?

It's not quite clear what exactly you want to know:
a.) Length of stream within the container(Mosu: "Track duration = last timecode + duration of last packet")(1*) or
b.) "extracted length" of the audio track (the sum of all frame durations, for streams with constant duration [number of frames]*[frame duration])

For this example:
a.) duration = 2885.928s + (0.032/3)s ~= 2885.939s = 48min5s939ms
b.) duration = 282112(2*) * (0.032/3)s ~= 3009.195 = 50min9s195ms

(1*) I left out the delay (first timecode) to simplify.
(2*) Parsed the mkvinfo output. (Hopefully correct)

Also, since only the timecodes of the frames are stretched, and not the length of the packets, there is an additional small error in calculation a. In theory you would have to calculate the stretching factor from all but the last frame. (Maybe nitpicking...)

I hope this is correct.

[Chetwood]

I am having a problem with MKVExtractGUI here. I have downloaded the last version, 2.2.2.7, and tried to extract a subtitle from a Matroska file converted from a DVD. It failed, since ended right after started, generating no file.
Same here, only it happens when extracting from MKVs ripped from Bluray with MakeMKV and when done with MKVCleaver. However, doing it manually with mkvextract works so yes, it's a GUI bug.

[Selur]

b.) "extracted length" of the audio track (the sum of all frame durations, for streams with constant duration [number of frames]*[frame duration])
this is what I want :)

I nearly all of the Frames are in SimpleBlocks, but there's also a single Blockgroup with a 'Block (track number 3' which also has a Block Duration entry, should the frames from the 'Block (track number 3' also be counted or just the frames from the SimpleBlocks ?

Cu Selur

[Mosu]

@mosu: Will you also adjust mkvinfo to the TrackIDs mkvmerge&mkvextract use since 5.2.1+?

No. sneaker_ger has answered as to why not. I will also not add additional information to mkvinfo's output. Finding out the track IDs is what mkvmerge's "--identify" options are for. I won't duplicate that feature into another program, especially as mkvinfo's output does not take default values into account while mkvmerge's does (e.g. track language, "default" flag status etc).

Wouldn't that just give me the length of the stream inside the container?

Correct.

"duration of last packet"
is this:
a. distance between the last entry for Track 3 and the next entry in the container?
b. distance between the last entry for Track 3 and the length of the clip as a whole?
c. none of the above,.. (what?)

The timecode + the packet's duration. If an explicit duration is given in a BlockGroup element, then it is that duration. Otherwise it's the default duration.

It's definitely not the difference between the timecode and the end of the stream/file.

[Mosu]

this is what I want :)

I nearly all of the Frames are in SimpleBlocks, but there's also a single Blockgroup with a 'Block (track number 3' which also has a Block Duration entry, should the frames from the 'Block (track number 3' also be counted or just the frames from the SimpleBlocks ?

Cu Selur

All frames, of course. How they're stored (SimpleBlock vs BlockGroup) is simply a matter of taste/information that has to be stored. SimpleBlocks have less overhead, a BlockGroup can contain an explicit duration for that frame.

[Selur]

btw.: Thanks to Mosu&sneaker_ger, I got a stretch detection working for all streams that have a duration specified, without extracting the streams!! :)

[Abradoks]

btw.: Thanks to Mosu&sneaker_ger, I got a stretch detection working for all streams that have a duration specified, without extracting the streams!! :)
Can you please share corresponding code? Such tool is often asked on the forums.

[Selur]

atm. it's not a stand alone tool but a new part of Hybrid.
I already got the Track IDs, length indicated by the container (needed for length comparisons) and the frame count of the video stream (needed for progress indication) there, so the code is probably not really useful to others in the state it is now.
If people are interested I could probably come up with a small stand alone tool (without progress indication, since total frame count of any stream isn't indicated by mkinfo.

Cu Selur

[Abradoks]

It would be enough if you can tell, how do you get real (extracted) frame duration.

[Selur]

Like I wrote before it only works for streams where the frame duration is known, i.e. dts, ac3, it's basically a simple scan the input,.. count&multiply that could be done by a shell script. :)

Cu Selur

Ps.: source code for a small shell application using mkvinfo: http://www.multiupload.com/BO3IFKAVWP and a win64 static binary (http://www.multiupload.com/OGON5W22G8)

[Simon88]

I'm using MKVmerge v5.2.1 converting an RV40/cook file from a RMVB container to a MKV container, afterwards the file will no longer play. Nothing changed, only the container. MPC-HC, VLC 1.30 git, & SMPlayer 0.6.10, all did not work. Once I removed the audio & remuxed to a new MKV file w/ only the RV40 video, everything worked.

Does Matroska v5.2.1's mkvmerge have trouble dealing w/ "cook" audio?

[wbee]

I encountered a problem

muxing or spliting video files with aac 24khz Audio track, will cause the audio track's samping rate changed to 48khz.
Because some playback device cant play video with 48khz audio track.
is it possible to leave the sampling rate unchanged? how?

[Mosu]

Does Matroska v5.2.1's mkvmerge have trouble dealing w/ "cook" audio?

I don't know. And honestly, Cook/RealAudio is so old and unused today that I don't really care.

[Mosu]

I encountered a problem

muxing or spliting video files with aac 24khz Audio track, will cause the audio track's samping rate changed to 48khz.
Because some playback device cant play video with 48khz audio track.
is it possible to leave the sampling rate unchanged? how?

Are you the one who's posted a similar bug in my bug tracker (https://www.bunkus.org/bugzilla/show_bug.cgi?id=699)? Even if not, the answer is still the same. If your source file uses a sampling rate of 24kHz then it uses spectral band replication (SBR). For such cases Matroska contains two header fields, the sampling frequency (unchanged at 24kHz) and the output sampling frequency (48kHz). That is perfectly normal. If your player cannot play such files then it's more likely that it either cannot play SBR at all or that its Matroska support is so abysmal that it's so confused by the additional header field that it just gives up. Either way, this is not a problem in mkvmerge, it's the correct and spec-compliant behavior. There's no way to change it.