MKVToolNix v99.0 released

[Anakunda]

This reorder doesn't make any difference. I think there should be used something stronger than --no-chapters which suppresses any atomization.

[mkver]

Yes, it can. But this would involve writing code specifically for it and mkvmerge doesn't seem to have this code.
The --no-chapters option is actually an input file option, not an output file option, i.e. it discards chapters already in your input file, but leaves chapters that you explicitly add during the muxing process (e.g. by using a chapters file) alone. In this case this means that any chapters in your w64 file (there aren't any and I don't believe that w64 is able to contain chapters anyway) would be discarded.
I'll open an issue for the real problem (that PCM is not split sample-accurately, but only block-accurately), but I don't think that he will fix this. After all, this just affects PCM.

[hubblec4]

Hi Mosu

I want replace an attachment with mkvpropedit.

"mkvpropedit.exe" "S01E00 - Hauptmenü.mkv" --replace-attachment name:"Matroska Medium Menu Config.mmmcfg"


I get always this error message

>"mkvpropedit.exe" "S01E00 - Hauptmenü.mkv" --replace-attachment name:"Matroska Medium Menu Config.mmmcfg"
Error: Invalid selector in '--replace-attachment name:Matroska Medium Menu Config.mmmcfg'.


What I'm doing wrong?
When I use the ID to replace an attachment, this works.

"mkvpropedit.exe" "S01E00 - Hauptmenü.mkv" --replace-attachment 1:"Matroska Medium Menu Config.mmmcfg"

[Mosu]

The `--replace-attachment` option requires a selector and the name of the file to use instead. Both are separated by a colon.

In the case of `1:Matroska…` the selector is the 1 and the `Matroska…` is the file name. So far, so good.

When you type `name:Matroska…` the selector itself is just `name` and the new file name is `Matroska…`. However, `name` on its own is not a valid selector: it requires a colon and the name of the existing file to replace, meaning the full option would actually contain two colons:

--replace-attachment "name:old name:new file name"

[hubblec4]

Thanks for this info, and maybe you should add this example to your mkvpropedit page (selectors (https://mkvtoolnix.download/doc/mkvpropedit.html#mkvpropedit.edit_selectors)).

[hubblec4]

And for the MIME-type you have to use also 2 colons?

--replace-attachment "mime-type:mime-type-name:new file name"

[Mosu]

Thanks for this info, and maybe you should add this example to your mkvpropedit page (selectors (https://mkvtoolnix.download/doc/mkvpropedit.html#mkvpropedit.edit_selectors)).

There is just such an example in the Examples (https://mkvtoolnix.download/doc/mkvpropedit.html#mkvpropedit.examples) section.

And for the MIME-type you have to use also 2 colons?

Yes.

[hubblec4]

Hi Mosu

I have some trouble with mkvpropedit.exe. I would add Tags,Chapters and Attachments in one go to a very small mkv file.
All works fine when no chapters,tags and attachments are present in the mkv file. But when I repeat the same cmd the Tags are not present but there is a seek entry with a position value which is greater as the entire file.
When I change the size of tags and chapters(add tags and chapters) and use again the same cmd, then no chapters and no tags in the mkv file.

Here is a sample (https://forum.videohelp.com/attachments/47003-1540222580/mkvpropedit.7z) with two mkvpropedit.bat files. (maybe you have to change the path for mkvpropedit)

EDIT:
It seems mkvpropedit is OK, but the InfoTool in the GUI shows it not correct

[mkver]

The relocation of level 1 elements to the end (if there is not enough space in front of the video clusters) is nothing new and I'm surprised that you didn't know about it. But now you seem to do. But I can't see what's supposed to be wrong with the InfoTool in the GUI. You should open an issue if you think that there is something wrong. (If you're believe that the discrepancy between the offsets in the file and the offsets in the seekheads are a bug: No, they aren't. The seekhead contains the offset relative to the first byte in a particular segment (i.e. the first byte after the length field of the segment). The same is used for the cues.)

[Mosu]

mkver has already explained most of what's relevant. The only thing missing is an explanation why the command-line mkvinfo doesn't show elements at the end of the file by default: there's a FAQ entry (https://gitlab.com/mbunkus/mkvtoolnix/wikis/Understanding-mkvinfo's-output) dedicated to it.

[mkver]

EDIT:
It seems mkvpropedit is OK, but the InfoTool in the GUI shows it not correct
As you see, he actually said that the InfoTool in the GUI has a bug.
Btw: Why does mkvpropedit write two SeekHeads? Why doesn't it write one SeekHead with pointers to the relevant level 1-elements (which may very well be at the end of the file)? If there is enough space for a complete SeekHead at the beginning, there is no reason for a second SeekHead at all.
(I am speaking of normal situations, not situations where one wants to have the clusters referenced in the SeekHead, too.)

[Mosu]

As you see, he actually said that the InfoTool in the GUI has a bug.

I've used the batch files provided by hubblec4, and both resulting files (batch 1 (https://mkvtoolnix.download/misc/hubblec4_mkvpropedit_1.mkv), batch 2 (https://mkvtoolnix.download/misc/hubblec4_mkvpropedit_2.mkv)) look just fine in both mkvinfo and the GUI's info tool. I don't know what he thinks the bug is.

Btw: Why does mkvpropedit write two SeekHeads?

Because at the point in time it needs to add an element to the seek head there isn't enough room to write the whole seek head at the front of the file. mkvpropedit does NOT try to optimize all the elements before the first cluster — instead it only tries to (re-)write the element it needs to update and maybe the meta seek. It will merge two or more consecutive EBML void elements if they're present or if they result from mkvpropedit's own action, but it won't move elements around in order to free up space. For example, if you have MetaSeek — Void — Tracks — Void — Chapters, it won't move the Tracks up or down in order to merge those two Voids.

Additionally, mkvpropedit doesn't batch changes. Meaning that if mkvpropedit will need to rewrite Tracks, Chapters and Attachments, it will first rewrite Tracks and fix up the MetaSeek for the newly written Tracks, then rewrite Chapters and fix up MetaSeek for the newly written Chapters etc. What usually happens is:

Layout could be something like MetaSeek — SegmentInfo — Tracks — Void — Clusters — Cues.
Let's assume you want to add chapters that fit into that Void and add a movie title (updating SegmentInfo); in that order. mkvpropedit will first write the Chapters there and shrink the void resulting in MetaSeek — SegmentInfo — Tracks — Chapters — Void — Clusters — Cues.
Now the newly added Chapters will have to be added to the Cues. As there's no place behind the existing MetaSeek, it will create a new MetaSeek entry at the end, move all level 1 references to the second MetaSeek and reduce the first MetaSeek to simply point to the second MetaSeek. There'll be new space behind the first MetaSeek. The result is: MetaSeek1 —Void — SegmentInfo — Tracks — Chapters —Void — Clusters — Cues — MetaSeek2.
Adding the title to SegmentInfo makes it larger. Let's assume the title is so long that adding the space from the Void before the SegmentInfo won't be enough; meaning SegmentInfo will be located to the back as well. Result: MetaSeek1 —Void — Tracks — Chapters —Void — Clusters — Cues — MetaSeek2 — SegmentInfo.
The reference to SegmentInfo is in MetaSeek2 before step 4. It has to be updated, but as the file position is now much larger, it won't fit into MetaSeek2 anymore. mkvpropedit will remove the reference from MetaSeek2 and include it in MetaSeek1 as there's more than enough space behind MetaSeek1 now. However, mkvpropedit will NOT simply move the whole of MetaSeek2 anywhere, even if the Void after MetaSeek1 would be big enough now to fit MetaSeek1+MetaSeek2 into; MetaSeek2 is here to stay (until you remux with mkvmerge). The final result is: MetaSeek1 —Void — Tracks — Chapters —Void — Clusters — Cues — MetaSeek2 — SegmentInfo.

If you want optimal layout, use mkvmerge.

[hubblec4]

I've used the batch files provided by hubblec4, and both resulting files (batch 1 (https://mkvtoolnix.download/misc/hubblec4_mkvpropedit_1.mkv), batch 2 (https://mkvtoolnix.download/misc/hubblec4_mkvpropedit_2.mkv)) look just fine in both mkvinfo and the GUI's info tool. I don't know what he thinks the bug is.

Yes both files looks good in mkvinfo tool.

Here is a pic from mkvinfo tool for my Hauptmenü.mkv
https://forum.videohelp.com/attachments/47005-1540241468/mkvinfo-tool.PNG

You see there is no Level1 element Tags or Chapters.

Mosu, have you used batch file 1 twice and then batch file 2?

I do the following:
run batch 1 -> load mkv in mkvinfo looks fine
run batch 1 again -> load mkv in mkvinfo missing Tags element
run batch 2 -> load mkv in mkvinfo look at the picture.

[Mosu]

Ah, no, I didn't run the first step twice. Yeah, that's a bug. Please file an issue over on Gitlab, but don't expect too timely a fix.

[hubblec4]

Is this a bug in mkvinfo or mkvpropedit?

[Mosu]

mkvpropedit

[hubblec4]

Ah, no, I didn't run the first step twice. Yeah, that's a bug. Please file an issue over on Gitlab, but don't expect too timely a fix.

I have opened an issue (https://gitlab.com/mbunkus/mkvtoolnix/issues/2413) on Gitlab

I hope you can find quickly the bug, because it breaks a new feature for chapterEditor.

Occurs this issue because tags and chapters AND attachments at the same time are written?

[mkver]

mkvpropedit
No, it's a bug in the mkvinfo GUI embedded in MKVToolNix GUI. The old (external) mkvinfo doesn't have this bug (click on pic to see it bigger):
https://i.imgur.com/y26XbtUl.png (https://i.imgur.com/y26XbtU.png)
It probably stops after finding the first void after the cluster or so.

[Mosu]

No, it's a bug in the mkvinfo GUI embedded in MKVToolNix GUI.
It probably stops after finding the first void after the cluster or so.

Both of those are spot on. The issue's been fixed.

[detroit1]

I am trying to use mkvtoolnix to join several 4K files

I notice it gives errors often and will not join the files

Most have the same profile mp4 with the same audio, some may not have any audio

I have a feeling it is the audio that is making it fail

What can I do to join the files without any problem

[sneaker_ger]

I have a feeling it is the audio that is making it fail
The error messages should show you exactly which tracks they refer to. "Feeling" is no good.

[detroit1]

Yes I looked at the log and my first file was 4096 and all others were 3840 so I converted the first file to 3840 and then did it again

no errors but early on the audio from the next file is playing in file before so it did not do it correctly

I am trying again now after deleting one of the files out

[Mosu]

Hey,

due to an unfortunate bug in the AV1 sequence header parser in release 28.0.0, here's a small bug fix update: MKVToolNix v28.1.0.

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 of the course of the next couple of hours.

Here are the NEWS (https://mkvtoolnix.download/doc/NEWS.md) since the previous release:

# Version 28.1.0 "Morning Child" 2018-10-23

## Bug fixes

* mkvmerge: AV1 parser: fixed an error in the sequence header parser if neither the `reduced_still_picture_header` nor the `frame_id_numbers_present_flag` is set. Part of the fix for #2410 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2410).
* mkvmerge: AV1 parser: when creating the `av1C` structure for the Codec Private element the sequence header OBU wasn't copied completely: its common data (type field & OBU size among others) was missing. Part of the fix for #2410 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2410).
* mkvmerge: Matroska reader, AV1: mkvmerge will try to re-create the `av1C` data stored in Codec Private when reading AV1 from Matroska or WebM files created by mkvmerge v28.0.0. Part of the fix for #2410 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2410).
* MKVToolNix GUI: info tool: the tool will no longer stop scanning elements when an EBML Void element is found after the first Cluster element. Fixes #2413 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2413).

Have fun :)

[Mosu]

Hey,

unfortunately I have to release a third time within a week: this time due to a use-after-free bug in all programs that make up the MKVToolNix package. This type of vulnerability allows arbitrary code execution using specially crafted Matroska files. It was introduced in v5.5.0 and affects all following releases up to and including the latest one, v28.1.0. Hence today's bug fix release.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the Windows installer/portable version & macOS DMG & Linux AppImage (https://www.fosshub.com/MKVToolNix.html) and the source code (https://mkvtoolnix.download/source.html).

The Windows binaries as well as the Linux AppImage are available already. The maxOS binaries and the other Linux binaries are still being built and will be available of the course of the next couple of hours.

Here are the NEWS (https://mkvtoolnix.download/doc/NEWS.md) since the previous release:

# Version 28.2.0 "The Awakening" 2018-10-25

## Bug fixes

* mkvmerge, mkvinfo, mkvextract, mkvpropedit, MKVToolNix GUI's info tool & chapter editor: fixed a case of memory being accessed after it had been freed earlier. This can be triggered by specially crafted Matroska files and lead to arbitrary code execution. The vulnerability was reported as Cisco TALOS 2018-0694 on 2018-10-25.

Have fun :)

[Selur]

Small question how to get the 'default' and 'forced' track info using 'mkvmerge --identify' ?
"I:\Hybrid\64bit\mkvmerge.exe" --identify "C:\Users\Selur\Desktop\Test.mkv"
returns:
File 'C:\Users\Selur\Desktop\Test.mkv': container: Matroska
Track ID 0: video (MPEG-4p10/AVC/h.264)
Track ID 1: audio (AAC)
Track ID 2: subtitles (SubStationAlpha)
Attachment ID 1: type 'application/x-truetype-font', size 221328 bytes, file name 'OpenSans-Semibold.ttf'
adding '--engage keep_track_statistics_tags', I get:
File 'C:\Users\Selur\Desktop\Test.mkv': container: Matroska
Track ID 0: video (MPEG-4p10/AVC/h.264)
Track ID 1: audio (AAC)
Track ID 2: subtitles (SubStationAlpha)
Attachment ID 1: type 'application/x-truetype-font', size 221328 bytes, file name 'OpenSans-Semibold.ttf'
Tags for track ID 0: 7 entries
Tags for track ID 1: 7 entries
Tags for track ID 2: 7 entries

Mediainfo returns:
Default : Yes
Forced : No
for each of the tracks.

In older versions I got something like (different file):
Track ID 1: video (V_MS/VFW/FOURCC, DIVX) [language:und display_dimensions:640x480 default_track:1 forced_track:0]
Track ID 2: audio (A_AAC) [language:und default_track:1 forced_track:0]
Track ID 3: subtitles (S_TEXT/UTF8) [language:chi default_track:1 forced_track:1
(seems like I totally missed that this output changed :))

Okay, forget that question, using '-F json' helps.

Cu Selur

[Mosu]

Yeah, the verbose identification format was removed in January. Use the JSON format for anything above the most basic track list.

[mkver]

@mosu: Your signature is outdated.

[Ex0rcist]

Repeating my question.

Is there any mkv extractor which is capable of applying audio delay when extracting audio/video files?

[Mosu]

mkvextract itself has no functionality for that. I don't know if any of the various GUIs out there does.

[mkver]

eac3to tries to do that, but if you don't want to reencode, then the precision with which you can do that is limited by the length of the audio packets of the format that you are extracting.

[LeMoi]

If I have a 3hr file and want to cut some part of it to have a 2hr one, AFAIK, I have to:
- open original_file.mkv
- cut with timecodes, for example I want to keep the parts 00:00:00.000-01:00:00.000,02:00:00.000-03:00:00.000
- then I have two 1hr files, original_file-001.mkv and original_file-002.mkv
- open the first one in the GUI, and append the second one, then mux and I'll have the 2hr original_file-001.mkv+original_file-002.mkv=target_file.mkv

Is there a way to skip the intermediate part1 and part2 files, and mux directly from original_file.mkv to target_file.mkv?
The app would read and mux the first hour, stop muxing and keep reading until the second hour, then restart to mux, in order to have only one final target file?
I know this is a feature request, AFAIK MKVToolnix GUI doesn't allow to do so, would it be possible to add this option in the future?

Thanks in advance!

[hubblec4]

Yes there is a way, insert a "+" in front of the second timestamp pair.

00:00:00.000-01:00:00.000,+02:00:00.000-03:00:00.000

[mkver]

Use "00:00:00.000-01:00:00.000,+02:00:00.000-03:00:00.000". (That's by the way included in both the ballon help in the GUI (https://gitlab.com/mbunkus/mkvtoolnix/blob/master/po/fr.po#L6014) as well as in the documentation (https://mkvtoolnix.download/doc/mkvmerge.html#mkvmerge.description.split). Where did you get the idea that it isn't possible from?)

[mood]

@Mosu

on windows 7 pro 32bit the mkvtoolnix-32-bit-28.2.0-revision-006 and revision-008 "mkvtoolnix-gui.exe" crash on startup

https://i.imgur.com/XoGL6gy.png


revision-005 works fine

[mkver]

@mood: This has just been fixed and the new continuous build is up (https://mkvtoolnix.download/windows/continuous/32-bit/28.2.0/).

[mood]

@mood: This has just been fixed and the new continuous build is up (https://mkvtoolnix.download/windows/continuous/32-bit/28.2.0/).

oh, oki, thanks...

when I made the post the lastest build it was revision-008

[mkver]

I know. Inspired by your post I made a bug report (https://gitlab.com/mbunkus/mkvtoolnix/issues/2424) on GitLab (that's the proper place for MKVToolNix bug reports) and mosu fixed it quickly.

[LeMoi]

Yes there is a way, insert a "+" in front of the second timestamp pair.

00:00:00.000-01:00:00.000,+02:00:00.000-03:00:00.000

Thanks for the tip!

[zaemon]

Hello.

madshi has been working for some time now to improve HDR tone mapping in madVR. The relevant thread can be found on AVS forums. As of now, madVR is able to parse HDR files in order to measure nits content of files (thus producing an HDR measurement file). Me and others encountered problems with remuxes done with MKVToolNix, where the same remuxes done with MakeMKV were fine (MKVToolNix remuxes yielded incomplete HDR measurement files with seamless branched movies). madshi reported that the problematic remuxes done with MKVToolNix had weird timestamp.

At this point I'm switching to MakeMKV for all my future remuxes and will redo problematic remuxes (hopefully only seamless branched titles). I just wanted to make some people here aware of the "problem", maybe someone could investigate it further and fix whatever needs to be fixed (not saying something's wrong with MKVToolNix per se).

I'm willing to provide more information if someone requests it.

In a non related topic, my experience with MKVToolNix is that the tool is way slower than MakeMKV for the same task. MakeMKV is 2-3x faster for remuxing purpose. Does anyone noticed this?

Thanks.

zaemon

[hubblec4]

MKVToolNIX(MTX) has indeed a small issue while muxing seamless branching discs.
https://gitlab.com/mbunkus/mkvtoolnix/issues/2051
A workaround is to process the audio streams with eac3to.
MTX is able to preserve multi edition seamless branching discs with the help of chapterEditor, Makemkv can't do this.

[mkver]

@zaemon:
1. mkvmerge compresses the subtitles with zlib (to save some space), MakeMKV doesn't. This might make a bit of difference, but I don't think it could explain what you experienced.
2. What version of mkvmerge were you using to remux the files? Version 18.0 greatly improved the speed of remuxing H.264 and H.265 from unframed sources (everything except mp4 and mkv). And version 25.0 was the first (release) version that had a bug affecting seamless branching Blurays (https://gitlab.com/mbunkus/mkvtoolnix/issues/2321) fixed. I will test if newer versions of mkvmerge are still slower.
3. There might of course still be a bug in mkvmerge. And for this the right place is actually on GitLab (https://gitlab.com/mbunkus/mkvtoolnix/issues?scope=all&utf8=%E2%9C%93&state=all), not here in this thread. If you still have this bug with a recent version of mkvmerge (Here (https://mkvtoolnix.download/windows/continuous/) are the latest continuous builds of MKVToolNix. The very latest of it contains a new option should the GUI look bad because of High DPI stuff. (High DPI awareness has been enabled since version 28.0 and some users reported problems -- this does of course not affect the cli tools in any way.)) What you can do then: You can upload the output of mkvinfo -v -v -r <output.log> <Input.mkv>, where <Input.mkv> is once the file created by a recent version of mkvmerge and once the file created by MakeMKV. Upload it somewhere (normally, I'd say that you should upload it to the server (https://gitlab.com/mbunkus/mkvtoolnix/wikis/FTP-server) of the MKVToolNix author, but I want to look at it myself, so please upload it to somewhere where I can get it (you may of course also upload it to his ftp-server, too)). And if you want mosu to be able to take a look at it, you should upload the whole, unencrypted disc to his ftp-server.

PS: It would have been nice if you had directly linked to the avsforum thread (https://www.avsforum.com/forum/24-digital-hi-end-projectors-3-000-usd-msrp/2954506-improving-madvr-hdr-sdr-mapping-projector-129.html). Although I have to say that it really doesn't contain more relevant information than "Madshi said the timestamps are weird".

[zaemon]

Thanks to both of you. First I'll try the eac3to method. I think it will be useful to know out of the three methods which one works. Now again, I had no problem with MKVToolNix prior to doing measurement with madVR: no warning, no error, no playback issue. I wouldn't consider it a bug at this point. But it's a fact that MKVToolNix's seamless branched remuxes are not compatible with the current dev version of madVR regarding HDR measurement files.

As for speeds, this does not really concern me but I was just curious to know why there was so much difference with MakeMKV.

[mkver]

And which version of mkvmerge did you use?

[hubblec4]

Hi Mosu

I have opened a thread (https://forum.doom9.org/showthread.php?t=175889): And the WebM file (https://github.com/brenopolanski/html5-video-webvtt-example/blob/master/MIB2.webm) in this project (https://github.com/brenopolanski/html5-video-webvtt-example) could not be recognized by mkvmerge. Also the .vtt file (https://github.com/brenopolanski/html5-video-webvtt-example/blob/master/MIB2-subtitles-pt-BR.vtt) on this github project could not be loaded into MTX-GUI.
Could you have a look?

[Mosu]

Both the WebM file and the VTT file can be read & muxed by mkvmerge 28.2.0 just fine here. The resulting file plays fine in VLC; subtitles are shown.

Did you right-click & "save as" perhaps? That way you might end up with HTML code being downloaded, not the actual files.

[hubblec4]

Wow, thanks Mosu you are right, I saved it with a rigth-click.
I had never thought that this is the issue.

[Mosu]

Hey,

it's time for MKVToolNix v29.0.0 which fixes a couple of bugs and adds one or two new features.

There were two important changes for package managers regarding library dependencies. Please see the NEWS below for details.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the Windows installer/portable version & macOS DMG & Linux AppImage (https://www.fosshub.com/MKVToolNix.html) and the source code (https://mkvtoolnix.download/source.html).

The Windows and macOS binaries as well as the Linux AppImage are available already. The other Linux binaries are still being built and will be available over the course of the next couple of hours.

Here are the NEWS (https://mkvtoolnix.download/doc/NEWS.md) since the previous release:

# Version 29.0.0 "Like It Or Not" 2018-12-01

## Important notes

* The string formatting library used was switched from `boost::format` to [`fmt`](http://fmtlib.net/). See the section "Build system changes" for details.

## New features and enhancements

* MKVToolNix GUI: added an option in the preferences for disabling automatic scaling for high DPI displays. Implements #2415 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2415).
* MKVToolNix GUI: the GUI will now prevent the system from going to sleep while the job queue is running. This feature is implemented for macOS, Windows and Linux/Unix systems where the `org.freedesktop.login1.Manager` D-Bus interface is available. Implements #2411 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2411).

## Bug fixes

* mkvmerge: chapter generation: the start timestamps of chapters generated in intervals was wrong for files whose smallest video timestamp was bigger than 0. Fixes #2432 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2432).
* mkvmerge: MP4 reader: fixed handling of atoms whose size exceeds the parent atom's size. Fixes #2431 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2431).
* mkvmerge, MKVToolNix GUI's chapter editor: the chapter name template will now also be used when reading Ogg-style chapter files with empty chapter names. Fixes #2441 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2441).
* mkvextract: AAC: mkvextract will now write the program config element (PCE) before the first AAC raw data packet if the PCE is present in the `AudioSpecificConfig` structure in the `Codec Private` Matroska element. The PCE carries vital information about the number of channels and is required in certain cases. Fixes #2205 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2205) and #2433 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2433).
* mkvpropedit, MKVToolNix GUI's header editor: in situations when a one-byte space must be covered by a new EBML void element the following element must be moved up instead. If that moved element is a cluster, the corresponding cue entries will now be updated to reflect the cluster's new position. Fixes #2408 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2408).
* MKVToolNix GUI: Windows: the application manifest is now included properly so that Windows actually recognizes it. See #2415 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2415).

## Build system changes

* Qt's D-Bus implementation is now required for building on systems other than macOS and Windows,
* The `boost::format` library is not used anymore.
* The [`fmt` library](http://fmtlib.net/) is now required. Versions 3 and newer are supported. As not all Linux distributions include packages for the library, its release 5.2.1 comes bundled with MKVToolNix. The `configure` script will check for a system version of the library and use it if present and recent enough. Otherwise it will fall back to the bundled version and link that statically.

Have fun :)

[kuchikirukia]

I have some UI suggestions that might improve the usability of the GUI.
I've noticed the GUI is really big. I find myself moving it around the screen a lot to get behind it to get to Explorer to pick files to throw in it. The main snag with making the window smaller seems to be that you lose sight of the mux button and have to scroll down to find it. As soon as you collapse smaller than 678 pix high you start to lose those buttons.
If it's at all possible to move the buttons to the status bar it would fix this problem.

Here's the current smallest without getting any scroll bars:

https://i.postimg.cc/m2JhfTrS/default.png


Proposed change:

https://i.postimg.cc/y6r8c70z/changes.png

Buttons are moved to status bar.

Add Source Files label gets reduced to Add Files
Start Multiplexing label gets reduced to Start Mux
Add to Job Queue label gets reducted to Add to Queue
(so now the buttons can be a little smaller)

Jobs to Execute reduced to just Jobs
Automatic shortened to Auto
Warnings shortened to warn

This gives room for the buttons in the same space as the current default.

That would allow us to resize it vertically to this and still be perfectly usable:

https://i.postimg.cc/pTrpMrKq/small-with-jobs.png


And if it's at all possible to have the status bar UI collapse onto the "Jobs to execute" bar when resized horizontally, it could further be resized down to this:

https://i.postimg.cc/wTg39w51/small-change.png

The Jobs bar is nice but not exactly vital to the basic use, so collapsing down on it would lose almost nothing.


(Also, Save buttons would be nice on the chapter editor)

[mkver]

I find myself moving it around the screen a lot to get behind it to get to Explorer to pick files to throw in it.
My solution for this is to include MKVToolNix in the "Open with" list of the file types that are processed with MKVToolNix.

[Mosu]

I have some UI suggestions that might improve the usability of the GUI.

Thanks for the suggestions. I won't implement any of them as they aren't going in a direction I want to take the GUI in. I simply don't support such low resolutions.