MKVToolNix v99.0 released

[Mosu]

In the last continuous build 38.0.0-revision-028, how can I disable the dark theme?? the new GUI is mess up, I'm using windows 7 x86

Oops, the dark theme was only supposed to be enabled if Windows' own color mode is set to dark. This check was buggy; it even enabled dark mode on Windows versions that don't actually support a color mode setting (anything before Windows 10 1809). I've just fixed that check. New continuous builds will be available in a couple of hours.

[Mosu]

Sort of an odd request, but when setting mkvtoolnix to split by chapters, would it be possible to have a period as a valid separator along with the comma?

I'm not going to add something like that, sorry. It would be confusing (why only there? Why that particular character? why is "," not enough, it works everywhere else?), and it would be a one-person-feature, something I'm really not keen to add.

[Mosu]

@Mosu
My point is, if MKVToolNix started using "font/" suddenly, there could be a lot of confusion.

That's definitely a good point. Announcing such a change in advance is indeed a good idea, something I've done in the past with other changes as well (e.g. the deprecation & later removal of options such as the verbose identification mode). It isn't something I'm willing to work on right now, though I'll probably revisit the topic early next year.

[filler56789]

Oops, the dark theme was only supposed to be enabled if Windows' own color mode is set to dark. This check was buggy; it even enabled dark mode on Windows versions that don't actually support a color mode setting (anything before Windows 10 1809). I've just fixed that check. New continuous builds will be available in a couple of hours.

Just tested v38-029 and confirmed that now it works as expected :)

:thanks:

[mood]

Oops, the dark theme was only supposed to be enabled if Windows' own color mode is set to dark. This check was buggy; it even enabled dark mode on Windows versions that don't actually support a color mode setting (anything before Windows 10 1809). I've just fixed that check. New continuous builds will be available in a couple of hours.

oki thanks Mosu :)

[Liisachan]

That's definitely a good point. Announcing such a change in advance is indeed a good idea, something I've done in the past with other changes as well (e.g. the deprecation & later removal of options such as the verbose identification mode). It isn't something I'm willing to work on right now, though I'll probably revisit the topic early next year.
Thanks for taking this seriously & sorry about the fuss. It's nothing urgent, really. What I'm worrying about is, what's happening like 10 years later. The offical FAQ (https://matroska.org/technical/guides/faq/index.html#q7) says: "Q: Will my .mkv files be compatible with future Matroska software if i will use current tools to mux my files? A: The files being created now are spec compliant." That sort of things.
It would be reassuring if in the future, there is a little footnote to FileMimeType in the specs, saying e.g. "For historical reasons please treat (a list of MIMEs) as 'font/sfnt'."

Also, I still think it would be more intuitive if the menu item "Show job queue" is renamed to "Show job queue/log" when "Error(s)" on the statusbar is right-clicked.

Another thing I always find counter-intutive about GUI is this. If you open a source file e.g. vorbis.ogg, and just try to close the GUI, it says...

Close modified file
-------------------
The file "vorbis.mka" has been modified. Do you really want to close?
[Close file] [Cancel]

From the user's point of view, "vorbis.mka" doesn't even exist, and it's not clear what the GUI "has modified" or what it wants to "close". If you [Close file], not the "modified file" but the GUI itself will close. I find this a bit illogical. I think what it wants to say is something like this:

Unsaved project
------------------
Unsaved changes to a job to write "vorbis.mka". Exit anyway?
[Yes] [Cancel]

This happens to me, e.g. when I use the GUI to generate a prototype command line, copy it to the clipboard, and quickly close the GUI without muxing.

Finally, I've noticed that MKVToolNix automatically imports a cover art in several cases, e.g. from FLAC, but not from MP4 (moov.udta.meta).

Perhaps none of the above are important (at least nothing is urgent). Perhaps some of them are known limitations or by design. Reporting them anyway just in case. Feel free to ignore them :) and thanks again for your hard work :D

[Mosu]

Also, I still think it would be more intuitive if the menu item "Show job queue" is renamed to "Show job queue/log" when "Error(s)" on the statusbar is right-clicked.

I've just changed that to "Show job queue & access job logs".

From the user's point of view, "vorbis.mka" doesn't even exist, and it's not clear what the GUI "has modified" or what it wants to "close". If you [Close file], not the "modified file" but the GUI itself will close. I find this a bit illogical. I think what it wants to say is something like this:

I partially agree. I've changed the wording to make it clear that the program is asking about changed multiplex settings that would create a certain file.

I disagree about changing the wording to "exiting" the program. The thing is that the question applies both when you quit the program & when you close the current tab. In fact, quitting the program will first close all open tabs, and that's when the question is asked. It is asked for all tabs that have been modified (in the multiplexer, chapter editor & header editor). So labeling the button with "exit program" would be somewhat strange if one of the following tabs was modified, too; the question would again be asked for that tab, and the program would not have been quit yet. I'll leave the wording for the button as "close …".

Finally, I've noticed that MKVToolNix automatically imports a cover art in several cases, e.g. from FLAC, but not from MP4 (moov.udta.meta).

Yeah, it's not been on my radar yet. I'll look into implementing support for it.

Edit: gosh I wish Doom9 still had working email notifications…

[Liisachan]

I disagree about changing the wording to "exiting" the program. The thing is that the question applies both when you quit the program & when you close the current tab. In fact, quitting the program will first close all open tabs, and that's when the question is asked. It is asked for all tabs that have been modified (in the multiplexer, chapter editor & header editor). So labeling the button with "exit program" would be somewhat strange if one of the following tabs was modified, too; the question would again be asked for that tab, and the program would not have been quit yet. I'll leave the wording for the button as "close …".
Okay, that makes sense. I'm guessing everything looks cool in the original language (German), and changing text even a bit is actually a lot of work, since it'll have to be re-translated to many user-interface languages. Please don't overthink about my random observations... Take it easy & thanks again :)

[Mosu]

Good evening everyone. Here's a nice fresh release of MKVToolNix for y'all: v39.

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 39.0.0 "In The Waiting Line" 2019-11-04
New features and enhancements

mkvmerge: Blu-ray: when reading an MPLS playlist mkvmerge will look up and use chapter names from the Blu-ray's "track/chapter names" meta data if it exists. Part of the implementation of 2486.
mkvmerge: MP4 reader: if present, cover art images (the "meta.udta.ilist.covr" atom) will be converted into attachments.
MKVToolNix GUI: multiplexer: when adding a playlist from a Blu-ray disc, the disc library meta data will be parsed, and the biggest thumbnail, if present, will be added as a new attachment with name "cover.jpg" (extension depends on thumbnail's extension). Implements #2644 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2644).
MKVToolNix GUI: multiplexer: when adding a playlist from a Blu-ray disc, the title from the disc library meta data will be set as the new file title if the disc library meta data contains one & no title has been set yet.
MKVToolNix GUI: multiplexer: the automatically generated destination file name will now be based on the file title if one is set at that point. This works in conjunction with the title being said from the Blu-ray disc library meta data.
MKVToolNix GUI: chapter editor: when reading chapters from an MPLS playlist the GUI will look up and use chapter names from the Blu-ray's "track/chapter names" meta data if it exists. Part of the implementation of 2486.
MKVToolNix GUI: Windows: added a dark mode that's enabled when Windows 10's dark mode is turned on.
translations: added a Bulgarian translation of the programs & the man pages by Симеон Цветков (see "AUTHORS").

Bug fixes


mkvmerge: attachments without a file name won't be ignored anymore. Part of the fix of #2642 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2642).
MKVToolNix GUI: header editor: attachments with an empty name element will be shown as "<unnamed>" as originally intended. Part of the fix of #2642 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2642).
Linux AppImage: the AppImage will no longer change directories before running the desired executable allow the use of relative file names. Fixes #2632 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2632).

Build system changes


MKVToolNix now requires a C++ compiler that supports the following features of the C++17 standard: ""[[maybe_unused]]" attribute", "nested namespace definition", "structured bindings". For the GNU Compiler Collection (gcc) this means v7 or newer; for clang it means v4 or newer.
Boost 1.60.0 or newer is now required.


Have fun :)

[hubblec4]

Thank you for your work all the time.

[DMD]

I congratulate the developers of the 39.00 release, the dark blue graphic appearance is very welcome and restful.
Thanks :thanks:

[Liisachan]

@Mosu
Thanks a lot! Tested MP4 cover art support: it works fine, even supporting 2 or more cover arts flawlessly. Very cool :) Also, thanks for text tweaking.
Really appreciated.

Just so you know (not your problem!): While testing, I noticed that foobar2000 (tested v1.5 beta20) writes cover art(s), under certain conditions, in a non-standard position of MP4 (moov.udta.tags.cvrx). I think you can ignore such wild cover art(s). Compared with older version, fb2k is now trying to use moov.udta.meta more, but it still uses moov.udta.tags at least sometimes.

EDIT
changelog typos?
"meta.udta" -> "udta.meta"
"ilist" -> "ilst"

[Mosu]

Thanks a lot! Tested MP4 cover art support: it works fine, even supporting 2 or more cover arts flawlessly. Very cool :)

Good to hear. The only files I had available for testing were ones with a single cover art picture each; therefore I couldn't test that.

changelog typos?
"meta.udta" -> "udta.meta"
"ilist" -> "ilst"

Yeah, typos. I'll fix them. Thanks.

[Liisachan]

Good to hear. The only files I had available for testing were ones with a single cover art picture each; therefore I couldn't test that.

Thanks :) but small bad news: MPC-like players (including the latest MPC-BE) and LAV recognize a cover art in BMP too, iff the atom flag is 0x1b (undocumented value?).

I don't think there are many MP4s with BMP cover arts, but such images are somehow widely supported anyway (MPC, LAV, foobar2000). Currently MKVToolNix treats such a BMP as cover.jpg (image/jpeg) when it's actually BMP, which is obviously not good.

Maybe the right thing to do is, treat a cover as jpeg if 0x0d, as a png if 0x0e, otherwise just ignore a cover image as unrecognizable. Of course you could support non-standard (?) BMP covers if you'd like to... or you can just ignore this problem as such a file is perhaps actually rare.

Here's a sample clip (http://faireal.net/image/2019/3covers.mp4) - no video, silent audio + 3 cover arts in PNG/JPG and BMP. When e.g. MPC-HC (clsid2) plays this clip, it even shows the BMP image like a static video, as it's the 1st cover art.

EDIT
1. It seems that mp4 parsers tend to ignore this atom flag, and instead read the first 4 bytes of the image data to see if it's JPEG or PNG.
2. FYI: foobar2000 (audio player for Windows) also accepts BMP and GIF (not only JPEG and PNG) in its "Import picture file" dialog box. As such, an MP4 file written by foobar2000 is generally broken (not standard-compliant) in more than one aspect.

[redbtn]

Something weird happens. When I mux 7.1 channel opus file into MKV, it seems like some metadata is lost.
It doesn't have Channel layout anymore (mediainfo shows only L channel, I think WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0X6 is lost) and information about encoder, maybe something else.
And after demuxing opus from MKV, files are not the same. They looks very different in hex editor. Is it normal? I'm asking because any other formats like flac, dts, ac3 etc exactly the same after mux>demux.

[tormento]

Is it possible to have the light theme back? I find the dark theme too dark.

[Mosu]

Thanks :) but small bad news: MPC-like players (including the latest MPC-BE) and LAV recognize a cover art in BMP too, iff the atom flag is 0x1b (undocumented value?).

Thanks, I'll add BMP handling & skipping cover art with unsupported type fields (instead of treating them as JPEG).

[Mosu]

Is it possible to have the light theme back? I find the dark theme too dark.

See here (https://gitlab.com/mbunkus/mkvtoolnix/issues/2646).

[Mosu]

Something weird happens. When I mux 7.1 channel opus file into MKV, it seems like some metadata is lost.
It doesn't have Channel layout anymore (mediainfo shows only L channel, I think WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0X6 is lost) and information about encoder, maybe something else.

I don't know how channel layout is stored off the top of my head. I'll have to investigate. Please upload one such Opus file (from before muxing it!) to my file server (https://gitlab.com/mbunkus/mkvtoolnix/wikis/FTP-server) or somewhere else I can get to. Thanks.

And after demuxing opus from MKV, files are not the same. They looks very different in hex editor. Is it normal? I'm asking because any other formats like flac, dts, ac3 etc exactly the same after mux>demux.

That is normal as Opus is extracted into the Ogg container format (same as Vorbis, but unlike the other formats you've listed which do not require a container around them). That process is lossy, e.g. the stream's serial number is chosen randomly during extraction.

[redbtn]

I don't know how channel layout is stored off the top of my head. I'll have to investigate. Please upload one such Opus file (from before muxing it!) to my file server (https://gitlab.com/mbunkus/mkvtoolnix/wikis/FTP-server) or somewhere else I can get to. Thanks.
Done. File named "opus-512.opus"

Original

Channel(s)_Original : 8
Channel(s)_Original : 8 channels
Channel positions : Front: L C R, Side: L R, Back: L R, LFE
ChannelPositions_Original : Front: L C R, Side: L R, Rear: L R, LFE
Channel positions : 3/2/2.1
ChannelPositions_Original : 3/2/3 ( i dont know why, cuz original flac before convert to opus was 3/2/2.1 )
Channel layout : L R C LFE Lb Rb Ls Rs


After muxing

Channel(s) : 8
Channel(s) : 8 channels
Channel positions : Front: L C R, Side: L R, Rear: L R, LFE
Channel positions : 3/2/3
Channel layout : L

[Mosu]

Ah right; the source file stores information such as the the encoder used or the channel layout in Vorbis comment packets (what other containers call "tags"). mkvmerge doesn't support converting Vorbis comments to Matroska tags and back at the moment. I might work on that some day. If you want me to, please open an issue over on GitLab (https://gitlab.com/mbunkus/mkvtoolnix/issues/); otherwise chances are I'll forget about it again.

[redbtn]

Ah right; the source file stores information such as the the encoder used or the channel layout in Vorbis comment packets (what other containers call "tags"). mkvmerge doesn't support converting Vorbis comments to Matroska tags and back at the moment. I might work on that some day. If you want me to, please open an issue over on GitLab (https://gitlab.com/mbunkus/mkvtoolnix/issues/); otherwise chances are I'll forget about it again.Thank you very much for the explanation. I'll open an issue on github. Will the file without this information be played correctly?

[Mosu]

That I cannot answer.

[john33]

The channel mapping info is contained in the opus header and, by default, is the same as for vorbis files. It would be reasonable to expect any self-respecting decoder/player to map the output correctly but clearly there are no guarantees. ;)

[Abs62]

When I set .mkv file as source, v39.0.0 GUI make destination filename from "Title" field instead of source filename as in previous versions. How to return old behaviour?

[Mosu]

When I set .mkv file as source, v39.0.0 GUI make destination filename from "Title" field instead of source filename as in previous versions. How to return old behaviour?

See this issue (https://gitlab.com/mbunkus/mkvtoolnix/issues/2648).

[Mosu]

The channel mapping info is contained in the opus header and, by default, is the same as for vorbis files. It would be reasonable to expect any self-respecting decoder/player to map the output correctly but clearly there are no guarantees. ;)

Yeah. Even when I'll implement converting Vorbis comments to Matroska tags, I will likely not keep any tags regarding channel mapping for Opus files as the format itself specifies the channel mapping.

[Mosu]

Hey y'all,

there's been quite a lot of feedback on the changes in v39, and due to it I decided to make two of the new features configurable: the dark mode for Windows & deriving the file name from the file title. Combine that with an easy-to-trigger regression in the MP4 handling in v39, and I've decided to get a new release out sooner rather than later. So here it is, v40.0.0 is out.

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 40.0.0 "Old Town Road + Pony" 2019-11-09
New features and enhancements

mkvmerge: MP4 reader: added support for BMP covert art images.
MKVToolNix GUI: multiplexer: added an option to disable deriving the destination file name from the file title. Implements #2648 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2648).
MKVToolNix GUI: multiplexer: the content of the "stereoscopy" combo box has been simplified making the box's minimum width much smaller, allowing the user to resize the GUI's whole window to a much smaller width.
MKVToolNix GUI: multiplexer: whenever the user changes the "aspect ratio" or "display dimensions" controls, the corresponding radio button will be activated automatically. Implements #2651 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2651).
MKVToolNix GUI: Windows: added a setting in the preferences to disable the GUI's dark color mode even if Windows's app color mode is set to dark. Implements #2646 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2646).
MKVToolNix GUI: Windows: replaced the dark mode introduced in v39 with another dark mode that's less wasteful with space between widgets.

Bug fixes


mkvmerge: MP4 reader: mkvmerge was reading eight bytes too many for cover art images. This could cause file identification to fail when the cover art was located at the end of the MP4 file. Even if it succeeded, this meant too much data present in the attachment. Fixes #2650 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2650).
mkvmerge: MP4 reader: covert art images with unknown image types will be skipped instead of treated as JPEG images.

Build system changes


Qt 5.9.0 or newer is now required for building MKVToolNix GUI.


Have fun :)

[sneaker_ger]

Something weird happens. When I mux 7.1 channel opus file into MKV, it seems like some metadata is lost.
It doesn't have Channel layout anymore (mediainfo shows only L channel, I think WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0X6 is lost) and information about encoder, maybe something else.
I get this even when encoding from 7.1 wav to 7.1 opus via OpusEnc directly (no MKVToolNix involved). Are we certain it is an MKVToolNix and not e.g. a MediaInfo issue?

General
Complete name : source.wav
Format : Wave
File size : 3.66 MiB
Duration : 5 s 0 ms
Overall bit rate mode : Constant
Overall bit rate : 6 144 kb/s
Writing application : Lavf58.33.100

Audio
Format : PCM
Format settings : Little / Signed
Codec ID : 00000001-0000-0010-8000-00AA00389B71
Duration : 5 s 0 ms
Bit rate mode : Constant
Bit rate : 6 144 kb/s
Channel(s) : 8 channels
Channel layout : L R C LFE Lb Rb Ls Rs
Sampling rate : 48.0 kHz
Bit depth : 16 bits
Stream size : 3.66 MiB (100%)

General
Complete name : encode.opus
Format : Ogg
File size : 76.2 KiB
Duration : 5 s 7 ms
Overall bit rate : 125 kb/s
Writing application : opusenc from opus-tools 0.2-3-gf5f571b

Audio
ID : 10181 (0x27C5)
Format : Opus
Duration : 5 s 7 ms
Channel(s) : 8 channels
Channel layout : L
Sampling rate : 48.0 kHz
Compression mode : Lossy
Writing library : libopus 1.3-26-ge85ed772, libopusenc 0.2.1-2-g9cb17c6


https://www.sendspace.com/file/3x7564

[redbtn]

It's not MediaInfo issue cuz I can see (in hex editor) WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0X6 in source opus file and I can't see it in file after mux>demux. But since opus has only one Channel Layout for 7.1, I think it's not a big problem for decoder. But, I'll open an issue later, maybe it will be possible to save this information in MKV down the road.
Ps: I downloaded your wav file, and it was made by ffmpeg. FFmpeg doesn't save WAVEFORMATEXTENSIBLE_CHANNEL_MASK at all. You can check it, make flac (or another format) from source like TrueHD in eac3to and in ffmpeg and compare.

[Mosu]

There's no use for a channel configuration indication if the format's specification explicitly says what the channel configuration for a given number of channels must be. All it does is confuse users (and developers).

[redbtn]

I was worried about the differences in the opus files before and after mux>demux. But I investigated it deeper and I found differences in headers of every frame, all other information the same. And if I convert these files to flac they are identical. So, all works perfectly. I take my hat off to Mosu

[Liisachan]

Thanks Mosu. I can verify the mp4 cover art 8-byte bug in 39 and fix in 40 (also BMP cover art support).

Something cosmetic - the GUI is no more fully DPI-aware on Windows (at least on Win7) starting from around version 25, when the default window size is initially calculated. The [Start multiplexing] button etc. are not visible when GUI opens the first time, if the DPI is higher than 96.
The image below shows the GUI versions 20 (left) and 40, on Windows 7, when 120 dpi is used.

http://faireal.net/image/2019/mmg120dpi.jpg (http://faireal.net/image/2019/mmg120dpi.png)
Click to enlarge

EDIT
Verified: Jpeg/Png/BMP image in MP4 -> imported to MKV attachments bit-identically
Verified: Unrecognizable artwork in MP4 -> ignored ok
(FYI) MPC/LAV recognize Jpeg/PNG even if their flags are wrong/unrecognizable (not sure how this actually helps, but kind of impressive)
Question: Is libmpagic reliable? The registered media type of BMP seems to be image/bmp (https://www.iana.org/assignments/media-types/media-types.xhtml#image), but the GUI automatically uses image/x-ms-bmp. This lib used strange font mime types in the past too. MPC shows a BMP cover art in MP4 correctly as "image/bmp".

[SeeMoreDigital]

Something cosmetic - the GUI is no more fully DPI-aware on Windows (at least on Win7) starting from around version 25, when the default window size is initially calculated. The [Start multiplexing] button etc. are not visible when GUI opens the first time, if the DPI is higher than 96.
The image below shows the GUI versions 20 (left) and 40, on Windows 7, when 120 dpi is used.

I can confirm much the same behaviour with Windows 10. I've been meaning to mention it :o

[Atak_Snajpera]

I've just noticed that mkvtoolnix-gui.exe can't be compressed by upx without --force switch. This is first time I had to use that option on executable. I wonder what is so unusual in that executable?
https://i.postimg.cc/fLTS7nKD/Capture.png

[filler56789]

I've just noticed that mkvtoolnix-gui.exe can't be compressed by upx without --force switch. This is first time I had to use that option on executable.
https://i.postimg.cc/fLTS7nKD/Capture.png

I confirm that, it's been happening since various revisions ago... I never reported it though because I thought it was not an actual issue...

I wonder what is so unusual in that executable?

Good question :confused:

[Mosu]

Something cosmetic - the GUI is no more fully DPI-aware on Windows (at least on Win7) starting from around version 25, when the default window size is initially calculated.

Ugh, I hate high DPI shit. It's really, really hard getting good information how one is supposed to make all of it work correctly, including the user-defined UI scaling thingy in Windows, _and_ how to make it all work in a cross-platform way.

I will likely have to look into it again sometime in the future, but it's really one of my least favorite areas to work on. So don't expect any miracles.

On top of that note that I won't spend time on Windows 7 specific issues anymore as Windows 7 nears even the end of its extended support period (2020-01-14). No, this doesn't mean the GUI will magically stop working on W7 on that date. Yes, I did read that a Windows 10 user complained about the same thing one post after yours, and I will look into the high DPI issue, but I will only do so on W10, and if a fix works on W10 but not on W7, then it'll likely stay unfixed for W7.

Question: Is libmpagic reliable? The registered media type of BMP seems to be image/bmp (https://www.iana.org/assignments/media-types/media-types.xhtml#image), but the GUI automatically uses image/x-ms-bmp.

I… honestly don't know. The "file" project (where libmagic comes from) is _the_ default content type recognition library on all Open Source systems; it's used in thousands of commercial/proprietary products, too. Maybe it's a backwards-compatibility thing?

Regarding MIME types for attachments from MP4 files: I don't use libmagic for them, actually, I simply use ones depending on the numeric object type present in the MP4 file. As "file --mime-type somefile.bmp" said "image/x-ms-bmp", that's what I hardcoded. I'll change it to "image/bmp".

[Mosu]

I've just noticed that mkvtoolnix-gui.exe can't be compressed by upx without --force switch. This is first time I had to use that option on executable. I wonder what is so unusual in that executable?

I really have no idea. I've never used upx, I definitely don't purposefully do anything to make upx's life harder.

[manolito]

On top of that note that I won't spend time on Windows 7 specific issues anymore as Windows 7 nears even the end of its extended support period (2020-01-14). No, this doesn't mean the GUI will magically stop working on W7 on that date. Yes, I did read that a Windows 10 user complained about the same thing one post after yours, and I will look into the high DPI issue, but I will only do so on W10, and if a fix works on W10 but not on W7, then it'll likely stay unfixed for W7.


I think that it is a shame that developers like you show so little regard to the privacy concerns of so many users and government authorities (German conference of "Datenschutzbeauftragte"). Here is a link from Heise which is only a few days old:
https://www.heise.de/newsticker/meldung/Datenschutzkonferenz-Hohe-Huerden-fuer-den-Einsatz-von-Windows-10-4584678.html

For me Win10 is evil, I will never use it, and I am not the only one. It may make life a little easier for devs, but this is not enough to justify your decision to ignore Win7 compatibility in the near future.

Cheers
manolito

[Liisachan]

Ugh, I hate high DPI shit. It's really, really hard getting good information how one is supposed to make all of it work correctly, including the user-defined UI scaling thingy in Windows, _and_ how to make it all work in a cross-platform way.

I don't know how difficult it would be to make it cross-platform. If it were just for Windows, things would be rather trivial; e.g. when you create a logical font, you can multiply the font size by 96.0 / GetDeviceCaps( hDC, LOGPIXELSY ) and round the result to int, after that, functions like GetTextExtentPoint32 return the correct width and height of the text area in pixels, so you can place static text / GUI parts accordingly.

On top of that note that I won't spend time on Windows 7 specific issues anymore as Windows 7 nears even the end of its extended support period (2020-01-14). No, this doesn't mean the GUI will magically stop working on W7 on that date. Yes, I did read that a Windows 10 user complained about the same thing one post after yours, and I will look into the high DPI issue, but I will only do so on W10, and if a fix works on W10 but not on W7, then it'll likely stay unfixed for W7.

Fine with me :)
Many Windows programs don't work so well for me anyway. I have the taskbar thing at the top of my desktop, not at the bottom; a stupid program (including some tool created by Microsoft itself) always places its main window at y=0 of the desktop (below the task bar), so I can't even use its menu with mouse unless I move the window to a lower position using keyboard only. Compared with this, the problem of MKVToolNix GUI is very minor (I can just resize the main window a bit with mouse, and then that window size will be automatically used the next time).

That said, I think many people use larger and “dense” monitors these days, and higher-dpi settings are used more and more frequently. Although the problem is cosmetic and nothing urgent, I don't think it's W7-specific.

As for MIME types, since Matroska is a multimedia container where the MIME types are sometimes critically important, imho it would be safer if you manually hard-code some important MIME types (like you did for fonts). Even if libmagic is the de facto standard in the world, Matroska has its own internal (de facto) standard for historical reasons, widely supported in the multimedia world. This is mostly about font MIME types, and I know I'm paranoid; as a typesetter, the recent font mime-type related problem (fonts not loaded) was a bit traumatic, though the MIME type of BMP itself is not very important. Thanks again! :)

EDIT:
One can get the height of Windows GUI part this way:
Caption : GetSystemMetrics( SM_CYCAPTION )
Border : GetSystemMetrics( SM_CYSIZEFRAME )
Menu : GetSystemMetrics( SM_CYMENU ) or via GetMenuBarInfo (there may be a 1-pixel difference)
Statusbar : empirically (height of Caption) - 2, more reliably via GetWindowRect with hwndStatusbar

But like you said, the "theme" thing may confuse things even more...

[Liisachan]

For me Win10 is evil, I will never use it, and I am not the only one. It may make life a little easier for devs, but this is not enough to justify your decision to ignore Win7 compatibility in the near future.

I feel the pretty much the same way about Win10 itself, but the problem here is just cosmetic. We know we're going to have a lot of problems soon. You're going to protect yourself, not depending on security patches by Windows Update (actually I disabled Windows Update itself many years ago, in the services.msc level). While it would be great if many devs try to keep supporting Win7 in the future, maybe that won't happen so we're going to have to deal with minor conveniences by ourselves. The way I see it #1 problem of Win10 is forced updates (you don't own your windows; Windows own you... like in Soviet Russia). From what I gathered, the privacy issues of Win10 can be fixed relatively easily (there are many tools for that too). Anyway, let's be strong. You're not alone.

[stax76]

I think traditional QT isn't High DPI independent like QT Quick or WPF.

[Mosu]

I think that it is a shame that developers like you show so little regard…

This is the same discussion when I dropped support for XP. And I'm just as unsympathetic to your arguments. No one is forcing you to do anything, least of all using Windows 10. Looks like I have to re-iterate a couple of points about Open Source software in general and MKVToolNix in particular:

This is Open Source software. You get the source code. You can do anything you want with it. Don't like that XYZ doesn't work on Windows 7? Well, you get all the source to fix problems yourself or get someone else to fix them for you.
Just because I'm offering a program doesn't mean I'm under any obligation to make it suit your particular use case.
You don't even have to keep using Windows. MKVToolNix is a cross-platform product, and I've been offering (and will continue to) binaries for various Linux distributions as well as macOS. Switching from W7 doesn't mean you must switch to W10.
The best way to protect your privacy is not staying with an unsupported, proprietary operating system, but switching to an updated, free one instead. Like Linux. Or one of the BSDs. If privacy were really that important to you, you'd chose that route. But I'd wager you won't, which only means that privacy is either just a pretext for not liking Windows 10, or you're just angry that I don't value your personal level of privacy concerns the same as you.
You get something for free here. I don't owe you anything, and I'm 100% free to chose what I spend my time on.

[ChaosKing]

I think traditional QT isn't High DPI independent like QT Quick or WPF.

It seems high dpi scaling is also supports for legacy apps

Qt 5.6 supports cross-platform high-DPI scaling for legacy applications, similar to the scaling done natively in macOS. This allows applications written for low DPI screens to run unchanged on high DPI devices. This feature is opt-in, and can be enabled using the following environment variables:
QT_AUTO_SCREEN_SCALE_FACTOR
QT_SCALE_FACTOR
QT_SCREEN_SCALE_FACTORS
Source https://doc.qt.io/qt-5/highdpi.html

By default, Qt applications are set to Per-Monitor DPI Aware on Windows 8.1 or System-DPI Aware on older Windows versions.
Maybe this is why it is not scaling on win7?

[stax76]

The best way to protect your privacy is not staying with an unsupported, proprietary operating system, but switching to an updated, free one instead. Like Linux. Or one of the BSDs. If privacy were really that important to you, you'd chose that route. But I'd wager you won't, which only means that privacy is either just a pretext for not liking Windows 10, or you're just angry that I don't value your personal level of privacy concerns the same as you.

The way I see it is Linux technically is not on par with Windows, example one is no browser supports hw acceleration making YouTube unusable for people with 4K/UHD display. I can use mpv to watch YourTube but very often I want to use Chrome.

Second example is PowerShell which I as .NET programmer consider far superior to bash, everything .NET including PowerShell runs fine on Linux but there is still an ideology problem on Linux against Microsoft even though MS nowadays does much for Open Source, much more than Apple I believe and also even Torvalds made a statement that this kind of thinking does not help. If I remember correctly than you left github the time around when it was acquired by Microsoft.

[manolito]

This is the same discussion when I dropped support for XP.

Yeah, history repeating itself... :devil:

But there is one big difference this time. This time you are pushing your users towards using an Operating System (I am talking about Win10, IMO not many users consider Win8 or 8.1 as a viable alternative) which neither corporate users nor government agencies or other public organizations can legally use in Germany. And probably not in the whole European Union because the privacy laws come from the EU.

Did you even read the Heise artikel I linked to?
https://www.heise.de/newsticker/meldung/Datenschutzkonferenz-Hohe-Huerden-fuer-den-Einsatz-von-Windows-10-4584678.html

One of the key statements of this article:
Verschiedene Untersuchungen zeigten, dass es aktuell nicht möglich sei, die Übertragung insbesondere von Telemetrie-Daten "durch Konfiguration von Windows10 vollständig zu unterbinden.

Several research showed that it is actually impossible to completely disable the transfer especially of telemetry data by configuring Win10.

Since you have your own company you should be familiar with the DSGVO. This law makes it illegal for anyone whose business involves working with personal data of others to transfer such personal data to a third party without explicit consent of the persons who give their personal data to a European company. And transferring such data into a country like the US where no comparable privacy laws exist is completely forbidden.

And Win10 does just this.

[Mosu]

Again, I'm _not_ pushing you to use Windows 10. I would if I only offered a Windows 10 version of MKVToolNix. But I don't. I actually offer it for quite a range of operating systems.

And my philosophy is really easy: if the vendor doesn't support it anymore, I don't either. Unsupported software & unpatched machines are quite a problem on the internet (not just Windows, mind you, pretty much all IoT devices fall under this category as to wide swaths of home routers/modems).

So don't try playing the "W10 bad, W7 good" card; I completely reject that premise as it's a very selective view on a rather complex matter.

[Mosu]

It seems high dpi scaling is also supports for legacy apps

I'm well aware of Qt's documentation regarding high DPI settings. MKVToolNix is using the settings there (Qt::AA_EnableHighDpiScaling). However, that leads to interesting results, especially with the 125% scaling mode in Windows.

In general it works more or less.

What I haven't turned on yet is using proper high-density pixmaps for icons, mostly because I haven't figured out how to make the tool selector's icons behave properly (size calculation, drawing high-density pixmaps properly so they're scaled accordingly).

Certainly not impossible but rather time-consuming.

And the only high DPI monitor I have is connected to my Windows machine. That's all fine, but it makes testing with Linux hard & with macOS (this is just a VM) impossible. Hence me not liking having to work on this particular feature :)

[Liisachan]

@Mosu
Speaking of privacy... In MKVToolNix GUI, the "Check online for available updates" option is enabled by default. There are many such tools today, but good old tools tend to ask, "Do you want to automatically check updates...?" before phoning home for the first time. Yes, the right thing for me to do would be compiling my own version the way I like. I know that.

@manolito
Don't worry too much.
(1) Mosu explicitly said: “No, this doesn't mean the GUI will magically stop working on W7 on that date.” It's not like W7 support will be intentionally terminated.
(2) We're free to keep using an old OS; similarly we're free to keep using an old version of MKVToolNix forever. Not using the latest version too soon (i.e. using the same old version for a while) is actually a good idea for most (including Win10) users, so you can avoid accidental regressions and tacit compatibility-breaking changes, and make sure you have your MKV files consistent.
(3) Even if GUI becomes incompatible in the future, it's probably easy (if not trivial) to maintain Win7 compatible fork privately, as long as mkvmerge runs on Win7.


The best way to protect your privacy is not staying with an unsupported, proprietary operating system, but switching to an updated, free one instead. Like Linux. Or one of the BSDs. If privacy were really that important to you, you'd chose that route. But I'd wager you won't, which only means that privacy is either just a pretext for not liking Windows 10, or you're just angry that I don't value your personal level of privacy concerns the same as you. Don't bet on it :) I've been thinking that this might be a great opportunity (blessing in disguise) for me to finally migrate to Linux. I don't even like Win7 itself. My friend told me that the easiest way to migrate to Linux is Win10 + WSL. So I might actually get Win10 to learn how to use Linux (kind of ironic).

X : potential security/privacy risks by keeping using Win7
Y : immediate privacy issues and daily annoyance by using Win10
Many somehow assume X > Y. While X > Y might be true for naive users (e.g. if you use Google on Win7, you're already in a worse world than Win10), if you're careful, my gut feeling is X < Y at least for the time being. Sorry OT.

[Mosu]

@Mosu
Speaking of privacy... In MKVToolNix GUI, the "Check online for available updates" option is enabled by default. There are many such tools today, but good old tools tend to ask, "Do you want to automatically check updates...?" before phoning home for the first time.

Yeah, sure, I could ask that question. But I don't care all that much for one simple reason: the update check transmits & reveals less information about the user than what they reveal when visiting the MKVToolNix web site with a regular browser as Qt's network library only transmits a very limited set of headers. Here's the full request:

GET /latest-release.xml.gz HTTP/1.1
Host: mkvtoolnix.download
Connection: Keep-Alive
Accept-Encoding: gzip, deflate
Accept-Language: en-US,*
User-Agent: Mozilla/5.0

The same request will be made for "/releases.xml" for populating the list of changes.

Other things to consider:

The only person having access to the server and all of its data is me (apart from the people having physical access in the data center, of course, but then again that's true with all data centers).
I only log truncated portions of the source IP address: IPv4 addresses are truncated to their /24 network, IPv6 addresses to /56.
I only store logs for five days.
I do not ever share log files with anyone else.

I'm not opposed to having that question asked and would accept patches/merge requests that implement such functionality.