MKVToolNix v99.0 released

[Mosu]

Sounds like… well… something, maybe bad compiler optimizations? I don't know… Please give the latest continuous build (https://mkvtoolnix.download/windows/continuous/64-bit/35.0.0/) a try. They're built with newer compiler versions.

Not that I think that'll really do anything, mind you…

As I don't have access to a single Ryzen system, I don't think there's really anything I can do at the moment, especially given that older Ryzen seems to have run the binaries just fine according to you.

[Mosu]

The old "codec name" track property (now codec_name) was "codec" only?

No. "codec" wasn't changed at all. The property "codec_name" was added containing the value of the "CodecName" track header attribute if present.

[nogames]

Sounds like… well… something, maybe bad compiler optimizations? I don't know… Please give the latest continuous build (https://mkvtoolnix.download/windows/continuous/64-bit/35.0.0/) a try. They're built with newer compiler versions.

Downloaded the 64-bit version of the continuous build. And no errors. It runs. I'll report back again when this version goes final.

[DragonQ]

MKVToolNix GUI v35.0.0/64bit keeps crashing when adding a file to GUI. It does not matter if it is via drag-drop or Add file option.

I just upgraded my system to Ryzen 7 3700X. It's a fresh install of Windows 10 Pro 64-bit (version 1903). I came from a Ryzen 7 1800X (but not version 1903 but the previous version) which did not have this problem.

The 32bit version of MKVToolNix GUI v35.0.0 works! I have tried all 64 bit versions from v30.0.0 and on and they all crash when I add a file.

Note: No difference in behaviour between Installed and Portable versions
I have a similar issue. I also have a Ryzen 7 3700X, a fresh install of Windows 10 1903, and the 64-bit version of MKVToolnix GUI. I can add files and make changes, but as soon as I hit "Start multiplexing", the app crashes and disappears. I then cannot restart the app at all (it presumably insta-crashes since I never see the window). The only way to get the app to relaunch is to empty the "AppData\Local\bunkus.org\mkvtoolnix-gui\jobQueue" directory.

The only workaround I've found is to import files, choose my settings, then do "Show command line" and run it manually in the command line.

[Snowknight26]

Yep, just noticed the same thing, Ryzen 5 3600. Start multiplexing crashed the program and it won't start again. It was working fine up until I chose the destination file using the button instead of typing the name in manually.

[Mosu]

The new Ryzens are known to contain several bugs, e.g. with their RDRAND instruction. This is not a bug in MKVToolNix, and AMD has released new BIOSes that're supposed to fix some of those bugs to for the motherboard manufacturers. Another user who reported the issue over on Gitlab (https://gitlab.com/mbunkus/mkvtoolnix/issues/2589) also reported that their motherboard manufacturer's just released a BIOS update. After having applied the update MKVToolNix started to work fine (https://gitlab.com/mbunkus/mkvtoolnix/issues/2589#note_198551877) for them.

[chros]

The new Ryzens are known to contain several bugs, e.g. with their RDRAND instruction.
That's interesting, thanks. Did AMD become the new Intel?! :devil:

[DragonQ]

The new Ryzens are known to contain several bugs, e.g. with their RDRAND instruction. This is not a bug in MKVToolNix, and AMD has released new BIOSes that're supposed to fix some of those bugs to for the motherboard manufacturers. Another user who reported the issue over on Gitlab (https://gitlab.com/mbunkus/mkvtoolnix/issues/2589) also reported that their motherboard manufacturer's just released a BIOS update. After having applied the update MKVToolNix started to work fine (https://gitlab.com/mbunkus/mkvtoolnix/issues/2589#note_198551877) for them.
Which bugs are "known" other than the RDRAND bug? Does MKVToolnix actually use RDRAND?

Either way, I tried the latest dev release and it seems to work now. Not sure if it's because of the new version or a new BIOS but at least it works now. :)

[huhn]

there are quit some issues they even pulled bios versions thanks to bugs in the AGESA. boards are shipped with alpha version bios this is as rushed as possible...

if you want a stable system zen 2 shouldn't be an option for now.

[MrVideo]

I tried looking thru the change logs and a search here, but didn't find anything. At what version did Windows support change to Win7, and later? Thanks.

[lvqcl]

and a search here
There is also an old thread: http://forum.doom9.org/showthread.php?t=155732

I tried looking thru the change logs and a search here, but didn't find anything. At what version did Windows support change to Win7, and later? Thanks.

You mean officially? I suspect that the answer is here - https://gitlab.com/mbunkus/mkvtoolnix/wikis/Officially-supported-operating-systems-and-versions

Supported are all client versions of Windows (meaning Intel architecture) that Microsoft supports. This means Windows 7 or newer, 32-bit and 64-bit architectures. On the server side Windows Server 2012 and newer are supported.
(emphasis mine)

At least, version 11 was the first that dropped support for WinXP.

PS: http://forum.doom9.org/showthread.php?p=1806381#post1806381

[sneaker_ger]

Yeah, officially. The sounds made the GUI not work on XP for good. CLI may still work. As should Vista.
# Version 11.0.0 "Alive" 2017-04-22

## New features and enhancements

* MKVToolNix GUI: implemented several built-in actions that can be executed
either on special events or once via the "watch jobs" tool. These are:
playing an audio file (implemented for all operating systems)

## Build system changes

* Qt's multimedia component is required for compilation of the GUIs since
version 11.0.0.
https://mkvtoolnix.download/doc/NEWS.md

[MrVideo]

You mean officially? I suspect that the answer is here - https://gitlab.com/mbunkus/mkvtoolnix/wikis/Officially-supported-operating-systems-and-versions
I saw that. It doesn't say when.
At least, version 11 was the first that dropped support for WinXP.
I've got V24 32bit running on an XP system. I've never used the GUI. I do all my mkvmerge stuff via the CLI within Zshell scripts under cygwin. That said, I do not use that system for recoding and merging of the video and audio streams anymore. But, I do use mkvmerge a lot. I guess I'll just keep upgrading until I find a version whereby it no longer works and go back to the previous version.

I had to rebuild another XP system that I was using for compiling and loaded XP-64 on it. I ran either 31 or 33 on it. Hardware issues required a new mobo so I upgraded it to Win7 as well. I had already built another Win7 box for compiling and have basically turned off the other Win7 box. At least I haven't turned it back on after AC power issues. :eek:
PS: http://forum.doom9.org/showthread.php?p=1806381#post1806381
Personally I do not like the "ding"ing that goes on when programs finish, or if there are errors. I find it annoying. The error dialog popups are good enough for me.

Thanks for the responses. It has been helpful.

[manolito]

The last CLI version which works under WinXP is v.29. If you need the GUI you have to replace some components of the package with older versions.

FWIW here is a package which does this...
https://files.videohelp.com/u/172211/ToolNix_XP.zip


/EDIT/
The archive was updated to also include the last Win7 compatible version (32-bit only)

[MrVideo]

The last CLI version which works under WinXP is v.29.
Thanks for the info. That'll save me a lot of trial and error.
If you need the GUI you have to replace some components of the package with older versions.
Thanks. But like I wrote, I do not use the GUI and have never used the GUI.

[Mosu]

Here's another small summery bug fix release for MKVToolNix, v36.0.0. Nothing major's changed; just a couple of fixes here & there.

There've been no changes regarding packaging since the previous release.

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 36.0.0 "Is That Jazz?" 2019-08-10
New features and enhancements

mkvmerge: mkvmerge now allows appending AV1, VP8, VP9, H.264/AVC and H.265/HEVC tracks whose pixel dimensions differ. Implements #2582 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2582).

Bug fixes


source code: fixed building with Boost 1.71.0. Fixes #2599 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2599).
all: fixed the spelling of the H.264 & H.265 codec names.
mkvmerge: Blu-ray MPLS handling: mkvmerge will now find corresponding M2TS files even if the "clip_codec_identifier" playlist item field is not set to "M2TS" in the MPLS file. Fixes #2601 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2601).
mkvmerge: fixed handling of text files that use both DOS-style and Unix-style line endings resulting in problems such as text subtitle files not being parsed correctly. Fixes #2594 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2594).


Have fun :)

[Mosu]

Which bugs are "known" other than the RDRAND bug? Does MKVToolnix actually use RDRAND?

MKVToolNix itself does not contain any assembly instructions, nor does it contain any CPU-specific or CPU-vendor-specific code. It is, of course, more than possible that at least some of the libraries used by MKVToolNix do use those instructions, especially given that MKVToolNix does communicate via HTTPS, meaning there are a lot of security-related code paths.

I don't know specifics about buggy instructions other than RDRAND, but there are tons of reports out there of bugs such as software crashing (see e.g. Destiny 2 crashing (https://hothardware.com/news/amd-ryzen-3000-zen-2-destiny-2-bungie-crash)), Windows blue-screening during boots and several board vendors releasing BIOS updates several times a week. All of that paints a picture of a rather immature hardware platform. Not really surprising, really, as AMD's hardware seems to include much more radical changes & new features than the glacial enhancements Intel seems to produce these days. I'd simply give the hardware platform some more time to mature, or be aware of the usual risks for early adopters.

[Mosu]

I tried looking thru the change logs and a search here, but didn't find anything. At what version did Windows support change to Win7, and later? Thanks.

While we're on the topic: yes, my official policy is that I only support those Windows versions that Microsoft supports for the general population (= unpaid support). So yes, this means that Windows 7 itself will soon not match this criteria anymore as its unpaid, extended support will end on January 14, 2020.

This doesn't mean that MKVToolNix will stop running on Windows 7 on that day, nor does it mean that I'll go out of my way to make MKVToolNix require newer Windows versions to run. In fact, it's quite possible MKVToolNix will continue running on Windows 7 for much longer than it used to run on XP after its end of support. But I do reserve the right to refuse to debug issues occurring on Windows 7 unless the user can show the problem happens on other supported platforms, too.

Queue the outrage in 3… 2… 1…

[Mosu]

I saw that. It doesn't say when.

That's because I don't implement intentionally that cause MKVToolNix not to run on older versions anymore. "Not supported" doesn't necessarily mean "doesn't run anymore". I just don't pay attention to unsupported OS anymore regarding my choice of things such as library versions, features used, compiler flags used etc. I often don't even realize there's a problem running on older OS until users complain.

[MrVideo]

That's because I don't implement intentionally that cause MKVToolNix not to run on older versions anymore.
I don't mean to imply that you do anything intentionally to not make it work.

[Mosu]

I don't mean to imply that you do anything intentionally to not make it work.

I hadn't understood you that way, don't worry. I just wanted to make clear that I'm not intentionally trying to piss people off :)

[MrVideo]

I just wanted to make clear that I'm not intentionally trying to piss people off :)
The only one that I get pissed off at is Adobe. For example, with the latest Premiere, one must run a certain edition of Win10, or later.

I expect software to eventually stop working, so I just use the last one that still works. In the case of Premiere, I just do not use it, instead using another party's software that still works under Win7-64.

[kuchikirukia]

Did I misclick some setting to screw up the automatic file name logic? It used to always increase in level when muxing -- i.e. xxx.mkv would mux to xxx (1).mkv which would then mux to xxx (1) (1).mkv. Now mine is all screwed up. xxx (1).mkv will mux to xxx (2).mkv, but xxx.mkv will also mux to xxx (2) if (1) is present so you can't tell what the source was anymore. I've even seen it go down a level after cleaning up some intermediate files and muxing again.

I can't tell what the latest generation top-level mux is anymore since it can be mixed in with lower level ones. How do I get the other way back?

[sneaker_ger]

There were some changes in the last versions. Which can be quite confusing. Especially since the file name can change the moment you click "Start muxing".

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

[Mosu]

Oh, that's a nice GIF showing off a bug in the logic. It happens when the number to add, "(3)", is already present at the end of the original base name. In that case too much is removed (from "m (3) (3)" down to "m" instead of "m (3)") before the GUI checks for existing files. I'll see to it that it gets fixed.

And no, I cannot simply remove any trailing number in parenthesis, as that lead to a bug where the GUI was also removing stuff like a year from the file name, e.g. it truncated "Blade (1998).mkv" to just "Blade.mkv", which is obviously not what the user expected.

[kuchikirukia]

Oh, that's a nice GIF showing off a bug in the logic. It happens when the number to add, "(3)", is already present at the end of the original base name. In that case too much is removed (from "m (3) (3)" down to "m" instead of "m (3)") before the GUI checks for existing files. I'll see to it that it gets fixed.

Does it need to remove anything? I liked the way it worked before. You had definite tiers of muxes and could trace the children back to the parent. Having movie.mkv and movie (1).mkv now both mux to movie (2).mkv means you can't tell by looking at movie (2).mkv where it came from. You could tell before because only movie.mkv would mux to movie (2).mkv while movie (1).mkv would mux to movie (1) (1).mkv.

I don't mind that I have files that end up looking like zszs (1)-002 (1) (1)-001 (8) (2)-001 (5).mkv. I can follow that.

[Asmodian]

I have to agree with kuchikirukia, even if it isn't as slick. :o

[Mosu]

Having movie.mkv and movie (1).mkv now both mux to movie (2).mkv means you can't tell by looking at movie (2).mkv where it came from.

Assuming "movie.mkv" and "movie (1).mkv" exists in the destination folder, the current, fixed algorithm will chose "movie (2).mkv" for "movie.mkv" and "movie (1) (1).mkv" for "movie (1).mkv". That "movie (2).mkv" was chosen for "movie (1).mkv" was the bug I was referring to.

[kuchikirukia]

Cool. Thanks for the fix!

[Mosu]

Due to two nasty bugs in v36 I'm releasing v37 sooner than anticipated. This release fixes both of the bugs; see below for details.

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 37.0.0 "Leave It" 2019-08-24
New features and enhancements


MKVToolNix GUI: the list of often used languages now contains those from Wikipedia's "List of languages by native speakers" by default. Also by default only those languages will be shown in the language drop-down boxes.


Bug fixes


MKVToolNix GUI: multiplexer: fixed a bug in the "make destination file names unique" logic that caused an existing number-in-parenthesis at the end of the file base name to be removed in certain situations (e.g. when the first added file was named "m (3).mkv" and both "m (3) (1).mkv" and "m (3) (2).mkv" existed already, the GUI was suddenly use "m.mkv" instead of "m (3) (3).mkv").
MKVToolNix GUI: on Windows the GUI is built with a slightly older version of the Qt library again (5.12.4). The Qt version used in release v36.0.0, v5.13.0, lead to crashes when doing certain things such as selecting multiple tracks in the multiplexer. Fixes #2605 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2605) and #26008 (https://gitlab.com/mbunkus/mkvtoolnix/issues/26008).


Have fun :)

[filler56789]

^ :thanks:

[Masutin]

WithFOR %%A IN (*.mp4) DO mkvmerge -o "%%~nA.mkv" ^
--default-duration 0:23.976fps "%%A"I change the frame rate to constant and have had a problem with only one file where mkvmerge v.10 processes 200% and the tracks merge onto themselves, the duration doubles.

[sneaker_ger]

mkvmerge v10 is not supported. We are currently at version 37.0.0. First test the latest mkvmerge version. If v37 shows the same problem show us the samples (at least MediaInfo) of input and output and the full mkvmerge log. But I suspect it is not a bug. Maybe Track with ID 0 is not 23.976 fps or maybe not even a video track. And I don't even know what "tracks merge onto themselves" means.

[mkver]

Some mp4 files use edit lists to loop the content (and some tools seem to add such edit lists even when they shouldn't). This could be such a file. Newer versions of mkvmerge contain a heuristic to detect such bogus edit lists, so this might be fixed already. As sneaker_ger said: Ancient versions are not supported.

[Masutin]

No support for older verions on Doom9 at all? 10 must be the last one for XP, I can't try a new one now. But once I've brought this up, I clarify, only the video (23.976!) is doubled (looped, 'merged onto itself'), the audio is of normal duration. The file is from mp4creator, it must add this 'edit list'. Any idea of fixing it? Nothing unusual in the log or MediaInfo report (Advanced, too).
-o "Witness (1985).mkv" --default-duration 0:23.976fps "Witness (1985).mp4"
mkvmerge v10.0.0 ('To Drown In You') 32bit
'Witness (1985).mp4': Using the demultiplexer for the format 'QuickTime/MP4'.
'Witness (1985).mp4' track 0: Using the output module for the format 'AVC/h.264'.
'Witness (1985).mp4' track 1: Using the output module for the format 'AAC'.
The file 'Witness (1985).mkv' has been opened for writing.
'Witness (1985).mp4' track 0: Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 1280/720.
Progress: 100% (the intermediate was 200%)
The cue entries (the index) are being written…
Multiplexing took 4 minutes 56 seconds.

Format : MPEG-4
Formatprofile : Base Media / Version 2
Codec Id : mp42 (mp42/isom)
File size : 564 MB
Duration (ms) : 1h 52mn
Overall bit rate mode : Variable
Overall bit rate : 703 Kbps
Encoded date : UTC 2011-09-06 21:04:43
Tagged date : UTC 2011-09-06 21:05:35
Writing application : mp4creator 1.6.1d
===================== Video =====================
Id : 1
Format : AVC
Format info : Advanced Video Codec
Formatprofile : High@L4.1
Formatsettings, CABAC : Yes
Formatsettings, ReFrames : 8 frames
Codec Id : avc1
Codec info : Advanced Video Coding
Duration (ms) : 1h 52mn
Bit rate : 664 Kbps
Width : 1 280 pixels
Height : 720 pixels
Original height : 716 pixels
Display aspect ratio : 16:9
Original display aspect rat : 16:9
Frame rate mode : Variable
Frame rate : 23.976 (23976/1000) fps
Minimum frame rate : 23.974 fps
Maximum frame rate : 23.981 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.030
Stream size : 533 MB (94%)
===================== Audio =====================
Id : 2
Format : AAC
Format info : Advanced Audio Codec
Formatprofile : HE-AAC / LC
Codec Id : 40
Duration (ms) : 1h 52mn
Bit rate mode : Variable
Bit rate : 35.0 Kbps
Maximum bit rate : 55.0 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz / 24.0 KHz
Frame rate : 23.438 fps (1024 spf)
Compression mode : Lossy
Stream size : 28.1 MB (5%)
Language : English

[sneaker_ger]

Yes, it seems mkver is right. Maybe you could use something like --split parts:-01:51:59.

Does v 37.0.0 really not support XP at all or is this just the GUI? Maybe mkvmerge (CLI) works?

[manolito]

Does v 37.0.0 really not support XP at all or is this just the GUI? Maybe mkvmerge (CLI) works?

No, it is not just the GUI. The last CLI version which works under WinXP is v29.0.0

[sneaker_ger]

In v29 the problem mentioned by mkver should already be fixed.

[KaraokeAmerica]

I just installed this on a Pi4 running Raspbian. It runs, but the version is 31.

Is that the best it gets for the Pi platform?

Yes, I understand that a Pi is not a quad-Xeon. I just like to play......;)

[Masutin]

mkvmerge 29 works on XP and fixes the problem! I was informed that mkvtoolnix 10 was the last to work on XP and never thought it worth inquiring if it applied to CLI. DE über alles!

[manolito]

Maybe my workaround package from this link is for you:
https://forum.doom9.org/showthread.php?p=1881431#post1881431

Maybe you can even help me to make it more "universal", that means working under more local Windows versions.

When you mix an older MKVToolnix GUI with newer CLI versions, Toolnix will pop up a warning. My package clicks aways this warning, but for this to work it needs a substring which is part of the warning window title. I started with "Problem" as the substring to look for, but I later changed it to "robl" because the "P" can be lowercase or uppercase depending on the language, and the "e" character is different in French (it has an accent grave).

You did not say where you come from, can you test it and tell me what the window title of this warning message is for you?


Cheers
manolito

[Mosu]

I just installed this on a Pi4 running Raspbian. It runs, but the version is 31.

Is that the best it gets for the Pi platform?

There's no limit to ARM that I know of. However, I don't provide packages for the ARM architecture as I don't use it myself. Therefore all you get is the package provided by Raspbian (= Debian) itself, and that's v31 for "buster" (https://packages.debian.org/buster/mkvtoolnix).

Feel free to compile the package yourself (https://mkvtoolnix.download/source.html#debian_ubuntu_package). I cannot tell you if a Pi4 has enough resources for that, though.

[ChaosKing]

There's no limit to ARM that I know of. However, I don't provide packages for the ARM architecture as I don't use it myself. Therefore all you get is the package provided by Raspbian (= Debian) itself, and that's v31 for "buster" (https://packages.debian.org/buster/mkvtoolnix).

Feel free to compile the package yourself (https://mkvtoolnix.download/source.html#debian_ubuntu_package). I cannot tell you if a Pi4 has enough resources for that, though.

I think flatpak has also arm support. They have at least the newest version on their page. https://flathub.org/apps/details/org.bunkus.mkvtoolnix-gui

https://flatpak.org/setup/Raspbian/

[Mosu]

Oh right, the Flatpak! I totally forgot about that. Thanks for thinking of it.

[Inviska]

Would it be okay to bundle the MKVToolNix command line tools in my Inviska MKV Extract AppImage?

It seems more people are using the MKVToolNix Snap and AppImage, which Inviska MKV Extract won't work with. After being contacted a few times asking how to get it working, I started to think it would be better to include the MKVToolNix command line tools in my AppImage, but I didn't know if this would be okay with you.

Would you have any problems with me bundling the MKVToolNix command line tools in my AppImage?

Edit: I just released a new version with the MKVToolNix command-land tools bundled in the AppImage. If this is a problem I can delete it and do another release without the tools included.

[rmlazzari]

Hello, first I apologize if this is not the right place to post beginner questions. If not, please indicate the right place.

But if my question can be answered in this topic, here it goes:

For many years I have been using MKVToolNix-gui under Windows. I also used a gui to extract .MKV files. The interface for extract, if I'm not mistaken, was not installed. I just copied .DLL and .EXE files to the same folder where MKVToolNix-gui had installed itself and created a link to .EXE on the desktop. Even so, I never clicked on the extract. I directly clicked on the .MKV file and from the context menu chose to open it with the extract.

But now I'm using Linux Mint.

I am new to Linux although I worked from 1978 until a few years ago as a COBOL mainframe computer programmer (IBM / 370, 4341 etc.). That is, all my knowledge today is obsolete, maybe useless, but maybe I can recognize a command line, for example.

Well, using the Linux Mint Application Manager (19.2), I found MKVToolNix-gui, installed it and it is working fine. But I don't know how to update it or how to install the gui for MKVExtract (or something).

I read the page at "https://mkvtoolnix.download/downloads.html#ubuntu", copied and pasted the following lines into Terminal:

1 - wget -q -O - https://mkvtoolnix.download/gpg-pub-moritzbunkus.txt | sudo apt-key add -

2 - /etc/apt/sources.list.d/mkvtoolnix.download.list

3 - deb https://mkvtoolnix.download/ubuntu/ bionic main

4 - deb-src https://mkvtoolnix.download/ubuntu/ bionic main

Only the first line worked but the others... I have the impression that "wget" is a command, that the second line is a file but I don't know what the third and fourth line are.

Anyway, to avoid bothering you, I would like you to help me upgrade MKVToolNix-gui (installed version is 19 but the program asks me to upgrade to 37) and install gMKVExtract (I think it was This is the program but I may be wrong).

As I said before, I apologize for the difficulty and although I want to know at least the basics of Linux, in this message, if you can help me just install and update the MKV programs I would be very grateful.

[qyot27]

On Ubuntu (presumably any Debian variant, but I dunno for sure), after running the wget piping command, do
sudo add-apt-repository "deb https://mkvtoolnix.download/ubuntu/ bionic main"
(or swap 'bionic' for the corresponding one Mint should be using, or just the latest one in general - if that version of Mint was based on Ubuntu 19.04, use 'disco')

Which will perform the requisite steps to add that to the sources and update the lists. This avoids having to make the user muddle around in config files.

[rmlazzari]

On Ubuntu (presumably any Debian variant, but I dunno for sure), after running the wget piping command, do
sudo add-apt-repository "deb https://mkvtoolnix.download/ubuntu/ bionic main"
(or swap 'bionic' for the corresponding one Mint should be using, or just the latest one in general - if that version of Mint was based on Ubuntu 19.04, use 'disco')

Which will perform the requisite steps to add that to the sources and update the lists. This avoids having to make the user muddle around in config files.

Thank you. I've applied your suggestion and it seem to work fine. Well... whit some issues, if you want I can copy here the messages. But when I call MKVToolNix-gui, it shows the updated version ("Leave It", 37).

And a last question: I'd like to do what I did under Windows: right-click in the .MKV file then the option to open it with gMKVExtract Gui. I did that way because in the first time I try to open a .MKV file, I choose the .EXE in a folder. Now I don't know neither where or which file I have to point to open with an extract gui.

[Mosu]

Would it be okay to bundle the MKVToolNix command line tools in my Inviska MKV Extract AppImage?

In general: when you want to include someone else's work in your own package or when you have any question about the licensing of a specific piece of software, you should really contact the authors themselves, in MKVToolNix' case: me. My email address is readily available. Posting on a forum, not waiting for a response and just going ahead without understanding the licensing implications is not the polite thing to do.

That being said: MKVToolNix is licensed under the GPLv2. This allows you to do a lot of things wit the software, including re-distributing it either on its own or as part of a larger package. The website ChooseALicense.com (https://choosealicense.com/licenses/gpl-2.0/) contains a nice & concise list of things you may do & things you must do. Here's the list of things you must do and my additional information about it:

Disclose source — if anyone asks you, in whatever way, for the source code of the version of MKVToolNix you distribute, you must make that source code available. If you do not modify MKVToolNix, it suffices to link to the official MKVToolNix download locations. However, if you do make modifications to MKVToolNix, you must make those modifications available in source code form, too.
License and copyright notice — you must include the license and the copyright notice for MKVToolNix in your package. In general you can simply include the files "COPYING" and "README.md" from MKVToolNix in your package; just rename them to make it clear that they apply to the MKVToolNix portion of your package, not to your whole package (e.g. "COPYING.MKVToolNix" and "README.MKVToolNix.md", or place all of MKVToolNix' components in a single sub-directory called "MKVToolNix" and leave the original file names unmodified). Note that your package's own documentation (README file or whatever) should (must?) include a note that your package contains another piece of software, MKVToolNix, and where to find its license & copyright information (point to the "COPYING" and "README.md" files you've included).
Same license — this only applies if you made any modification to MKVToolNix. If you do, those changes must be licensed under the GPLv2, too. Note that this does NOT apply to any other application that's part of your package — you could easly bundle an application licensed under BSD-2-clause with another application covered under a proprietary licensed together with MKVToolNix in your package! "Same license" really only applies to any changes made directly to the copy of MKVToolNix you distribute.
State changes — again, this only applies if you made changes to MKVToolNix. If you did, you must document those changes (e.g. by including a diff file in your package containing the changes made, or by pointing to a git repository that contains each of your changes as commits).

Basically it's really easy, especially if you only distribute an unmodified copy of MKVToolNix. In that case include the license & README & point to them in your package's own documentation as described in point 2, and you'll be good to go.

[Mosu]

Only the first line worked but the others... I have the impression that "wget" is a command, that the second line is a file but I don't know what the third and fourth line are.

Welcome to Linux :) I suggest you read up on a couple of newbie guides. There are a ton of them out there, and they can really benefit new users.

Now: you're correct that "wget" is a command. It's used to download files from the internet. In this case, the whole command downloads a file from my web server with "wget" and feeds the file directly to a second command, "apt-key". What's downloaded is the GPG key that's used to cryptographically sign the locations where you will later download MKVToolNix from. That GPG key is fed to "apt-key", which installs that key as a trusted key for this type of operation (downloading & installing software from locations that are signed with that key).

The second line is indeed the name of a file which you must create. Lines three & four are the content you should place in said file. That file will configure the location where to download MKVToolNix from. That location is the one that's signed with the GPG key downloaded in step 1.

What qtyo27 posted is an alternative to creating that file manually. It runs another command, "add-apt-repository", which will create that file for you if it doesn't exist already and add the location information to it. It's slightly easier to use, but not available everywhere, which is why I'm not mentioning it on my web site.

And a last question: I'd like to do what I did under Windows: right-click in the .MKV file then the option to open it with gMKVExtract Gui.

That's something that has nothing to do with MKVToolNix. In fact, it has everything to do with the desktop environment you're using (on Linux there are tons of different desktop environments out there, unlike Windows where there's basically only one: Window's own). You should ask such a question on one of Linux Mint's forums. You'll likely have much better luck getting an answer there than here (e.g. I cannot answer your question as (1) I don't know which desktop environment Linux Mint uses by default as there are two or three possibilities and (2) even if I did, I only know how to do it in KDE/Plasma, and that's definitely not what Linux Mint is using).