www.makemkv.com

The problem is that the UIDs assigned by MakeMKV to tracks and chapters are not unique. For example, track UIDs are the same as the track numbers, 1, 2, 3, and so on. This may cause various issues when processing mkv files in other tools. More details below.

I've encountered this problem when converting a DVD containing several titles (episodes of the same series). Each episode contained one chapter. MakeMKV created one mkv file for each title, preserving the tracks and chapters; so far, so good. Then, I wanted to append all these files together into one large mkv file, using mkvmerge. It worked, except for chapters: the resulting file had only one chapter, at the beginning of the file.

After a bit of investigation done by the author of mkvtoolnix, it turned out the chapters in the mkvs created by MakeMKV all had the same UID - '2' - which caused them to be merged together by mkvmerge, instead of being adjusted to point to the right places in the new, large mkv file.

After changing the UIDs to different values, appending worked fine and resulted in a file with all chapters present with their timecodes correctly adjusted to point to the correct places.

The dummy track UIDs didn't cause issues in this case, but who knows what could happen in other usage scenarios.

It would be great if MakeMKV would create proper UIDs for tracks and chapters in mkvs.

Hm. As I recall matroska spec requires all UUIDs to be only unique per MKV file, or even per file segment. Needs to be investigated.

Well, glancing over a specification summary, it only seems to say they're 'random' and that they're 128 bits in length (at least most of them). In at least one place, it says something like 'as random as possible'.

Indeed, if the specification doesn't contain any clear rules for generating UIDs so that they're globally unique, you can't ask any tool to do that, can you? Fair enough.

However, using a standard random number generator, reasonably well seeded, not with 128-bit, but just 32-bit integers will yield UIDs that will be sufficiently random to make collisions very, very, ..., very unlikely in practice. (Well, make that 31-bit, to be on the safe side with conversions and all.)

There are, of course, lots of other ways to generate pseudo-unique IDs, but I think this one would solve the problem with the least effort, and would make the tool super-compliant with the spec.

What do you think?

Hi,

I was just wondering if this issue will be fixed in a future MakeMKV?

In the meantime, can someone tell me how to change the UIDs for the Chapters to be different so I can combine the two MKVs into one in mkvtoolnix whilst preserving the chapter info?

Many thanks,
Duke

Duke_Wybourne wrote:Hi,

I was just wondering if this issue will be fixed in a future MakeMKV?

In the meantime, can someone tell me how to change the UIDs for the Chapters to be different so I can combine the two MKVs into one in mkvtoolnix whilst preserving the chapter info?

Many thanks,
Duke

Yes, this should be fixed. For now it just slipped the way down.