Welcome!
This should be easy enough to reproduce with a simple two-step process:
- Create a sample MKV with any content you want, can eben be a one-entry subtitle track only, with
mkvmerge
- Edit the file with
mkvpropedit & add a TON OF DATA to the track headers, e.g. by setting the only track’s name to a very large string.
Background: I won’t repeat what’s written about the layout in the FAQ you’ve already linked to, but only what happens on a more technical level.
In order to reduce the need to relocate track headers when editing with tools such as mkvpropedit or the GUI’s header & chapter editors, mkvmergeleaves a certain amount of empty space behind the track headers covered by a so-called EbmlVoid element (that you can see in the verbose output of mkvinfo, and if you include the –size option you’ll see its exact size, too).
When a change to the track headers must be made, mkvpropedit first tries to use the space left by the EbmlVoid element, shrinking it as necessary (similarly if you remove data from the track headers, it’ll enlarge the EbmlVoid located afterwards). However, if it needs to enlarge the track headers by more than the EbmlVoid covers, it’ll have to do this relocation dance:
- Write new track headers at the end,
- Enlarge
EbmlVoid after old track headers so that it now covers the old track headers,
- Update the
MetaSeek elements at the start so that they now point to the new location of the new track headers (this might require a similar dance for updating/moving around as the size of MetaSeek might also change!)
Therefore adding a lot of stuff to the track headers should force relocation.
For example:
[0 mosu@sweet-chili 0.022s ~/prog/video/data] mkvmerge -o v.mkv ven.srt
mkvmerge v98.0 ('Buka') 64-bit
'ven.srt': Using the demultiplexer for the format 'SRT subtitles'.
'ven.srt' track 0: Using the output module for the format 'text subtitles'.
The file 'v.mkv' has been opened for writing.
The cue entries (the index) are being written...
Multiplexing took 0 seconds.
[0 mosu@sweet-chili 0.021s ~/prog/video/data] mkvinfo --positions --size v.mkv
+ EBML head at 0 size 40 data size 35
|+ EBML version: 1 at 5 size 4 data size 1
|+ EBML read version: 1 at 9 size 4 data size 1
|+ Maximum EBML ID length: 4 at 13 size 4 data size 1
|+ Maximum EBML size length: 8 at 17 size 4 data size 1
|+ Document type: matroska at 21 size 11 data size 8
|+ Document type version: 4 at 32 size 4 data size 1
|+ Document type read version: 1 at 36 size 4 data size 1
+ Segment: size 6942 at 40 size 6954 data size 6942
|+ Seek head (subentries will be skipped) at 52 size 65 data size 60
|+ EBML void: size 4031 at 117 size 4034 data size 4031
|+ Segment information at 4151 size 124 data size 119
| + Timestamp scale: 1000000 at 4156 size 7 data size 3
| + Multiplexing application: libebml v1.4.5 + libmatroska v1.7.1 at 4163 size 38 data size 35
| + Writing application: mkvmerge v98.0 ('Buka') 64-bit at 4201 size 33 data size 30
| + Duration: 00:01:06.555000000 at 4234 size 11 data size 8
| + Date: 2026-05-28 06:56:48 UTC at 4245 size 11 data size 8
| + Segment UID: 0xd0 0xe4 0xcf 0x04 0x6f 0xe8 0x76 0x5d 0xef 0xec 0x3c 0xd3 0xb5 0x98 0x0d 0xcd at 4256 size 19 data size 16
|+ Tracks at 4275 size 54 data size 49
| + Track at 4280 size 49 data size 47
| + Track number: 1 (track ID for mkvmerge & mkvextract: 0) at 4282 size 3 data size 1
| + Track UID: 13015179512104516174 at 4285 size 11 data size 8
| + Track type: subtitles at 4296 size 3 data size 1
| + "Lacing" flag: 0 at 4299 size 3 data size 1
| + Language: und at 4302 size 7 data size 3
| + Codec ID: S_TEXT/UTF8 at 4309 size 13 data size 11
| + Language (IETF BCP 47): und at 4322 size 7 data size 3
|+ EBML void: size 1046 at 4329 size 1049 data size 1046
|+ Cluster at 5378 size 140 data size 134
This is the normal layout with Tracks at the start, a Void after it & the first Cluster following.
Now let’s edit the file. You see the Void’s empty space is 1046 bytes. So let’s add a track name that’s more than 1100 Bytes long (I’ve left out all the "e"s) and see how that affects the position of the Tracks element (before it was located at position 4275):
(Edit: I accidentally left out the mkvpropedit call cmpletely… re-added!)
[0 mosu@sweet-chili 0.001s ~/prog/video/data] mkvpropedit v.mkv --edit track:1 --set name=1100byteee…ees
The file is being analyzed.
The changes are written to the file.
Done.
[0 mosu@sweet-chili 1.642s ~/prog/video/data] mkvinfo --verbose --positions --size v.mkv | grep Tracks | head -n 1
|+ Tracks at 6994 size 11060 data size 11054
Easy.
Please note that using mkvinfo for gathering information about Matroska file is VERY BAD STRATEGY, not just for this reason. Please follow the recommendation given at the end of the very FAQ entry you’ve linked to by using mkvmerge –identification-mode JSON –identify yourfile.mkv or its shortcut, mkvmerge -J yourfile.mkv — it’s quick, it acts like a player doing all the required interpretations & analysis required by the Matroska specs (and not like a slightly better raw hex dump as mkvinfo does), its output is JSON & trivially usable by other tools etc. etc.
If you’re using not external tools but your own code for reading Matroska files, the trick here is to read the MetaSeek elements at the front & to follow them recursively (one level of recursion should suffice according to the specs, meaning there can be either a MetaSeek pointing directly to Tracks/Cues/Attachments, or there can be a MetaSeek at the start also pointing to a second MetaSeek located elsewhere, e.g. at the end, and both of them point to different sets of elements — but not MetaSeek pointing to MetaSeek pointing to MetaSeek; the latter would be outside of the scope of what the specs require).