MKVToolNix v99.0 released

[Mosu]

2/ When transmuxing MKV to MKV: let's say "foo.ttf" is attached to source MKV - then if one tries to manually add "foo.ttf" (redundantly, so to speak, hoping "overriding" the existing attachment), GUI silently fails to add "foo.ttf" without any error/warning messages. This further confuses an inexperienced GUI user, as to how they can update the font mime type.

Preferences → "Multiplexer" → "Always skip while attaching new files when attachment with same name exists"

Disable that option and the GUI'll ask you (or your friend) what to do in such a case.

[shae]

MKV is so flexible that it's sometimes counter-intuitive and confusing: you may find it strange that MKV doesn't support "plain old CFR" in general.

I don't mean I necessarily expect MKV to be PTS-less. But in term of muxing, it makes sense to have a simple option that effectively recreates or overrides, and does behind the scenes what's suitable for plain CFR. I assume that's what people use in 99% of the cases.

I don't know if such an option exists, but based on what you said, I guess it does not.

BTW, the source file with frame 0 not at 0 PTS was the result of cutting in Avidemux. I have no idea why it would create such a thing.

[Liisachan]

How do I add a ClearSans.ttf to an existing mkv that will be used as subtitle when playing in a mediaplayer lik PotPlayer, MPC-HC or VLC?
I have tried but no subs show up in either player. MPC-HC, MPC-BE should be able to do that playback-time, assuming that the font you want to use is installed and available by OS.

1) Open your MKV file like you watch it normally.
2) &Play -> Su&btitle Track -> &Styles
3) You can change font(s) etc.

Or, if it's not SSA/ASS, you can try: &View -> &Options -> Subtitles -> Default Style.

If you want to modify the MKV file itself so that new fonts may be used permanently, then you'll have to re-create your MKV files. Doing this is not difficult (at least for typesetters) but not trivial. That is, you don't need to re-encode but you need to re-mux it, after slightly editing your SSA/ASS. You can first demux ASS then open it with a text editor, and edit a line that looks like this:


[V4+ Styles]
...
Style: sampleStyle1,fontName,30,...


Change fontName. It's a font-family name (not a font-file name) supposed to be used for the lines with sampleStyle1. 30 is the font size. When done, remux your updated ASS file.
Like Mosu said, this process is not something directly related to MKVToolNix. Information about "suggested" font faces is in the source file (SSA/ASS), which mkvmerge will simply copy without doing anything special (e.g. it doesn't verify that the font is actually usable as an attachment). Enjoy subbing :)

[Liisachan]

But in term of muxing, it makes sense to have a simple option that effectively recreates or overrides, and does behind the scenes what's suitable for plain CFR.
True. One surely hopes `--default-duration 0:24000/1001p` would do that seemingly simple job.
Currently, if for some reason timestamps are messed up, then the easiest and foolproof way to fix & set frame timestamps exactly as you like seems to be using timestamps.txt explicitly. Otherwise, sometimes it's impossible to fix timestamps even with `--fix-bitstream-timing-information`.

[filler56789]

"The procedure entry point CreateEventA could not be located in the dynamic link library api-ms-win-core-synch-l1-2-0.dll."

source: mkvtoolnix-64-bit-66.0.0-revision-004-g068687405,
operating system = 64-bit Windows 7.

EDIT: mkvtoolnix-64-bit-64.0.0-revision-045-g5ab2bd424 is the last good one, apparently.

EDIT 2:

I don't support Windows 7 anymore.

okay :-/

EDIT 3:

From https://mkvtoolnix.download/doc/NEWS.md :

Version 59.0.0 "Shining Star" 2021-07-10

.......

## Build system changes

The Qt library is now required for building all applications,
even the command-line ones,
as they use Qt's MIME type detection capabilities.
In turn this means that you cannot disable the Qt usage anymore; either Qt5 or
Qt 6 is required.

Now I understand why the file "magic.mgc" suddenly is not required anymore.
Anyway, that was a very-bad idea && move,
at least for all the users of Windows 7, surely.

[varekai]

Matroska...
Thanks for the info, appreciate it!

[varekai]

MPC-HC, MPC-BE...
Thanks for info, appreciate it, will do some testing aka trial&error!

[filler56789]

"No multiplex job has been opened yet."

Is there a way to disable that, let's say, ``splash screen´´?

[Mosu]

"No multiplex job has been opened yet."

Is there a way to disable that, let's say, ``splash screen´´?

I don't understand. That's only shown when no settings are currently open, and the GUI actually starts with one open, therefore you'll only see that message if you actively close the last open settings. It's not a splash screen.

If you want something along the lines of "always open new, fresh settings when I close the last open one", then the answer is no.

[Mosu]

@Mosu
1/ My friend is confused, and is complaining about this behavior: Even if "Use legacy MIME types for font attachments" is checked in GUI, it transmuxes the font files attached in existing MKV (without updating MIME types) to a newly written MKV, even without any warning.

I've taken the time over the last two days to implement this: both mkvmerge & mkvpropedit now have a new option called "--enable-legacy-font-mime-types" which will cause the same MIME type mapping that was previously only used in the GUI to be applied to both newly added attachments as well as existing ones (read from Matroska or SSA/ASS files). The GUI adds the option automatically if there are any attachments to be dealt with.

[filler56789]

I don't understand. That's only shown when no settings are currently open, and the GUI actually starts with one open, therefore you'll only see that message if you actively close the last open settings. It's not a splash screen.

If you want something along the lines of "always open new, fresh settings when I close the last open one", then the answer is no.

Thanks for answering. The fact is, before upgrading to version 64, I was using version 45, and I had never seen that kind of message until today. :–|

[Mosu]

Thanks for answering. The fact is, before upgrading to version 64, I was using version 45, and I had never seen that kind of message until today. :–|

The message has been there right from the start, certainly in v45. You simply never closed the last open settings tab, it seems.

[Liisachan]

I've taken the time over the last two days to implement this: both mkvmerge & mkvpropedit now have a new option called "--enable-legacy-font-mime-types" which will cause the same MIME type mapping that was previously only used in the GUI to be applied to both newly added attachments as well as existing ones (read from Matroska or SSA/ASS files). The GUI adds the option automatically if there are any attachments to be dealt with. Thank you very much. By "from SSA/ASS", you mean it also reads that old uuencode (?) font data embedded in SSA/ASS itself?

I'm somehow lucky I can use 66.0 on my Windows 7, but I'm getting the same error described by filler56789 now, with 66.0.0.18. Because of this, I can't personally test it and perhaps I won't be able to comment much on newer versions from now on. Well, I have Linux that runs from a thumb drive, so I might test MKVToolNix there, though. My friend who complained will be surely happier nevertheless.

One potential problem is, some users can be sometimes idiots from your point of view. They may enable "Use legacy" just before hit "Start Multiplexing" thinking "Oh yeah, I'd like to use legacy Mime, so I'll check it before multiplexing." Not before selecting the attached files. :)

As for the other issue: The main problem is, "Always skip while attaching new files..." is enabled by default. So you can't really blame the user saying "This is happening because YOU enabled it" can you? I'd question this default.

The secondary problem is: Let's say I'm attaching "./video/debug.log" as Name "video-debug.log" and then also attaching "./audio/debug.log" as Name "audio-debug.log". There are no name-space collisions in the resulted MKV; the 2 source files are different, having different paths; & the first file is explicitly named as "video-debug.log". Even then, if warning is enabled, there will be a warning: "Name debug.log is already present". This may not be ideal, although not really a problem for me, as I don't use GUI too often.

Thanks for your work anyway. I'd like to re-emphasize that the font-mime mess is no one's fault. "Higher-ups" suddenly (re)defined the font mime types ~10 years after the de facto standard for MKV had been well established, supported by many players & tools. The breaking change occurred well above Matroska devs or Matroska users. Who'd have imagined that "editing the mime type of an attachment" will be such a daily job - be it updating to use font/ or be it 'downgrading' to application/x- to be old-player-friendly. :(

[Mosu]

Thank you very much. By "from SSA/ASS", you mean it also reads that old uuencode (?) font data embedded in SSA/ASS itself?

That, yeah.

One potential problem is, some users can be sometimes idiots from your point of view. They may enable "Use legacy" just before hit "Start Multiplexing" thinking "Oh yeah, I'd like to use legacy Mime, so I'll check it before multiplexing." Not before selecting the attached files. :)

Yeah well, I cannot prevent users from doing dumb things, and there's no such thing as a foolproof software 😁

As for the other issue: The main problem is, "Always skip while attaching new files..." is enabled by default. So you can't really blame the user saying "This is happening because YOU enabled it" can you? I'd question this default.

Huh… I don't remember why I made it enabled by default, to be honest. At the moment I agree that the default should be off, and I'll change it accordingly.

The secondary problem is: …

With the warning enabled you'll still be able to add any file, no matter how many naming collisions there are. That should suffice for those cases.

[Atak_Snajpera]

How to convert minimum_timestamp value to audio delay in ms?

"codec": "AAC",
"id": 1,
"properties": {
"audio_channels": 2,
"audio_sampling_frequency": 22050,
"codec_id": "A_AAC",
"codec_private_data": "139056e5a0",
"codec_private_length": 5,
"default_duration": 46439909,
"default_track": false,
"enabled_track": true,
"forced_track": false,
"language": "eng",
"language_ietf": "en",
"minimum_timestamp": 2234000000,
"number": 2,
"track_name": "HE-AAC 50-70",
"uid": 1982383230
},
"type": "audio"

[Mosu]

The minimum timestamp is in ns. And "audio delay" is basically the difference of the audio track's minimum timestamp & the video track's timestamp. Meaning:

audio delay in ms = (audio track's minimum timestamp - video track's minimum timestamp) / 1000000

[Atak_Snajpera]

The minimum timestamp is in ns. And "audio delay" is basically the difference of the audio track's minimum timestamp & the video track's timestamp. Meaning:

audio delay in ms = (audio track's minimum timestamp - video track's minimum timestamp) / 1000000

Ok. Thank you.

[tebasuna51]

Making test about a problem, detected by StainlessS with PCM multichannel stored like A_MS/ACM in mkv's generated by MakeMKV, I read mkv docs about that codec ID. Link to the problem.https://forum.doom9.org/showthread.php?p=1966364#post1966364
I read also the related post in this thread https://forum.doom9.org/showthread.php?p=1949976#post1949976
And the pending enhancement about ADPCM codec https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2757

In my test:

- mkvmerge ignore and mkvtoolnixGUI reject WAV files with: unsupported container format (RIFF WAVE wfortmatTag 0x000X)
Rejected:
wfortmatTag 0x0002 ADPCM MS 2 channels 4 bits
wfortmatTag 0x0006 ADPCM A-Law CCITT 2 channels 8 bits
wfortmatTag 0x0007 ADPCM U-Law CCITT 2 channels 8 bits
wfortmatTag 0x0011 ADPCM Intel 2 channels 4 bits
wfortmatTag 0x0031 GSM 6.10 Microsoft 1 channel
Accepted:
wfortmatTag 1 PCM INT like Codec ID A_PCM/INT/LIT
wfortmatTag 3 PCM Float IEEE like Codec ID A_PCM/FLOAT/IEEE

- ffmpeg can mux and demux in/from mkv's all of them using the Codec ID A_MS/ACM for wfortmatTag <> 1 or 3
mpchc (LAV filters) seems play without problems these mkv's.

- mkvextract
Error: Extraction of track ID 1 with the CodecID 'A_PCM/FLOAT/IEEE' is not supported.
Error: Extraction of track ID 1 with the CodecID 'A_MS/ACM' is not supported.

- when mkvmerge or ffmpeg mux a multichannel wav PCM INT with WAVE_FORMAT_EXTENSIBLE header always use Codec ID A_PCM/INT/LIT, and the ChannelMask is lost.
I only know MakeMKV and the old AVI-Mux GUI than create mkv's using CodecID 'A_MS/ACM' for multichannel wav's. Like must be to play correctly the file.
mpchc (LAV filters) seems play without problems these mkv's.

There are any problem to use 'A_MS/ACM' by mkvmerge/extract when is needed?
The 'fmt' subchunk of wav/w64 (http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/WAVE.html) files can be stored in Codec Private data when merge, and recovered when extract and all seems ok.

[Mosu]

The reason PCM data isn't well supported is that no one cares enough about it to put in the work. Will likely never improve substantially.

[filler56789]

Making test about a problem, detected by StainlessS with PCM multichannel stored like A_MS/ACM in mkv's generated by MakeMKV, I read mkv docs about that codec ID. Link to the problem.https://forum.doom9.org/showthread.php?p=1966364#post1966364
I read also the related post in this thread https://forum.doom9.org/showthread.php?p=1949976#post1949976
And the pending enhancement about ADPCM codec https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2757

In my test:

- mkvmerge ignore and mkvtoolnixGUI reject WAV files with: unsupported container format (RIFF WAVE wfortmatTag 0x000X)
Rejected:
wfortmatTag 0x0002 ADPCM MS 2 channels 4 bits
wfortmatTag 0x0006 ADPCM A-Law CCITT 2 channels 8 bits
wfortmatTag 0x0007 ADPCM U-Law CCITT 2 channels 8 bits
wfortmatTag 0x0011 ADPCM Intel 2 channels 4 bits
wfortmatTag 0x0031 GSM 6.10 Microsoft 1 channel
Accepted:
wfortmatTag 1 PCM INT like Codec ID A_PCM/INT/LIT
wfortmatTag 3 PCM Float IEEE like Codec ID A_PCM/FLOAT/IEEE

- ffmpeg can mux and demux in/from mkv's all of them using the Codec ID A_MS/ACM for wfortmatTag <> 1 or 3
mpchc (LAV filters) seems play without problems these mkv's.

- mkvextract
Error: Extraction of track ID 1 with the CodecID 'A_PCM/FLOAT/IEEE' is not supported.
Error: Extraction of track ID 1 with the CodecID 'A_MS/ACM' is not supported.

- when mkvmerge or ffmpeg mux a multichannel wav PCM INT with WAVE_FORMAT_EXTENSIBLE header always use Codec ID A_PCM/INT/LIT, and the ChannelMask is lost.
I only know MakeMKV and the old AVI-Mux GUI than create mkv's using CodecID 'A_MS/ACM' for multichannel wav's. Like must be to play correctly the file.
mpchc (LAV filters) seems play without problems these mkv's.

There are any problem to use 'A_MS/ACM' by mkvmerge/extract when is needed?
The 'fmt' subchunk of wav/w64 (http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/WAVE.html) files can be stored in Codec Private data when merge, and recovered when extract and all seems ok.

:goodpost: and :thanks:
Specially for mentioning the olde and goode AVI-Mux GUI.
Now I've finally found a way to put ATRAC3plus and ATRAC9 audio into the Matroska container. :) :sly:

The reason PCM data isn't well supported is that no one cares enough about it to put in the work.

It seems the actual problem is not "PCM data", but the lack of support for the WAVE_FORMAT_EXTENSIBLE feature in both mkvmerge and ffmpeg's Matroska muxer.

[filler56789]

source: https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2757

Let me rephrase, I'll look into outputting this type of audio as A_MS/ACM, but chances are your player doesn't support that one either.

For the notes, or FWIW....

LAV Filters have no problems with ATRAC3plus and ATRAC9 in both .MKV and .AVI,
whereas mpv plays correctly only the .AVI format.
Also, MPC-BE's internal filters (AVI splitter, Matroska splitter and the generic audio decoder) haven't been updated yet.

[Mosu]

No, the actual problem is that the Matroska format simply doesn't have native elements for the channel mapping & various codec IDs for various elements. WAVE_FORMAT_EXTENSIBLE is a foreign data structure we don't simply want to import into Matroska; we want to use native elements. Yes, there's the A_MS/ACM workaround, but I simply don't want to go down that road. I don't really want to do the specs work for the other parts either, mind you…

[filler56789]

No, the actual problem is that the Matroska format simply doesn't have native elements for the channel mapping & various codec IDs for various elements. WAVE_FORMAT_EXTENSIBLE is a foreign data structure we don't simply want to import into Matroska; we want to use native elements. Yes, there's the A_MS/ACM workaround, but I simply don't want to go down that road. I don't really want to do the specs work for the other parts either, mind you…

Well, that suxxx terribly :(

Yes, there's the A_MS/ACM workaround, but I simply don't want to go down that road.

However you (and/or other possible Matroska developers) saw no problem in forcing "V_MS/VfW" onto VC-1 and MPEG4-ASP...

[nevcairiel]

MPEG4-ASP...

You know, these are a thing right?

V_MPEG4/ISO/ASP
V_MPEG4/ISO/AP
V_MPEG4/ISO/SP

[Mosu]

Well, that suxxx terribly :(

And yet it doesn't seem to suck enough for you to do something about it by doing the specs work, does it? See, that's the thing with Open Source software. You could actually do something about it, but you chose not to, which is perfectly fine. But then again you don't get to complain that others make the same choice of not doing anything about it.

However you (and/or other possible Matroska developers) saw no problem in forcing "V_MS/VfW" onto VC-1 and MPEG4-ASP...

V_MS/VFW was done right at the start of Matroska development, back when we all (and myself most of all) know a whole lot less about coding in general, good container design in particular and good practices to round it all up. It was the easy way to achieve quick success, especially wrt. integration into existing players. I would most likely chose differently today.

[derf]

One notable thing that changed is that mkvmerge now maps the "enabled" track header flag from MP4 file's "tkhd" atom to Matroska's "track enabled" flag. So maybe those tracks were disabled in the source MP4 files already. You can override those flags in the GUI, of course; that's one of the reason I added the "disabled track flag" combobox in the first place.

If that isn't it, report the issue to the MPC-HC bug tracker, please.

I finally got around with v66 to taking the time to check what's happening. Effectively, the audio tracks were marked as disabled, but were still present. Changing the audio tracks to enabled corrects the issue. Now I'm looking in the options to check if all audio tracks can be set to enabled by default.

Thanks for the great software.

[filler56789]

OVERDUE/BELATED REPLY:

However you (and/or other possible Matroska developers) saw no problem in forcing "V_MS/VfW" onto VC-1 and MPEG4-ASP...

You know, these are a thing right?

V_MPEG4/ISO/ASP
V_MPEG4/ISO/AP
V_MPEG4/ISO/SP
That's 100% true for ffmpeg, but only 50% (or less) true for mkvmerge, because

1) mkvmerge doesn't use "V_MPEG4/ISO/*" for DivX /Xvid unless you call the "--engage native_mpeg4" option;
2) at least if you're using the mkvtoolnix GUI, "--engage native_mpeg4" only takes effect after you close and restart the application. :-/

-----
P.S.: end of discussion.

[filler56789]

Reporting a design-flaw...
When trying to remux an MKV which contains an ATRAC9 stream,
MKVtoolnix "thinks" it is Vorbis(!) audio :eek:
Evidently the GUI.exe should say "format unsupported" and act accordingly,
because when I pressed the "Start multiplexing" button, the application returned no warnings, no errors,
and no new file as well. :confused:

https://forum.videohelp.com/attachments/64062-1648657324/mkvtoolnix-FLAW.png

P.S.: For the notes, here is what MediaInfo detects:
Audio
ID : 2
Format : Atrac9
Format/Info : Adaptive Transform Acoustic Coding 9
Codec ID : A_MS/ACM / FFFE / 47E142D2-36BA-4D8D-88FC-61654F8C836C
Duration : 1 min 12 s
Bit rate : 120 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Compression mode : Lossy
Stream size : 1.04 MiB (5%)
Language : English
Default : Yes
Forced : No

Most people think the WAVE_FORMAT_EXTENSIBLE thing is for multichannel uncompressed audio only, but in fact it also can replace the use of a TwoCC with a GUID number.

[Mosu]

Thanks, but I don't really care and will not spend time on improving A_MS/ACM support.

[tebasuna51]

That's 100% true for ffmpeg, but only 50% (or less) true for mkvmerge, because...

@nevcairiel and filler56789

Maybe ffmpeg can solve that audio problem also: ffmpeg ticket (https://trac.ffmpeg.org/ticket/9703)

[Aleksoid1978]

Reporting a design-flaw...
When trying to remux an MKV which contains an ATRAC9 stream...

Can you upload mkv+ATRAC9 sample for me ?

[filler56789]

Can you upload mkv+ATRAC9 sample for me ?

Done. ↓ ↓

https://www.mediafire.com/file/veqcsrux9jwt6hh/GQ-ACSW-01-intro.mkv/file

[filler56789]

Thanks, but I don't really care and will not spend time on improving A_MS/ACM support.

You should have written "improving LACK OF a_ms/acm support". :D

I know, you're too busy even for writing appropriate error-handling code. ;)

[Mosu]

Heyo!

Here's a new release of MKVToolNix. Quite a lot of work has gone into this release, vastly improving the support for BCP 47 language tags. While a lot of you won't see much of a difference, the support has vastly improved for a lot of Asian languages, both adding new features such as canoncalization, as well as fixing bugs, e.g. not allowing certain variants with certain languages even though they do make total sense together.

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 67.0.0 "Under Stars" 2022-04-10
New features and enhancements

all: IETF BCP 47/RFC 5646 language tags: when deriving the legacy language element codes to use a language tag's ISO 639 code is also potentially interpreted as an & its prefix is used as the legacy language code. For example, "Yue Chinese" = "yue" is not part of ISO 639-2. However, there is an extlang subtag "yue" with a valid prefix of "zh" ("Chinese"), and for "Chinese" there is an ISO 639-2 language code: "chi". In this example the IETF language element would be set to "yue" and the corresponding legacy element to "chi". Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
all: IETF BCP 47/RFC 5646 language tags: grandfathered language tags are now supported. Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
all: IETF BCP 47/RFC 5646 language tags: all deprecated subtags from the IANA language subtag registry are now supported. Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
all: IETF BCP 47/RFC 5646 language tags: all lists of valid subtags have been updated from their respective authoritative sources. Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
all: IETF BCP 47/RFC 5646 language tags: all in the IANA language subtag registry are now supported, even those marked as deprecated and of type 'grandfathered'. Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
all: IETF BCP 47/RFC 5646 language tags: reduced the maximum number of extended language subtags that are present in a valid tag from 3 to 1 in compliance with RFC 5646 section 2.2.2. Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
all: IETF BCP 47/RFC 5646 language tags: all language codes reserved for private/local use ("qaa"–"qtz") are now supported. Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
all: IETF BCP 47/RFC 5646 language tags: Digital Cinema Naming Convention language codes that fall into the IETF BCP 47 range of "private use" tags ("qaa"–"qtz") are now replaced by their IETF BCP 47 equivalents during normalization (e.g. "QMS" → "cmn-Hans"). Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
all: added a new translation to Chinese Simplified (Singapore) by Dian Li.
mkvmerge, mkvpropedit: added a new command line option called "--enable-legacy-font-mime-types". With this option on the two programs will use the same legacy MIME types for fonts whenever new attachments are added (both programs), when reading existing attachments (only "mkvmerge") or when replacing existing ones (only "mkvpropedit").
mkvmerge, mkvpropedit: IETF BCP 47/RFC 5646 language tags: added a command line option "--normalize-language-ietf &lt;mode>" which turns on normalization of IETF BCP 47 language tags to either their canonical (mode "canonical") or extended language subtags form (mode "extlang") or turns it off (mode "off"). If the option isn't given, language tags will now be normalized to the canonical form. Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
MKVToolNix GUI: IETF BCP 47/RFC 5646 language tags: ISO 639-3 and 639-5 languages will now be used by default. Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
MKVToolNix GUI: IETF BCP 47/RFC 5646 language tags: the language editor dialog will now show warnings in several cases: when deprecated tags are used; when the tag's canonical and/or extlang forms differ from the user input. Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
MKVToolNix GUI: IETF BCP 47/RFC 5646 language tags: the language editor now has a button to replace the current tag with a normalized form (canonical or extlang) if those differ from the current tag. Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
MKVToolNix GUI: IETF BCP 47/RFC 5646 language tags: added an option in the preferences to always normalize all language tags to their canonical or extlang forms or to turn normalization off. Can also be enabled from the language editor dialog. Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
MKVToolNix GUI: IETF BCP 47/RFC 5646 language tags: the language dialog now shows a warning if a variant is used with a prefix that isn't in the variant's list of suitable prefixes. It'll also say if the corresponding canonical/extlang forms would have a suitable prefix. Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
MKVToolNix GUI: IETF BCP 47/RFC 5646 language tags: the language dialog now shows a warning if a script is used with a language for which it should be suppressed. Part of the implementation of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
MKVToolNix GUI: multiplexer: the track property group boxes in the scrollable pane are now collapsible & expandable, saving their state over restarts of the GUI. This is in preparation of adding many more track properties in future releases, allowing the user to hide parts they don't use all that often.
MKVToolNix GUI: multiplexer: if the option "use legacy font MIME types" is enabled in the preferences, the new command line option "--enable-legacy-font-mime-types" will be passed to "mkvmerge" in order to have it remap the MIME types of existing attachments, too.

Bug fixes

all: IETF BCP 47/RFC 5646 language tags: variants aren't validated wrt. to prefixes anymore as BCP 47 doesn't actually pose restrictions on them, saying only that prefixes "are suitable sequences" for use with the variants. What is now verified, though, is that no variant is used multiple times within the same language tag. Part of the implementation/fix of #3307 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3307).
build system & MKVToolNix GUI: fixed detecting the presence of & the compilation with the multimedia module of Qt version 6.2.0 and newer.
build system: fixed compilation on Unices other than Linux & macOS (e.g. FreeBSD). Fixes #3316 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3316).
MKVToolNix GUI: job queue: fixed compiling in the audio player code for the the "play audio" end-of-job action. Fixes #3303 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3303).
MKVToolNix GUI: multiplexer: recognizing added XML chapter, segment info or chapter files required the XML declaration & root node (e.g. "&lt;?xml…?> … &lt;Chapters>" for chapters) be located within the first 1 KB, which wasn't enough for files that contain a lot of comments at the start like the included "example-chapters-2.xml". The detection range was extended to 10 KB. Fixes #3302 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3302).

Build system changes

build system: the provided Windows binaries are now compiled with Qt 6. A drawback is that certain audio formats aren't supported anymore by Qt for the "end of job" sound notification playback, notably the Ogg file format & the Vorbis audio codec. MKVToolNix therefore now ships Opus-in-WebM files for the same purpose.
The bundled "fmt" library was updated to v8.1.1.
The bundled "nlohmann-json" library was updated to v3.10.5.
The bundled "pugixml" library was updated to v1.12.1.


Have fun 😁

[VBB]

Big thank you, as always!

[hubblec4]

Hi Mosu

When I start MTXgui, I get this error:
"Der Prozedureeinsprungspunkt 'CreateDXGIFactory2' wurde in der DLL 'dxgi.dll' nicht gefunden"

I guess it's the end of Win7 support?

[Mosu]

I haven't supported Windows 7 for quite a while now. If prior versions still ran on it, it was unintentional & lucky. It's likely that Qt 6 uses stuff that isn't available on Windows 7 as that was the only change between 66 & 67 that could affect OS-level compatibility.

[filler56789]

I guess it's the end of Win7 support?

Surely.
MKVtoolnix does not need to always use the "latest and greatest" :rolleyes: :rolleyes: :rolleyes: QT thing for the GUI.
And at least the command-line applications of the suite should not require QT at all.

The problem of course is to convince Mosu that he is wrong.

[lvqcl]

I'd say that the problem is to explain to some users that Mosu doesn't owe them anything.

[Snowknight26]

Looks like a bug caused by the transition to Qt 6 is the fact that the main MKVToolNix GUI window always opens on display 1, even if it was previously opened/closed on display 2 (assuming display 1 is to the left of display 2). Additionally, opening any context menus while the UI is on display 2 causes them to open on display 1.

Using a setup that consists of 2x 2560x1440 monitors (desktop resolution basically 5120x1440), when opening the GUI, it seems to always clamp the window position values to 2560x1440, even if the last location was was something like x=3000, y=700 (for the top-left pixel of the UI). Same with context menus.

Example screenshot:

After opening and dragging the GUI to monitor 2:
https://www.stfcc.org/pics/i/0f8986b0fae3e7db1aa10fa80be6c90a_th.png (https://www.stfcc.org/pics/i/0f8986b0fae3e7db1aa10fa80be6c90a.png)

After closing and reopening the GUI:
https://www.stfcc.org/pics/i/a1f7f6d4a754461af15df0aa50c68460_th.png (https://www.stfcc.org/pics/i/a1f7f6d4a754461af15df0aa50c68460.png)

After moving the GUI to monitor 2 and clicking the first menu. Notice the context menu on monitor 1:
https://www.stfcc.org/pics/i/0f8986b0fae3e7db1aa10fa80be6c90a_th.png (https://www.stfcc.org/pics/i/0f8986b0fae3e7db1aa10fa80be6c90a.png)

[clsid]

Possible solution to get rid of the CreateDXGIFactory2 dependency:
https://forum.qt.io/topic/78380/entry-point-not-found-the-procedure-entry-point-createdxgifactory2-could-not-be-located-in-the-dynamic-link-library-dxgi-dll

[Mosu]

Looks like a bug caused by the transition to Qt 6 is the fact that the main MKVToolNix GUI window always opens on display 1, even if it was previously opened/closed on display 2 (assuming display 1 is to the left of display 2). Additionally, opening any context menus while the UI is on display 2 causes them to open on display 1.

Yeah, I've already received a similar report via email, I'll likely create a Qt5-based pre-build soonish for everyone to use & will switch back to Qt5 for the next release(s). I do run a multi-monitor setup myself, but I was lucky in that the display the GUI runs well on is my main display — and I simply forgot to test the other one.

[Mosu]

Looks like a bug caused by the transition to Qt 6 is the fact that the main MKVToolNix GUI window always opens on display 1, even if it was previously opened/closed on display 2 (assuming display 1 is to the left of display 2). Additionally, opening any context menus while the UI is on display 2 causes them to open on display 1.

The latest continuous builds (https://mkvtoolnix.download/windows/continuous/64-bit/67.0.0/) are done with Qt 5 again. Please give them a try.

[Liisachan]

The latest continuous builds (https://mkvtoolnix.download/windows/continuous/64-bit/67.0.0/) are done with Qt 5 again. Please give them a try.

I can start 67.0.0.1 on Win7 !
Thanks for taking time for backward compatibilities.
Also, a lot of work related to lang tags seems impressive.

[Mosu]

I can start 67.0.0.1 on Win7 !
Thanks for taking time for backward compatibilities.
Also, a lot of work related to lang tags seems impressive.

Just to be perfectly clear: going back to Qt 5 has nothing to do with Windows 7. It's solely due to the multi-monitor issues. Once those have been solved in newer versions of Qt 6, I will go back to Qt 6. Windows 7 is not support, won't be supported, and MKVToolNix will cease to run on it.

[manolito]

Just asking for a clarification:

Which is the last MKVToolNix version which runs without issues under Win7 ? I'm not asking for official Win7 support, I just want to know which version is the last one without any known Win7 problems. I have no intention to upgrade Windows to a later version than Win7, so I just want to know which MKVToolnix version will become my last version.

The thing I already did for Win XP some years ago was combining an older GUI version with a newer main executable which worked for a couple of versions. Would it be possible to do the same thing for Win7 ?


Cheers
manolito

[StainlessS]

I just want to know which version is the last one without any known Win7 problems. I have no intention to upgrade Windows to a later version than Win7, so I just want to know which MKVToolnix version will become my last version.

+1 on that.

EDIT: thanks filler56789 :)

[Snowknight26]

The latest continuous builds (https://mkvtoolnix.download/windows/continuous/64-bit/67.0.0/) are done with Qt 5 again. Please give them a try.

That did the trick, thanks.

[filler56789]

Just asking for a clarification:

Which is the last MKVToolNix version which runs without issues under Win7 ?

Answer:


EDIT: mkvtoolnix-64-bit-64.0.0-revision-045-g5ab2bd424 is the last good one, apparently.

[filler56789]

I'd say that the problem is to explain to some users that Mosu doesn't owe them anything.

Evidently your point-of-view is absolutely non-technical and therefore not of much relevance.