MKVToolNix v99.0 released

[Mosu]

That's great, thanks! I usually update my build environment once a month and should pick up 5.15.1 quickly after its release.

[chros]

No plans for making those fields editable with mkvpropedit/the header editor. The reason is that they're codec-specific data. I don't make CodecPrivate available for editing either.

Hi Mosu! Thanks for your continous work on mkvtoolnix.
Do you know any util to do this? I'm asking because of this (https://forum.doom9.org/showthread.php?t=181702). (Although I don't even know whether it's possible without reencoding.)

[Mosu]

I strongly doubt that you can convert HDR formats without re-encoding.

[SeeMoreDigital]

Hi Mosu! Thanks for your continous work on mkvtoolnix.
Do you know any util to do this? I'm asking because of this (https://forum.doom9.org/showthread.php?t=181702). (Although I don't even know whether it's possible without reencoding.)There's no need to convert HDR10+ to HDR10... As HDR10+ (and Dolby Vision) HEVC encodes already include mandatory HDR10 meta-data as a fall-back!

https://en.wikipedia.org/wiki/HDR10%2B

[chros]

Thanks, but for whatever reason the Oppo deal with HDR10+ in a different way. @butterw2 just wrote how to flag (https://forum.doom9.org/showthread.php?p=1921283#post1921283) these differently using ffmpeg. That's what I need for experimenting. I'll continue with this in this thread (https://forum.doom9.org/showthread.php?t=181702).

[Mosu]

Hello everyhone,

another month, another MKVToolNix release. This one includes quite a high number of commits under the hood due to the prominent new feature I've implemented: support for the new IETF BCP 47 language elements. Finally you can express things such as "Portuguese as spoken in Brazil" or "Serbian in Cyrillic script as spoken in Serbia".

Apart from that there are the usual enhancements & bug fixes.

Important news for package managers is that the PCRE2 library is now required (only its UTF-8 variant).

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 50.0.0 "Awakenings" 2020-09-06
New feature: IETF BCP 47 language tags

I've written up a nice FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Languages-in-Matroska-and-MKVToolNix) about the switch to using IETF BCP 47 language tags, how they interact with legacy language elements, how the programs actually behave and how to disable their use if necessary.
mkvmerge: IETF BCP 47/RFC 5646 language tags: mkvmerge will now accept full BCP 47 language tags for all options taking a language. mkvmerge will always write "LanguageIETF" track header elements. If the language tag contains a valid ISO 639-2 language code it will also set the legacy "Language" track header element to the included ISO 639-2 code. Part of the implementation of #2419 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2419).
mkvmerge: IETF BCP 47/RFC 5646 language tags: if present the "LanguageIETF" track header element will be reported as the "language_ietf" property in JSON identification mode. Part of the implementation of #2419 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2419).
mkvmerge: IETF BCP 47/RFC 5646 language tags in chapters: mkvmerge will now write "ChapLanguageIETF" elements when creating chapter atoms, either when reading the simple chapter format or when generating chapters due to the "--generate-chapters" command line option. Part of the implementation of #2419 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2419).
mkvmerge: IETF BCP 47/RFC 5646 language tags in tags: mkvmerge will now write "TagLanguageIETF" elements when creating "simple tag" elements, either when reading tag XML files or when generating them. Part of the implementation of #2419 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2419).
mkvmerge: IETF BCP 47/RFC 5646 language tags: added an option "--disable-language-ietf" that causes mkvmerge to only write the legacy language elements.
mkvmerge, mkvpropedit, MKVToolNix GUI's chapter editor: IETF BCP 47/RFC 5646 language tags in chapters: when reading XML chapter files the programs will now add "ChapLanguageIETF" elements for atoms that don't contain them. The values are derived from existing "ChapterLanguage" elements. Part of the implementation of #2419 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2419).
mkvpropedit: IETF BCP 47/RFC 5646 language tags: setting/deleting the track language now acts on both the old language element as well as the "LanguageIETF" track header element. Part of the implementation of #2419 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2419).
mkvpropedit: IETF BCP 47/RFC 5646 language tags: added an option "--disable-language-ietf" that causes mkvpropedit to apply changes to the "language" track header property only to the legacy language track header element.
mkvinfo: IETF BCP 47/RFC 5646 language tags: added support for the "LanguageIETF" track header element. Part of the implementation of #2419 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2419).
MKVToolNix GUI: multiplexer: added full support for IETF BCP 47/RFC 5646 language tags for both track and chapter languages. Part of the implementation of #2419 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2419).
MKVToolNix GUI: chapter: added full support for IETF BCP 47/RFC 5646 language tags for chapter languages. Part of the implementation of #2419 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2419).
MKVToolNix GUI: header editor: added full support for IETF BCP 47/RFC 5646 language tags for track header languages. The header editor allows editing of the legacy language elements and the IETF BCP 47 language elements independent of each other. Part of the implementation of #2419 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2419).

Other new features and enhancements

mkvmerge: the chapter generation mode "when-appending" now also works with the splitting modes "parts:" & "parts-frames:" when using the "…,+…" syntax for appending other sections of the source file to the same destination file. Implements #2898 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2898).
MKVToolNix GUI: multiplexer: the file selection dialogs now include the extension ".dtsma" for DTS files. Implements #2901 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2901).
mkvmerge: MP4 reader: sped up parsing MP4 DASH files with a lot of segments ("trun" atoms) quite a bit. Part of the fix of #2900 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2900).
The PCRE2 regular expression library is now used instead of "std::regex" for big performance improvements in all places where regular expressions are used for parsing big chunks of text, e.g. in the subtitle parsers. Part of the fix of #2899 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2899).
all programs: Windows: all programs now support long file names on Windows 10 release 1604 if they're turned on in the registry. Implements #2916 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2916).

Bug fixes

MKVToolNix GUI: preferences: under certain conditions changing the selected entry in the page tree on the left did not cause the page shown on the right to be updated. Fixes #2895 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2895).
mkvmerge: splitting text by a fixed string (e.g. ",") is now done by using "std::string.find()" instead of using a regular-expression-based text splitting function, greatly improving its performance. Part of the fix of #2899 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2899).
mkvmerge: mkvmerge will now read-buffer file I/O when probing text file formats which increases its speed significantly on Windows. Part of the fix of #2899 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2899).
mkvmerge: MP4 reader: fixed handling of "tkhd" atoms of version 1. Fixes #2900 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2900).

Build system changes

The PCRE2 library (the 8-bit variant) is now required.

[AYColumbia]

Thank you Mosu.

[Masutin]

1) Can the progress percentage appear in the CLI window title?
2) While lists of MKV files, as contents of storage media, appear in televisions, players, file managers or other interfaces, will attached images show as covers? They didn't in my case but I didn't try newer systems. Is the tag "Cover:Yes" required?

[Mosu]

1) Can the progress percentage appear in the CLI window title?

No, and I have no intention of implementing something like that.

2) While lists of MKV files, as contents of storage media, appear in televisions, players, file managers or other interfaces, will attached images show as covers? They didn't in my case but I didn't try newer systems. Is the tag "Cover:Yes" required?

From Matroska's side there is no official mechanism to mark attached pictures as cover images. Convention is to name them "cover.[ext]". If and how they're used is up to the software reading the files.

[Snowknight26]

Just from a usability standpoint, it's no longer possible to select a track in the multiplexer input panel, click language, then quickly type 'eng' (or whatever you choose) for to select the language you want. Instead, you have to click the very small edit button which has a much smaller click area than the input field that used to show in there instead.

What's more interesting is, if you double click on the label next to the edit button, the "Extended subtags" dropdown receives focus and opens, making it even more inconvenient to try to change the language component (you have to close the dropdown, Shift+Tab to go to language, type in the letters, then press enter).

These changes add unnecessary user actions.

Instead, might I suggest keeping the language dropdown visible on the main multiplexer panel (while still having the edit button), allowing one to quickly change languages while still having the option of defining a more specific language tags through the edit button?

[Mosu]

Instead, you have to click the very small edit button

That's incorrect. You can also click on the text itself. Nearly the whole row reacts to a single click by opening the dialog.

What's more interesting is, if you double click on the label next to the edit button, the "Extended subtags" dropdown receives focus and opens

This is likely due to what I wrote above: the first click of your double-click opens the dialog, and therefore the second click actually ends up in the dialog, not the main window. Easy solution: don't double-click.

Please also note that you can change which parts of the dialog are selected by default in the preferences. If you prefer to use the keyboard, maybe switch the preferences over to having the free-form input selected by default. That way all you have to do is click on the panel, type "en" and press enter.

If you don't double-click, the focus will be on the "language" drop-down initially if the preferences are set to "components", otherwise on the free-form input — meaning you can just start typing right after the dialog's been opened.

Instead, might I suggest keeping the language dropdown visible on the main multiplexer panel

A strong "nope" as that would make for a very confusing user interface if other parts than just the ISO 639 language code being set. And it would make the required validation quite a lot harder to implement (and in case of failures frustrating to users).

And just to preempt a potential followup question: no, I won't make this whole thing configurable via the preferences (so that you could opt back to the old drop-down box without all the other additional controls, without the dialog). That would mean TONS of more code to maintain, more combinations to test extensively, a lot more edge cases and an even more confusing UI for users in case of there being more than the ISO 639 language being set.

The old drop-down isn't coming back.

I'm definitely up to improving the support & UI! Your proposal isn't really an improvement, though, as it comes with a lot of drawbacks.

[Mosu]

Addon: I've tried hard to design a system that, while offering much more power, requires a minimum of additional clicks. I'm very much aware users don't like having to click more. From a design perspective I had to balance the following requirements:

The user should be able to use the full feature-set that BCP 47 language tags offer.
For users not familiar with BCP 47: the language tag should be easy to construct with a lot of help from the program.
Users intimately familiar with BCP 47 should be able to quickly input a valid BCP 47 language tag without having to hunt through multiple combo boxes.
The displayed language tag should be human-readable (e.g. "English" instead of "en").
The displayed language tag should still offer the full information about all of its components.
The new controls should ideally fit into the same space the existing controls were occupying, if at all possible without making the dialog any wider.
After swapping out the old for the new controls the interface should not be much more confusing than it was before.
The number of mouse clicks required for the most-often executed operation (changing solely the language code) should ideally not increase, or if it has to increase, as little a possible.
The new controls should be usable solely with the keyboard.
The user interface should not accept invalid language tags.

Of course several of those requirements conflict with each other.

Why am I writing this? To underline that I _have_ taken those concerns into consideration. I'm not just willfully making users' lives harder.

[Snowknight26]

This is likely due to what I wrote above: the first click of your double-click opens the dialog, and therefore the second click actually ends up in the dialog, not the main window. Easy solution: don't double-click.


You're right. It just so happened that when clicking once, the Edit language window appeared such that the 'Extended subtags' dropdown was exactly where the mouse cursor was, so naturally a 2nd click would focus on it instead.

That was simply a false assumption on my part.

And just to preempt a potential followup question

Well surprise surprise, I didn't have follow-up questions. :p I suppose my only complaint is that from a UI/UX perspective, it's not normal for a text label to be an actionable element (meaning clicking it does something).

Minor bug though:

Open MKVToolNix GUI
Click Add source files
Select a file with chapters
Click on the chapters in the "Tracks, chapters and tags" panel
Click "<Do not change>" next to Language in the Properties panel
Change any parts of the language
The new language option is reflected in the Properties panel
Click on a different track in the "Tracks, chapters and tags" panel
Click on the chapters in the "Tracks, chapters and tags" panel
Language settings are not preserved (naturally, since you shouldn't be able to change the language for chapters?)

[Mosu]

I suppose my only complaint is that from a UI/UX perspective, it's not normal for a text label to be an actionable element (meaning clicking it does something).

That's true, of course. That's why it isn't the only way to open the dialog & why the edit button is present, consistent with edit buttons in several other locations in MKVToolNix GUI. That the text label accepts a click, too, is purely for convenience & ease of use.

Maybe I'll change the visuals somehow to signal interactivity (similar to URIs are underlined & displayed in a different color).



Click on the chapters in the "Tracks, chapters and tags" panel
Click "<Do not change>" next to Language in the Properties panel

Ooooh, right. That shouldn't happen. From mkvmerge's perspective you cannot change the language of chapters & tags; therefore the GUI shouldn't allow you to change the language for those entries. It didn't before v50, and the edit button in v50 is disabled correctly, but the click on the text is still accepted. I'll fix that. Thanks.

[SeeMoreDigital]

With regard to adding chapters...

Is there any particular reason why the supported 'chapter file' types can't be dragged and dropped into the GUI's main window, instead of always having to visit the 'Output tab'?

[Mosu]

Is there any particular reason why the supported 'chapter file' types can't be dragged and dropped into the GUI's main window, instead of always having to visit the 'Output tab'?

Huh? You _can_ drag & drop chapter files onto the "input" tab. The GUI will recognize dropped chapter files & automatically insert their file name in the corresponding control in the output tab. It'll even show a helpful popup message explaining what it just did & why it did it.

If you don't see that popup, you've opted not to see it again earlier (there's a checkbox in the popup for that).

The reason chapter files aren't treated the same way other source files is that mkvmerge simply doesn't handle them the same way. I might change that someday, but it'd be quite a bit of work for, honestly, not even that much of a increase in convenience, never mind that it wouldn't actually enhance or extend existing features.

[SeeMoreDigital]

If you don't see that popup, you've opted not to see it again earlier (there's a checkbox in the popup for that)...How odd then!!!

A few days ago I used gMKVExtract GUI v2.5.2.0 to demux some chapters as an 'chapters.ogm.txt' file. And when I tried dropping them into MKVToolNix GUI I received this message: -

https://i.ibb.co/C75qw8L/Chapters.png

...And the chapters did not appear :eek:

Edit: I think I know what's happened now. The 'chapters.ogm.txt' file has been loaded and it appears under the 'Output' (Chapters) tab. But they don't appear within this box as being loaded: -

https://i.ibb.co/2kxqyXh/Box.png

[Mosu]

Edit: I think I know what's happened now. The 'chapters.ogm.txt' file has been loaded and it appears under the 'Output' (Chapters) tab. But they don't appear within this box as being loaded:

Chapters appear in that box only if they're part of one of the source files (e.g. inside Matroska or MP4 files or MPLS playlists) in the upper box. As I said earlier, pure chapter files are not regular source files, though, and don't appear there.

I know, somewhat confusing, due to design decisions in the early days, not trivial to change, might be changed one day, but don't hold your breath :)

[SeeMoreDigital]

I know, somewhat confusing, due to design decisions in the early days, not trivial to change, might be changed one day, but don't hold your breath :)Yeah, it is somewhat confusing. But at least I now know that they are in there ;)


EDIT: It's rather incredible that you first released your application way back on the 30 April 2003 and continue to regularly issues updates...

[hubblec4]

Hi Mosu

I want mux an mkv from a BD, and when I set the "--disable-language-ietf" flag there is no language for the video track.
Audio and subtitle tracks have the "normal" 3-letter-language code.

[Mosu]

there is no language for the video track.

Where exactly do you mean?

[SeeMoreDigital]

there is no language for the video track.
Out of interest... What's the purpose of assigning a language to a video track?

[Mosu]

Out of interest... What's the purpose of assigning a language to a video track?

The problem is with the Matroska specs in this particular case: the old Language element is both mandatory and has a default value of "eng". The effect is that there's no way NOT to assign a language to a track: if no language element is found, a reader must use the default value "eng" instead. Yes, that's one of the two design decisions we would definitely change if we redesigned the container.

From a semantic point of view it isn't that much of a problem as there's the code "zxx" = "No linguistic content; Not applicable" that can be used to signal that the video track does indeed not have any linguistic content.

[VBB]

What about "und" (undetermined)? That seems to work just fine when assigned to a video track, and it doesn't show as anything in MediaInfo.

[Mosu]

Semantically speaking "und" means that there is linguistic content, you just don't know which language it actually is. How players treat "undetermined" is not up to Matroska/MKVToolNix, and I bet it isn't uniform across players either.

[hubblec4]

Where exactly do you mean?

I forgot that no language element is written if the language is "eng".

[hubblec4]

Out of interest... What's the purpose of assigning a language to a video track?

This is maybe not important, but a video from an USA production looks different to Chinese production.

I have some movies where the original is produced in Sweden and Hollywood had make a remake of this movie.
There are a lot of scenes where signs in Sweden language -> newspaper articles or shop advertisement and others.

[SeeMoreDigital]

This is maybe not important, but a video from an USA production looks different to Chinese production.Hmmm...

But surely such sources would not arrive to you muxed within the Matroska container. They would be identified in a different way!

Do transport container and mp4 muxers offer a video language option?

[Mosu]

Do transport container and mp4 muxers offer a video language option?

MP4 does provide a language for all tracks in the "mdhd" atom, no matter the track's type.

MPEG transport streams do not have a language field in general. Certain track/codec types do have a language coded somewhere in their codec-specific initialization data, e.g. teletext or the generic subtitle PMT descriptors. However, MPEG transport streams as used on Blu-rays are always accompanied by clip information files ("CLIPINF/*.clpi"). Those files do contain a language field for all tracks, no matter their type, but for video tracks it's often empty.

[NanoBot]

Out of interest... What's the purpose of assigning a language to a video track?

I use the language tag of the video track to indicate the language of the opening credits, end credits and hardcoded subtitles.

Another possibility: Think of Star Wars, there the language tag could be used to indicate the language of the intro.

[netmask]

I don't support Windows 7 anymore.
Which is the latest version tat does support Windows 7 64bit Professional?

[jpsdr]

For me, the last (50.0.0) works on Windows 7 x64. By this, i think he means that he will not investigate any issue if you're under Windows 7. If it works, good for you, otherwise, too bad... :(

[netmask]

Thanks..

[Mosu]

Hello everyoone,

I've just pushed out MKVToolNix v51. As expected the new IETF BCP 47 language tag functionality introduced in v50 had a couple of bugs, which I've fixed in v51. Apart from that I've also started fuzzying mkvmerge, which turned up several issues that have also been fixed. Fuzzying will continue in the future and I fully expect a lot more bugs to be unearthed by it.

Important news for package managers is that `configure` can now detect and use a system-wide installed copy of the JPCRE2 header library. If it isn't found, the bundled version will be used (just like in v50).

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 51.0.0 "I Wish" 2020-10-04
New features and enhancements

mkvmerge, mkvpropedit, MKVToolNix GUI: IETF BCP 47 language tags: added missing support for UN M.49 regions for which there are no corresponding ISO 3166 alpha codes. This enables language tags such as "es-419" = Spanish in Latin America and the Caribbean. Implements #2919 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2919).
MKVToolNix GUI: IETF BCP 47 language tags: the text in the widget displaying the current language & the corresponding edit button is now displayed like a link (depending on the theme: different color & underlined), making it clearer that not just the edit button can be clicked but the text, too.

Bug fixes


mkvmerge: AV1 parser: fixed mkvmerge crashing after uncaught exceptions due to certain data conditions. Found by fuzzying.
mkvmerge: AV1 packetizer: the duration of frames wasn't set properly. When appending AV1 IVF or OBU files this meant that the last frame of the Nth file and the first frame of file N+1 had the same timestamp. Fixes #2937 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2937).
mkvmerge: DTS reader: fixed handling of buffers with an odd length when byte-swapped DTS is detected so that mkvmerge doesn't abort with a failed assertion. Found by fuzzying.
mkvmerge: h.264/AVC and h.265/HEVC elementary stream readers: mkvmerge will no longer claim to recognize data that looks like AVC or HEVC but with invalid video width/height values as that lead to failed assertions in libEBML later. Found by fuzzying.
mkvmerge: h.265/HEVC parser: fixed mkvmerge aborting after uncaught exceptions due to certain data constellations found by fuzzying.
mkvmerge: IVF reader: fixed mkvmerge crashing with a "division by zero" error due to certain data conditions. Found by fuzzying.
mkvmerge: fixed mkvmerge aborting with a "division by zero" error due to the timestamp scaling factor being 0 after handling certain data constellations found by fuzzying.
mkvmerge: track statistics: fixed a "division by zero" error when the content's shorter than 1ms. Found by fuzzying.
mkvmerge, mkvinfo, mkvextract, mkvpropedit: Matroska access class: fixed an invalid memory access under certain data conditions. Found by fuzzying.
MKVToolNix GIU: IETF BCP 47/RFC 5646 language tags: the GUI will no longer open the language dialog when clicking on a disabled language display widget.
MKVToolNix GUI: IETF BCP 47 language tags: the "variants" combo-boxes were not populated even when the language tag was valid and contained at a variant. Fixes #2923 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2923).
MKVToolNix GUI: IETF BCP 47 language tags: when no language is selected, at least one of the other components (extended subtags, region, or variants) has something selected and "private use" is not empty, the GUI would claim this to be a valid tag, which it isn't. Fixes #2924 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2924).
MKVToolNix GUI: multiplexer: when the tracks/chapters/tags selection changes from "at least one entry selected" to "no entry selected", the input controls will be reset to their default state and not just disabled. Fixes #2927 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2927).

Build system changes


"configure" now checks for the presence of the a system-wide installed copy of the JPCRE2 C++ wrapper library for the PCRE2 library and uses that if it's new enough (at least v10.32.1). If not, the bundled version will be used as a fallback. Implements #2929 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2929).


Have fun!

[VBB]

Thanks Mosu! I use your software almost every day. Shout out to Braunschweig from a former Frankfurter :D

[LeMoi]

Thanks for the latest updates.
Is there a way to have the possibility to choose between the old and the new language selector ? The old way (scrolling menu) was way more practical, it needed less clics, I can understand that it doesn't bother some people (maybe some asked for it ?!), but it's more complicated than it was... maybe we could choose between something like "easy mode" and "complete mode".

[Mosu]

Please see this FAQ section (https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Languages-in-Matroska-and-MKVToolNix#the-old-user-interface-is-not-coming-back) where I answer your question.

[hubblec4]

When 1000 user says this new language system is not good to use, I guess you are more willing to change/bring back the old language system.
For me personal is the IETF language a pain and not easy to use in MTX.

[Mosu]

At the moment I actually have more positive feedback (people that are glad they can finally be more precise wrt. to languages) than negative on the change.

[LeMoi]

I understand that, even if I disagree (the list was pretty complete, and the 3-char code was more precise, and it needed one click less ^^), that's why I wondered if there a way to have the choice between the new and the old method

[Mosu]

the list was pretty complete

Well, you couldn't differentiate between things such as "Portuguese as spoken in Brazil" vs. "Portuguese as spoken in Portugal" (which is quite different), nor could you mark subtitles with "Serbian in Latin" vs "Serbian in Cyrillic" with the old system. It was far from complete. Sure, it seems to have been enough for you and your use case, but you and your use case aren't everyone else's.

and the 3-char code was more precise

This part of your sentence I don't understand at all. BCP 47 language tags use the same ISO 639 language codes the old system used. The only difference is that the old Matroska system only used the three-letter codes whereas BCP 47 says that the two-letter code should be used if there is one available for a given country, and if not to use the three-letter code. There's nothing being more or less precise about this; the ISO 639 code list contains three-letter codes for all countries and two-letter codes for a lot (but not all) others.

As a matter of fact: the old Matroska system only supported languages from the ISO 639-2 standard. However, there have been extensions of that list with ISO 639-3 and 639-5, which the old Matroska standard did not support. BCP 47 does support those (MKVToolNix doesn't yet, though I'm going to implement them soonish).

[Atak_Snajpera]

What am I doing wrong here?
https://i.postimg.cc/sfJxVFf0/Untitled-1.png

[sneaker_ger]

Try
mkvmerge "@options.json"

[Atak_Snajpera]

Still the same error. Is there anybody who uses json configuration file with success? BTW. Yes my file is detected by notepad++ as ANSI as UTF-8. The same problem in v51 as well.

[sneaker_ger]

Is there anybody who uses json configuration file with success?
Yes. Working fine with mkvmerge v51 as long as I don't forget the "@".

[Atak_Snajpera]

Could you show me some screenshots? Obviously I must be doing something...

[sneaker_ger]

:confused:
https://i.imgur.com/cIFBYb7.png

[Atak_Snajpera]

:confused:
https://i.imgur.com/cIFBYb7.png

Does it also work if you run that command from .cmd/.bat file?

https://i.postimg.cc/635P8JMJ/Untitled-1.png

By the way. Is there any logical reason why the method of loading option file is "over engineered/unusual". Why not something simpler like
mkvmerge --options "MyOptions.txt"
or even better
mkvmerge "MyOptions.txt"

Why do we have to use that @ symbol?

[sneaker_ger]

Move the "@" to the front of the absolute path.

[Atak_Snajpera]

Move the "@" to the front of the absolute path.

Thanks! That works! Jesus...