MKVToolNix v24.0.0 released

[Midzuki]

Thanks for the update

[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]

Originally Posted by mariush

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]

Originally Posted by Telion

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 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]

Originally Posted by Mosu

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 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.

[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]

Originally Posted by mkver

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).

Originally Posted by mkver

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

Originally Posted by mkver

So currently I'd say that this is a bug in the specs. If mose agrees, you should file a bug report on github.

That would be great as both calculations are still present there.

[hubblec4]

Originally Posted by 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".

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

Originally Posted by Mosu

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?

Originally Posted by Mosu

That would be great as both calculations are still present there.

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