MKVToolNix v24.0.0 released

[Mosu]

Originally Posted by ndjamena

As long as I can copy from there that would be an improvement.

I've implemented both changes that I've talked about. Here's the corresponding ChangeLog entry:

        * MKVToolNix GUI: header editor enhancement: several track
        properties like name or language are shown as columns in the tree
        for easier distinction between tracks. They're also shown on the
        overview page on the right when that track's entry is selected in
        the tree. The text in the labels on this overview page can be
        selected with the mouse for copying & pasting elsewhere.

Identifying which track to click on and copying & pasting the track name will be easier with these changes, and I hope they can help you with your workflow a bit, too.

A small tip: you can select the whole label for a property by triple-clicking on it, even across spaces and other non-word characters.

I'd appreciate some testing & feedback. You can get new pre-builds from here; build numbers 986 and higher contain the change.

How difficult would providing a dropdown box with a list of custom entries to choose from in the name section be? Too hard?

If you don't need all those columns then remember you can hide them by right-clicking on the column labels (or re-order them via drag & drop). Those changes are remembered across restarts, of course.

[ndjamena]

I got half way through my current batch before I found the first movie that it turned out to be useful. It does help. I remember even before deleting my batch having to have MediaInfo and the MMG Header Editor open at the same time so I could copy/paste track names at least this is better than that.

Oh, right, one thing I've always noticed was missing in the header editors was the ability to simply remove the header for a track completely like MakeMKV does with empty forced tracks. At the moment I'm just setting the subtitles I don't want to "fre" so that they'll be removed when I remux them but nuking the header completely would be better.

Would that be something you'd be willing to implement or would that be too dangerous? Do players generally care if they come across blocks for tracks they can't identify?

( Sword and the Stone has both normal and SDH forced tracks... I'm currently trying to figure out what the hell to call the SDH one... English Translations SDH - PGS..? Maybe I should have been calling the SDH tracks "English Main SDH - PGS", then I'd already have a protocol in place for when I'm ripping SDH commentary tracks... English (UK) Translations SDH (CC) - PGS )

*sigh*

[Mosu]

Thanks for the feedback, ndjamena.

Originally Posted by ndjamena

Oh, right, one thing I've always noticed was missing in the header editors was the ability to simply remove the header for a track completely like MakeMKV does with empty forced tracks. At the moment I'm just setting the subtitles I don't want to "fre" so that they'll be removed when I remux them but nuking the header completely would be better.

Would that be something you'd be willing to implement or would that be too dangerous? Do players generally care if they come across blocks for tracks they can't identify?

To be honest I don't know of a player that would choke on finding content for a track number for which corresponding track headers exist, but I'd rather not risk it. My past experience with Matroska players (especially with hardware devices) is really bad – the slightest problem (more likely: unanticipated situation) can throw them off. If I provide such a mechanism then I'm more or less condoning the creation of invalid files, or ones whose validity is highly questionable.

Note that mkvmerge will emit a warning for each block group for which no corresponding track header was found as such a situation usually indicates file corruption.

Can't you just set the Enabled flag of those tracks to 0?

[ndjamena]

That's interesting, MPC-HT actually obeys the enabled flag. Nothing else does.

Really I'm just looking for a way to tell a remuxer NOT to remux the track, my batch used to rename them as "###REMOVE###", but that only works when used alongside my remuxing batch. MediaInfo doesn't read the enabled flag so, that's no good. Interestingly both MKVToolNixGUI AND MakeMKV can remove tracks automatically based on language, it's just that nuking the header would be more efficient and I wouldn't have to look at them. It doesn't help that I feel like I'm insulting any language that I happen to select for the purpose.

It's not important.

[SeeMoreDigital]

Originally Posted by Mosu

My past experience with Matroska players (especially with hardware devices) is really bad – the slightest problem (more likely: unanticipated situation) can throw them off.

Indeed...

There are more hardware playback devices than ever capable of supporting the Matroska container, including televisions. And TV manufacturers are pretty bad at offering updates when third-party software developers decide to change the way their software's function.

It's bad enough getting TV manufacturers to support YouTube app changes

[Mosu]

I've released MKVToolNix v8.5.1 only four days after 8.5.0. The reason is that Cisco's Talos Research Group has found several cases of invalid memory access and instances of freeing memory twice in libEBML (TALOS-CAN-0036, TALOS-CAN-0037). The consequences range from heap information disclosure to denial of service.

Those issues have been fixed along with some more cases of invalid memory access discovered while investigating the TALOS-CAN reports. New releases of libEBML (v1.3.3) and libMatroska (v1.4.4) were made yesterday. Today's release of MKVToolNix incorporates both updated libraries, and its build system requires at least those versions if you want to use globally-installed copies.

As MKVToolNix and therefore both libEBML and libMatroska are often used to process content from arbitrary sources I highly recommend everyone to upgrade.

Here are the usual links: the MKVToolNix home page, the Windows installer and portable version and the source code.

All binaries that I provide have been uploaded already.

Here's the full ChangeLog since the previous release:

2015-10-21 Moritz Bunkus <moritz@bunkus.org>
* Released v8.5.1.

2015-10-20 Moritz Bunkus <moritz@bunkus.org>
* build system: libEBML v1.3.3 and libMatroska v1.4.4 are now required due to important fixes for invalid memory accesses in those two releases. The copies included in the MKVToolNix source code have been updated to those releases as well.

2015-10-19 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: the "save file" dialogs did not have the currently entered file name pre-selected anymore. Fixes #1480.
* MKVToolNix GUI: header editor enhancement: several track properties like name or language are shown as columns in the tree for easier distinction between tracks. They're also shown on the overview page on the right when that track's entry is selected in the tree. The text in the labels on this overview page can be selected with the mouse for copying & pasting elsewhere.

2015-10-18 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: fixed a crash when loading corrupted job settings.
* MKVToolNix GUI: header editor bug fix: the tree items weren't re-translated when the GUI language was changed.
* mkvmerge: bug fix: updating the track headers wasn't working in some rare cases (corresponding error message "Re-rendering track headers: data_size != 0 not implemented yet").

2015-10-17 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix (Linux): the function "open folder" was inserting a superfluous leading slash in the directory name. This causes some file managers (in this particular case Dolphin on Linux) to interpret a directory name like "//home/mosu/…" as a share called "mosu" on a Samba/Windows server called "home" and to prepend the whole name with the "smb://" protocol. Fixes #1479.

Have fun.

[Atak_Snajpera]

Question: Is there any reason why you don't use ULTRA preset in 7-zip while compressing portable version? Your 7z file is 15,5 MiB but with ULTRA preset you can reduce size even down to 11 MiB.

[Mosu]

The reason is that I don't care that much about the size. It already takes too long to compress the archives, especially when I build ten or twelve a day.

[ndjamena]

Can I just voice a minor annoyance.

When MKVToolNixGUI informs me that a new version is out it gives a link to the download page here:

https://www.bunkus.org/videotools/mk...s.html#windows

That's not the actual link it provides, it would be nice if it would automatically append the #windows bit (or appropriate OS).

But that's not the problem. The problem is that page gives four separate versions to download, and of course each time I get there I sit and take the time to figure out which one I need to click, effort which is ultimately wasted because all four links go to the same page.

http://www.fosshub.com/MKVToolNix.html

And then I have to repeat the process again to begin the download. I feel like a sucker each time...

Since they all go to the same place anyway, would it be too much to ask for one, single, clearly marked download link so I don't have to feel like I'm playing mind games with the website?

[Atak_Snajpera]

Originally Posted by Mosu

The reason is that I don't care that much about the size. It already takes too long to compress the archives, especially when I build ten or twelve a day.

I do not know what you have there but difference between Normal vs ULTRA on my cpu is only 2 seconds (15s vs 17s). 7-zip most of the time uses only two cores while compressing mkvtoolnix so you do not need expensive i7 cpus at all.

[Mosu]

Atak_Snajpera: When I said that I don't care about size then I meant that I haven't even tried to measure it. Because I don't care about the size.

[Mosu]

ndjamena: Well, that was easy to change. Done.

[Jamaika]

OK. I understand now that "zlib" is an addition to advertising. Indeed, these are trifles finishing, which need a bit more memory when displaying subtitles. I wanted to ask, is it possible to pack text in global-tags.xml?

[Mosu]

Uhm… what!? I honestly don't understand you're talking about, never mind what you're actually asking, Jamaika.

[Jamaika]

Uhm… what!? I don't understand you're reading about, Mosu. I thought talking about functions --compression zlib. Good night.

[Mosu]

If you're asking whether or not you can compress tags: you can't. The Matroska spec only has provisions for compressed track content.

[Jamaika]

I am surprised, because in the container ASS are additives fonts and images. They can be encoded and aren't track content.

[Mosu]

Matroska doesn't care about the _content_ of attachments. Its interpretation is up to the application using those attachments. If an applications supports using e.g. attached compressed fonts then that's great, but Matroska doesn't have anything to do with that.

[Mosu]

Originally Posted by Atak_Snajpera

Question: Is there any reason why you don't use ULTRA preset in 7-zip while compressing portable version? Your 7z file is 15,5 MiB but with ULTRA preset you can reduce size even down to 11 MiB.

Looks like I was wrong. There obviously was a time when I cared about this enough to devise the following options for compression:

-t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=on

I'm pretty sure that this is from back when 7z didn't support lzma2. I'll replace all of those by -mx=9 which means that my current p7zip will default to lzma2 achieving better compression.

[Carpo]

think you need to add -m0=lzma2 to make it use lzma2, don't think -mx9 on its own selects it, unless the newer 7zip 15.x version has changed it, still using 9.20 myself