MKVToolNix v99.0 released

[Vicio]

Note: The latest release is v58.0.0.


Hi Mosu, greetings from Brazil.
First of all I would like to apologize if my text is not understandable, as I am using Google Translate to translate from Portuguese to English.

I am a great admirer and user of MKVToolNix and would like to thank you and everyone involved in the project for this amazing tool. I even have a channel where I post many videos about him to help people here in Brazil, I invite you to visit it.
Playlist MKVToolNix (https://www.youtube.com/playlist?list=PL9nYaAU_ht9zPSUBfOLY5hl8YuTjqGCOS)


But anyway, what I would like to report/ask you is that you re-evaluate the change that occurred in version 50.0.0 of MKVToolNix. This change has greatly harmed the productivity of users like me who make daily use of the software.

In versions prior to v50.0.0, it only took 2 clicks on the “Language” function to change the language information of the video, audio and subtitle tracks.
See the gif I made for better understanding:
https://i.imgur.com/H6zvqfx.gif


Remembering that this function is the one we use the most and in my opinion it should have quick access as it was in previous versions.
Functions like the ones below that we rarely use are like quick access.
https://i.imgur.com/A0jS4db.png


The "Language" function, which we use the most, was hidden, now we need to give 4 clicks to change the language of each track, making this process painful and tiring for users who make a lot of use of it, because every track we need to define the language will be 4 clicks to finish the task.
https://i.imgur.com/wN3zSF0.gif


Finally, I know that it is possible to rename the tracks with the tags of each language, like, pt, por, en, eng, etc... But this ends up being unproductive in the same way, as we will have to rename the tracks manually before import them into MKVToolNix. Now imagine in series that are several episodes?!

That was it Mosu, I hope that my feedback can be useful and noting that my message is not intended to criticize or offend, I am writing only to report the difficulties I have been having with this change and with the hope that you may be reassessing this situation.


Att.
Vício.

[Vicio]

Note: The latest release is v58.0.0.


Hi Mosu, greetings from Brazil.
First of all I would like to apologize if my text is not understandable, as I am using Google Translate to translate from Portuguese to English.

I am a great admirer and user of MKVToolNix and would like to thank you and everyone involved in the project for this amazing tool. I even have a channel where I post many videos about him to help people here in Brazil, I invite you to visit it.
Playlist MKVToolNix (https://www.youtube.com/playlist?list=PL9nYaAU_ht9zPSUBfOLY5hl8YuTjqGCOS)


But anyway, what I would like to report/ask you is that you re-evaluate the change that occurred in version 50.0.0 of MKVToolNix. This change has greatly harmed the productivity of users like me who make daily use of the software.

In versions prior to v50.0.0, it only took 2 clicks on the “Language” function to change the language information of the video, audio and subtitle tracks.
See the gif I made for better understanding:
https://i.imgur.com/H6zvqfx.gif


Remembering that this function is the one we use the most and in my opinion it should have quick access as it was in previous versions.
Functions like the ones below that we rarely use are like quick access.
https://i.imgur.com/A0jS4db.png


The "Language" function, which we use the most, was hidden, now we need to give 4 clicks to change the language of each track, making this process painful and tiring for users who make a lot of use of it, because every track we need to define the language will be 4 clicks to finish the task.
https://i.imgur.com/wN3zSF0.gif


Finally, I know that it is possible to rename the tracks with the tags of each language, like, pt, por, en, eng, etc... But this ends up being unproductive in the same way, as we will have to rename the tracks manually before import them into MKVToolNix. Now imagine in series that are several episodes?!
For now I am still using v49.0.0 due to this.

That was it Mosu, I hope that my feedback can be useful and noting that my message is not intended to criticize or offend, I am writing only to report the difficulties I have been having with this change and with the hope that you may be reassessing this situation.


Att.
Vício.

[Mosu]

This FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Languages-in-Matroska-and-MKVToolNix#the-old-user-interface-is-not-coming-back) contains all I have to say on the topic.

[Vicio]

As I've said several times before, the old way of selecting languages will not come back.

I don't know the reason for this rude response, even because I wrote a cordial text.
But patience..., this decision is a huge step backwards, who knows with time your arrogance will wear out and you will be able to respond to people with more politeness.


This FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Languages-in-Matroska-and-MKVToolNix#the-old-user-interface-is-not-coming-back) contains all I have to say on the topic.

I noticed that you edited your post, you must have realized it was stupid for no reason.
As I said, I don't speak the English language and that's why I don't follow gringo sites precisely because I didn't know that you had already spoken about the topic.
Anyway, I respect your decision even though I don't agree with it. Thank you now for this second most cordial response, kindness begets kindness.

[Mosu]

Please read the FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Languages-in-Matroska-and-MKVToolNix) I've written on the topic. It contains a LOT of information and explanations on why the change was made, why it cannot be simply reverted, and why it isn't the catastrophe some people make it out to be.

[Vicio]

Please read the FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Languages-in-Matroska-and-MKVToolNix) I've written on the topic. It contains a LOT of information and explanations on why the change was made, why it cannot be simply reverted, and why it isn't the catastrophe some people make it out to be.

Yes, I will read it calmly.
But as I said before, I'm not a hater, on the contrary, I'm the biggest promoter of your software here in Brazil.

Anyway thanks for the reply.

[Mosu]

I don't think you're a hater at all. Your request is absolutely reasonable. But that still doesn't mean that I will change the functionality back to what it was before for all the reasons I've laid out in said FAQ entry.

[Snowknight26]

Regarding taking 4 clicks to set the language, there a few workarounds.

mkvmerge doesn't properly show whether an element has focus. When you click the language name link (or the edit button to the right, which isn't visible in the above gifs), the Edit language window appears with the language dropdown focused. Therefore you can:

immediately type "en" on your keyboard for "English", "port" (or maybe "p", "po", or "por") for "Portuguese", etc.
use the scroll wheel (when hovering over the dropdown) to change languages
set the default language (Preferences -> Multiplexer -> Default values) to one you use most often, requiring 0 clicks in most cases
etc.

[Liisachan]

I can set e.g. 'eng' on GUI this way: Click the pen icon, hit [e], hit [enter], that's all. Quick enough.
Similarly for 'jpn': one click, two key strokes [j][enter].

[Vicio]

Regarding taking 4 clicks to set the language, there a few workarounds.

I'm aware of these options friend, I didn't think it was worth mentioning them because I don't think these alternatives are practical, among them and giving 4 clicks, 4 clicks end up being more viable.

Remembering that at no time I asked the developer to go back to the previous GUI, but I suggested that they rethink a way to shorten this long path to access the most used function of the software. Because for me it doesn't make any sense, functions like these in the image below, which we rarely use, have a quick access while the most used function became difficult to access.

https://i.imgur.com/O6ZO96j.jpg

https://i.imgur.com/pA8NPqM.gif



But anyway, any discussion here about it became irrelevant, since the developer was adamant about the topic, so I'm done with this subject here.

But thanks for trying to help.

[Liisachan]

Yeah, I've upgraded the "file" library used for MIME type detection, and it seems it isn't that good at that. Someone else already opened an issue for it. I plan to replace it by using Qt's MIME type detection which seems to work correctly with my (very) limited set of test files (both OTF & TTF fonts), but that requires quite a bit of work on the code in "configure", which is easily my least place to work in.

As stated in the NEWS file, there is an option in the preferences to use the MIME type that the Windows version of MKVToolNix had used for TrueType fonts (.ttf, not font collections) up until v57, application/x-truetype-font. You can enable that for the time being.
Mosu, thanks for taking time to change the library for this, stopping using libmagic. I'll test new builds, maybe this weekend.

The good news is, files written by v58 are likely to be okay: MPC-HC, MPC-BE, and LAV Filters all support exotic MIMEs like font/sfnt, or even application/font-sfnt, and load the attached fonts. We specifically asked each devs for that in 2019, if you remember. Those nice devs kindly added the support for almost every possible MIME type for fonts :)

That being said, I have an important request for the Matroska people. Could you include a note like this in the new specs, related to FileMimeType?

"Matroska was born more than 10 years before the font MIME types have been standardized. Initially the generic type application/octet-stream was used for font files, and then starting in 2004, application/x-truetype-font was used for TTF embedded for subtitle tracks (by a patch by Haali), and this private MIME type was the de facto standard for many years. For backward compatibility, a player that supports embedded fonts for subtitles SHOULD treat application/x-truetype-font as font/ttf, and application/vnd.ms-opentype as font/otf. Such a player also MAY check the extention stored in FileName, when it can't recognize the value in FileMimeType: case-insensitive .ttf, .otf, .ttc strongly suggest that the attached file is font/ttf, font/otf, font/collection, respectively."

[Mosu]

IBecause for me it doesn't make any sense, functions like these in the image below, which we rarely use, have a quick access while the most used function became difficult to access.

That observation is not correct. Those attributes that only have a limited set of options ("yes", "no" and maybe "default") can easily be expressed with a simple drop-down box. Languages, however, are incredibly complex in Matroska, and the aforementioned FAQ entry explains in great detail why they're complex — and why I cannot simply use drop-down boxes for them anymore. You just don't want to accept that there is much greater complexity to languages, but that complexity is there, you cannot magick it away.

[Vicio]

That observation is not correct. Those attributes that only have a limited set of options ("yes", "no" and maybe "default") can easily be expressed with a simple drop-down box. Languages, however, are incredibly complex in Matroska, and the aforementioned FAQ entry explains in great detail why they're complex — and why I cannot simply use drop-down boxes for them anymore. You just don't want to accept that there is much greater complexity to languages, but that complexity is there, you cannot magick it away.

Not quite! I carefully read that link you passed about the elements of "LanguageIETF" "Languages BCP 47", etc... That I understood very well. The point is, can you shorten this path?! Or keep the suspend box as it was before, with a link at the end of it that directs you to this new dialog??? That way there would be a merge of the previous function (drop-down box) with this new dialog box.

See the edit I made in PhotoShop for a better understanding of what I mean.

https://i.imgur.com/V1SjBVs.jpg

[Mosu]

I explain in the FAQ that I do not want to do something like that because it totally hides the tag's information that isn't the language (such as the country or the script). It suggests to the user that the additional information isn't there. This poses huge problems: the user will most likely be surprised to find out that there is more information in the tag and why they couldn't see it.

More importantly, what should happen when you change the language when additional information is present in the tag? For example, if the current language tag is "zh-Hani-CN" (Chinese in Han script in China) and you change the language drop down to "Japanese", would that now become "jp-Hani-CN"? That result wouldn't make much sense. Would it just become "jp"? That would ALWAYS destroy the additional information present in the tag.

None of those things are easy to solve with a drop-down box directly in the track properties, not without causing a lot of confusion all around.

I get that those issues are most likely completely irrelevant to you personally. But please keep in mind that your needs aren't the only needs I keep in mind when designing features. Please acknowledge that other people have different priorities, that satisfying everyone all the time simply isn't possible. I've done my best to curb the confusion, to limit the additional work required, while still providing a powerful interface — all in a package that I can actually support with the limited amount of time I have.

[Mosu]

Mosu, thanks for taking time to change the library for this, stopping using libmagic. I'll test new builds, maybe this weekend.

As always, the continuous builds (https://mkvtoolnix.download/windows/continuous/64-bit/58.0.0/) contain the changes. I've verified that the following cases work fine:

TrueType font files whose name ends with ".ttf" or no extension at all (for testing the content-based detection) yield "font/ttf".
OpenType font files whose name ends with ".otf" or no extension at all yield "font/otf".
TrueType font collection files whose name ends with ".ttc" yield "font/collection".

What doesn't work is a TrueType font collection whose file name doesn't end in ".ttc", though I really don't care about that case, to be honest.

That being said, I have an important request for the Matroska people. Could you include a note like this in the new specs, related to FileMimeType?

Good point. I've opened an issue (https://github.com/ietf-wg-cellar/matroska-specification/issues/518) for that over on the Matroska specification repo (https://github.com/ietf-wg-cellar/matroska-specification) so that we don't forget about it.

[Vicio]

I explain in the FAQ that I do not want to do something like that because it totally hides the tag's information that isn't the language (such as the country or the script). It suggests to the user that the additional information isn't there. This poses huge problems: the user will most likely be surprised to find out that there is more information in the tag and why they couldn't see it.
On this issue, I think this is underestimating user intelligence.

But please keep in mind that your needs aren't the only needs I keep in mind when designing features.
It's not just my needs, it's those of several other users too!!! As you said yourself in the FAQ, several other people have come to you disagreeing with your decision, this just goes to show that many others were also unhappy with these changes.

But that's okay Mosu, I'm not here to riot, as I said before, I respect your decision even though I don't agree with it, because I know you could get around this problem despite the complexity that has already been said.
Success with the project.

[imhh11]

At first, I hated the new way but now I'm used to it and I prefer it :)

1 click,
press letter f (for french),
enter

[Liisachan]

It's not just my needs, it's those of several other users too!!! As you said yourself in the FAQ, several other people have come to you disagreeing with your decision, this just goes to show that many others were also unhappy with these changes. On the other hand, more than one billion other people in the Chinese speaking area will be so happy when both muxing-side and player-side finally support zh-Hans and zh-Hant, auto-selecting the right subtitle track, and that recent change is an important milestone.

But I agree with you...

I know you could get around this problem despite the complexity that has already been said. ...In principle, it should be possible to make a more convenient GUI to select a language tag quickly. Maybe something like this?

http://faireal.net/aaa/mmg-language-menu.png

- Typical users can just use the "Simple" list.
- If you want to use a more complicated tag like zh-Hans or syc-Syrj, you can choose the "Advanced" radio button.
- There may be handy shortcuts to the recently used tags (the 3rd radio button).

However, there is not enough space for this in MKVToolnix GUI. All things considered, the current GUI for a language tag is well designed, compact and intuitive enough.

Also, you can add things like ".fre." ".dut." ".ita." in your input file names, and the GUI will automatically select the tag for you, zero clicks needed.

[Vicio]

On the other hand, more than one billion other people in the Chinese speaking area will be so happy when both muxing-side and player-side finally support zh-Hans and zh-Hant, auto-selecting the right subtitle track, and that recent change is an important milestone.
But I agree with you...
Hi Liisachan, how are you? Then...

The problem is not the addition of the new functions, but the way in which they were implemented, as they sacrificed the tool's usability. For those who use MKVToolNix sporadically, these changes will not be felt. The advanced user, who is the profile that makes the most use of the software, felt that the simple task of setting the language became a painful process.



...In principle, it should be possible to make a more convenient GUI to select a language tag quickly. Maybe something like this?

http://faireal.net/aaa/mmg-language-menu.png

- Typical users can just use the "Simple" list.
- If you want to use a more complicated tag like zh-Hans or syc-Syrj, you can choose the "Advanced" radio button.
- There may be handy shortcuts to the recently used tags (the 3rd radio button).
That's exactly what I suggested before. But the developer said he doesn't want to do that, as he claims users wouldn't realize there's a shortcut to advanced functions. I don't agree with this argument, because for me this is underestimating the intelligence of the users, those who use the software frequently know at least the basic functions.
Implementing something like me and now you suggested would merge the functions. That way anyone who wanted to make advanced adjustments to the language tags would be directed to the EDIT LANGUAGE window.
https://i.imgur.com/tgexzmN.jpg



Also, you can add things like ".fre." ".dut." ".ita." in your input file names, and the GUI will automatically select the tag for you, zero clicks needed.
This I already mentioned colleague, there in my first comment. Doing this on ALL audio and subtitle tracks is as unproductive as having to keep opening a secondary window to set the language.
Manually typing track by track to add the language tag is infeasible and unproductive.
But now it's just wait and hope that the developer finds a better solution for the language tags.

PS.
I apologize if any of my words sound aggressive, but as I said before I am using Google Translate to translate from Portuguese to English, so the translations may not reflect exactly what I am saying.
Hug.

https://i.imgur.com/t3bLPRM.png

[Liisachan]

I apologize if any of my words sound aggressive, but as I said before I am using Google Translate to translate from Portuguese to English, so the translations may not reflect exactly what I am saying. Then you do have good reasons to support pt-PT and pt-BR, don't you? Long, long ago, when Matroska was officially released, a few sample files were provided to demonstrate what this container can do. One of the sample clips was multi-subbed, including "Portuguese (Br.)" - back then, we only had a generic tag "por" for that track... :)

[Liisachan]

As for font mime types, the new beta (58.0.0.30 tested) is clearly more reasonable. There are other (non-font-related) subtle differences, of which none seems really important so far, though some kind of issues might occur in rare situations because there are so many changes.

[58.0.0] -> [58.0.0.30]
* = winner who guessed the registered type correctly

(libmagic rules)
vorbis.ogg = [audio/ogg]* -> [audio/x-vorbis+ogg]
theora.ogg = [video/ogg]* -> [video/x-theora+ogg]
.mp2 = [audio/mpeg]* -> [audio/mp2]

(libmagic sucks)
.m4a = [audio/x-m4a] -> [audio/mp4]*
.ac3 = [application/octet-stream] -> [audio/ac3]*
.rar = [application/x-rar] -> [application/vnd.rar]*

(the new library seems cleverer in some cases)
.mka = [video/x-matroska] -> [audio/x-matroska]
.ass = [text/plain] -> [text/x-ssa]
.wv = [application/octet-stream] -> [audio/x-wavpack]

(some of other differences)
.xml = [text/xml] -> [application/xml]
.log = [text/plain] -> [text/x-log]
.mtxcfg = [application/json] -> [text/plain]
.ffindex = [application/zlib] -> [application/octet-stream]

[Vicio]

Then you do have good reasons to support pt-PT and pt-BR, don't you?


As I said before:
The problem is not the addition of the new functions, but the way in which they were implemented, as they sacrificed the tool's usability.

[Mosu]

Thanks for the overview, Liisachan. I hadn't looked into it in detail as much.

(the new library seems cleverer in some cases)

Yeah, Qt can take both the content & the file name (= the extension) into account and will use the extension for resolving ambiguities. A lot of the differences you've noticed are down to using the extension, especially .mka = audio/…

Even though some of those changes are debatable, I actually agree with these, for example:

.mtxcfg = [application/json] -> [text/plain]
.ffindex = [application/zlib] -> [application/octet-stream]

There is a clear difference between a file's encoding and its semantics. What I mean by that is: just because a file has been compressed with the z compression library doesn't mean that any other application than ffmpeg can make use of the uncompressed contents. Same with .mtxcfg files; just because it's JSON doesn't mean any other application storing their settings in JSON can make sense of my GUI's settings. That's why such files need their own MIME type, and if there isn't a specialized one, a more generic MIME type makes more sense.

[Snowknight26]

Does mkvmerge remove filler data for HEVC streams like it does for H.264? Specifically nal_unit_type = 38.

[Mosu]

Yes, it does.

[Liisachan]

Finally, I know that it is possible to rename the tracks with the tags of each language, like, pt, por, en, eng, etc... But this ends up being unproductive in the same way, as we will have to rename the tracks manually before import them into MKVToolNix.

You don't have to do that one by one manually. Create a small batch file, e.g.
ren *.ac3 *.pt.ac3
ren *.srt *.pt.srt
...and save it as "pt.cmd". From now on, whenever needed, copy pt.cmd into your source folder, click it, and every .ac3 / .srt file in that folder becomes .pt.ac3 / pt.srt.

[elubron]

Has something changed between 53 and 57-58 with regards to appending, specifically --append-mode file and track? I've been using your program to split and append matroska files and have had no problems except when the files had subtitles which I fixed by adding the option --append-mode track. If I left it at default, the file would freeze video for 1-2 seconds (audio would still play) at the point where the 2 files were joined and then start playing normally. The append-mode track option would resolve this problem until I installed 57. I tried 58 as well, but have eventually gone back to using 53.

[Mosu]

No, the code dealing with appending tracks & files hasn't changed in a long time.

[Vicio]

You don't have to do that one by one manually. Create a small batch file, e.g.
ren *.ac3 *.pt.ac3
ren *.srt *.pt.srt
...and save it as "pt.cmd". From now on, whenever needed, copy pt.cmd into your source folder, click it, and every .ac3 / .srt file in that folder becomes .pt.ac3 / pt.srt.

Hi Liisachan. Grateful for the tip.

This will be a palliative measure that will help to get around this problem for now.
I'm even preparing a new video on my channel on this subject of the "LanguageIETF" element, in it I'll give people some tips, trying to alleviate this situation. Your tip will be in the video for sure.

Greetings from Brazil.

[odino]

@odino I don't follow. For me nothing changes in the destination file name when I press Ctrl+D. Can you please be a bit more specific? What exactly is the destination file name set to before you press Ctrl+D, and what does it change to? And which operating system & which MKVToolNix version are you using?

Sorry, Ctrl+T, see the changes in the attached pics but easy to reproduce.

Windows 64bit and v58.0.0

[Mosu]

Can you post the pictures somewhere else, please? It can take quite a bit for attachments to be approved here from time to time. You can easily upload them to my file server (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/FTP-server). Thanks.

[Liisachan]

This will be a palliative measure that will help to get around this problem for now. You mean it's just a workaround and not good enough? You're free to keep using older versions of MKVToolNix, if you don't like newer GUI. You can get an older, portable version, and before starting the GUI for the first time, create mkvtoolnix-gui.ini that says:
[settings]
updates\checkForUpdates=false so that it might not update itself. Or you can simply use mkvmerge directly without using GUI at all, which is most flexible and convenient once you prepare your "template" batch file — you can directly edit whatever using a plain editor (no list-box, no click, "replace all" if needed), tweaking and re-tweaking, test-muxing again and again by just typing e.g. "ep10mux"...

[Mosu]

so that it might not update itself

Just a small clarification: MKVToolNix only checks whether or not there's an update available. It does NOT contain code to update itself.

[Vicio]

You mean it's just a workaround and not good enough?
Yes, palliative, because any other language that is also inside the folder will be renamed.
At the moment, I've opted for this alternative below, but it suffers from the same problem as the *.cmd script hint.
https://i.imgur.com/OpaUssB.gif


You're free to keep using older versions of MKVToolNix, if you don't like newer GUI.
Staying stagnant in older versions can be a momentary measure, but not in the long term, as new audio and video codecs are emerging, thus making older versions outdated, so at one time or another there will be a need to use the version more current.


Or you can simply use mkvmerge directly without using GUI at all, which is most flexible and convenient once you prepare your "template" batch file — you can directly edit whatever using a plain editor (no list-box, no click, "replace all" if needed), tweaking and re-tweaking, test-muxing again and again by just typing e.g. "ep10mux"...
We don't just merge series, there are also different videos. Me and, I'm sure other colleagues also create duals of MANY different files on a daily basis! And so I say again, the user who actually makes a lot of use of the software knows exactly the difficulties I'm reporting here for these changes. Now if a person uses the software once in life and once in death, these changes make little difference.

For batch blending of series I will leave a video of my own, where I show how to do this without the need for commands. Downloadable software is in the video description.

How to Merge Audio+Subtitles from Batch Series
https://youtu.be/XR5Ez9eSRQM
https://i.imgur.com/v6mcK4m.jpg

[Liisachan]

Yes, palliative, because any other language that is also inside the folder will be renamed.

As long as there is a pattern between the file names and languages, you can automate this in one way or another. For example, if *_1.ac3 is en, and *_2.ac3 is pt, then
ren *1.ac3 *1.pt.ac3
ren *2.ac3 *2.en.ac3

Your pattern might be more complicated; you might have to use something like Perl that generates your command line, or you might have to use ugly FOR in your batch file itself. Think this as a great opportunity to try new things. Leaning script-fu will save your time greatly in the long run — a blessing in disguise.

Another simple option. Though it depends, using a text editor and directly editing the command-line is often faster once you understand how it works, than manually clicking here and there. This might be a generation gap, though. We didn't have any GUI for Matroska until MMG came out. We started by typing "regsvr32 kaxdemux.dll" to just play a MKV file ^^;

PS (2021-06-25):
@Vicio
I mean, even if you can save 4 clicks or 40 clicks per track, muxing say 13 similar files (1-season episodes of the same series) using GUI is painfully tedious. Instead, you can prepare the command line for Episode 1 (here you can use GUI and copy-paste the command line), and then copy-edit it a little to make a 13-line batch file, "mux13eps.bat". While this batch file editing is usually easy enough (surely easier than doing the equivalent thing one by one on GUI), you could even automate that if you want to (for example, if there are 10 seasons x 13 files to mux, you may want to create a "meta-script" first which generates a big batch file automatically).

@Mosu
Thanks for clarification about updating check, and for fixing the year 2038 problem! :)

[Liisachan]

@Mosu
Though this is something technical and practically not yet important, robUx4 is thinking that, becuse say 2021-01-01T00:00:00Z is not exactly 20 years (counted in SI seconds) after 2001-01-01T00:00:00Z, the Date value for it should not be D = 86400*10^9*365.25*20 = 631152000000000000 = 0x08C2 4D66 6747 0000, but 5 leap seconds should be counted:
D + 5*10^9 = 631152005000000000 = 0x08C2 4D67 914C F200.

https://github.com/ietf-wg-cellar/ebml-specification/issues/411

Though this is ideal, it’s non-trivial to be leap-second-aware; the meaning of the Date value will become ambiguous (is the writer/parser leap-sec aware or not?). What do you think? Would you implement this in MkvToolNix?

If the standard becomes rigorous like that, 0x08C2 4D66 6747 0000 is no more 2021-01-01T00:00:00Z but 2020-12-31T23:59:55Z, the conversion between the value and a human-readable string being difficult or even impossible for the future value where we don't yet know how many more leap secs there will be.

[Mosu]

I seen but not read the discussion around leap seconds. For me it's really easy: we're storing the number of nanoseconds elapsed since 2001-01-01 00:00:00 UTC. This is basically the same as what in computer terms is called the "Epoch" or the "Unix Epoch", just in nanoseconds instead of seconds & a slightly different reference date. It is a very, very common way to store dates & timestamps.

This representation doesn't concern itself with leap seconds at all, nor does it concern itself with time zones. Both only come into play when converting between that number of nanoseconds and a different representation/system, e.g. year-month-day hour:minute:second. That conversion is definitely varying over time, sure, especially when you create a file with a date that is, at the point in time when you create the file, in the future. But that's simply how it is.

Other ways of expressing & storing date information has other problems, and most are very quirky edge cases. For example, if you decide to store a date as, let's say, six integers representing year, month, day, hours, minutes and seconds. You might think that his is fine. However, as soon as you introduce a leap second somewhere, how do you store it? You could store the value 60 for a second. Most software out there, however, will break somehow if you use 60 as a number of seconds (in the form of 2345-06-07 08:09:60). And if you want to do any sort of calculation with that type of storage (e.g. calculating the difference between two timestamps stored in this six-integers-format) you cannot simply convert those six integers to a number of seconds by multiplying & adding them all up, because for certain ranges there were 61 seconds in a minute and not just 60.

Aaaaand then there are things such as countries changing time zones. And some countries simply skipping over whole sections of their calendar. If you want to go down this rabbit hole some more, see Tom Scott's excellent & entertaining video (https://www.youtube.com/watch?v=-5wpm-gesOY) on the topic.

Or to put it differently: what we think of as a "year" is actually a timeframe with of varying length. Both leap seconds & leap years make sure of that. Your calculation "86400*10^9*365.25*20" is therefore fundamentally wrong as it assumes that all years are equally long. Which they aren't.

Storing the "Unix Epoch" value (or an equivalent) is an incredibly sane way to represent timestamps. You always have to take leap seconds, time zones into account anyway.

So that's what MKVToolNix does (via Qt or other libraries): it converts between that epoch & a components-based representation based on all conversion rules available at the time of the conversion (when the user uses the program). In that way it seems Steve & I are in agreement.

[Liisachan]

I agree with you that counting leap seconds would be ideal, but this is not yet a solved problem in real life. On the contrary, not counting leap seconds is still quite common, while only a few "good" systems are leap second-aware.

A Unix timestamp, for example, is usually the number of seconds that have elapsed since January 1, 1970, 00:00 UTC, not counting leap seconds. That's why one says 2^31−1 <=> 2038-01-19T03:14:07Z. Counting leap seconds, this conversation wouldn't be deterministic, and the Y2038 problem would occur about 30 seconds before 03:14:07.

The current version of MKVToolNix, too, converts e.g. 2038-01-19T03:14:07Z <=> 0x1039BFC8B3303600, not counting leap seconds (use Header Editor to set that Date, then open it with Info Tool, see the hex dump).

While counting leap seconds is definitely ideal, the real-life implementations are generally not so ideal yet. To avoid potential confusion, there could be a LeapSecondAware flag for Date; or a legacy Date & an optional LeapSecondAwareDate elements. New LeapSecondAwareDate could be even better if it were 16 bytes, instead of 8 bytes, to avoid the Y2293 problem of EBML, in case Matroska will be still popular in the 23rd century :D

[odino]

Can you post the pictures somewhere else, please? It can take quite a bit for attachments to be approved here from time to time. You can easily upload them to my file server (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/FTP-server). Thanks.

Sorry, couldn't use your the fileserver, it never connects. Maybe because my connections are on private VPNs and your side blocks it. Anyhow, I posted it here:
https://ibb.co/vvPfJM9
https://ibb.co/rvhy4Hv

I have noticed this ONLY happens when the destination file name is x:\ and not if the destination filename has additional subfolders, e.g. x:\mkvstuff\ will not change to \\ when pressing CTRL+T

Steps for Windows on v58.0.0 64bit:
1. Add a random video file into the multiplexer
2. Set destination folder to c:\filename.mkv
3. Add a file title
4. press CTRL+T or use the menu shortcut
5. the destination folder will change to c:\\filename.mkv

Not a big deal, just odd behavior. This didn't happen a few versions ago because I would have noticed.

[Mosu]

Thanks, but I cannot reproduce it following your steps; for me the result after 4. is e.g. "C:\test title.mkv". Might be dependent on certain settings in the preferences.

[DMD]

Good morning
I have detected a strange problem, it is not of great importance but I want to understand if it is possible to solve with mkvtoolnix, avoiding re-encode the video.
Regarding the issue is that when I make the muxing of most HD or UHD movies in any aspect ratio from 1.33: 1 to 2.40: 1, in the section of the "Video Properties" the aspect ratio is always 16/9 or 1920x1080 or 3840x2160.
This assumed because the film was originally coded with the letterbox bands.
What I ask you can insert a tag that does don't modify the real aspect ratio but only the value of the aspect ratio.
I hope I was understandable.
It could be possible?
Thank you very much

MKVToolNix
https://i.postimg.cc/tRYv9t5g/Ridimensiona-di-Screenshot-001.png

Mediainfo
https://i.postimg.cc/g2N3w1cb/Screenshot-002.png

Aspect Ratio 2.39:1
https://i.postimg.cc/Twqd1vGr/Ridimensiona-di-Screenshot-003.png

[dvmoo]

Hi all, I am new to here, trying to search on forums (which one to use? doom9 or gitlab, reddit from MKVtoolnix's help menu?), but it seems there is no answer to the following points:

1) To cut/remove part of a mkv, currently I have to split it by timeframes, to 1st run, then the 2nd run will append (join) the spit parts without the cut part. Is there any way to do, instead of splitting, but joining part of mkv by timeframes, within 1 run/1 output file?
This is not only to save time, but it seems that on the 2nd run, mkvtoolnix does not recognize that the files have the similar properties to proceed a quick join losslessly (thing that I've seen on an Android app), so mkvtoolnix starts from frame 1 and takes time, as long as for normal run on the whole file, meaning double time.

2) Merge ERROR: it happened (sometimes) that after joining, the (joined) 2nd part (shorter) starts, then freezes or scratches images for a second or two, then continue fine. Playing the 2nd part alone, or duplicate it (for test) and joins these 2 parts, the resulting video is fluid, the freezing part was not part of the 2nd video. How to fix that? The way I used was just add the 1st part video, then context menu append the 2nd part.

3) From my understanding, but wish to be sure: MKVtoolnix does not decode/encode during process of add/remove audio/video/subtitle items, so MKVtoolnix is "lossless" (no modification) on audio/video tracks, is that correct?

4) When a mkv has DTS audio only, it can't be played on (my Samsung) TV. So the solution was to extract DTS, then EAC3To to get AC3, then merge back with MKVtoolnix. Is there anyway that we can set in mkvtoolnix to proceed all these steps within 1 queue? Would it be a suggestion to include in MKVtoolnix a cmd for mkvextract + EAC3to and wait for their completion before continueing?

Thanks for any help or suggestion.

[SeeMoreDigital]

Regarding the issue is that when I make the muxing of most HD or UHD movies in any aspect ratio from 1.33: 1 to 2.40: 1, in the section of the "Video Properties" the aspect ratio is always 16/9 or 1920x1080 or 3840x2160.
This assumed because the film was originally coded with the letterbox bands.

The 16:9 aspect ratio refers to 1920x1080 or 3840x2160 pixel frame size. Which includes the black bars above and below the 2.40:1 image.

The Blu-ray disc video encoding specification supports 4:3 and 16:9 pixel frame sizes. It does not support cropped images...

[Mosu]

Welcome to the forum. Both here and the sub-Reddit are fine for support/usage questions such as yours. Gitlab is solely for bug reports & feature requests.

Now on to your questions:

1. The "splitting by parts" mode does exactly that: you specify one or more parts to keep when remuxing. See the documentation (https://mkvtoolnix.download/doc/mkvmerge.html#mkvmerge.description.split) for examples (look for "--split parts:").

2. Due to how frames are numbered in HEVC & AVC it's possible that you're running into a limitation of the lossless (see 3.) process at this point. Read more here (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2990#note_535215149). Not saying your issue is 100% the same, just that there are certain limitations you just have to live with. The only way to "fix" this is to re-encode the video.

3. MKVToolNix does not contain any codecs, that is correct. It cannot encode/decode video. Therefore the quality won't suffer one bit. The decoded images will be the same before & after muxing. That being said, MKVToolNix does modify the bitstream where necessary (e.g. in order to patch the aspect ratio, and it throws away filler NALUs). Therefore "no modification" is incorrect.

4. No, such a feature is outside the scope of MKVToolNix. You can easily script something around mkvextract, eact3to & mkvmerge that suits your needs as they're all command-line utilities and made for scripting.

[dvmoo]

@Mosu: Many thanks, it is so quick! All your answers help well with solutions, the parameters have more possibilities than I thought, it looks so complete then, I didn't use correctly. Thanks for the tips too :)

[Perenista]

When we try to copy a subtitle like this:

******
PGS, zlib, S_HDMV/PGS, Picture based subtitle format used on BDs/HD-DVDs
******

From one MKV to another, I am not sure if I have seen this happening, instances they became smaller in the destined file, compared to the original one (which had these subtitles inserted by MAKEMKV, after ripping the disc). Are they supposed to look the same when we do this between 1080p MKVs and also between UHD/4K and 1080p?

*******
dvmoo: avoid at all cost to split any MATROSKA file. I had to do a 2nd rip from many titles again because I discovered the total duration from these video files (and anything they contained) was permanently messed with (despite all of them not being out of sync) and there was also a case in which macroblocks or similar technical issues appeared in the resulting splitted parts (especially if we are talking about UHD rips), and the problem didn't go away when joining them into a single file. I even blamed the disc without realizing it was not meant to be splitted.

This isn't MKVToolnix's fault, either, it's a feature that has been explained here to be far from perfect, so it may work for a few, it may ruin others. I am not going to split anything ever again, because some of the contents I got rid of the original source and then when I tried to merge everything back and add new stuff into them I discovered their length changed. So I am now using WinRAR even if I deal with huge files.

[SeeMoreDigital]

So yeah, having dual-layer-both-layers-in-same-track sample files would definitely help.

If you're still interested, I can send you some (short duration) 2-layer Dolby Vision .m2ts contained samples backed-up from some 4K UHD discs...

[Mosu]

Sure, thanks, though I don't expect to be able to work on that any time soon as I don't have the specs for the hvcE HEVCDecoderConfigurationRecord which I'll have to recreate from the UNSPEC63 NALUs in the bitstream.

[Mosu]

Oh wait, that's the same record structure as the hvcC, right? And parsing the UNSPEC63 NALUs shouldn't be too hard as they seem to be regular NALUs wrapped in an additional short header. I totally spaced when I wrote that above… So parsing MPEG transport streams (or rather HEVC elementary streams) with both DV layers and generating the required configuration records shouldn't be that hard.

What's more of a problem is extracting dual-layer HEVC tracks to elementary streams as that potentially requires creating UNSPEC63-variants of the parameter set NALUs in the hvcE record, and for that I'd need to understand the aforementioned additional header that UNPSEC63 NALUs start with, which I don't just yet.

So yeah, please do upload sample files. I'd appreciate it. Thanks!

[Mosu]

Heyooo!

Summer's here, so let's stay inside & play with a new release of MKVToolNix: v59. There were several nice quality of life improvements to the GUI as well as the usual bug fixes.

Several things have changed for packagers, so many that I won't list them here. You can find them the NEWS below.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the Windows installer/portable version & macOS DMG & Linux AppImage (https://www.fosshub.com/MKVToolNix.html) and the source code (https://mkvtoolnix.download/source.html).

The Windows and macOS binaries as well as the Linux AppImage are available already. The other Linux binaries are still being built and will be available over the course of the next couple of hours.

Here are the NEWS (https://mkvtoolnix.download/doc/NEWS.md) since the previous release:

Version 59.0.0 "Shining Star" 2021-07-10
New features and enhancements

mkvmerge: WebVTT parser: the parser now follows the specs' rules for parsing timestamps more closely by being more lenient: it allows arbitrary number of spaces & tabs at the start of the line & around the arrow; it allows any number of digits for the hours. Part of #3139 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3139).
MKVToolNix GUI: multiplexer: when adding a Blu-ray playlist without scanning for other playlists the GUI will now look for disc library information & let the user select which one to use if there's more than one entry. Implements #3143 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3143).
MKVToolNix GUI: multiplexer: added an option for sorting files & tracks by track types when adding them to multiplex settings. The order is: video first followed by audio, subtitles and other types. Files & tracks can still be reordered manually later. The option is enabled by default & can be found in the preferences → "Multiplexer" page → "Adding files" section. Implements #2366 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2366).
MKVToolNix GUI: multiplexer: added an option for recognizing file name sequences such as "movie.001.mp4", "movie.002.mp4", "movie.003.mp4" when adding multiple files at once. If a sequence is detected, the only first file will be added while the second and following file names will be appended to the first one. The option is enabled by default & can be found in the preferences → "Multiplexer" page → "Adding files" section. Implements #2866 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2866).
MKVToolNix GUI: multiplexer: added small colored boxes for each file & track in order to indicate from which file each track is read. The colors used can be configured in the preferences → "Multiplexer" page → "File & track colors" section.

Bug fixes

build system: fixed compilation with fmt v8. Fixes #3151 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3151).
mkvmerge: SRT subtitle reader: characters that aren't valid according to the assumed encoding of the file will now be replaced by the Unicode "Replacement Character" U+FFFD instead of keeping the invalid characters, potentially violating the Matroska specs.
mkvmerge: WebVTT parser: the parser now accepts timestamps with hours larger than 99. Part of #3139 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3139).
mkvextract: TTA extraction, only on Windows: fixed removing the temporary file created during extraction.
mkvmerge, mkvpropedit, MKVToolNix GUI's multiplexer & header editor: MIME type detection is now done using Qt instead of the "magic" library. The main impact is the MIME types of TrueType & OpenType fonts are now detected correctly. Fixes #3137 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3137).
mkvmerge, mkvinfo, MKVToolNix GUI's info tool: only on Windows: displaying dates before 1970-01-01 00:00:00 UTC or after 2038-01-19 03:14:08 UTC was broken. Note that the header editor was not affected. Fixes #3148 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3148).
MKVToolNix GUI: only on 64-bit Windows: under certain conditions, the 64-bit Windows binaries crashed when opening dialog windows. Even though the underlying bug hasn't been identified, the investigation showed that building it with newer versions than 10.2.0 of the mingw/gcc cross-compiler enabled the crashes, while binaries built with 10.2.0 were fine. This affected v57 and v58 which were built with gcc versions 10.3.0 and 11.1.0 respectively. For the time being I've switched back to building Windows binaries with gcc 10.2.0. Fixes #3132 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3132) & #3133 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3133).
MKVToolNix GUI: multiplexer: when adding files to the multiplexer by running the GUI's executable with file names as command line arguments, the source directory will be remembered as the "last open directory" again, causing subsequent uses of the "open file" dialog to start in the same directory.
MKVToolNix GUI: multiplexer: the "default track flag" column in the track list was missing its icons. Additionally it contained text even for things that aren't regular tracks and therefore do not actually have that flag (e.g. chapters or tags). Fixes #3144 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3144).
MKVToolNix GUI: multiplexer: the default for the dialog asking the user what to do with dragged & dropped files if they've never seen the dialog is back to adding the files to the current multiplex settings instead of "add as additional parts" which was an unintentional default.
MKVToolNix GUI: multiplexer: the "show command line" dialog will now always use backward slashes for the "Windows (cmd.exe)" mode and forward slashes for the "Linux/Unix shells" mode, regardless of the operating system it's currently running on. Fixes #3155 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3155).

Build system changes

The Qt library is now required for building all applications, even the command-line ones, as they use Qt's MIME type detection capabilities. In turn this means that you cannot disable the Qt usage anymore; either Qt5 or Qt 6 is required. You can still chose not to build MKVToolNix GUI, though. A new option has been added to "configure" for this purpose: "--disable-gui".
The "gmp" library is now required.
The "magic" library is not used anymore.
The "PCRE2" & "JPCRE2" libraries are not used anymore. The bundled version of "JPCRE2" was removed.
Boost's "rational" library is not used anymore.
"configure": the option "--enable-appimage" has been removed. The location of the relevant directories within an AppImage is now detected automatically.
The bundled "fmt" library was updated to v8.0.0.


Have fun 😁