MKVToolNix v24.0.0 released

[Frechdachs]

I don't know from the top of my head. The latest "stable" Aegisub is quite old and there have been delay bugfixes in ffms2 in the meantime. Might want to check a recent trunk build (http://plorkyeran.com/aegisub/).
Thank you very much. I updated from r8700 to r8792 and it actually solved the problem with qaac and Nero! There have been three updates to ffms2 since. Completely forgot about that. I'm used to rarely update Aegisub, since I know from my own experience that recent trunk builds can be highly unstable.

However, I did another test with FDK AAC. After muxing with mkvmerge there is still a positive delay of ~40ms according to Aegisub. My fdk_aac enabled ffmpeg build was build on 03/24/2014, though. So it would be nice if someone with a recent build can test that also. I assume the priming should be stored somewhere in the metadata of the .m4a by the encoder, right? Or is it hardcoded in mkvmerge depending on the used encoder?
Additional samples. (https://0x0.st/-VW.7z)

[sneaker_ger]

The delay values mkvmerge uses are not hardcoded (not that there is any good way to detect the encoder used in the first place). It can use two different infos:
- proprietary Apple atom ("iTunSMPB")
- mp4 edit list
QAAC, Nero and fhgaacenc write the Apple atom by default, (qaac has an option to choose one or write both IIRC).

Your ffmpeg/fdk_aac sample does not have this atom. It does have an edit list, though, and from what I can see mkvmerge does not obey it. I'm not sure why. Either it's a bug or it's a feature since there is no other track to sync it to (read: no other tracks to delay). Mosu should be able to comment on that.

/edit:
I think this is relevant, i.e. it's by design and not considered a bug (last 4 posts):
https://github.com/mbunkus/mkvtoolnix/issues/780

Can't say I agree with it but it seems that's how Mosu thinks about the issue.

[Frechdachs]

Well, thanks for clearing that up.

I guess, I'll just refrain from using FDK AAC for video files for now.

[ndjamena]

The Frame Count in the tags for PGS Subtitles is twice the number of actual subtitles as confirmed by both eac3to and DVDSubextractor.

Extracting the cues for the subtitle track shows the double count though.

Is this normal for PGS? Is there an end of caption frame for each display frame maybe? Is there ever LESS than double (or possibly more)?

[sneaker_ger]

Is this normal for PGS? Is there an end of caption frame for each display frame maybe?
Yes.
http://forum.doom9.org/showthread.php?p=1736749#post1736749

[ndjamena]

Crap.

I thought Matroska had it's own frame duration and removed that kind of nonsense from the streams.

The Count of Elements added to MediaInfo is still kind of useful, but now I'm wondering.

Since SDH encoded in "Closed Caption" mode (with a black background) comes out having a smaller size than regular subtitles (despite having more frames), now it's possible a SDH subtitle could have less frames as well if the regular subtitle over-uses clear-screen frames where the SDH doesn't.

*sigh*

So much for trying to be clever. It should make forced subtitles stand out at least.

[sneaker_ger]

I thought Matroska had it's own frame duration and removed that kind of nonsense from the streams.
I was talking about raw .sup files. Empty frames should not be needed within the mkv container because we have the BlockDuration element. That said, I have never taken a closer look as to how mkvmerge does it - maybe they are kept? Should be fairly simple to see in e.g. mkvinfo.

[ndjamena]

Yup, every second frame is 36 or 37 bytes in size.

That would be why MakeMKV sometimes copies several non-forced frames into the forced track if they're directly after a forced frame. I suppose a Blu Ray player just treats non-forced frames as clear-alls in a forced situation.

[foxyshadis]

Is there any PGS or Blu-ray spec document available yet? That would really help with some of the strange corner cases....

[sneaker_ger]

Is there ever LESS than double (or possibly more)?
Since mkvmerge seems to treat the empty frames just like normal ones (except for calculating end the time of previous frames) it means you may happen to cut to uneven counts of subtitle frames if you cut in a middle of one. I.e. you might get a stray empty one at the beginning of a file or a regular frame without an empty one at the end. This also means you cannot guess correctly even if you know this. A count of 41 might mean a stray empty one at beginning (=20 "real" frames) or a missing empty one at the end (=21 "real" frames).

[kuchikirukia]

Would it be possible to get a Split By Chapter option that only output the selected chapter(s)? When I split by chapter it's almost always because I want only certain chapters, not the entire video.
"Split selected chapters," would be nice.

[Mosu]

Would it be possible to get a Split By Chapter option that only output the selected chapter(s)? When I split by chapter it's almost always because I want only certain chapters, not the entire video.
"Split selected chapters," would be nice.

It's unlikely that I'll implement such an option. Sorry. I'd welcome patches that add such an option, though, I just don't want to spend time on it myself.

[Mosu]

I reproduced the error, here's the job queue file: https://drive.google.com/file/d/0BzeF_1syecQwQllKbTRkSlBqUTA/view?usp=sharing

Thanks for the file. Are you sure this is the right file? Its content shows that the job hasn't been run yet – the end date isn't set and the job output is empty.

Just in case I've tried to reproduce it by creating a similar setup (same file types, same file names, same numbers and types of tracks) here – still no dice.

In the queue file I can see that you're muxing two files appending the second one to the first one. How big are those two files (in bytes)? Are you using the 32bit or the 64bit variant of MKVToolNix? Which MKVToolNix version? And are you 100% sure you've sent me the correct job queue file?

[Boulder]

Thanks for the file. Are you sure this is the right file? Its content shows that the job hasn't been run yet – the end date isn't set and the job output is empty.

Just in case I've tried to reproduce it by creating a similar setup (same file types, same file names, same numbers and types of tracks) here – still no dice.

In the queue file I can see that you're muxing two files appending the second one to the first one. How big are those two files (in bytes)? Are you using the 32bit or the 64bit variant of MKVToolNix? Which MKVToolNix version? And are you 100% sure you've sent me the correct job queue file?It's a correct file, I just reproduced the issue with a different movie and it also contains "null" for dateFinished and dateStarted.

I'm using the 64-bit version of mkvmerge v8.6.1. I can reproduce the issue with many but not with all files. It also occurs via the command line so it's not a GUI problem.

In this latter case, the first file is 4564850985 bytes and the next file is 1528773206 bytes. They were created using the link files option.

https://drive.google.com/file/d/0BzeF_1syecQwSGlyOTIxQndjSFU/view?usp=sharing

[Mosu]

Yeah I can reproduce the issue now. It's only triggered with files that were split using linking. Thanks for the input. I'll fix it.

[Mosu]

Oh, and the reason the job file was still showing "dateFinished" set to null is that the job queue is only saved when you exit the program.

[Mosu]

Fixed in pre-builds 1049 & 1050 (https://mkvtoolnix.download/windows/pre/).

[ndjamena]

Did you know AnyDVDs CloneBD has been muxing TrueHD into Matroska files with the embedded AC-3 core intact.

Is this a problem? Is this moving in a direction you're willing to support?

[Mosu]

Nothing's changed for me. I still consider embedded AC3 in TrueHD in Matroska to be non-compliant. I'm sure players will play it just because they also have to support TrueHD+AC3 in M2TS etc. But mkvmerge never will.

[ndjamena]

OK then. They've also added a duration tag without the security tags, there's some crap in the tags that are just targets with no values and they seem to be marking every track as default (or at least NOT marking any as NOT being default).

I'm just testing it out and am commenting on what I've found. Really, if I were to decide to use the program all I'd want from MKVMerge at the moment is the ability to strip the AC-3 core during remux, but if you don't want to touch it I understand perfectly.

It has potential but it has a long way to go before it can be considered a viable replacement for MakeMKV.

[Mosu]

I'm… actually not certain how mkvmerge treats TrueHD+AC3 when reading it from a Matroska file as I don't think that I've ever had a sample file to work with. It's possible that the AC3 core is simply dropped. I don't think that the AC3 core would be presented as an extra track as mkvmerge does with e.g. M2TS as that requires extra work from me for each demuxer, and as I have no sample file I don't think I implemented such support in the past.

I would be willing to work on improving this so mkvmerge treats the embedded AC3 core like a separate track just like in M2TS. My earlier "mkvmerge doesn't support" was only meant to say that mkvmerge won't create such files itself.

[Selur]

would be interested in such a sample too :)

[ndjamena]

I extracted the track with MKVExtract, then remuxed the elementary stream using MKVMerge and wound up with a fully functional AC-3 track, so its definitely there.

MPC-HC doesn't like the file at all. It seems to think it's 20 hours long and there's definitely something wrong with the audio. I think it might be trying to play two tracks at once, but one of the tracks seems to be from a different part of the movie.

Remuxing with MKVMerge didn't fix any of that, the AC-3 core was still present, I could still extract the TrueHD and remux the AC-3 from the elementary stream, and the movie was still 20 hours long. Remuxing without the TrueHD/AC-3 track restored the file to its proper duration.

I could probably split off a few seconds of the file for you to play with if you like. Remuxing doesn't seem to affect anything.

[nevcairiel]

MPC-HC doesn't like the file at all. It seems to think it's 20 hours long and there's definitely something wrong with the audio. I think it might be trying to play two tracks at once, but one of the tracks seems to be from a different part of the movie.

Thats why its considered non-compliant. There is no clean way to split the tracks without careful bitstream parsing. In m2ts, there is metadata that identifies the embedded ac3 core, so you can read that and split it cleanly without any knowledge of the stream layout itself. Without such metadata, splitting the TrueHD from the AC3 core is serious effort. In fact, I would consider a m2ts demuxer "broken" if it doesn't split the TrueHD and AC3 into distinct tracks (or at least drops one of them), since they *are* just that.

So, just don't create those tracks, ever, and software that does is plain broken.

[ndjamena]

You make it sound like I was happy to find out what it had done.

I was actually hoping it would help me split certain play alls into individual episodes but it's not very good at that either.

Still, the thing is still in early development and it's more likely to get such a feature implemented properly before MakeMKV, especially since it should be doing it already, it's just a pain in the arse to use. If this is how it's going to treat TrueHD then anyone who uses it has to work with that.

My concern isn't inflicting absolute support for embedded AC-3 cores in TrueHD on the Matroska world, it's getting rid of that damn core from the stream without having to demux it from the file. I've been told MKVMerge should be able to read from any matroska file, whether it complies absolutely with the specs or not, it just won't make one that doesn't. I don't know how far that stretches in reality but this situation would seem to be a likely candidate.

[ndjamena]

AC-3 has frames with a duration of 32ms or 31.25fps.

According to MediaInfo TrueHD has a frame rate of 1200fps or a duration of 0.833..ms.

According to MKVInfo each frame is the file is 32 ms long, but 32 doesn't divide cleanly by 0.833..

The frames have a variable size so I'm assuming they can't be all AC-3, which means a variable number of TrueHD frames must be packaged with each AC-3 frame in the file.

So since MKVMerge can identify it and remux it perfectly after MKVExtract has extracted it, I'm assuming it must be nothing but an elementary stream cut at the start of each AC-3 frame, with each section placed in a single Matroska frame.

If that makes sense.

[SeeMoreDigital]

Did you know AnyDVDs CloneBD has been muxing TrueHD into Matroska files with the embedded AC-3 core intact.Out of interest, have you tried directly muxing these .mkv files into the .m2ts container using TSmuxerGUI?... Does it accept or reject them?

I would be willing to work on improving this so mkvmerge treats the embedded AC3 core like a separate track just like in M2TS. My earlier "mkvmerge doesn't support" was only meant to say that mkvmerge won't create such files itself.If you are able to do this I will arrange to have some samples sent to OppoDigital and Panasonic ;)

[ndjamena]

TSMuxer still rejects it.

Interestingly enough after converting the file to be spec compliant using MKVMerge the original rip is still 4 mb small than the new one. Simply remuxing the original file without correcting it results in a file that's almost 80 mb smaller than the spec complaint version.

Considering the AC3 core is over 5gb and (unless you're stuck with badly outdated audio equipment) is completely redundant, just removing the thing would still be preferable though.

They "solved" the "problem" of the TrueHDs AC-3 core, and they "solved the problem" of TrueHDs miniscule frame size. I seem to recall both issues have come up recently...

[Mosu]

Can you please upload a sample file created by AnyDVD to my FTP server? It doesn't have to be the full file; just stop uploading after 100 MB or so. Assuming the track headers are located at the front this should still be readable. Thanks.

[ndjamena]

I uploaded a little over 200mb of Age of Extinction.

It may be a moot point for me at least. I just discovered AnyDVD don't accept MasterCard, and my trial expires soon.

But other people may find anything you can do with it useful though.

[Mosu]

Thanks for the file. I can work with it and will investigate.

[kuchikirukia]

So you can't add custom command lines to mkvmerge anymore?

This MKVtoolnix GUI is sooo much worse than the old mkvmerge.

[wanezhiling]

This MKVtoolnix GUI is sooo much worse than the old mkvmerge.
Can't agree more, I just gave up the app for this reason... :o

[Boulder]

So you can't add custom command lines to mkvmerge anymore?

This MKVtoolnix GUI is sooo much worse than the old mkvmerge.
:confused:

The additional options are in the Output tab.

[ndjamena]

??? Is the pre I'm using really that more advanced than what you guys have?

There's 'additional options' fields in the properties of each track and another one in the output tab.

Unless you feel the need to add entire input files via extra command lines I don't see why you'd need anything more...

...(or is this just a deliberate attempt to not look properly just to have an excuse to protest the perceived slight inflicted by daring to change something you'd gotten used to.)

To be honest I use the actual command line FAR more than I use the GUI, and despite rarely ever using it I've had zero problems migrating from MMG to MKVToolNix GUI.

[Mosu]

So you can't add custom command lines to mkvmerge anymore?

You can change the additional options for the current mux settings on the "output" tab, bottom right, inside the "Miscellaneous" group. The button next to the input will open a dialog presenting all known extra options you cannot set otherwise in the GUI.

Changing the additional options for all future mux settings can be achieved both from the aforementioned dialog (there's a checkbox at the bottom to use the current options for all future settings, too) and from the "preferences". You'll find the input with its associated button on the "Merging" tab; it's called "Default additional command line options" there.

??? Is the pre I'm using really that more advanced than what you guys have?

No :) These two controls have been part of the new MKVToolNix GUI release ever since its first official release in 8.3.0.

This MKVtoolnix GUI is sooo much worse than the old mkvmerge.
Can't agree more, I just gave up the app for this reason...

What exactly don't you like? Are there particular features that you're missing? Does it do things you don't want it to (if so, which)? Please be speciffic, because then I can maybe help you discover features about the GUI you didn't know exist; or I can point you to how you can change the GUI's behavior.

[Mosu]

Did you know AnyDVDs CloneBD has been muxing TrueHD into Matroska files with the embedded AC-3 core intact.

Is this a problem? Is this moving in a direction you're willing to support?

Thanks again for the test file. Your observation that simply re-muxing such a file with mkvmerge was keeping the track intact (including its AC-3 core) was indeed correct. The reason is that up to and including the latest release mkvmerge was using its "pass-through" packetizer for TrueHD tracks instead of using its specialized TrueHD packetizer. This seems to be an omission, and I've changed this since.

Now the TrueHD packetizer is used. The immediate effect is that twofold:

The AC-3 core is dropped from that track.
The TrueHD packets that are currently grouped into a single Matroska block are split up properly into separate blocks.

Now the re-muxed files are spec-compliant again.

This was step one. You can check the result in the latest pre-builds (https://mkvtoolnix.download/windows/pre/) (1080 32bit, 1081 64bit).

I will most likely implement exposing the AC-3 core as a separate track just like it's done for the M2TS reader and other readers, too.

[ndjamena]

The file muxed perfectly, MPC-HC now shows the correct duration and the audio sounds fine.

Have you thought about how to output the info in -I mode? Is it just going to be a property of the TrueHD track or will it be listed as a separate track?

Listing it as a separate track could be a problem for MKVExtract and/or MKVPropEdit. NOT listing it as a separate track could be a problem for MKVMerge GUIs, unless you're happy to scrap the core by default and only rescue it if specifically told to.

[Mosu]

I'm not sure yet. Yes, the track numbering would be a big problem for mkvpropedit and mkvextract. For the time being I will likely only drop the AC-3 core and NOT expose it as a separate track. I don't think this would be too much of a problem: in Matroska TruehHD+AC-3 core inside a single track is non-compliant whereas in M2TS it is compliant or even required. Therefore simply dropping it when reading shit from Matroska would be fine with me.

I also don't want to encourage using TrueHD+AC-3 inside Matroska any more than I have to, and supporting this just like any other track would signal validity where there is none.

[ndjamena]

Assigning things like names or track order to a rescued AC-3 core during remux would be a pain too if you don't output it with its own TrackID, unless you just duplicate whatever has been assigned to the TrueHD and let the CodecID do the talking. There are a bunch of things you could do that you most likely can't be bothered doing. You COULD output it with its own TrackID, and then if MKVPropEdit or the header editor is pointed at it, create a new header for the AC-3 track with the same track number as the TrueHD track. That's how I envision 608 caption data would work in Matroska, with CC1 and CC2 muxed into the same track, but each given their own header differentiated only by their CodecIDs (S_EIA608-CC1, S_EIA608-CC2 or something), it could work just as well for TrueHD and it's core. And if MKVExtract is told to extract the core... extract the core, if it's told to extract the core and the TrueHD into the same file then that shouldn't be too hard.

*sigh* I'd been meaning to try pointing two headers at the same track and remuxing with MKVMerge to see what would happen, I almost did it accidently with subtitles but cancelled before seeing what happened to the output.

I guess I should just check if Subtitle Edit or CCExtractor can read 608 captions from mp4s properly yet...

I have a few days to figure out if I should buy CloneBD without AnyDVD or bits and pieces from the DVD Fab suite before all the sales end... Decide whether I feel up to spending actual money to put up with the bugs, limitations and other crap from yet more programs.

[SeeMoreDigital]

This MKVtoolnix GUI is sooo much worse than the old mkvmerge.How strange... I think it's much easier :)

[ndjamena]

Does anyone happen to know if the Oppo BD-93 has problems with Track Statistics Tags?

[SeeMoreDigital]

Does anyone happen to know if the Oppo BD-93 has problems with Track Statistics Tags?I can't help you with the Oppo BD-93 but I can confirm that the Oppo BDP-10x range of players are okay with them ;)

[Mosu]

Hey,

here's the last release for this year: 8.7.0. This release contains a more even mix of bug fixes and enhancements. One area that has received special attention is the HEVC/h.265 code where multiple issues have been fixed. I strongly urge everyone to upgrade if you're dealing with HEVC/h.265 in Matroska.

The enhancements and new features include:

a reworked preferences dialog in the GUI
a rather flexible method of running arbitrary programs after the GUI has finished a job or the whole queue
more items output in verbose & JSON identification modes
more options for dealing with attachments and track statistics tags in mkvpropedit

I've also decided to revert the change to writing byte order marks (BOMs) for UTF-8 encoded files that was introduced in the last release. This was due to user feedback. A common workflow is to extract subtitles to an extern file, to edit them somehow and to mux the back. On Windows this became annoying without BOMs: the extracted text files are UTF-8, but mkvmerge defaults to Windows' own locale when reading text files – unless a BOM is found.

Another change I've reverted due to user feedback is the removal of several ISO 639-2 codes for very old languages. Certain users have used those codes to indicate variations to the default language, and the earlier removal broke this workflow.

Nothing has changed for package maintainers compared to v8.6.1.

The Windows and Mac OS binaries are available. Most of the Linux binaries are still being built and will be available in a couple of hours.

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

Here's the full ChangeLog (https://mkvtoolnix.download/doc/ChangeLog) since the previous release:

2015-12-31 Moritz Bunkus <moritz@bunkus.org>
* Released v8.7.0.

2015-12-30 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed the handling of a PES size of 0 ( = unknown). Tracks whose PES packets had such a size were sometimes not detected at all, and even if they were their content was incomplete. Fixes #1553 (https://github.com/mbunkus/mkvtoolnix/issues/1553).
* mkvmerge: bug fix: made the MPEG 1/2 video elementary stream file type recognition more resilient and more flexible dropping the requirement for a file to start with an MPEG start code (0x00 00 01). Fixes #1462 (https://github.com/mbunkus/mkvtoolnix/issues/1462).
* mkvpropedit: bug fix: when changing the track language it is now verified to be a valid ISO 639-2 language code before writing it to the file. Fixes #1550 (https://github.com/mbunkus/mkvtoolnix/issues/1550).
* mkvmerge: enhancement: the MP4 reader will keep the display dimensions from the track header atom ("tkhd") and use them as the display width & height. See also #1547 (https://github.com/mbunkus/mkvtoolnix/issues/1547).

2015-12-29 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: the "add source files" button now has optional popup menu containing actions for adding/appending files and adding files as additional parts for easier discovery of those actions. This popup is only shown if the user clicks on the arrow shown on the right of the button.
* mkvmerge: new feature: TrueHD tracks that contain Dolby Atmos will be identified as "TrueHD Atmos". Implements #1519 (https://github.com/mbunkus/mkvtoolnix/issues/1519).
* mkvmerge: bug fix: the Matroska reader now uses TrueHD-specific code when reading Matroska files. This can fix things like wrong frame type flags.

2015-12-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: MP4 edit lists of certain types (two entries, first entry's media_time is -1, second entry's segment_duration is != 0) weren't handled properly resulting in key frame flags being assigned to the wrong frames. Fixes #1547 (https://github.com/mbunkus/mkvtoolnix/issues/1547).
* mkvmerge: bug fix: the h.265/HEVC code was writing SEI NALUs twice. This had already been mentioned in #1076 (https://github.com/mbunkus/mkvtoolnix/issues/1076) but never fixed. Patch by Vladimír Pilný.
* mkvmerge: bug fix: the h.265/HEVC code wasn't converting slice NALUs to RBSP form before parsing it resulting in wrongly timestamped frames under certain conditions. This is a similar fix to the issues reported in #918 (https://github.com/mbunkus/mkvtoolnix/issues/918) and #1548 (https://github.com/mbunkus/mkvtoolnix/issues/1548).
* mkvmerge: bug fix: the h.264/AVC code wasn't converting slice NALUs to RBSP form before parsing it resulting in wrongly timestamped frames under certain conditions. Fixes #918 (https://github.com/mbunkus/mkvtoolnix/issues/918) and #1548 (https://github.com/mbunkus/mkvtoolnix/issues/1548).
* mkvmerge: bug fix: the MP4 reader can now understand the 'random access point' sample grouping information for marking open GOP random access points as key frames. Fixes #1543 (https://github.com/mbunkus/mkvtoolnix/issues/1543).

2015-12-27 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed the decisions whether or not to write the last frame of a track as a BlockGroup or a SimpleBlock and whether or not to write a block duration for that frame. Fixes #1545 (https://github.com/mbunkus/mkvtoolnix/issues/1545).
* MKVToolNix GUI: new merge tool feature: added menu options in the "Merge" menu for copying either the first source file's name or the current output file's name into the "file title" control.

2015-12-22 Moritz Bunkus <moritz@bunkus.org>
* mkvpropedit: new feature: added an option for calculating statistics for all tracks and adding new/updating existing statistics tags in a file. Second half of the implementation of #1507 (https://github.com/mbunkus/mkvtoolnix/issues/1507).

2015-12-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: the progress calculation was sometimes outputting negative numbers when appending Matroska files whose timestamps don't start at 0 (e.g. if they were created by splitting with linking enabled). In the the GUI this resulted in lines like "#GUI#progress -2%" in the job's output.
* mkvpropedit: new feature: added an option for removing all existing track statistics tags from a file. Part of the implementation of #1507 (https://github.com/mbunkus/mkvtoolnix/issues/1507).
* mkvmerge: bug fix: AAC with low sampling frequencies was sometimes mis-detected with the wrong profile preventing appending it to other AAC tracks. Fixes #1540 (https://github.com/mbunkus/mkvtoolnix/issues/1540).

2015-12-17 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: chapters were output as both "chapters" and "track_tags" in JSON identification mode. Fixes #1538 (https://github.com/mbunkus/mkvtoolnix/issues/1538).
* mkvmerge: enhancement: added the container's internal track ID as the "number" attribute in verbose & JSON identification modes for several container types (QuickTime/MP4: the track ID from the 'tkhd' atom; MPEG program stream: the sub-stream ID in the upper 32 bits and the stream ID in the lower 32 bits; MPEG transport stream: the program ID; Ogg/OGM: the stream's serial number field; RealMedia: the track ID). Implements #1541 (https://github.com/mbunkus/mkvtoolnix/issues/1541).

2015-12-16 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: the "split mode" drop-down box got reset to "do not split" each time the preferences dialog was closed with the "OK" button. Fixes #1539 (https://github.com/mbunkus/mkvtoolnix/issues/1539).
* mkvmerge: enhancement: if JSON identification mode is active then warnings and errors will be output as JSON as well. They're output as arrays of strings as the keys "warnings" and "errors" of the main JSON object. Implements #1537 (https://github.com/mbunkus/mkvtoolnix/issues/1537).
* all: reversion of a change: several ISO 639-2 codes of languages that are very old and not spoken anymore have been re-added (e.g. "English, Middle (1100-1500)") due to feedback from users who did have a use for such codes.
* all: reversion of a change: all of the tools will write a byte-order mark (BOM) to text files encoded any of the UTF-* schemes again. This reverts the change in release 8.6.0 due to user feedback preferring the old way.

2015-12-12 Moritz Bunkus <moritz@bunkus.org>
* mkvpropedit: enhancement: when using --add-attachment, --replace-attachment or --update-attachment the UID can be changed with --attachment-uid. See #1532 (https://github.com/mbunkus/mkvtoolnix/issues/1532).
* mkvpropedit: new feature: added an option "--update-attachment" for updating the properties of existing attachments without replacing their content. Implements #1532 (https://github.com/mbunkus/mkvtoolnix/issues/1532).

2015-12-11 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature: added options for running arbitrary programs after a job has finished or after the queue has finished. Implements #1406 (https://github.com/mbunkus/mkvtoolnix/issues/1406).

2015-12-09 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: if files are dragged & dropped from an external application with the right mouse button being pressed then the GUI will always ask the user what to do with the files even if the user has configured the GUI not to ask. Implements #1508 (https://github.com/mbunkus/mkvtoolnix/issues/1508).
* MKVToolNix GUI: enhancement: when starting the GUI with a saved settings file then the GUI won't contain an empty tab in the merge tool anymore. Fixes #1504 (https://github.com/mbunkus/mkvtoolnix/issues/1504).

2015-12-08 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed the key frame detection for VP9 video tracks.
* MKVToolNix GUI: bug fix: relative file names given on the command line were interpreted as being relative to the user's home directory. Fixes #1534 (https://github.com/mbunkus/mkvtoolnix/issues/1534).

2015-12-01 Moritz Bunkus <m.bunkus@linet-services.de>
* MKVToolNix GUI: the preferences dialog has been reworked heavily in order to provide a better overview and to be less overwhelming.

Have fun :)

[sneaker_ger]

Does anyone happen to know if the Oppo BD-93 has problems with Track Statistics Tags?
Tags aren't exactly a new feature, are they? I have not seen any reports whatsoever about related playback problems.

[ndjamena]

Someone on the MakeMKV forum is complaining that the latest version is messing up the playback of subtitles for no player other than his oppo 93. As far as I'm aware the only thing that's changed is the addition of statistics tags. Should the oppo even be touching them?

[SeeMoreDigital]

Someone on the MakeMKV forum is complaining that the latest version is messing up the playback of subtitles for no player other than his oppo 93. As far as I'm aware the only thing that's changed is the addition of statistics tags. Should the oppo even be touching them?Hmmm...

Which MKV muxer does MakeMKV use?

[nevcairiel]

Which MKV muxer does MakeMKV use?

MakeMKV have their own.

[SeeMoreDigital]

MakeMKV have their own.Indeed, so I guess there could be an issue with their muxer ;)

[Chetwood]

Tags aren't exactly a new feature, are they? I have not seen any reports whatsoever about related playback problems.
You should check out a file muxed with global tags/tags for track 0 on the WDTV then. After 5 min max it stops playing and only remuxing will fix this.