MKVToolNix v24.0.0 released

[sneaker_ger]

And I used the append option
"the"? There is more than one.

[VictorLS]

1. You mean "the only one"? No. For example ffmpeg.
First of all - thanks for reply.
I didn't know ffmpeg can split without encoding. What GUI are you prefer or command line only?
2. "split by parts based on[...]" E.g. "00:05:03.200-". This saves everything from 5 minutes, 3 seconds, 200 ms to the end of the file.
Thanks once more!!!
On common: I was need in cut from i.e. 5 minutes, 3 seconds, 200 ms to 7 minutes, 7 seconds, 700 ms and "split by parts based on timecodes" "00:05:03.200-00:07:07.700" solved it...
3. Mkvmerge will split on the next following keyframe. You can't look this up using mkvmerge (no preview).
...with I-frame first.
You need another application to do that.
Do you know any such application except VirtualDub: it's a pity it can not seek I-frames only (even if I press Shift+arrow or key button by mouse) in h265 files I tried.

[Perenista]

I am having a problem with MKVExtractGUI2, the app that comes with MKVToolnix.

Multiple MKV lossless files don't work with it. When you tell the app to extract one track among many, it refuses and ends the command with an "OK" (in fact, it is not extracting any of these tracks, not just one of them).

I had to remove all tracks from another video and let just one in it for this app to extract it. In this second case, two .SUP tracks (Blu-ray subtitles).

Look at the situation below:

http://i.imgur.com/KNjSAzp.png

This is a big file, with more than 25 GB. I can't use MKVToolnix to remove all tracks and let just one, then use MKVExtractGUI2 to extract this track, and repeat this procedure 7 more times.

There's nothing wrong with my MKV file. Why is this happening with random files? I always used MKVExtractGUI2, I don't get why it refuses to work sometimes.

[gpower2]

@Perenista
Actually MKVExtractGUI2 DOES NOT come with MKVToolNix, it is an external GUI application for mkvextract.exe CLI utility that MKVToolNix provides. It is also quite outdated, hence you should either use gMKVExtractGUI or MKVCleaver, as the official MKVToolNix states at the end of the installtion.

Links:
gMKVExtractGUI
http://forum.doom9.org/showthread.php?t=170249

MKVCleaver
http://forum.doom9.org/showthread.php?t=152108

Please ask any questions at the appropriate threads, thanks! :)

[kuchikirukia]

https://picload.org/image/ragdiiii/capture.png

Left is source .ass. Right is read from the MKV after muxing. Timings are screwed up on playback, too.
Demuxing it with gMKVExtractGUI restores it. No delays set.

E: OK, setting all frames to +5ms in Aegisub fixed the timings. mkvtoolnix is still setting a -5ms delay from that, though.

E: also, I've noticed mkvtoonix won't save its settings. Is it set to save that to a directory it doesn't have write access to in Windows?
E2: YUP. I ran it as administrator and it made a mkvtoolnix-gui.ini file in c:\Program Files\mkvtoolnix. That's a no-no. So the installer's default install location and mkvtoolnix's default config save path are incompatible.

[microchip8]

@Mosu,

Any plans in adding Dolby AC-4 support? Is that even doable at this moment? I mean, is there enough info available that is required for adding this new audio codec?

[Mosu]

I don't know; I haven't looked into it yet. This also means that I don't have any information about AC-4 yet, never mind test files.

[SeeMoreDigital]

I don't know; I haven't looked into it yet. This also means that I don't have any information about AC-4 yet, never mind test files.
Hi Mosu,

I suppose you've downloaded all of this: http://www.dolby.com/us/en/technologies/ac-4.html


Cheers

[sneaker_ger]

ETSI has the download(s):
http://www.etsi.org/standards-search#page=1&search=103%20190

But is anyone using it already? Seems to be a contender for ATSC 3.0, haven't seen it in actual use anywhere yet.

[Mosu]

As I haven't looked into AC-4 yet, I also haven't downloaded anything :) But thanks for both links. I will definitely look into implementing AC-4, but I cannot give you guys a time frame.

[Mosu]

Dolby's site doesn't seem to offer sample files. Googling for some reveals nothing either. No sample files, no joy.

[microchip8]

ETSI has the download(s):
http://www.etsi.org/standards-search#page=1&search=103%20190

But is anyone using it already? Seems to be a contender for ATSC 3.0, haven't seen it in actual use anywhere yet.

Well, according to its Wiki page, some broadcasters use it, or at least will be using it (quoting Dolby's page on AC-4). Also Sony has adopted it for its to-be-announced visual products and it's said Samsung's TV models of 2017 will support it. Imagine when more brands get on the bandwagon... yamaha/onkyo/denon/etc

https://en.wikipedia.org/wiki/Dolby_AC-4

[Jamaika]

I ask out of curiosity. Are HEVC UHD movies now Dolby AC-4 in TV or Bluray? :D

Edit: Thanks

[sneaker_ger]

Blu-ray: no
TV: probably not, maybe in the future in some regions

[Mosu]

Left is source .ass. Right is read from the MKV after muxing. Timings are screwed up on playback, too.
Demuxing it with gMKVExtractGUI restores it. No delays set.

mkvmerge does NOT add delays to the timestamps read from an SSA/ASS file, and neither does mkvextract modify them upon extraction. I highly suspect there's a program (filter) in your playback chain that affects the timestamps in such a way.

E: also, I've noticed mkvtoonix won't save its settings. Is it set to save that to a directory it doesn't have write access to in Windows?
E2: YUP. I ran it as administrator and it made a mkvtoolnix-gui.ini file in c:\Program Files\mkvtoolnix. That's a no-no. So the installer's default install location and mkvtoolnix's default config save path are incompatible.

If the GUI tries to store its .ini file in the same directory, then you're running the portable version. That's its purpose: to be able to put both the executables and all of its configuration on a portable device such as a USB thumb drive.

The GUI's code determines wheter or not it's supposed to work as a portable or as an installed version by the presence or absence of the file "data\portable-app".

So there are two things to remember for you:

Don't put the portable version somewhere you need admin rights for.
Don't mess around with the files that come with MKVToolNix. You wouldn't delete arbitrary files in an installation of Microsoft Office either.



If you did use the installer

[kuchikirukia]

mkvmerge does NOT add delays to the timestamps read from an SSA/ASS file, and neither does mkvextract modify them upon extraction. I highly suspect there's a program (filter) in your playback chain that affects the timestamps in such a way.




Nope. Like I showed, that's how it shows up in Aegisub. It's not a playback filter.
Perhaps it has a problem with open GOP?
Figured out what was causing it. It was the Opus track. I think I set a delay for that track (and an AC-3 one) in mkvmerge in a previous mux. Adding subs now causes a -50ms delay when the Opus track is included.

And how the heck do we do strikethrough on this forum? I know I've seen it done.


If the GUI tries to store its .ini file in the same directory, then you're running the portable version. That's its purpose: to be able to put both the executables and all of its configuration on a portable device such as a USB thumb drive.

The GUI's code determines wheter or not it's supposed to work as a portable or as an installed version by the presence or absence of the file "data\portable-app".

Well, that was there. Looking through Recuva it seems I had a v9.1.0 portable downloaded, so I may have copy-pasted that to Program Files to upgrade months ago. Though I had the 9.2.0, 9.3.1, and 9.5.0 installers, and I'm positive I uninstalled and reinstalled when upgrading since. Would uninstalling not clear out the portable-app file?

[sneaker_ger]

Nope. Like I showed, that's how it shows up in Aegisub. It's not a playback filter.
Perhaps it has a problem with open GOP?
Figured out what was causing it. It was the Opus track. I think I set a delay for that track (and an AC-3 one) in mkvmerge in a previous mux. Adding subs now causes a -50ms delay when the Opus track is included.
I highlighted the problem. Aegisub does not show what's in the file. Use a lower level tool like mkvinfo for analyses of such problems and like Mosu said you will see mkvmerge does not alter the ASS timings.
Now the interesting part is Aegisub's behavior when it comes to different audio formats. It reacts to delayed Opus in a strange way which I believe may be unintended (even when keeping encoder delay in mind). The underlying ffms2 should be able to handle delays more cleanly. Maybe I will look closer and report to Aegisub team later.

/edit:
It's related to the 80ms Opus pre-roll. If delay is less than 80ms Aegisub will skew the subtitle timings according to audio delay. Maybe it's a hack that is ugly but intended. Have to ask them...

[kuchikirukia]

I highlighted the problem. Aegisub does not show what's in the file. Use a lower level tool like mkvinfo for analyses of such problems and like Mosu said you will see mkvmerge does not alter the ASS timings.
Now the interesting part is Aegisub's behavior when it comes to different audio formats. It reacts to delayed Opus in a strange way which I believe may be unintended (even when keeping encoder delay in mind). The underlying ffms2 should be able to handle delays more cleanly. Maybe I will look closer and report to Aegisub team later.

/edit:
It's related to the 80ms Opus pre-roll. If delay is less than 80ms Aegisub will skew the subtitle timings according to audio delay. Maybe it's a hack that is ugly but intended. Have to ask them...

Whatever it is, MPC-HC and VLC follow it too since both lose sync. (didn't check any other player as there aren't any relevant ones)

[Mosu]

This release fixes one major bug in mkvmerge (an endless loop) when appending files. It mostly occurred when muxing MPLS playlists. Several other minor bug fixes and usability enhancements were implemented.

Nothing's been changed regarding the packaging since v9.5.0.

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

All of the binaries that I provide myself have been built already and are available for download.

Here's the ChangeLog sincee v9.5.0:

2016-11-29 Moritz Bunkus <moritz@bunkus.org>
* Released v9.6.0 "Slave To Your Mind".

2016-11-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge & mkvextract: added support for HDMV TextST subtitles.

2016-11-20 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: VobSub bug fix: mkvextract will add a "langidx" line to the .idx file upon extraction. Fixes #1810 (https://github.com/mbunkus/mkvtoolnix/issues/1810).

2016-11-14 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: multiplexer enhancement: added a column "source file's directory" to the track list. Implements #1809 (https://github.com/mbunkus/mkvtoolnix/issues/1809).
* MKVToolNix GUI: multiplexer enhancement: added an option for selecting all tracks of the currently selected source files in the source file context menu. Inspired by #1809 (https://github.com/mbunkus/mkvtoolnix/issues/1809).

2016-11-07 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: job output tool bug fix: the button for acknowledging warnings & errors wasn't properly disabled when the user used outside methods of acknowledging them (e.g. via the menu or via the job queue). Fixes #1802 (https://github.com/mbunkus/mkvtoolnix/issues/1802).

2016-10-31 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: MPLS parser bug fix: fixed reading the "in" & "out" timestamps for "play items". This bug resulted in mkvmerge not reading the correct range from the referenced M2TS file under certain rare circumstances.

2016-10-30 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: mkvmerge was entering endless loops under certain conditions when appending files. This was a regression introduced with the fix to #1774 (https://github.com/mbunkus/mkvtoolnix/issues/1774) (using very large --sync values causing mkvmerge to abort).

2016-10-23 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature: added options in the preferences to only show the list of often used languages/country codes/character sets in their respective selections instead of both the often used and the full list. Implements #1796 (https://github.com/mbunkus/mkvtoolnix/issues/1796).

Have fun :)

[hubblec4]

Many thanks for the new version and your continuously work!

2016-10-31 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: MPLS parser bug fix: fixed reading the "in" & "out" timestamps for "play items". This bug resulted in mkvmerge not reading the correct range from the referenced M2TS file under certain rare circumstances.

What exatly was wrong? Your parsing of the "in-out-timestamp" values or is there any special byte-bit reading for special cases?
(from user: manolito which uploaded the Test-Bluray "Run-Moonfans")


2016-11-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge & mkvextract: added support for HDMV TextST subtitles.

Will you add this subtitle format to the Matroska spec page (https://www.matroska.org/technical/specs/subtitles/index.html)?




best regards
hubble

[Mosu]

What exatly was wrong? Your parsing of the "in-out-timestamp" values

My parser code was simply wrong. The timestamps are stored as 32bit unsigned integers with a certain scale, but my code simply didn't use the most significant bit. I don't remember why I initially filtered that bit out.

The result of this bug was that very huge timestamps stored in the MPLS file were interpreted as much smaller timestamps. As the timestamps are used by when reading the corresponding M2TS files (meaning only that content from the M2TS file whose timestamps fit into the range given by the MPLS file is copied) content could be lost.

I don't think that this was a big deal as I haven't received bug reports with matching symptoms. I only stumbled across while investigating an unrelated issue (https://github.com/mbunkus/mkvtoolnix/issues/1801). Even then I only discovered it by comparing my source code with the Blu-ray specs and not because I was actually missing any content in the output file.

Will you add this subtitle format to the Matroska spec page (https://www.matroska.org/technical/specs/subtitles/index.html)?

Yes, but as we're in the middle of formalizing the Matroska specs (latest work on that is on Github (https://github.com/Matroska-Org/matroska-specification/)) I don't know when. It's the same format MakeMKV uses, obviously.

[hubblec4]

Thanks for this reply.

You shared with me the Test-Bluray The Mummy 1 which have HDMV TextST inside. I load this m2ts file to MTX and all subtitle codecs are named with HDMV PGS. Is HDMV PGS and HDMV TextST the "same" or why is there not an other codec name?

[ChaosKing]

Mosu is a "Windows 10 Classic App" (for windows store) mkvtoolnix version planned? Maybe in the near future :D

There are already some "classic" apps available like Kodi https://www.microsoft.com/de-de/store/p/kodi/9nblggh4t892 and Crystal disk mark https://www.microsoft.com/de-de/store/p/crystaldiskmark-5/9nblggh4z6f2

[Mosu]

You shared with me the Test-Bluray The Mummy 1 which have HDMV TextST inside. I load this m2ts file to MTX and all subtitle codecs are named with HDMV PGS. Is HDMV PGS and HDMV TextST the "same" or why is there not an other codec name?

No, they're different codecs. PGS are bitmap graphics whereas TextST are text subtitles. I know that mkvmerge cannot find TextST subtitles in certain discs where MakeMKV can find them, but I don't know why yet. The PMT in the M2TS file doesn't contain an entry for them as far as I can tell. I don't plan on investigating this any time soon.

[Mosu]

Mosu is a "Windows 10 Classic App" (for windows store) mkvtoolnix version planned? Maybe in the near future :D

Neither in the near nor in the far future. As a matter of fact I have no intentions of dealing with stores.

[hubblec4]

Neither in the near nor in the far future. As a matter of fact I have no intentions of dealing with stores.

10 times +1 !!!

[hubblec4]

No, they're different codecs. PGS are bitmap graphics whereas TextST are text subtitles. I know that mkvmerge cannot find TextST subtitles in certain discs where MakeMKV can find them, but I don't know why yet. The PMT in the M2TS file doesn't contain an entry for them as far as I can tell. I don't plan on investigating this any time soon.


Is there a difference when I load the corresponding mpls?

Ok. A HDMV TextST will be found but get the name HDMV PGS, right?

(What is PMT?)

[Mosu]

…and I just realized that mkvmerge does not use the format for CodecPrivate data for TextST subtitles that MakeMKV uses. To be more precise: it uses an older variant¹. I seem to have forgotten to update the code to the new variant.

So maybe you shouldn't use it as-is just yet. You can simply re-mux a Matroska file created by MakeMKV (because here mkvmerge simply copies the CodecPrivate as-is), but you shouldn't re-mux from a Blu-ray (as mkvmerge has to construct the CodecPrivate element manually in this case).

I'll fix that in time for the next release, but I won't release 9.6.1 just for this particular issue.

¹: Background info: at the end of 2014 Mike from MakeMKV and me where debating how to store TextST in Matroska. MakeMKV was already able to do that and used this as the format for CodecPrivate:

One byte: character set used according to "Blu-ray Disc Read-Only Format: table 5-22: Character code"
n bytes: the "dialog style segment"
2 bytes: number of frames in the file

This information partially superfluous, partially harmful. We decided to only allow UTF-8 in Matroska (we only had Blu-rays that used UTF-8 anyway; this gets rid of the first byte). We also decided that having a frame counter served no purpose (the format doesn't need it, nor should players require such information up front), and it made splitting & joining operations harder than they have to be.

Therefore current versions of MakeMKV only include the "dialog style segment" in CodecPrivate, and that's what mkvmerge will do, too.

Note that mkvextract can already deal with both situations.

[Mosu]

Ok. A HDMV TextST will be found but get the name HDMV PGS, right?

No. Those are two different stream/tracks. It's quite common to have both PGS and TextST subtitles on the same disc. Ideally mkvmerge should find both, and I do have one or two samples where this is the case.

PGS is not TextST. Distinct codecs, distinct tracks.

[hubblec4]

No. Those are two different stream/tracks. It's quite common to have both PGS and TextST subtitles on the same disc. Ideally mkvmerge should find both, and I do have one or two samples where this is the case.

PGS is not TextST. Distinct codecs, distinct tracks.

OK.
In the Test-BD The Mummy mkvmerge dont find the TextST track.
Could you share with me a sample where it works, please?

[Mosu]

Could you share with me a sample where it works, please?

The files from VideoLAN's issue 13888 (https://trac.videolan.org/vlc/ticket/13888#comment:2) work.

[Ripman]

Sometimes I rip a BD to mkv and then encode the ripped mkv to generate a new audio track. After encoding, I have two mkv's: one is the exact copy of the source; and the second contains an encoded audio track, as well as a throw-away video track. (I do this when being lazy: I can skip an extraction step and also some command line typing - I encode the source mkv in handbrake with ultrafast and the lowest video quality settings.)

As a final step, I add the source-copy mkv into MKVToolnix and then also add the mkv with the encoded audio track, rearranging tracks as necessary, and de-selecting the throw-away video track from the encoded mkv.

When I mux I get a warning about track id's already being used - see pic. No big deal really bc MKVToolnix renumbers tracks as needed.

Since MKVToolnix is renumbering tracks as appropriate, I wondered if you considered it sensible to change the warning message about track numbers to an informational message. The point being that warnings and errors generally require at least some investigation, while an informational message can largely be ignored.

It's kinda nit-picky, but if you're into it, I'll enter it at github.


https://www.dropbox.com/s/es3syirjr4x97qo/Photo%20Dec%2002%2C%209%2049%2054%20AM.jpg?dl=0

[Mosu]

As track UIDs can be used in other parts of the file to refer to specific tracks (tags, chapters etc.) I consider such an issue important enough to be a warning. You're free to ignore it, of course.

[hubblec4]

Hi Mosu

I have 3 questions.

1: Is there a switch for mkvextract to disable extraction for the statistic Tags?
2: Is it possible to extract a SegmentInfo.xml with mkvextract?
3: Can mkvpropedit save a SegmentInfo.xml into Matroska file?

Thanks a lot
hubble

[Mosu]

1: Is there a switch for mkvextract to disable extraction for the statistic Tags?
2: Is it possible to extract a SegmentInfo.xml with mkvextract?
3: Can mkvpropedit save a SegmentInfo.xml into Matroska file?

The answer to all three questions is "no".

[hubblec4]

Could you imagine to implement this?

[Mosu]

I'm not really motivated to implement any of these three things.

As for using segmentinfo.xml files with mkvpropedit: you can set most of those elements (if not all of them) via mkvpropedit's normal targets already. Check the output of "mkvpropedit -l".

[Mosu]

And as for extracting segmentinfo.xml with mkvextract: you can use mkvmerge's JSON identification mode instead. Again most if not all elements are included in its output.

[hubblec4]

Yup, no problem.
At the moment it is not so important.

The statistics Tags are useful and I recognized when I get a "JSON-identify", ever the longest playtime of all streams will be output, right?

Statistic Tag for the video stream has a SimpleTag named DURATION(unfortunately, still without nanoprecision).
But there are a SimpleTag "NUMBER_OF_FRAMES" and with the right FPS I get a nanoprecision playtime. Is SimpleTag "BPS" equal to FPS?

You said mkvmerge calculate the playtime but stores milli-sec-precision only. Could you expand the DURATON to nanoprecision?

hubble

[Mosu]

I don't want to change an established format; I'd run the risk of existing applications that parse the format to fail. Sorry.

[hubblec4]

I don't want to change an established format; I'd run the risk of existing applications that parse the format to fail. Sorry.

Why and how should a better precision break other tools?

The nanoprecision is used but filled with zeros.
When you change the entry from
01:48:06.240000000 to
01:48:06.240123456 what should happens?

Or could you add a SimpleTag for the FPS?

hubble

[Mosu]

Believe me, my experience is that parsers break in the most interesting ways. For example: extending the number of digits will change their meaning. If a parser simply parses everything after the . as a number and then treats that number as meaning "milliseconds", then this works nicely with the current format. However, it will break horribly if I extend the number of digits because suddenly there are nine digits that the existing parser still treats as milliseconds even though they're supposed to be nanoseconds now.

It's just too risky.

No, I won't add other tags at the moment either. Sorry.

[filler56789]

@Mosu:

http://forum.videohelp.com/threads/381703-32GB-limit-in-MKVExtract-MKVCleaver

0_o

[Mosu]

@fillter56789: I've created builds (https://mkvtoolnix.download/windows/pre/) where I've re-defined the maximum number of chunks to 1024. The resulting maximum AVI file size should be 1 TB. I haven't tested it, though, as I don't have files that big.

[filler56789]

@fillter56789: I've created builds (https://mkvtoolnix.download/windows/pre/) where I've re-defined the maximum number of chunks to 1024. The resulting maximum AVI file size should be 1 TB. I haven't tested it, though, as I don't have files that big.

Many thanks for the attention.

[ChaosKing]

With the old version MKVToolNix (mmg) it was possible to copy the command line that was used/generated by mmg. Is this still possible with the new gui? I can't see such option there.

Edit:
I'm blind! Found it under "Multiplexer"

[sneaker_ger]

"Multiplexer">"Show command-line". There's a button "Copy to clipboard".

[gpower2]

I believe I stumbled upon a bug in the mkvmerge --identify output. With certain mkv files (created with MKVToolNix v9.3.1 in case it is relevant) mkvmerge --identify returns an output that contains two lines for the last track instead of one.
For example, I get the output:
Track ID 7: subtitles (SubRip/SRT) [codec_id:S_TEXT/UTF8 codec_private_length:0 default_track:0 enabled_track:1 forced_track:0 language:spa minimum_timestamp:7508000000 number:8 text_subtitles:1 track_name:Spanish
uid:11397892480729494287]

instead of:

Track ID 7: subtitles (SubRip/SRT) [codec_id:S_TEXT/UTF8 codec_private_length:0 default_track:0 enabled_track:1 forced_track:0 language:spa minimum_timestamp:7508000000 number:8 text_subtitles:1 track_name:Spanish uid:11397892480729494287]

I made a quick fix for it in gMKVExtractGUI's parser, but I wanted to report it here in case a better fix could be made.

PS.
I could upload a test file to your ftp if you'd like. ;)

[Mosu]

Looks like mkvmerge isn't escaping newlines. You still should use the JSON output, though…

[gpower2]

I will, at some point, write the parser for the JSON output, however since I'm going for backwards compatibility, I have to be really carefull not to break the existing code and I have to decide which MKVToolNix version and afterwards I will read the JSON output instead of the plain text one.

Are you thinking of deprecating the plain text output at some point?