About track UIDs, track numbers and track IDs
There are three concepts that all sound similar but are very different: track UIDs, track numbers and track IDs.
Track UID = unique track ID
This is a Matroska element in the track headers in each file. The purpose of this unique ID is to identify tracks between many others, potentially even across different files. Therefore the unique ID must be as unique as possible. mkvmerge will therefore generally chose random 64-bit integers for this number.
The exception is reading tracks from Matroska and WebM files as those container formats contain a UID for each track already. mkvmerge will keep that UID unless it has already been used for a different track (in which case it falls back to generating a new, random one again).
Track UIDs are also used to map tags, chapters and attachments to tracks. In order to say that certain tags only apply to certain tracks but not others, the track's UID must be used in a TrackUID sub-element in the Targets sub-element of the tags.
However, you, the user, don't usually have to muck around with track UIDs yourself. Instead you should mkvmerge do that for you. Whenever you use mkvmerge's -t or --tags option to specify a tag file for a track, mkvmerge will automatically take the track's UID it has generated (or kept) for that track and add it as Targets → TrackUID in the tags. You don't have to specify the TrackUID in the tag file you're providing yourself as mkvmerge discards that section anyway and does the work for you.
Example in mkvinfo's output:
| + Track UID: 6962806464711866347
Track numbers
This is a Matroska element in the track headers of each file. They're mainly used in the block groups & simple block elements to specify which track the current frame belongs to. They only have to be unique within the same file. As they're used very often (once in each block group or simple block), they have to be as small as possible in order to occupy the least space possible in the file.
For those two reasons they're usually sequence numbers starting at 1. mkvmerge does not keep them when reading tracks from Matroska or WebM files.
Example in mkvinfo's output:
| + Track number: 1 (track ID for mkvmerge & mkvextract: 0)
Here only the first part is relevant; 1 is the track's number. The latter part is described below.
Here's how mkvinfo shows a block belonging to that track:
| + Simple block: key, track number 1, 7 frame(s), timestamp 00:01:09.600003648
| + Frame with size 576
| + Frame with size 960
…
Track IDs
These are actually not part of the Matroska file structure/content. They're ephemeral IDs assigned by mkvmerge when it reads the track headers (of any file type it supports). Each track found that mkvmerge supports and can copy gets assigned an ID in the order they're found, starting at 0. Those track IDs are guaranteed to be stable between invocations of mkvmerge of the same version, but they aren't guaranteed to be stable between different mkvmerge versions. These track IDs aren't stored anywhere.
You can get those IDs by using mkvmerge's identification mode: mkvmerge --identification-format json --identify yourfile.ext (or its shortcut mkvmerge -J yourfile.ext).
Those track IDs are solely used in mkvmerge's and mkvextract's command line in order to state that a certain option applies to a certain track.
MKVToolNix GUI does exactly the following:
- When you add a file, it runs
mkvmerge --identification-format json --identify added-file.extand parses the output. - It presents the tracks and other content that mkvmerge just reported to have found and lets you make changes.
- When you "start muxing", the GUI constructs a command line using the track IDs reported by mkvmerge in step 1.
Here's mkvinfo's track headers again:
| + Track number: 1 (track ID for mkvmerge & mkvextract: 0)
For these ephemeral track IDs only the part in parenthesis is relevant.
Misconceptions about the relationship between track IDs and track numbers
Some people see mkvinfo's output and think: "track IDs are always track number - 1". That's actually not the case. As I've said above, mkvmerge assigns track IDs only for those tracks it actually supports and that contain valid data. mkvinfo on the other hand reports all tracks it sees.
Another reason is that track numbers aren't guaranteed to be in order, nor are they guaranteed to always start at one, or that there aren't any gaps in them. It's entirely valid and possible that the first track's number is 5, the second one's is 1 and the third track's number is 4. mkvmerge will still assign track IDs in the order the tracks are found, which means the first track's ID will be 0 (track number 5), the second one's ID will be 1 (track number 1) and the third's 2 (track number 4).
For those reasons the following should be obvious: don't use mkvinfo for determining track IDs. As stated above, use mkvmerge's identification mode as only mkvmerge knows which tracks it supports and which it doesn't.