MKVToolNix v24.0.0 released

[Mosu]

Welcome to release v18.0.0 of MKVToolNix. This is just a smallish bug fix release which also contains a couple of performance improvements.

There were no changes for package maintainers.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the Windows installer/portable version & macOS DMG (https://www.fosshub.com/MKVToolNix.html) and the source code (https://mkvtoolnix.download/source.html).

The Windows and macOS binaries are available already. The Linux binaries are stil being built and will be available of the course of the next couple of hours.

Here are the NEWS (https://mkvtoolnix.download/doc/NEWS.md) since the previous release:

# Version 18.0.0 "Apricity" 2017-11-18

## New features and enhancements

* build system: when building with clang v3.8.0 or newer, `configure` will no longer restrict optimization flags to `-O1` and use `-O3` again (older versions of clang suffered from excessive memory usage with higher optimization levels).
* build system: when building with mingw 7.2.0 or newer, `configure` will no longer restrict optimization flags to `-O2` and use `-O3` again (older versions of mingw suffered from bugs such as segmentation faults with higher optimization levels).
* build system: stack protection is enabled when building with clang 3.5.0 or newer on all platforms.
* mkvmerge: AVC & HEVC ES parsers: performance improvements by copying much less memory around.
* mkvmerge: tags: reintroduced a workaround for non-compliant files with tags that do not contain the mandatory `SimpleTag` element. This workaround was removed during code refactoring in release v15.0.0.
* GUI: multiplexer: the "AAC is SBR/HE-AAC/AAC+" checkbox in the "audio properties" section will be disabled if the functionality is not implemented for the selected track's codec & container.
* GUI: multiplexer: the "reduce to core" checkbox in the "audio properties" section will be disabled if the functionality is not implemented for the selected track's codec. See #2134 (https://github.com/mbunkus/mkvtoolnix/issues/2134).

## Bug fixes

* mkvmerge: AAC ADTS parser: fixed interpretation of the `channel_configuration` header element for ADTS files that do not contain a program configuration element: value 7 means 7.1 channels. Fixes #2151 (https://github.com/mbunkus/mkvtoolnix/issues/2151).
* mkvmerge: Matroska identification: the `date_local` and `date_utc` attributes will only be output if the identified Matroska file actually contains the "date" header field.
* mkvmerge: WebVTT: mkvmerge did not recognize timestamp lines if the hours components were absent. Fixes #2139 (https://github.com/mbunkus/mkvtoolnix/issues/2139).
* mkvpropedit, GUI's header editor: the `date` header field won't be added automatically anymore whenever the segment info section is edited and the `date` element is either deleted or not present in the first place. Fixes #2143 (https://github.com/mbunkus/mkvtoolnix/issues/2143).

Have fun :)

[raymondjpg]

Thank you for MKVToolNix. I have used it for many years.

Lately, muxing 25 fps AVC TS files into MKV containers I have observed strange frame rates reported by MediaInfo. Before muxing MediaInfo would be reporting one frame rate of 25 fps (PAL standard) for the TS files as follows:

Frame rate : 25.000 FPS

After muxing with MKVToolNix, MediaInfo reports video frame rates as follows:

Frame rate mode : Variable
Frame rate : 31.021 FPS
Original frame rate : 25.000 FPS

Even if I force 25 fps for the video stream in MKVToolNix I see the same result.

Can anyone explain to me why this is happening, and if there is some solution, can they point me to it?

TIA.

[Midzuki]

Somewhat off-topic but necessary, me thinks.

Internet Explorer 11 says about https://mkvtoolnix.download/windows/pre/ :

This page can’t be displayed

Turn on SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2 in Advanced settings and try connecting to https://mkvtoolnix.download again.

[Mosu]

Yes, I've deactivated inferior and partially-broken protocols such as anything below TLS 1.2. Do as it says and activate TLS 1.2. Or use a different browser.

[Midzuki]

Yes, I've deactivated inferior and partially-broken protocols such as anything below TLS 1.2. Do as it says and activate TLS 1.2. Or use a different browser.

The problem is, my IE11 IS configured to use TLS 1.2.
Also, other browsers, all up-to-date, return similar error messages.
Maybe your site has learned to ignore Windows 7 specifically? :confused:
Yes, I've already met certain sites which stopped working on all the browsers available on my machine. But this is the first time the problem has something to do with the use of the https protocol.

EDIT:

Seamonkey says: "The document contains no data".

Pale Moon says: "An error occurred during a connection to mkvtoolnix.download. Cannot communicate securely with peer: no common encryption algorithm(s). (Error code: ssl_error_no_cypher_overlap)"

K-Meleon says: "Connection Interrupted
The document contains no data.
The network link was interrupted while negotiating a connection. Please try again."

[sneaker_ger]

You can have TLS 1.2 and not brake too many browsers:
https://www.ssllabs.com/ssltest/analyze.html?d=forum.doom9.org
https://www.ssllabs.com/ssltest/analyze.html?d=mkvtoolnix.download&s=144.76.6.86

(Just saying ...)

[nevcairiel]

Thats probably because he also removed any AES 128 encrypted cipher suits (which for the record is not considered insecure)

[manolito]

It seems to follow the old pattern to shut out all users who do not use the latest and greatest (also very crappy) Win10 like it happened for XP users.

Thank God we have Baldrick and his invaluable VideoHelp site... :devil:
https://www.videohelp.com/software/MKVToolNix


Cheers
manolito

[Mosu]

Shutting out Windows 7 wasn't my intention, and judging from SSLLabs' report (which I did actually use) Windows 7 users should still be able to connect. As they aren't, I'll re-add the 128bit variants for AES.

I don't care about XP.

[Taurus]

Win7 64bit, Firefox 64bit latest, Internet Explorer 11 latest = no trouble reaching https://mkvtoolnix.download/windows/pre/
Standard Installations...

[hubblec4]

I use Waterfox with Win7(64) and have no issues.

[Midzuki]

Win7 64bit, Firefox 64bit latest, Internet Explorer 11 latest = no trouble reaching https://mkvtoolnix.download/windows/pre/
Standard Installations...

Perhaps your Windows 7 is full of "updates", whereas mine is not :confused:

No way I'm going to install Firefox or Chrome/Chromium because of a handful of sites — specially when there is no guarantee that these pesky browsers are going to work properly on my machine.

As a last resort, I can use wget 1.19.2.

</END OF COMPLAINT>

[Mosu]

The 128bit variants are now enabled again.

[Midzuki]

^ thanks!

[kuchikirukia]

Appending seems to be broken in the last couple releases. It used to work perfectly but now there's a hitch at every join if audio is present.

[sneaker_ger]

The way mkvmerge appends by default usually results in small timecode gaps. Read doc about append modes. If you are sure it's a regression please find out exact version and post sample.

[hdboy]

Is there a way to make an audio track the primary one without remuxing?

Say I have a m2ts file with

Audio 1: truehd English
Audio 2: ac3 English

I want to make audio 2 the default English track and Audio 1 the secondary, without making any other changes.

Is there a quick way to do this without remuxing? Thanks

[nevcairiel]

You can set the default flag on the second track, if a given player honors that is not something mkvmerge can influence.

[sneaker_ger]

Say I have a m2ts file with
[...]
Is there a quick way to do this without remuxing?
There is a reason it's called MKVToolNix, not M2TSToolNix. The only thing MKVToolNix can do with a m2ts file is to remux it to mkv (you can set default flags, deactivate tracks or change track order for that remux, of course).

[hdboy]

You can set the default flag on the second track, if a given player honors that is not something mkvmerge can influence.

But it still requires going through a remux, correct?

There is a reason it's called MKVToolNix, not M2TSToolNix. The only thing MKVToolNix can do with a m2ts file is to remux it to mkv (you can set default flags, deactivate tracks or change track order for that remux, of course).

Reason I'm asking is I'm trying to use my TV's internal player to play UHD files. It is a very capable player that handles many containers and codecs except it freaks out when there is a main lossless audio track, which there is for most movies. I think if I can edit the header and disable or renumber the lossless audio track that will do the trick. Is there any such tool?

[nevcairiel]

But it still requires going through a remux, correct?

Since its not MKV in the first place, then very much so (I missed that the first time since I didn't expect someone to write anything about other contains in a thread about MKV tools).

[hdboy]

Sorry, a another question. This time, it IS about mkvtoolnix, I hope.

I'm remuxing a UHD m2ts to mkv. I stripped out most audio tracks and subtitles. The file size went from 53GiB to 37GiB, which was surprising since the audio tracks and subs can't take that much space. So I looked at the files' mediainfo. Here's the original (video only)


Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
Codec ID : 36
Duration : 2 h 0 min
Bit rate : 57.9 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.291
Stream size : 48.7 GiB (91%)
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0050 cd/m2, max: 4000.0000 cd/m2
Maximum Content Light Level : 9918 cd/m2
Maximum Frame-Average Light Level : 3241 cd/m2



here's the remuxed



Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2 h 0 min
Bit rate : 44.1 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.222
Stream size : 37.1 GiB (99%)
Language : English
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0050 cd/m2, max: 4000.0000 cd/m2
Maximum Content Light Level : 9918 cd/m2
Maximum Frame-Average Light Level : 3241 cd/m2



The video stream size went from 48GiB to 37GiB. I was under the impression that mkvtoolnix is only copying the stream over. Where does the additional compression come from? Does it affect PQ?

thanks

[Selur]

Where does the additional compression come from?
Transport streams containers can have a lot or overhead, depending on the streams inside of them.

[sneaker_ger]

Is it from a Blu-ray with Dolby Vision?

[hdboy]

Is it from a Blu-ray with Dolby Vision?

No. HDR only. It's mad max fury road

[sneaker_ger]

While m2ts has a lot of overhead it seems a little too high for me. Please post the complete MediaInfo of the source. Maybe MediaInfo is underestimating audio track sizes. Video track size is probably just calculated by [total size] - [audio track sizes] - [overhead estimate] - [subtitles] etc. And/or extract the full audio tracks to get their exact sizes.

[hdboy]

I extracted all the audio and it's 12.3GiB. So it computes. I guess the 2 TrueHD atmos and multiple ac3 tracks do add up.

Mystery solved :)

[Midzuki]

"MKVToolNix moves to GitLab"

https://www.bunkus.org/blog/2017/12/mkvtoolnix-moves-to-gitlab/

[Mosu]

Hey people,

the year's almost over, so I'm just in time for the last release of the year: MKVToolNix v19.0.0 is out. It's not that big of release, but it still contains a couple of improvements all over the place — and two nice performance improvements on Windows that people will likely notice.


There were no changes for package maintainers.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the Windows installer/portable version & macOS DMG (https://www.fosshub.com/MKVToolNix.html) and the source code (https://mkvtoolnix.download/source.html).

The Windows and macOS binaries are available already. The Linux binaries are stil being built and will be available of the course of the next couple of hours.

Here are the NEWS (https://mkvtoolnix.download/doc/NEWS.md) since the previous release:

# Version 19.0.0 "Brave Captain" 2017-12-17

## Important notes

* The MKVToolNix project now contains a Code of Conduct (https://mkvtoolnix.download/doc/CODE_OF_CONDUCT.md).
* The MKVToolNix project's source code repository, bug tracker and wiki have been moved to GitLab (https://gitlab.com/mbunkus/mkvtoolnix/).

## New features and enhancements

* mkvmerge: splitting by duration, by timestamps or by timestamp-based parts: mkvmerge will now consider the first key frame within 1ms of the requested value to be eligible for splitting.
* MKVToolNix GUI: the GUI will now save and restore the widths of columns in tree and list views. Implements #2057 (https://github.com/mbunkus/mkvtoolnix/issues/2057).
* MKVToolNix GUI: header editor: when closing or reloading a modified file, the GUI will now focus the first element that's been modified before asking the user for confirmation regarding discarding unsaved changes.

## Bug fixes

* mkvmerge: fixed reading text files encoded in UTF-16 order UTF-32 that have different forms of line endings (new lines, carriage returns or a mix of both). Fixes #2160 (https://github.com/mbunkus/mkvtoolnix/issues/2160).
* mkvmerge: MP4 reader: fixed mkvmerge's interpretation of edit list entries with `segment_duration == 0` when there's more than one edit list entry. In that case mkvmerge was reading the whole content more than once. Fixes #2152 (https://github.com/mbunkus/mkvtoolnix/issues/2152).
* mkvmerge, GUI's multiplexer: MIME types: added the `font` top-level media types from RFC 8081. This means that the following new MIME types for fonts can be used: `font/ttf`, `font/otf`, `font/woff` and `font/woff2`.
* mkvmerge: MPEG transport stream reader: fixed slow speed on Windows due to lack of buffering.
* mkvextract: fixed slow track extraction speed on Windows due to lack of buffering. Fixes #2166 (https://github.com/mbunkus/mkvtoolnix/issues/2166).
* MKVToolNix GUI: multiplexer: changing the "subtitle/chapter character set" drop-down was ignored when the selected track was a chapter track. Fixes #2165 (https://github.com/mbunkus/mkvtoolnix/issues/2165).
* MKVToolNix GUI: multiplexer: once a "subtitle/chapter character set" was set for a track it couldn't be changed back to the empty entry (= auto-detection) anymore.
* MKVToolNix GUI: header editor: fixed re-translating several displayed strings when the GUI language is changed if the language the GUI was started with was not English. Fixes #2159 (https://github.com/mbunkus/mkvtoolnix/issues/2159).
* MKVToolNix GUI: header editor: whenever a file did not contain a "date" element in its segment information section, the GUI would erroneously ask the user to confirm discarding unsaved changes when closing or reloading the tab. Fixes #2167 (https://github.com/mbunkus/mkvtoolnix/issues/2167).
* MKVToolNix GUI: job queue: jobs are now saved when their status changes in addition to when the program exits. Fixes #2168 (https://github.com/mbunkus/mkvtoolnix/issues/2168).

Have fun :)

[sneaker_ger]

Thx.
Are new font MIME types a default in any way or just new, optional settings?

[Midzuki]

Thanks for the update :thanks:

[Mosu]

Due to my experience with players and font Mime types in the past, the new types are not the default and purely optional.

[sneaker_ger]

Good. Thx.

[Telion]

* The MKVToolNix project now contains a Code of Conduct.
I hope this means it's about time to become more inclusive towards Windows XP users community, isn't it? The painful harassment of this minority, the brunt on the problems and needs of those poor third worlders are so against this CoC that it literally moans to check your first world privilege. Recurrent derogatory remarks about Windows XP (i.e. its users) and the enforcement of those absolutely artificial, unnecessary, and discriminative constraints (MF instead of DX in Qt) which actively marginalize and push out of the community not only XP but also N/KN editions users are the exact opposite of creating an inclusive and more diverse environment. We feel humiliated when we encounter your hostile attitude towards us, we feel like we are steadily losing our human dignity in this toxic environment, we feel that we are so inferior and despicable we won't ever worth even a minuscule mercy from a meritocratic patriarch in a position of power. How can we believe in the sincerity of your pledge when you have just installed another suffocating axis of oppression, now based on Windows versions we are using? Only if you would abide by this part: "Project maintainers have the <...> responsibility to <...> edit <...> code <...> that are not aligned to this Code of Conduct", especially considering it's so easy to do so. Please quell the qualms and show us that CoC adoption isn't just for hypocritical virtue signalling, but social justice really matters for you. Actions speak louder than words.

[Mosu]

Not giving you something you very vociferously demand isn't harassment. What you're doing, on the other hand, is pretty much trolling. Please stop it.

[mariush]

There's a tiny bug i noticed a while ago. Well maybe it's not a bug, probably "unexpected behavior" would be better.

If you set a track name with spaces in it (edit: or you have files with spaces in them) and you then select Multiplexer > Show command line, the default escaped output (Windows cmd.exe is selected by default) is correct. But if I go in the drop down menu and select Don't escape, then the cmd escaping AND the " " for the text are removed.
For example, let's say I use "English 5.1" as track name, the default is shown like this:

mkvmerge.exe --ui-language en --output ^"D:\temp\output.mkv^" --language 0:und --language 1:und ^"^(^" ^"D:\temp\video.m2ts^" ^"^)^" --language 0:eng --track-name ^"0:English 5.1^" ^"^(^" ^"D:\temp\sound.opus^" ^"^)^" --track-order 0:0,0:1,1:0

Notice the --track-name ^"0:English 5.1^"

After selecting don't escape, it's converted to this:

mkvmerge.exe --ui-language en --output D:\temp\output.mkv --language 0:und --language 1:und ( D:\temp\video.m2ts ) --language 0:eng --track-name 0:English 5.1 ( D:\temp\sound.opus ) --track-order 0:0,0:1,1:0

so that's not correct because it takes track name as "English" and then it's confused by the standalone 5.1
mkvmerge v19.0.0 ('Brave Captain') 64-bit
Error: The file '5.1' could not be opened for reading: open file error.

(edit) Ah .. now I see the "Don't escape" also removes the "" around filenames if they have spaces in their name.

IMHO, the "don't escape" should not remove " characters which are required for values of parameters to function, for the command to actually work. I just want the ^ and cmd.exe escaping to go away.

In my particular case, I'm just trying from time to time to get the command and then replace filenames with %1, %2 etc and create a batch merge with a PHP script.

[Mosu]

IMHO, the "don't escape" should not remove " characters which are required for values of parameters to function, for the command to actually work. I just want the ^ and cmd.exe escaping to go away.

Uhm, no. Either you escape, or you don't. There is no middle ground, just "wrong/incomplete escaping that'll do the wrong thing in situations you don't expect".

[mariush]

I sort of see what you're saying but at the same time by your logic, since you're escaping the parenthesis in the first example, shouldn't those be missing in the 2nd form as well?

What's the difference between the ( ) characters and the " characters that the () get special treatment while " are silently removed? Your special way of parsing the parameters/arguments in command line seems to make using ( ) characters a requirement so to me it would seem your program should either add some intelligence during parsing to guess where file names end (and what's normally in text fields) , or you should treat " characters like those ( ) characters, as required to read arguments properly.

I think it's not a Windows thing to require " characters, you'd need them in Linux and other operating systems as well, or am I wrong...

[Mosu]

Parenthesis have nothing to do with escaping or the shell or cmd.exe. They're a function of mkvmerge and important to mkvmerge regarding appending files.

[Gser]

WHATTTTT? NO SUPPORT FOR WINDOWS 95? I am totally going to complain about this on my myspace page that has 3 visitors a year.

PS. You can send me your hearts and prays through AOL Instant Messenger, my email is backstreet_boys_superfan_*85*_<333@aol.com

[hello_hello]

I hope this means it's about time to become more inclusive towards Windows XP users community, isn't it?

You can always use another GUI that uses MKVToolNix for muxing, such as MeGUI, and while it's not as feature rich, MeGUI's muxer has one advantage over MKVToolNixGUI. The button to start muxing and the button to stop it are located together at the bottom of the same window. And if a language is written to a raw stream/file as any "Delay" often is, the world mysteriously keeps turning while MeGUI applies it automatically. ;)

I've only just switched to MKVToolNix 19, but so far version 10 of mkvtoolnix-gui.exe is playing nice with version 19 of mkvmerge.exe, so you can use that.

manolito's utility for automatically dismissing the warning could previously be found via this post (https://forum.doom9.org/showthread.php?p=1813131#post1813131) but the link seems to be dead so here's a new one if you want it.

(I've removed the link as I only had the exe's without instructions, plus it turns out I uploaded the first version and the SendTo method of opening files doesn't work. I didn't realise I'd kept it. See the next post for a new link from manolito).

PS. Thanks for the update Mosu.

[manolito]

Thanks hello_hello for uploading my little hack to VideoHelp...

ZippyShare deletes uploads after noone has downloaded them for more than 4 weeks, and this is very much OK with me. I just reuploded the complete hack (which contains instructions and the sources for the executable) here:
https://files.videohelp.com/u/172211/ToolNix_XP.zip

I do check new releases of MKVToolNix to make sure my workaround still works, so far I found no issues...


Cheers
manolito

[ccutrer]

Any more thoughts on Dolby Vision? UHD ripping has really taken off since it was first mentioned in October, and things are starting to get software updates to support Dolby Vision (I just got my AppleTV 4k -> Pioneer VSX-1131 -> LG OLED65C7P chain working today thanks to a Pioneer software update). I know it's a chicken-and-the-egg problem (why add DV to MKV if all current devices will choke on it), but until it's at least added to the spec, no device will ever be able to support it. Infuse on Apple TV 4k seems like a great first player for DV-in-MKV content.

[Mosu]

I currently have no plans for spending time on it. Busy with other things.

[ccutrer]

I currently have no plans for spending time on it. Busy with other things.

Ok. Thanks for the response, and all your hard work on MKVToolnix!

[hubblec4]

Hi Mosu,

I have started in the german forum (https://forum.gleitz.info/showthread.php?47806-Matroska-parsen&p=459923&viewfull=1#post459923) a topic about the Block structure.

Block Structure

Size = 1 + (1-8) + 4 + (4 + (4)) octets. So from 6 to 21 octets.

Could you explain a bit what the numbers mean?

[mkver]

The first 1 is for the 0xA1 denoting a block; 1-8 is not a substraction, but means that the size of the data to follow is coded with a variable length EBML integer. The next four bytes seem to be for the TrackID, the relative timestamp/timecode (soon to be depreceated verbiage) and the byte with the flags. I don't know what the last (4+(4)) means: You can possibly have lacing data next (depending on the flags), but even in this case (4+(4)) doesn't make any sense. Furthermore, the interpretation of the first four depends on the TrackID coded in 1 octet (Matroska allows up to 2^56-1 tracks at the moment and they are coded in EBML integer form like EBML sizes (but with the difference that there is no reserved value (EBML sizes have a reserved value denoting an unknown size; TrackID has not)).
So currently I'd say that this is a bug in the specs. If mose agrees, you should file a bug report on github (https://github.com/Matroska-Org/matroska-specification/issues).

[Mosu]

I'm pretty sure those numbers are completely wrong, both for the Block and the SimpleBlock elements. You've wondered that yourself in that German thread already, and it looks right to me.

For the Block structure, better numbers would be:

1 byte: element ID
1-8 bytes: element size (variable-sized integer)
1-8 bytes: track number (variable-sized integer)
2 bytes: block's timestamp relative to the cluster's timestamp (signed 16-bit integer)
1 byte: flags
1 byte: number of laced frames; only present if lacing is signaled in the flags
n bytes: lacing information; only present if lacing is signaled in the flags; total size depends on lacing method and number/size of laced frames; no upper limit (e.g. the Xiph method is rather wasteful for big frame sizes)
n bytes: content of laced frames

Edit: added missing "number of laced frames".

[Mosu]

The next four bytes seem to be for the TrackID, the relative timestamp/timecode (soon to be depreceated verbiage) and the byte with the flags.

More or less correct, but that is a) wrong if there's a track with a track number >= 128 and b) confusingly written on the web page (not your fault, obviously).

Furthermore, the interpretation of the first four depends on the TrackID coded in 1 octet (Matroska allows up to 2^56-1 tracks at the moment and they are coded in EBML integer form like EBML sizes (but with the difference that there is no reserved value (EBML sizes have a reserved value denoting an unknown size; TrackID has not)).

Nitpick: there's no such thing as the "TrackID" in Matroska, there's only the "TrackUID" and the "TrackNumber". The "TrackNumber" is what's stored in the Block. There's also no guarantee that the "TrackNumber" must always start at 1 and not have any gaps — you could have a file with a single track whose "TrackNumber" is 666, requiring two bytes in the Block/SimpleBlock structures.

"TrackID" (or rather: "track ID") is a concept used by mkvmerge & mkvextract, but there's no corresponding Matroska element.

Yeah, it's confusing, I get that ;)

So currently I'd say that this is a bug in the specs. If mose agrees, you should file a bug report on github (https://github.com/Matroska-Org/matroska-specification/issues).

That would be great as both calculations are still present there (https://github.com/Matroska-Org/matroska-specification/blob/master/index_matroska.md).

[hubblec4]

I'm pretty sure those numbers are completely wrong, both for the Block and the SimpleBlock elements. You've wondered that yourself in that German thread already, and it looks right to me.

For the Block structure, better numbers would be:

1 byte: element ID
1-8 bytes: element size (variable-sized integer)
1-8 bytes: track number (variable-sized integer)
2 bytes: block's timestamp relative to the cluster's timestamp (signed 16-bit integer)
1 byte: flags
1 byte: number of laced frames; only present if lacing is signaled in the flags
n bytes: lacing information; only present if lacing is signaled in the flags; total size depends on lacing method and number/size of laced frames; no upper limit (e.g. the Xiph method is rather wasteful for big frame sizes)
n bytes: content of laced frames

Edit: added missing "number of laced frames".

Many thanks for reading and this wonderful explanation. Now it is clear to me.

Nitpick: there's no such thing as the "TrackID" in Matroska, there's only the "TrackUID" and the "TrackNumber". The "TrackNumber" is what's stored in the Block. There's also no guarantee that the "TrackNumber" must always start at 1 and not have any gaps — you could have a file with a single track whose "TrackNumber" is 666, requiring two bytes in the Block/SimpleBlock structures.

"TrackID" (or rather: "track ID") is a concept used by mkvmerge & mkvextract, but there's no corresponding Matroska element.

Yeah, it's confusing, I get that ;)

Right! But the TrackNumber (like EBML variable-sized integer) can't be zero, because Tracknumbers start at 1, right?



That would be great as both calculations are still present there (https://github.com/Matroska-Org/matroska-specification/blob/master/index_matroska.md).

@mkver
Would you do this? I think your English is better.