MKVToolNix v89.0 released

[Vicio]

Originally Posted by Mosu

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


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:



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.



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.



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]

Originally Posted by Mosu

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


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:



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.



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.



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 contains all I have to say on the topic.

[Vicio]

Originally Posted by Mosu

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.

Originally Posted by Mosu

This FAQ entry 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 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]

Originally Posted by Mosu

Please read the FAQ entry 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]

Originally Posted by Snowknight26

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.







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]

Originally Posted by Mosu

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]

Originally Posted by Vicio

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]

Originally Posted by Mosu

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.

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

Originally Posted by Liisachan

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

Originally Posted by Liisachan

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 for that over on the Matroska specification repo so that we don't forget about it.

[Vicio]

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

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]

Originally Posted by Vicio

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

Originally Posted by Vicio

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?



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

Originally Posted by Liisachan

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?



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

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.

[Liisachan]

Originally Posted by Vicio

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