MKVToolNix v24.0.0 released

[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]

Originally Posted by kuchikirukia

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

Can't agree more, I just gave up the app for this reason...

[Boulder]

Originally Posted by kuchikirukia

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

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

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]

Originally Posted by kuchikirukia

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.

Originally Posted by ndjamena

??? 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.

Originally Posted by kuchikirukia

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

Originally Posted by wanezhiling

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]

Originally Posted by 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?

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:

1. The AC-3 core is dropped from that track.
2. 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 (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]

Originally Posted by kuchikirukia

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]

Originally Posted by ndjamena

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, the Windows installer and portable version and the source code.

Here's the full 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.
* 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.
* 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.
* 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.

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.
* 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.
* mkvmerge: bug fix: the h.265/HEVC code was writing SEI NALUs twice. This had already been mentioned in #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 and #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 and #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.

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.
* 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.

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.
* 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.

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.
* 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.

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.
* 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.
* 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.
* mkvpropedit: new feature: added an option "--update-attachment" for updating the properties of existing attachments without replacing their content. Implements #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.

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.
* 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.

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.

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]

Originally Posted by ndjamena

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]

Originally Posted by 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?

Hmmm...

Which MKV muxer does MakeMKV use?

[nevcairiel]

Originally Posted by SeeMoreDigital

Which MKV muxer does MakeMKV use?

MakeMKV have their own.

[SeeMoreDigital]

Originally Posted by nevcairiel

MakeMKV have their own.

Indeed, so I guess there could be an issue with their muxer

[Chetwood]

Originally Posted by sneaker_ger

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.