MKVToolNix v24.0.0 released

[Mosu]

Read this fine FAQ entry (https://github.com/mbunkus/mkvtoolnix/wiki/Elements-not-showing-up-in-output-file). The summary is: TrackFlagDefault's default value (= the value a player must use if the element is not present) is "true". As you're setting that flag to "true", mkvmerge does not have to write it and doesn't do so, because its absence means implicitly that it is "true".

[hubblec4]

Ok, fine. I thought I did an issue.

[Nico8583]

Hi,
I've seen some people uses "--clusters-in-meta-seek --disable-track-statistics-tags --engage no_cue_duration --engage no_cue_relative_position" options to improve compatibility. What are the others pros and cons to allways use it ?
Thank you !

[sneaker_ger]

https://github.com/mbunkus/mkvtoolnix/wiki/Improving-playback-compatibility-with-players

If it adds data: more overhead. no_cue_duration/engage no_cue_relative_position: seeking into the middle of a subtitle line works in players that can make use of those (e.g. LAV/MPC-HC).

[hello_hello]

When appending MKVs, MKVToolNix accounts for any existing audio/video delays or gaps etc and maintains sync, unless one of the MKVs being appended contains no audio at all.
For example, if you append three MKVs, and the second MKV contains no audio, in a perfect world it'd be treated as an audio gap and the video/audio sync for the third MKV being appended would be unaffected. What seems to happen though, is the audio in the third MKV is appended to the audio in the first MKV as though individual streams were being appended. I don't know if the same applies to subtitle streams. Is that a bug or intended behaviour?

Cheers.

PS. Keep in mind I'm using manolito's workaround with MKVToolNix version 15 (thanks manolito), given I'm running "no-ding" XP, although I doubt it's related to the problem....

[Nico8583]

https://github.com/mbunkus/mkvtoolnix/wiki/Improving-playback-compatibility-with-players

If it adds data: more overhead. no_cue_duration/engage no_cue_relative_position: seeking into the middle of a subtitle line works in players that can make use of those (e.g. LAV/MPC-HC).
Ok thanks :)
I don't know if I must use it or not, I can test my players now but in few months perhaps I'll use new devices so I can't know if these options will be supported... Difficult choice :rolleyes:

[hubblec4]

Hi Mosu

I have noticed that when I load a UHD-Bluray m2ts or mpls to MTX then all languages are well defined.
In an older version of MTX all languages was set to "und".

Have you improved your UHD-Bluray parser? Where you got this new infos?

[Mosu]

I didn't really change anything regarding languages on Blu-rays. If the language is present in the MPLS/CLPI files, then it is used. Simple as that.

[hubblec4]

Hi Mosu

I have some questions about mpls.

In the identify.json for all streams exists a "stream_id" with a number. This number seems to me not always match with the number in the mpls.

Here is an example (https://forum.videohelp.com/attachments/43114-1505400085/MTX-mpls-PIDs.7z) of the Terminator 2 Bluray.

mpls 00018: there are 2 DTS-Express audio tracks and a second video track.

Video 2: "stream_id": 6912 -> binary 1B 00
DTS 1: "stream_id": 6656 -> binary 1A 00
DTS 2: "stream_id": 6657 -> binary 1A 01

But I don't found this binary values in the mpls.

Why is the order of the streams in MTX different to the order in the mpls?

Best regards

[Mosu]

But I don't found this binary values in the mpls.

Why is the order of the streams in MTX different to the order in the mpls?

For mkvmerge the actual content of the M2TS file(s) is relevant, not what's in the MPLS. mkvmerge reads the M2TS files listed in the MPLS file and uses all streams found in the M2TS files. Track IDs are assigned in the order they're found in the M2TS.

It's quite possible those streams are simply not listed in the MPLS.

[hubblec4]

For mkvmerge the actual content of the M2TS file(s) is relevant, not what's in the MPLS. mkvmerge reads the M2TS files listed in the MPLS file and uses all streams found in the M2TS files. Track IDs are assigned in the order they're found in the M2TS.

Ok, nice to know and that makes now some cases clearly to me.


It's quite possible those streams are simply not listed in the MPLS.

Mmh thats not so fine.
The streams also listed in the mpls but with different stream_id's.
Is there a chance to get the correct mpls stream_id's with the identify-json?

[Mosu]

The streams also listed in the mpls but with different stream_id's.
Is there a chance to get the correct mpls stream_id's with the identify-json?

Uhm… no? There's only one stream ID in the M2TS for each packet, and if that is present in the MPLS, then great; if it isn't, then that's how it is. There's nothing wrong with the stream IDs reported by mkvmerge.

[Mosu]

In fact, one could argue that mkvmerge should not report streams found in the M2TS files that aren't listed in the MPLS if an MPLS is used as an input file. On the other hand, that might be considered to be a step in the wrong direction and taking away functionality that people like.

[hubblec4]

Uhm… no? There's only one stream ID in the M2TS for each packet, and if that is present in the MPLS, then great; if it isn't, then that's how it is. There's nothing wrong with the stream IDs reported by mkvmerge.

I'm sure mkvmerge works fully correct, but I hoped there are more info in the m2ts for the streams.


In fact, one could argue that mkvmerge should not report streams found in the M2TS files that aren't listed in the MPLS if an MPLS is used as an input file. On the other hand, that might be considered to be a step in the wrong direction and taking away functionality that people like.


Mmh...
When I play the 00018.mpls in mpc-hc, I see both DTS-Express streams and I can select them, BUT mpc-hc stops immediately playing (playback button is shown active).

When I play the Bluray in TotalMediaTheater(TMT) both DTS-Express streams are not available (for the Theater Version and the Director's Cut, I can't play the T-1000 Edition, but I guess there are both streams available)

I think TMT is more closer to the Bluray Specs than mpc-hc.

It seems to me this behaviour is same like found on DVD's for Multi/Angle Edition cases.
In the IFO the streams are listed which used, but in some VobID's more audio streams listed.
TMT shows the respective audio streams for each edition only.
No mkv which I muxed played correctly when I select the "extra" audio stream.

Maybe have not all m2ts files all audio streams inside.
I don't know how many m2ts files mkvmerge scaned from an mpls which have more than 30 m2ts files.

If so, only audios which listed should be used.

[hubblec4]

Hi Mosu

As I already suspected it is the same behaviour like on DVD's.
Only the 00020.mpls have the secondary video stream and all other audio(secondary) streams listed and are playable.

I scaned the different m2ts files with MediaInfo and all files have all streams inside.
Maybe thats the reason why I had never problems to mux Multi-Edition-mkvs for such cases.

[Perenista]

Question: if I simply add a file to MKVToolnix and save as MKV, will that change its contents? I mean, will this MKV be lossless or lossy?

Look the info from the .MPG file:

https://pastebin.com/9BikesZS

And now the MKV created by MKVToolnix:

https://pastebin.com/Jzz7WkYC

If nothing changed why the original file has 7.58 and the MKV 7.44 GB? And what about this?


Original file:
Frame rate : 29.970 (30000/1001) FPS

Matroska:

Frame rate : 23.976 (24000/1001) FPS
Original frame rate : 29.970 (30000/1001) FPS

Note: I always like to add files to MKVToolnix and save as MKV to change something specific, such as naming the audio tracks or adding subtitles. Since it's easier to use MKVToolnix for this, I simply add the .AVI, .MPG or whatever file is, and do the procedure there. I am assuming despite the above changes from Pastebin it's still lossless, right?

[Asmodian]

Yes, it will be lossless. The size difference is simply because matroska is a very efficient container.

The change in the frame rate is probably due to the mpeg2 using soft pulldown. This is flagging which generates 29.970 fps video from 23.976 encoded video during playback and mkv doesn't keep this flagging the same way as the mpg container. You generally don't want pulldown unless putting the video on DVD (which do not allow 24fps) because it adds 3/2 judder.

[MrVideo]

I'm sure this has been brought up before, but because there lots of pages and searching for "truehd" leads to too many results, I figure it would be easier to just ask.

AIUI, when a TS/M2TS file is muxed into a MKV wrapped file, and if the the audio is TrueHD, or maybe even DTS-MA, the core is stripped out. That means if the MKV file is imported into tsmuxer, the audio streams are rejected. Why is the core ripped out? Why not leave the TrueHD/DTS-MA streams intact?

[sneaker_ger]

https://github.com/mbunkus/mkvtoolnix/wiki/TrueHD-and-AC-3

This does not apply to DTS-HD MA. The lossless HD part is a "true" extension that needs the core data. It is not independent.

[MrVideo]

Thanks for the reference. IMHO, the spec needs to be changed to allow audio streams like TrueHD to remain intact. But, that's just me.

[nevcairiel]

Thanks for the reference. IMHO, the spec needs to be changed to allow audio streams like TrueHD to remain intact. But, that's just me.

Those streams aren't really "combined" in MPEG-TS either, there is a clear separation in MPEG-TS that allows you to cleanly split it into AC3 and TrueHD streams. It is basically two streams, just muxed in a peculiar way for backwards compatibility for certain players.

In any other container, it should definitely and absolutely be two separate streams.

Maybe you should lobby tsMuxer that it learns to re-combine an AC3 stream with a TrueHD stream, instead? That would be the right thing to do.

[LeMoi]

I have the following error when trying to mux from an mpls playlist (sorry it's in french...):
--- Erreurs émises par la tâche « Multiplexage du fichier « film.mkv » dans le dossier « ***\RIP » » lancée le 2017-09-28 19:59:20 ---
Le fichier n° 0 (« ***\BDMV\PLAYLIST\..\STREAM\00009.m2ts ») ne contient pas de piste d'identifiant 3 ou cette piste ne doit pas être copiée. Aucune piste ne peut donc lui être ajoutée. L'argument de « --append-to » était incorrect.
Here are the tracks that appear in mkvtoolnixGUI:
http://nsa39.casimages.com/img/2017/09/29/170929123258163070.jpg

I think the problem is that the mpls contains 4 files:
http://nsa39.casimages.com/img/2017/09/29/1709291235325377.jpg

One of them contains 4 tracks:
http://nsa39.casimages.com/img/2017/09/29/170929123532135740.jpg

The last 2 only have video track, the 1st one one video and 2 audio.

How to bypass this error?
I think the program should skip the tracks that are not available in every mpls, or a least we could be able to choose...
In my case, I only need the 2 first m2ts with audio and video (or only video), I can arrange myself with the sub track from the 2nd one and last 2 are not useful.
Thanks for your help!

[von Suppé]

a mpls can have multiple streams, it's not uncommon. But as I see your mkvtoolnix window, can't you just check the french or spanish audio box to mux them?

I don't understand the error; it's in French.

[Mosu]

I have the following error when trying to mux from an mpls playlist (sorry it's in french...):

Your error message and all of your screenshots don't match each other:

The error message talks about file 0 being 00009.m2ts. However, the first file (that's the one mkvmerge considers to be file 0) in the list is 00000.m2ts.
The track list doesn't show any appended track even though the file list shows appended files.

This makes is neigh impossible to help you. Please post a screenshot of the GUI's "input" tab (especially so that we can see which file each track belongs to) if you want a proper answer.

[hubblec4]

@LeMoi

I found some Blurays with multiple Playitems(more then one m2ts) and sometimes a m2ts has other stream settings like the other m2ts files.
MKVToolNix bring this error when you try to combine different streams.

Play file 00009 and 00001 and 00010 and see what is content.
In my chapterEditor (MultiEditionEditor) there is a possibillity to ignore the first and last m2ts file, maybe you could try this.

[Mosu]

I've just released v16.0.0 of MKVToolNix. This release is mostly a bug fix release.

Changes for package maintainers: libMatroska v1.4.8 is now required.

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

All binaries have been built and uploaded.

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

# Version 16.0.0 "Protest" 2017-09-30

## New features and enhancements

* mkvmerge: MP4 reader: added support for Vorbis. Implements #2093 (https://github.com/mbunkus/mkvtoolnix/issues/2093).

## Bug fixes

* configure: the checks for libEBML and libMatroska have been fixed to require libEBML 1.3.5 and libMatroska 1.4.7 as intended.
* mkvmerge: AAC reader: mkvmerge will now emit an error message for AAC files whose header fields imply a sampling frequency or number of channels of 0. See #2107 (https://github.com/mbunkus/mkvtoolnix/issues/2107).
* mkvmerge: AVC/h.264 ES parser: fixed the calculation of reference information for P and B frames. This also fixes some P frames being marked as B frames and vice versa.
* mkvmerge: AVC/h.264 ES parser: only non-key frames that have the NALU header field `nal_ref_idc` set to 0 will be marked as "discardable" in `SimpleBlock` elements. Other half of the fix for #2047 (https://github.com/mbunkus/mkvtoolnix/issues/2047).
* mkvmerge: HEVC/h.265: the generation of the HEVCC structure stored in `CodecPrivate` was wrong in two places: 1. the position of the number of sub-layers was swapped with reserved bits and 2. the VPS/SPS/PPS/SEI lists did not start with a reserved 1 bit.
* mkvmerge: output: the `doc type version` will be set at least to 2 if certain elements are written (`CodecState`, `CueCodecState`, `FlagInterlaced`).
* mkvmerge: output: the track header attributes `MinCache` and `MaxCache` will not be written anymore. Fixes #2079 (https://github.com/mbunkus/mkvtoolnix/issues/2079).
* mkvmerge: Matroska reader: the "key" and "discardable" flags of SimpleBlock elements will be kept as they are. Partial fix for #2047 (https://github.com/mbunkus/mkvtoolnix/issues/2047).
* mkvmerge: Matroska reader: if present in the file, the "white colour coordinate x" track header attribute was written to both "white colour coordinate x" and "white colour coordinate y" in the output file.
* mkvmerge: Opus output: mkvmerge will now put all frames with discard padding into their own block group. Fixes #2100 (https://github.com/mbunkus/mkvtoolnix/issues/2100).
* MKVToolNix GUI: header editor: removed the check for external modification when saving the file. Fixes #2097 (https://github.com/mbunkus/mkvtoolnix/issues/2097).
* MKVToolNix GUI: job queue: fixed calculation of total progress when automatic removal of completed is enabled. Fixes #2105 (https://github.com/mbunkus/mkvtoolnix/issues/2105).

## Build system changes

* libEBML v1.3.5 and libMatroska v1.4.8 are now required. In fact v15.0.0 already requires libEBML v1.3.5 and libMatroska v1.4.7 but did not include proper version checks for them (nor was there a NEWS.md entry for the new libMatroska requirement). New is the requirement for libMatroska v1.4.8 due to it fixing writing block groups for tracks with the track number 128 (see #2103 (https://github.com/mbunkus/mkvtoolnix/issues/2103)).

Have fun :)

[hubblec4]

Hi Mosu

First, thanks for the new version of MTX.

Second, I have a question about the order of the ID's which are used for the switches --video-tracks,--audio-tracks and --subtitle-tracks in an option-json file.
How important is the/your order (min to max).
Example: 1,2,4,7,13,18
Is it ok when I use 1,18,4,2,13,7 ?

After this 3 switches and their values follows a list with the ID's and some other options like --language and so on.
Can I change this order also or is it important to order the ID's (min to max)?

hubble

[sneaker_ger]

Order should be irrelevant. Did you run into problems?

[Mosu]

As long as the options remain in front of the file they apply to and as long as no ID occurs multiple times: the order isn't important, neither the IDs listed with a multi-ID option such as "--audio-tracks", nor multiple single-ID options such as "--language 1:fre". Meaning "--language 1:fre --language 2:ger input.mkv" and "--language 2:ger --language 1:fre input.mkv" are equivalent, as are "--audio-tracks 1,2" and "--audio-tracks 2,1".

If you have multiple options with the same ID, then the last one wins (e.g. in "--language 1:fre --language 1:ger…" the actual language would be "ger").

The order of the different options doesn't matter either: "--language 1:ger --audio-tracks 1" and "--audio-tracks 1 --language 1:ger" are equivalent.

That being said: there are certain options that correspond to other options and that are reset as soon as that other option is encountered. Sounds abstract? Here are two examples:

All options "--attachment-*", e.g. "--attachment-description", apply to the following "--attach-file" or "--attach-file-once" option. "--attachment-mime-type image/jpeg --attachment-description cover --attach-file 1.jpg" and "--attachment-description cover --attachment-mime-type image/jpeg --attach-file 1.jpg" are equivalent, but "--attachment-description cover --attach-file 1.jpg --attachment-mime-type image/jpeg" aren't as the very last "--attachment-mime-type" applies to the following "--attach-file" (which doesn't even exist in my example, meaning it would effectively be ignored).
"--chapter-charset" applies to the following "--chapters …" or the following input file, whichever comes first.

Basically there are two easy to remember rules:

Options apply to whatever comes next that uses that option (input file, chapter file, attachment…).
The order before each input file/chapter file/attachment doesn't really matter.

[hubblec4]

Order should be irrelevant. Did you run into problems?

I hope not, but I want to be sure before I start with coding.

@Mosu
Thanks for this explanation, it makes my task easier.

[LeMoi]

Your error message and all of your screenshots don't match each other:

The error message talks about file 0 being 00009.m2ts. However, the first file (that's the one mkvmerge considers to be file 0) in the list is 00000.m2ts.
The track list doesn't show any appended track even though the file list shows appended files.

This makes is neigh impossible to help you. Please post a screenshot of the GUI's "input" tab (especially so that we can see which file each track belongs to) if you want a proper answer.

I think you misunderstood the screens, or maybe they were not clear (1st screen is from mkvtoolnixgui, other ones from TSMuxerGUI).
First file is 00009.m2ts, not 00000.
Here's the screen from MKVToolnixGUI:
http://nsa39.casimages.com/img/2017/10/01/171001055913477928.jpg

As you can see, the GUI doesn't show any detail about the m2ts files included in the playlist.

I managed to solve the problem by creating my own 'playlist' while appending 00009.m2ts with 00000.m2ts, but I think there's a problem with the program and such playlists

[Ripman]

Thanks for v16 (and v15 too).

[LeMoi]

@LeMoi

I found some Blurays with multiple Playitems(more then one m2ts) and sometimes a m2ts has other stream settings like the other m2ts files.
MKVToolNix bring this error when you try to combine different streams.

Play file 00009 and 00001 and 00010 and see what is content.
In my chapterEditor (MultiEditionEditor) there is a possibillity to ignore the first and last m2ts file, maybe you could try this.

I think that's that is the problem, that's why I suggest that if the program finds many m2ts in the mpls file, and if all m2ts files don't contain the same tracks, it could offer the ability to choose the tracks to append to other ones

[Mosu]

I think that's that is the problem, that's why I suggest that if the program finds many m2ts in the mpls file, and if all m2ts files don't contain the same tracks, it could offer the ability to choose the tracks to append to other ones

Fine-grained track control for the files a single MPLS references won't happen. Would take way too much time rewriting stuff in both the GUI and in mkvmerge.

[hubblec4]

Maybe could Mosu do that, but I think this is a bit much work. Ask him :-)

On such a Bluray, the last m2ts file contains no audio or sub stream. So if you like to keep the last m2ts, you can't use any audio or sub.
I think it is better to ignore such "dummy" m2ts files.

[hubblec4]

As you can see, the GUI doesn't show any detail about the m2ts files included in the playlist.

A "normal" Bluray mpls looks like the same.
No m2ts files are listed.

[LeMoi]

Thanks for your answers, so the easiest way should be to use TSMuxerGUI to know what m2ts files to append, then MKVToolnixGUI to select the wanted tracks from these files. That's what I finally did and would do again if needed

[hubblec4]

Thanks for your answers, so the easiest way should be to use TSMuxerGUI to know what m2ts files to append, then MKVToolnixGUI to select the wanted tracks from these files.

For this simple case it would be ok, but believe me there are some Blurays with more then 40 m2ts files.
It is a huge task to append all this files.

The fastest way is to use chapterEditor(cE).
You get a mtxcfg file with all m2ts files and ordered streams (used or not).
Ok, for the moment is cE (BD2mkv) depent on eac3to.
The new cE (BD2mkv, comming soon) is only depent on MKVToolNix.

[LeMoi]

I rarely need it, usually TSMuxerGUI can provide me a playable file, but this time, for some reason, the video track was corrupted when I remuxed the mpls file with TSMuxer, and fine with MKVToolnixGUI...
Thanks for the tip, I'll try when I need to!

[AYColumbia]

Hi Mosu,
In the last couple versions I've started seeing more of this error:
[O] [2017-10-06] [18:41:37] Error: 'SomeAudioFile.ac3': Reading encrypted VOBs is not supported.
If I try to add the AC3 file to the UI it rejects it with an "Unrecognized file format" dialog that says "The file was not recognized as a supported format (exist code 2)." What's strange is it seems the issue is only on files encoded at 192kbps or 384kbps. This happens with files I reencode from dts for example or those I extract directly at original bit rate of 192 or 384. I'll upload an audio file with this issue shortly. Please let me know if you need any other info. Thank you.

[Mosu]

Thanks for the report. In the future I'd really appreciate it if such issues were raised in the bug tracker (https://github.com/mbunkus/mkvtoolnix/issues/). That generally makes my life easier because I don't have to remember that there was a bug report on e.g. Doom9 or via private mail.

[AYColumbia]

Thanks for the report. In the future I'd really appreciate it if such issues were raised in the bug tracker (https://github.com/mbunkus/mkvtoolnix/issues/). That generally makes my life easier because I don't have to remember that there was a bug report on e.g. Doom9 or via private mail.
I appreciate that. I'll put it in the bug tracker shortly. Thanks again.

[Mosu]

For those not following on Github: the AC-3 detection issue has been fixed. New pre-builds for Windows (https://mkvtoolnix.download/windows/pre/) are available.

[AYColumbia]

For those not following on Github: the AC-3 detection issue has been fixed. New pre-builds for Windows (https://mkvtoolnix.download/windows/pre/) are available.
Wow, that was quick. :) Thank you.

[Mosu]

Yeah… It was one of those issues where I knew in advance exactly what was happening and why; therefore it was easy to verify that assumption and change some things around in order to improve file type detection.

[Megalith]

I am trying to mux Blade Runner but MKVMerge is producing a file that can't be played. I can only assume that it has something to do with the video file being in VC-1 format...

[Mosu]

If it's VC-1, then see this issue (https://github.com/mbunkus/mkvtoolnix/issues/2113).

[Megalith]

Thanks, I had never bothered to look at the pre-builds before.

[burfadel]

I've been using prebuilds for a long while, and this is the first time in a very long time that I've come across an issue with them. For the last couple of prebuilds I get the following messge:
mkvmerge executable was not found. in the GUI when I add a source file, even though the mkvmerge.exe file is in the same folder. If I add audio (opus file) it shows the error, however it adds and it can be muxed. It does not allow additing of the video file though (and the message appears).

In Staxrip 1.7.0.0, which accesses mkvmerge directly, the following error occurs:
Muxing using mkvmerge 15.0.0 failed with exit code: -1073740940 (0xC0000374)

The exit code might be a system error code: A heap has been corrupted.

The version 15.0.0 is there because that's what Staxrip 1.7.0.0 comes with. The video file is h265 with .hevc extension.

The version 16.0.0 works fine.

[Mosu]

Can you please upload one such problematic file to my FTP server (https://github.com/mbunkus/mkvtoolnix/wiki/FTP-server)? Thanks.