MKVToolNix v83.0 released

[Mosu]

Originally Posted by mood

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]

Originally Posted by kuchikirukia

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]

Originally Posted by Liisachan

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

Originally Posted by Mosu

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

[mood]

Originally Posted by Mosu

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]

Originally Posted by Mosu

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

[Mosu]

Originally Posted by Liisachan

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

Originally Posted by Liisachan

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

Originally Posted by Liisachan

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]

Originally Posted by Mosu

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, the Windows installer/portable version & macOS DMG & Linux AppImage and the source code.

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 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.
• 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.
• MKVToolNix GUI: header editor: attachments with an empty name element will be shown as "<unnamed>" as originally intended. Part of the fix of #2642.
• Linux AppImage: the AppImage will no longer change directories before running the desired executable allow the use of relative file names. Fixes #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

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

Originally Posted by Liisachan

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.

Originally Posted by Liisachan

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

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

[Liisachan]

Originally Posted by Mosu

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

Originally Posted by Liisachan

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]

Originally Posted by tormento

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

See here.

[Mosu]

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

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 or somewhere else I can get to. Thanks.

Originally Posted by redbtn

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]

Originally Posted by Mosu

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