MKVToolNix v99.0 released

[Mosu]

Uh, no, that's a very, very old name. When you look at the "git blame" output for the file, you might notice that line is from 2004. It's since been renamed to EditionFlagOrdered, but it looks like I never got around to replacing it in the DTD, too. I'll fix it in a moment.

[hubblec4]

:-)

Mmh maybe a next issue.
"ChapterLanguage" uses a "+" for the occurrence, but this element can be omitted.
Would it be better to use the "*" (Asterisk) sign?

[WSC4]

I need some information on the old abandoned MKVToolNix thread that dates back to December 2017 please?

https://forum.doom9.org/showthread.php?p=1828168#post1828168

It is post #4992 and was posted by forum member manolito, and he posted this link there:

https://files.videohelp.com/u/172211/ToolNix_XP.zip

Error - File has been deleted.

I hope he sees this and can let me know if it can be upload again please?

[manolito]

The link address has changed after I added Win7 to the supported versions. Use this one:
https://files.videohelp.com/u/172211/ToolNix_XP_Win7.zip

(VideoHelp does not allow posters to edit their older posts after a certain time, so there is no way for me to update this old post)

Cheers
manolito

[Mosu]

Heyo.

I've just released a new minor update, v71.1. It solely fixes the "configure" script not having the correct requirements wrt. to libEBML & libMatroska. It also fixes several issues in the XML DTDs, but those aren't actually used in MKVToolNix itself. Functionality wise v71.1 is the same as v71.0. If you aren't a Linux package maintainer, feel free to skip this release.

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

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

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

Version 71.1.0 "Fortitude" 2022-10-09
Bug fixes

Chapters DTD: added the new edition & chapter elements from Matroska v5.
Chapters DTD: fixed EditionUID being mandatory. mkvmerge can auto-generate it if it's missing from the XML file.
Chapters DTD: fixed the "example-chapters-1.xml" not validating against the DTD.
Chapters DTD: corrected the old name "EditionManaged" to "EditionFlagOrdered".
Chapters DTD: fixed "ChapLanguageIETF" missing its element declaration & "ChapterLanguage" being required.
XML DTDs: fixed elements representing binary data not allowing the "format" attribute.

Build system changes

bug fix: configure accidentally tested for libEBML ≥ 2.0.0 & libMatroska ≥ 2.0.0, even though the actual requirements are 1.4.4 & 1.7.1 respectively.


Have fun 😁

[hubblec4]

Hi Mosu

MTX supports now Matroska v5 elements: is this the official start for Matroska v5?

[Mosu]

v4 is the one that's currently going through the IETF standardization process. All elements we're adding now will be v5. These elements are the first v5 elements that have been specified. If you want to take that as to be an "official start", feel free, though there really isn't anything more behind this as "not part of the initial IETF standard".

[WSC4]

The link address has changed after I added Win7 to the supported versions. https://files.videohelp.com/u/172211...ix_XP_Win7.zip

Hi there manolito. Very pleased to see you are back posting again. I was told about your ill health last February in the Optimal encoding with FFmpeg for DVD thread and was very sorry to read about it. Sincerely hope you are fit and well now and have made a full recovery.

I need some information about MKVToolNix for Windows XP and Windows 7 please. Those operating systems have not been supported here for 3 years. Would it be more convenient if I post my question in the "MKVToolnix Windows 7 "The final Countdown" thread than here?

[manolito]

I need some information about MKVToolNix for Windows XP and Windows 7 please. Those operating systems have not been supported here for 3 years. Would it be more convenient if I post my question in the "MKVToolnix Windows 7 "The final Countdown" thread than here?

Hi WSC4 and thanks for the kind words. In my case there is no way to hope for a full recovery. The brain cells are too specialized to be replaced by new cells once they have died. Nothing you can do about it, I used to be pretty smart for 68 years, and now I will stay pretty dumb for the rest of my life. No reason to become grumpy...

To discuss MKVToolNix for WinXP and Win7 it would be good to move this to the other forum thread you mentioned. I am quite sure that Mosu is not amused to see this discussion in his main thread... :rolleyes:


Cheers
manolito

[WSC4]

OK. Shall do. See you over there. https://forum.doom9.org/showthread.php?p=1968296#post1968296

[archiel]

EAC3 issue - Resolved see edit below

Initially noted this running a batch conversion in RipBot64, but the issue seems to go the mkvtools. If I run MediaInfo against the source file the Audio has one length, however after extraction the length has changed.

from source
ID : 2
Format : E-AC-3
Format/Info : Enhanced AC-3
Commercial name : Dolby Digital Plus
Codec ID : A_EAC3
Duration : 46 min 16 s
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 32 bits
Compression mode : Lossy
Stream size : 63.6 MiB (4%)
Language : English
Service kind : Complete Main

After extraction (via mkvtoolnix GUI or mkvextract)
Audio
Format : E-AC-3
Format/Info : Enhanced AC-3
Commercial name : Dolby Digital Plus
Duration : 46 min 34 s
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 64.0 MiB (100%)
Service kind : Complete Main

Is this a known issue / is anyone else seeing this?

I am running Win11 Pro 22H2

Edit: The audio was fine, but the video was reporting the wrong frame rate, which resulted in an incorrect duration. At a guess the whole file had been cropped, but not on a key frame, so the first block had a different frame rate - the file showed as 24.131 instead of 23.976, the rate for the rest of the file.

[Emulgator]

How do these files compare (decoded) in a DAW (Audacity or what you prefer) ?

[archiel]

Problem resolved - see my edit to the original post.

[tebasuna51]

Don't trust always in all data than MediaInfo show, because it don't read the full streams and assume some info.
When show the container seems assume a duration (and size = Duration x Bitrate) wrong for the eac3 track, the correct is the info about the extracted track.
Also it lie when show:
Bit depth : 32 bits
A lossy encode don't have Bitdepth

[Moonbase]

Splitting after timestamp/frame—how exactly is it done?

Until now, I was usually fortunate when needing to split a long file. For "time stamp after", I used the last, say P frame before an I frame, and MKVToolNix GUI seems to perfectly include the last P frame (at my given timestamp) in the first file, and start the second file with the next frame, i.e., the I frame.

What would happen if I had a file with long GOPs and needed to cut somewhere else (i.e., not at an I frame)? Would MKVToolNix "blindly" cut at the given position, or somehow search to the next/previous I-frame and cut there, in order not to mess up the start of the next file?

[Moonbase]

Don't trust always in all data than MediaInfo show, […]

This may actually be important. I recently ran MediaInfo across a few 3D MKV files, looking for the "3d-plane" tags MakeMKV puts there for some 3D subtitles. They suddenly seemed all gone!

Somehow, MediaInfo couldn’t "see" them (although being in the files) across a network mount (ftp:// via Nemo on Linux). So beware, MediaInfo might show odd data on network mounted files (with ftp: being an especially bad case, and nfs: seemingly the best, because one can wildly seek around within the file, which ftp: cannot support).

[Mosu]

mkvmerge only ever splits before I frames, no matter which splitting mode you use. If you need to split within a GOP, you must use different tools that can re-encode the frames in that GOP as needed.

[Moonbase]

Thanks for the confirmation. Good to know it’s not a "dumb" splitter, possibly corrupting split files.

If I specify an arbitrary timestamp, will it search forward or backward to find the next I-frame for splitting? Or will it use the nearest I-frame?

[Mosu]

Always forward if it isn't on a keyframe at that point. Some modes seem to split on key frames, some on the next one; though I don't remember the details & why this is the case, to be quite honest. Probably something like off-by-ones or > vs >=

[hubblec4]

Would it be much amount of work to offer a "where mkvmerge splits list"?

Like "mkvmerge an.mkv --testsplit 00:01:00.000"
mkvmerge outputs then the timestamp of the real split.

[Mosu]

Not in a test mode, no. It has to process all the frames in order to determine how the timestamps actually pan out & where to split. Sure, I could add the information about which timestamps it has used for splitting, but that way you still would have to read the whole file. It would still take a lot of time depending on the source material.

[hubblec4]

Sure, I could add the information about which timestamps it has used for splitting
Mmmh indeed such an info would be nice. i have create a ticket (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/3421).


but that way you still would have to read the whole file. It would still take a lot of time depending on the source material.
Ok, but Mkvmerge doesn't have to write any new MKV. files, which is probably the most of the time, or am I wrong?

[Mosu]

Writing & reading takes a similar amount of time, maybe 40/60%.

[darksen]

I have added a mpls to MKVToolNix but it doesn't add the audio track, if I open said playlist file with mediainfo it does shows an audio track. The thing is, the mpls links two files, the first file has a duration of a few seconds and doesn't have any audio, the second one does have an audio track. Can this be fixed? I've uploaded the mpls, I can share the files if needed.

[Mosu]

No, not with MKVToolNix. It requires all tracks to be present in the first M2TS referenced from an MPLS playlist.

To put it differently: when you tell it to add an MPLS file, it'll parse it & take a lot of its metadata (such as the chapter information, track languages, cover image if you're using the GUI). It'll also parse the list of M2TS & the start & end timestamps for each of those.

The next step is track identification — and for this it acts as if you had added the first M2TS file referenced in the MPLS & appended all the other ones. And what you need to realize is that mkvmerge will only create tracks in the destination file for each track in all the source files that have been added, but not for the appended files.

On top of all that for most track types having them referenced in an M2TS's PAT/PMT is not enough; instead mkvmerge will actively look for the first couple of frames for those tracks in order to extract certain information that isn't present in the PAT/PMT (e.g. sampling frequency, channel count, image dimensions etc.).

[darksen]

Thank you for the detailed response, you made it pretty clear. I'll have to do this manually which should be easy.

[Mosu]

Heyo!

here's MKVToolNix release v72. It fixes quite a lot of bugs, several one of them in the component driving the in-place file modification in mkvpropedit & the GUI's chapter & header editors. Therefore I urge everyone to update.

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 72.0.0 "Minuano (Six-eight)" 2022-11-13
New features and enhancements

mkvmerge: AV1 parser: the variable-width OBU size field will be re-written with minimal length if it's encoded longer than necessary.
mkvmerge: when splitting is active the program will output the timestamps actually used for making the decision when to split. If GUI mode is active, a specially formatted line "#GUI#splitting_before_timestamp <timestamp>" is output as well. Lines prefixed with"#GUI#" are suitable for machine parsing, won't be translated and are guaranteed not to change in format. Implements #3421 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3421).
MKVToolNix GUI: multiplexer: when dragging & dropping directories to the "attachments" tab, the files contained in those directories will be attached. Implements #3410 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3410).
MKVToolNix GUI: info tool: added information about the file (directory, size, modification timestamp) at the top of each tab. Implements #3407 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3407).

Bug fixes

mkvmerge: AV1 parser: fixed the parser completely aborting when parsing the OBU size field fails due to there not being enough data to parse. Instead the parser will remember the last known-good position & restart from there after more data is available. Fixes #3431 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3431).
mkvmerge: HDMV PGS subtitles: reverted the change that implemented a heuristic for detecting bogus timestamps & attempting to fix them. This was done to fix #3268 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3268). Unfortunately this affected valid subtitle files with intentional huge gaps in timestamps, e.g. forced subtitle tracks. The heuristic has simply been removed, fixing #3392 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3392).
mkvmerge: Matroska reader: fixed reading files with EBML Void elements before the Matroska Segment element.
mkvmerge: fixed reversed attachment selection: "--attachments !4" would not copy any attachment instead of all attachments but the one with ID 4. Fixes #3427 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3427).
mkvextract: IETF BCP 47/RFC 5646 language tags: mkvextract will now use & prefer IETF BCP 47 track language elements if they're present. Only affects the VobSub & USF subtitle extraction.
mkvpropedit, MKVToolNix GUI's chapter & header editors: updated the list of deprecated Matroska elements. The applications will no longer try to write those elements, even if they're found in the file to be modified. The programs will no longer abort with error messages such as "assertion "false" failed". Fixes #3416 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3416).
mkvpropedit, MKVToolNix GUI's chapter & header editors: when the Matroska version numbers stored in the EBML Head element are updated, the updated EBML Head element might be smaller than the existing one. In that case the programs used to shrink the EBML Head & write a small EBML Void element between the updated EBML Head & the following element, usually a Matroska Segment element. This isn't widely supported by programs including MKVToolNix itself, causing them to declare such files as invalid. The programs will now create the EBML Void element inside the EBML Head element, making them a level 1 element instead of a level 0 element. Fixes #3355 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3355).
mkvpropedit, MKVToolNix GUI's chapter & header editors: often the programs have to relocate the Master elements in which the modifications were done. In that case the Seek Head elements must also be updated to reflect to the Master elements' new positions. If a file contained a Seek Head element at the start already and if that Seek Head was too small to contain the updated positions, the programs would end up in an endless loop trying to write data to the end, creating ever-growing files. This is now handled properly by voiding this too-small Seek Head & finding a proper space for a new one instead. Fixes #3338 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3338).
MKVToolNix GUI: header editor: fixed pixelated icons on higher display scaling values. Fixes #3420 (https://gitlab.com/mbunkus/mkvtoolnix/issues/3420).


Have fun 😁

[quietvoid]

Hi Mosu, thanks for this release.

Here are the NEWS (https://mkvtoolnix.download/doc/NEWS.md) since the previous release:
It appears clicking the NEWS link now always downloads the file, instead of opening in the browser.
Maybe something has changed in the site's setup?

I've tried on both Firefox and Google Chrome.

[Mosu]

It appears clicking the NEWS link now always downloads the file, instead of opening in the browser.

Oh… right, that's due to a related config change. I'll fix it. Thanks.

Edit: fixed

[AYColumbia]

@Mosu,
Thanks much for the continued releases of this invaluable tool. :)

[FranceBB]

Thank you for the new release, as always. :)

[Peter_A]

Often, I copy & paste the MKVToolNix output (from "Job Output") into a text/log file (on a Windows machine). The output has always maintained the line breaks when pasted in the past, but it is not doing that with v72.0.0. When I paste now, all of the lines are concatenated into a single line. I thought that maybe either the CR or LF was dropped, but I tried saving as text files with UNIX (LF) and MAC (CR) line terminators, as well, and experienced the same (output all in single line).

Was this an intentional change in v72.0.0? I didn't see anything in the release notes, but perhaps I overlooked something.

[Mosu]

I definitely didn't change anything there, and most certainly this isn't intentional. I can reproduce it on my end. My guess is that this is due to Qt which was updated to v6.4.0 with MKVToolNix v72.

I suggest you don't copy-paste, but instead use the "Save output" function from the "More actions" button.

Edit: looks like QTBUG-107004 (https://bugreports.qt.io/browse/QTBUG-107004).

[manolito]

@ Peter_A

Or you can use an alternative build compiled using Qt5.7 from here:
https://forum.videohelp.com/threads/405407-NON-OFFICIAL-Windows-builds-of-MKVtoolnix/page3#post2672418

Cheers
manolito

[Peter_A]

I suggest you don't copy-paste, but instead use the "Save output" function from the "More actions" button.

Edit: looks like QTBUG-107004 (https://bugreports.qt.io/browse/QTBUG-107004).

Thanks, but that doesn't even totally work as I'd expect. If I mux and then clear the output, it removes the output from the window. If I mux again, the new output shows in the window, but if I then save the output (as you suggest), the file contains the output from both muxes. It seems to keep everything since the program was last closed. Why does it not just save what's currently in the window (what I'd assume would be the desired behavior)?

[Mosu]

OK, this is a bit complicated.

The one "job output" tab that's always visible does indeed collect the logs of all jobs. The output isn't just saved from the "output" text field to a file as there are three text fields: "output", "warnings", "errors". What's saved is the internal representation of the output as it is produced by mkvmerge — meaning warnings & error messages are interleaved with regular output, preserving the order in which the messages arrive.

That being said, clearing the output on the "job output" tab should also clear its internal representation, which it doesn't seem to do — hence you seeing the output of all jobs in the saved file. I'll look into that.

As yet another workaround you can go to the "job queue" tool & right-click on the job whose output you want to save. Select "View output" from the context menu. This will open a separate tab in the "job output" tool, and from there you can save it.

[Moonbase]

Thanks for continuous upgrades! I actually had some cases where the GUI Header Editor messed up the header slightly in v70. Nothing that couldn’t be fixed by doing a fresh remux, though. Will check if this is better now with v72.

[Kairys]

Hi! Is it possible to use your program to create a Blu-Ray Remux with the addition of your own audio track? There are folders (BDMV, CERTIFICATE) extracted using the MakeMKV program. What to do next? Could you give a brief instruction? Thanks

[Megalith]

How feasible is this via scripting?

1. Scan all MKVs and remove all audio tracks with the words "audio commentary"
2. Retain file accessed/modified dates

And would this require re-muxing?

[Mosu]

Not that hard at all with proper scripting languages (can even be done with bash, but it's a bit harder).

Removing whole tracks always requires full remuxes.

[hubblec4]

Hi! Is it possible to use your program to create a Blu-Ray Remux with the addition of your own audio track? There are folders (BDMV, CERTIFICATE) extracted using the MakeMKV program. What to do next? Could you give a brief instruction? Thanks

Hi Kairys
and welcome to Doom9.

Simple drag&drop the index.bdmv file into a Muxing-Tab in MKVToolNix(MTX).

MTX scans this file and presents a selection form with all the content of this disc (except: Angles of titles).

[Megalith]

Question about Dialnorm:

Whether Dialnorm is modified/retained is strictly decided in the muxing stage, correct? Regardless of how an audio track (e.g., TrueHD) was extracted, the only way that the Dialnorm settings could have been modified is if I toggled "remove dialog normalization gain" under the audio properties section of MKVToolNix, correct?

(For the longest time, I had assumed that eac3to determined this during the extraction phase, but apparently I have been wrong...)

[hubblec4]

You are correct. And yes, eac3to removes the Dialnorm by default.

[Mosu]

Question about Dialnorm:

Whether Dialnorm is modified/retained is strictly decided in the muxing stage, correct?

Removing it requires modification of each and every AC-3 packet. In the case of MKVToolNix it's therefore only possible to remove it during muxing, meaning you're correct.

Note that "removing dialnorm" is technically impossible. It's only possible to set the value used for dialog normalization to its minimum or maximum value, but you cannot remove it. However, mkvmerge uses established verbiage in order not to confuse users further that might know that functionality from tools such as eac3to.

[beto]

Thank you for the tool. Is there a way to use it to extract streams and attachments from a MKV file using a GUI? I do not know if a GUI is provided in the bundle for this purpose. The GUI provided shows me only a multiplexer and not a demultiplexer.

Thanks.

[NanoBot]

Are you looking for a program like this:

https://forum.doom9.org/showthread.php?t=170249

[beto]

Yes. That will do the trick. Thanks a lot.

[Perenista]

The 1st file was saved as AVI. DVDRip, but with the wrong AR (1.90). I wanted to use MKVToolnix and save as MKV. Specifying the 16:9 AR (1.78).

It worked. But the audio is now out of sync.

Why?

AVI:

https://pastebin.com/bza6Gx2f

MKV:

https://pastebin.com/fGUvYjAp

Important: before using MKVToolnix I appended at the very end of CD-1 (AVI) the 2nd file (CD-2), resulting in a single AVI, saving with the option "direct stream copy" using VirtualDubMOD. I used to split into 2 CDs in the past, and joined both files that way.

If I play that single AVI it's OK and the audio isn't out of sync. MKVToolnix, however, causes that issue.

[Mosu]

I suggest you try it without appending the AVIs first. There are two possible ways:

Simply use MKVToolNix GUI/mkvmerge to append the AVIs to a single Matroska file in a single go. Add the first AVI to the GUI's multiplexer, append the second one, go.
Another possibility is to mux each AVI to a separate Matroska file first, and then append those two Matroska files to a combined, long Matroska file.

The background is that the AVI container simply doesn't provide timestamps for audio data. Therefore appending AVIs to other AVIs requires hackery, and it's quite possible that mkvmerge simply doesn't support some types of those tricks.

[Perenista]

Oh-oh... I got this while trying to put the CD1.avi into MKV...

********
This audio track contains 146944 bytes of invalid data which were skipped before timestamp 00:36:42.352000000. The audio/video synchronization may have been lost.
********

I just checked the original AVI and indeed after 36m42s there's an abrupt cut in the video/audio, which seems to remove a portion of the content. Oddly this abrupt cut turns into the image freezing only for the MKV, for 1-2 seconds, then resumes from that. After that moment, the audio is out of sync in the CD1.mkv.

For example, at 46 minutes...

But here's something funny: this CD1.avi (affected with this issue) is not out of sync anywhere. I checked and it's OK into 46 minutes. I predict it will also remain unaffected if I append with CD2.avi using VDM.

MKVToolnix will not handle with the AVI due to this internal error, in other words the fact there is an error in there derails the whole thing as a result.

I am going to discard these old AVIs and create a new one from the disc...