MKVToolNix v24.0.0 released

[burfadel]

Uploaded a short video and related audio clip of an early 80's TV show under a folder with my username. The video file does not work on any test build past mkvtoolnix-64-bit-16.0.0-build20171001-01570-f3ebd6ba7. The error message displayed is added as an image file. If the video file appears to get added muxing still isn't successful. Ryzen 1700X on Skip Ahead build 17004 if that affects anything :).

[Mosu]

Thanks. I'll look into it.

BTW, same request as before to AYColumbia: 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. Thanks.

[Mosu]

The HEVC problem should be fixed in the latest pre-builds (https://mkvtoolnix.download/windows/pre/).

[burfadel]

Thanks! Works :)

[Thunderbolt8]

is there any current known limitation when it comes to remuxing of UHD BDs regarding the dolby vision metadata? is that data transferred over into the .mkv correctly as well, just as it is the case with HDR information?

[Mosu]

Just yesterday a user contacted me and reported that Dolby Vision data seems not to be transferred if HDR is used at the same time. He also provided a couple of sample files. However, as I have neither knowledge about Dolby Vision is stored in the first place nor how I can verify whether or not Dolby Vision is present in the output file, I cannot really do anything about this at the moment. The reporting user only said his TV showed whether or not it is present — which doesn't help me one bit, though.

[nevcairiel]

Its doubtful Dolby Vision in MKV would work on any TV. There is no specification how it should be contained in it. Its only specified for MPEG-TS and MP4, as far as I know, and requires additional metadata beyond the codec stream, and/or depending on the Dolby Vision profile, even two separate streams.

[SeeMoreDigital]

Its doubtful Dolby Vision in MKV would work on any TV. There is no specification how it should be contained in it. Its only specified for MPEG-TS and MP4, as far as I know, and requires additional metadata beyond the codec stream, and/or depending on the Dolby Vision profile, even two separate streams.On a slightly different note... I have managed to mux some BBC/NHK HLG (Hybrid Log-Gamma) HDR samples into the MKV container, which maintain the correct flag on my LG television ;)

.TS Source: -
General
ID : 1049 (0x419)
Complete name : F:\UHD HDR Test Files\HLG [BBC & NHK]\LG Cymatic Jazz 4K [HLG 10-bit BT.2020] Demo.ts
Format : MPEG-TS
File size : 738 MiB
Duration : 4 min 57 s
Overall bit rate mode : Variable
Overall bit rate : 20.8 Mb/s

Video
ID : 33 (0x21)
Menu ID : 301 (0x12D)
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@Main
Codec ID : 36
Duration : 17 h 6 min
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate : 59.940 (60000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Writing library : ATEME Titan File 3.7.7 (4.7.7.1)
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : HLG / BT.2020 non-constant
Matrix coefficients : BT.2020 non-constant

Audio
ID : 36 (0x24)
Menu ID : 301 (0x12D)
Format : AAC
Format/Info : Advanced Audio Codec
Format version : Version 4
Format profile : LC
Muxing mode : ADTS
Codec ID : 15
Duration : 4 min 57 s
Bit rate mode : Variable
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 kHz
Frame rate : 46.875 FPS (1024 SPF)
Compression mode : Lossy
Delay relative to video : -36 ms


.MKV Re-mux: -
General
Unique ID : 226448609532334779746348042747359445820 (0xAA5C6A71A0A2109DBEC244278B4AC33C)
Complete name : F:\UHD HDR Test Files\HLG [BBC & NHK]\Container Tests\HLG [BBC & NHK] [mkv].mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 721 MiB
Duration : 4 min 57 s
Overall bit rate : 20.3 Mb/s
Encoded date : UTC 2017-10-10 17:04:09
Writing application : mkvmerge v16.0.0 ('Protest') 64-bit
Writing library : libebml v1.3.5 + libmatroska v1.4.8

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 4 min 57 s
Bit rate : 20.2 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 59.940 (60000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.041
Stream size : 717 MiB (99%)
Writing library : ATEME Titan File 3.7.7 (4.7.7.1)
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : BT.2020 non-constant
Matrix coefficients : BT.2020 non-constant

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC-2
Duration : 4 min 57 s
Bit rate : 129 kb/s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 kHz
Frame rate : 46.875 FPS (1024 SPF)
Compression mode : Lossy
Delay relative to video : -417 ms
Stream size : 4.57 MiB (1%)
Default : Yes
Forced : No

Cheers

[nevcairiel]

On a slightly different note... I have managed to mux some BBC/NHK HLG (Hybrid Log-Gamma) HDR samples into the MKV container, which maintain the correct flag on my LG television ;)

One of the advantages of HLG is that it doesn't require *any* additional metadata and comes with backwards compatibility baked in, so it wouldn't require any special handling by the container.

[SeeMoreDigital]

One of the advantages of HLG is that it doesn't require *any* additional metadata and comes with backwards compatibility baked in, so it wouldn't require any special handling by the container.Thanks for the info @nevcairiel,

Needless to say I'm willing and able to try any experimental MKVToolNix test builds you guys can think of intended to preserve a Dolby Vision signal :)

[Mosu]

At the moment I don't have any plans on spending serious time on the issue as I don't have any information about how Dolby Vision is stored in the first place. The freely available information on Dolby Vision is, as is the norm with codecs, rather sparse regarding container mappings.

[DMD]

Good evening
Version 16.0.0 has problems creating mkv files, I tried it several times and read the file either with VLC or with MPHC and it returns the following error.

https://s20.postimg.org/xon5fxde5/Screenshot_002.png

https://s20.postimg.org/x0eawzeod/Screenshot_004.png (https://postimages.org/)


I have reinstalled version 15.0.0 and no problem creating mkv files is perfect.
I ask if you can fix the problem.

Thank you

[nevcairiel]

Good evening
Version 16.0.0 has problems creating mkv files, I tried it several times and read the file either with VLC or with MPHC and it returns the following error

See here for the VC-1 issue:
https://github.com/mbunkus/mkvtoolnix/issues/2113

[DMD]

See here for the VC-1 issue:
https://github.com/mbunkus/mkvtoolnix/issues/2113
Right at this time I was doing tests and I noticed only with VC-1 format this problem happens,
How it does not happen with version 15.0.0, we hope it can be resolved.

Thank you

[Mosu]

It has already been resolved. See that issue nevcairiel's linked to.

[DMD]

It has already been resolved. See that issue nevcairiel's linked to.
I apologize, but I did not understand where I can download this correct version.

Thank you

[Mosu]

Click on the linked issue, look for my comments, see that the word "here" is actually a link to the download location.

[DMD]

I downloaded mkvtoolnix-64-bit-16.0.0-build20171013-01586-d053122a0
It works.
I'm waiting for the official release when it's available.

Thank you

[Mosu]

Here's release v17.0.0 of MKVToolNix. The rather short timespan since the previous release is due to a nasty bug in the VC-1 code that a lot of people are hitting with v16.

Other important changes are the overhaul of mkvextract's command line interface and all programs using the word "timestamp" instead of "timecode" (which also affects mkvmerge's command line interface). See the news below for more information.

There were no changes for package maintainers.

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

The Windows and macOS binaries are available already. The Linux binaries are stil being built and will be available of the course of the next couple of hours.

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

# Version 17.0.0 "Be Ur Friend" 2017-10-14

## Important notes

* The word "timecode" has been changed to "timestamp" everywhere it was
used in MKVToolNix. This affects program output (including mkvinfo's), GUI
controls, command line parameters (e.g. `mkvmerge --timestamp-scale …`) and
file formats. All programs remain backwards compatible insofar as they still
accept "timecode" in all those places (e.g. `mkvmerge --timecode-scale …`).

The reason for the change is wrong usage. What both the Matroska specification
and MKVToolNix used "timecode" for is normally called a "timestamp" in audio &
video domains. A "timecode" on the other hand has a specific meaning. As the
Matroska specification is moving towards implementing real timecodes, it will
also move towards correcting the verbiage. MKVToolNix is following this
change.

* mkvextract's command line interface has been changed to allow extraction of
multiple items at the same time. The first argument must now be the source
file's name. All following arguments either set the mode (e.g. `tracks`) or
specify what to extract in the currently active mode.

Those items that were written to the standard output (chapters, tags and cue
sheets) are now always written to files instead. Therefore the respective
modes require an output file name.

For example, extracting two tracks, the chapters and the tags can be done
with the following command:

`mkvextract input.mkv tracks 0:video.h265 1:audio.aac chapters chapters.xml tags tags.xml`

The old interface (specifying the mode first and the source file name
second) remains working and supported. However, it is now deprecated and
will be removed at the end of 2018.

## New features and enhancements

* mkvmerge: AC-3: during identification regular AC-3 and E-AC-3 tracks will
now be identified differently for most container formats (exception: AVI,
Real Media, Ogg/OGM). The codec will be reported as `AC-3` for regular AC-3
and as `E-AC-3` for E-AC-3 tracks instead of the combined `AC-3/E-AC-3`.
* mkvextract: the command line interface has been changed to allow extraction
of multiple items at the same time. See section "Important notes" for details.

## Bug fixes

* mkvmerge: AAC ADTS parser: mkvmerge will now parse the
`program_config_element` if it is located at the start of an AAC frame in
order to determine the actual number of channels. This overrides invalid
channel configurations in the ADTS headers, for example. Fixes #2107.
* mkvmerge: fixed AC-3 being misdetected as encrypted MPEG program streams
under certain conditions.
* mkvmerge: Dirac: under certain conditions (e.g. only muxing a single Dirac
track without any other tracks) mkvmerge was always setting the pixel width
& height to 123. The frame rate was wrong, too.
* mkvmerge: E-AC-3 in Matroska: if AC-3 cores and their corresponding E-AC-3
extension are located in two different Matroska blocks, then mkvmerge will
now re-assemble them into a single block and only use the first block's
timestamp.
* mkvmerge: SRT reader: fixed calculating the duration of entries starting
with at a negative timestamp.
* mkvmerge: VC-1: under certain conditions (e.g. only muxing a single VC-1
track without any other tracks) mkvmerge was always setting the pixel width
& height to 123. The frame rate was wrong, too. Fixes #2113.
* mkvmerge: command line options: an error message will be output if the
single-value-form of the `--sync` option is used and it isn't a number
(e.g. `--sync 0:asd`). Fixes #2121.
* mkvpropedit, GUI's header editor: both programs will now show proper error
messages instead of crashing when certain kinds of data corruption is found
when reading a file. Fixes #2115.

Have fun :)

[manolito]

Thanks very much for the new version... :thanks:

In some short tests I found no problems with the new mkvextract CLI interface. MKVExtractGUI2 and the latest GUI by GPower2 worked without issues, AVStoDVD and StaxRip also worked so far.

Even my hack for using the software under WinXP still works... :D


Cheers
manolito

[Megalith]

Is there any way to demux an .mpls file with MKVToolNix? I know there are other tools (eac3to, tsMuxeR) for that, but they do not seem to handle UHD Blu-ray files correctly.

[sneaker_ger]

You can first mux using mkvmerge, then demux that using mkvextract. Direct conversion from mpls to "raw" (non-mkv) formats in a single step is not supported.

[DMD]

Also I thank very much for solving the VC1 codec problem. :)

[Megalith]

Thank you.

MKVToolNix appears to be creating corrupt MKVs when I try to mux "raw" Blu-ray UHD files (h265/HEVC). If I try to create/mux an MKV with an MPLS as the source file, the result seems to be fine. I am not sure whether this is an issue with the extraction software I am using (eac3to) or MKVToolNix...

[mkver]

Does the raw HEVC stream play properly? Does ffmpeg complain about something when you decode it with it (you can use the null muxer to test this)? If the answer to these two questions is no, then it's probably a bug in MKVToolNix and you should open an issue on github; if it is no, then it's probably a bug in eac3to. In any case, a sample (of the relevant m2ts file) would be nice.

[Bozotheclown]

Hi,

Thx for this great soft.
Little suggestion about versioning:
Maybe is worth to considering "year.month.hot fix no." for release numbering, as example:
ver 17.10.0 - version form year 2017.Oct.Hotfix0

Question about updating:
It is possible to implement auto update from application?
Now is info about new version and user need to go to web page for download.

[Mosu]

Date-based version numbers have no more real advantages than any other type of arbitrary versioning scheme. The only property that's really important is that newer versions have higher version numbers. What I especially dislike about date-based version numbers is that you have to make up exceptions on the spot in cases where two or more releases happen within the same timeframe (e.g. two regular releases in one month; in your proposed scheme I would have to mark one of them as… a hotfix? Even though it isn't?). So no, I won't change to something like that.

I have zero interest in implementing an auto updater.

[VAMET]

Dear Mosu

I am confused, some people say, that they can extract Dolby Vision layer via MKVToolNix.

So there is possibility to use MKVToolNix on m2ts file, which has got Dolby Vision and make it mkv file with specified tracks and remain Dolby Vision?

I would be glad for your reply.

Thank you in advance.

Sincerely

[sneaker_ger]

https://forum.doom9.org/showthread.php?p=1821449#post1821449

[d3rd3vil]

Its a damn shame

[VAMET]

Dear Friends

I have used mkvmerge and have created .mkv file with --compression set to none for video and audio tracks. Please look below for mkvmerge --identify and eac3to identify of those .mkv files.

First .mkv file:

[mkvmerge]
File 'THE FATE OF THE FURIOUS [2017] [2160P].mkv': container: Matroska
Track ID 0: video (MPEG-H/HEVC/h.265)
Track ID 1: video (MPEG-H/HEVC/h.265)
Track ID 2: audio (DTS-HD Master Audio)

[eac3to]
MKV, 2 video tracks, 1 audio track, 2:15:58, 24p /1.001
1: h265/HEVC, English, 2160p24 /1.001 (16:9), 10 bits
2: h265/HEVC, English, 1080p24 /1.001 (16:9), 10 bits - Dolby Vision Enhancement Layer
3: DTS Master Audio, English, 7.1 channels, 24 bits, 48kHz (core: DTS, 5.1 channels, 1509kbps, 48kHz)

Second .mkv file:

[mkvmerge]
File 'TRANSFORMERS - THE LAST KNIGHT [2017] [2160P].mkv': container: Matroska
Track ID 0: video (MPEG-H/HEVC/h.265)
Track ID 1: video (MPEG-H/HEVC/h.265)
Track ID 2: audio (TrueHD Atmos)

[eac3to]
MKV, 2 video tracks, 1 audio track, 2:34:39, 24p /1.001
1: h265/HEVC, English, 2160p24 /1.001 (16:9), 10 bits
2: h265/HEVC, English, 1080p24 /1.001 (16:9), 10 bits - Dolby Vision Enhancement Layer
3: TrueHD (Atmos), English, 7.1 channels, 48kHz, 32ms

1. My question is related with (core: DTS, 5.1 channels, 1509kbps, 48kHz) in the first .mkv file on audio track. In the second .mkv file there is no core embedded with TrueHD Atmos, why? Source disk has got core embedded in this audio track. If mkvmerge removes core embedded in TrueHD Atmos and doesn't for DTS-HD Master Audio? I use command line with mkvmerge. Are there any options in command line to use mkvmerge to create audio tracks without core embedded?

2. My second question is related with DTS:X, which should be in THE FATE OF THE FURIOUS [2017] [2160P].mkv and it's identified in mkvmerge and eac3to as Track ID 2: audio (DTS-HD Master Audio). Why it's not properly identified?

3. mkvmerge also doesn't identify Track ID 1: video (MPEG-H/HEVC/h.265) as Dolby Vision Enhancement Layer like eac3to.

Thank you in advance for your support.

Sincerely

[sneaker_ger]

1. DTS and Dolby work differently. https://github.com/mbunkus/mkvtoolnix/wiki/TrueHD-and-AC-3
2. Probably no detection implemented but works anyways? Wait for Mosu to answer ...
3. Like already said two posts above: https://forum.doom9.org/showthread.php?p=1821449#post1821449


I have used mkvmerge and have created .mkv file with --compression set to none for video and audio tracks.
Extra compression is off by default for video and audio anyways. Only active for certain subtitle formats. (And has nothing to do with core or similar. Extra compression is lossless.)

[Mosu]

DTS:X identification isn't all that easy, it seems. It's not implemented in mkvmerge. There was some work on it by Konablend that resulted in a pull request (https://github.com/mbunkus/mkvtoolnix/pull/1629), but his changes resulted in other bugs. It wasn't polished to the point where it could be included in mkvmerge.

[VAMET]

Dear Friends

OK, I understand. I wish it would be identified as DTS:X in the future version. I cross my fingers about it.

As far as I understand English, Dolby Atmos/TrueHD cannot have core track in single track, while DTS:X can. So mkvmerge creating .mkv file with Dolby Atmos/TrueHD track it removes all core tracks, so there is only Dolby Atmos/TrueHD and if I will try to play it on the device, which hasn't got Dolby Atmos/TrueHD support, I will not hear anything, right?

The other situation is with DTS:X, which has got core track in a single file, right? My question is, I don't care to have core tracks with my DTS:X. Are there any possibility to remove those core tracks from DTS:X, to have only DTS:X track without core? If it's possible may you be so kind and write, what options with mkvmerge should I add to create .mkv file without core tracks in DTS:X or DTS-MA?

Thank you in advance for your help.

Sincerely

[sneaker_ger]

So mkvmerge creating .mkv file with Dolby Atmos/TrueHD track it removes all core tracks, so there is only Dolby Atmos/TrueHD and if I will try to play it on the device, which hasn't got Dolby Atmos/TrueHD support, I will not hear anything, right?
Like the FAQ said: mkvmerge will split AC3 core and TrueHD into two tracks. You can keep the AC3 core track for compatibility if you want - or not if you don't want. That's your choice.

The other situation is with DTS:X, which has got core track in a single file, right? My question is, I don't care to have core tracks with my DTS:X. Are there any possibility to remove those core tracks from DTS:X, to have only DTS:X track without core?
Not possible. DTS MUST have core. It cannot be removed.

[Thunderbolt8]

are there any specifications on how dolby vision can be used inside the matroska container format? if not, would it be possible to add those in the future?

[Mosu]

There aren't. After what I've read over how DV can be stored in completely separate sub-streams and how complex the whole DV stuff is, I highly doubt you'll see DV-in-Matroska specs any time soon, if ever.

Contributions and people working on such specs would be highly appreciated.

[sneaker_ger]

I see you've changed from "timecode" to "timestamp" in lots of mkvtoolnix parts but is it intentional even for the timecode files outputted by mkvextract? Having the first line of such a file say "# timecode format v2" is kind of an established format in use by lots of other programs as well and now they don't read them anymore (and I assume mkvmerge also won't read anymore?). Of course it's easy to edit but still ...

[Mosu]

Yes, that change was intentional. mkvmerge will read both the old and the new format line, just as it will still accept "--timecodes …" as a command-line argument even though it was renamed to "--timestamps …".

As this was a format invented by me for use with mkvmerge, and as I've never had any intention of it being some kind of standard format, I don't consider other applications to be a concern of mine. If you need the format changed, use a small oneliner script such as this one: perl -pi -e 's/timestamp/timecode/' yourfile.txt

[Thunderbolt8]

Contributions and people working on such specs would be highly appreciated.arent such specifications always agreed upon by a large group of people and such? can individuals actually define a standard on their own?

[sneaker_ger]

@Mosu
I see, thx.

arent such specifications always agreed upon by a large group of people and such? can individuals actually define a standard on their own?
I believe for the longest time only Steve Lhomme and Mosu decided things. And if Mosu implemented something in mkvtoolnix others just followed because mkvtoolnix is the de-facto standard implementation. So if you have a good idea on how to implement Dolby Vision and come up with a patch for mkvtoolnix it's likely others will simply follow. (Nowadays there are companies like Google weighing in and a standardization progress but they still come to Lhomme/Mosu to discuss.)

[nevcairiel]

One should however note that software playback of DoVi is not available anywhere (yet anyway), and TVs/STBs are not likely to adopt such an MKV standard for DoVi unless its officially endorsed by Dolby. So even if such a thing were to be defined and added to the MKV spec, that wouldn't really get you much.

[SeeMoreDigital]

Until 'backing-up' UHD discs becomes as easy as backing-up DVD and Blu-ray discs, how likely is it going to be that we will need a method of muxing DoVi content into the .MKV container anytime soon?

And it's not like there are hundreds of DoVi UHD movie discs available now or planned for future release!

[VAMET]

Dear Friends

mkvmerge shows:

Track ID 0: video (MPEG-H/HEVC/h.265)
Track ID 1: audio (TrueHD Atmos)
Track ID 2: audio (AC-3)
Track ID 3: subtitles (HDMV PGS)
Track ID 4: subtitles (HDMV PGS)
Track ID 5: subtitles (HDMV PGS)
Track ID 6: subtitles (HDMV PGS)
Track ID 7: subtitles (HDMV PGS)
Track ID 8: subtitles (HDMV PGS)
Track ID 9: subtitles (HDMV PGS)
Track ID 10: subtitles (HDMV PGS)
Track ID 11: subtitles (HDMV PGS)
Track ID 12: subtitles (HDMV PGS)
Track ID 13: subtitles (HDMV PGS)
Track ID 14: subtitles (HDMV PGS)


eac3to shows:

1: h265/HEVC, 2160p24 /1.001 (16:9), 10 bits
2: TrueHD (Atmos), English, 7.1 channels, 48kHz
3: AC3 EX, English, 5.1 channels, 640kbps, 48kHz
4: Subtitle (PGS), English, "English"
5: Subtitle (PGS), English, "English (SDH)"
6: Subtitle (PGS), Danish, "Danish"
7: Subtitle (PGS), German, "German"
8: Subtitle (PGS), Spanish, "Spanish (Castilian)"
9: Subtitle (PGS), French, "French"
10: Subtitle (PGS), Italian, "Italian"
11: Subtitle (PGS), Japanese, "Japanese"
12: Subtitle (PGS), Dutch, "Dutch"
13: Subtitle (PGS), Norwegian, "Norwegian"
14: Subtitle (PGS), Finnish, "Finnish"
15: Subtitle (PGS), Swedish, "Swedish"

Are there any chances to implement to mkvmerge identify of tracks languages in such estetic way like eac3to?

Sincerely

[Mosu]

Use "mkvmerge --identification-format json --identify yourfile" or the shortcut "mkvmerge -J yourfile" if you want more details.

And no, mkvmerge's default identification output will never match eac3to's.

[VAMET]

Dear Mosu

Use "mkvmerge --identification-format json --identify yourfile" or the shortcut "mkvmerge -J yourfile" if you want more details.

And no, mkvmerge's default identification output will never match eac3to's.

Thank you very much, but I know that command. I mean, one track one row with language in this row.

Sincerely

[Mosu]

No, there isn't, no, there won't be. You can easily write your own wrapper script that executes mkvmerge's JSON identification, reads that JSON data and outputs your own custom output format.

[DMD]

Good morning
I could also check with MKVToolNix GUI you can create mkv files from Blu-ray 4k UHD already decrypted on HDD.
Just drag the index.bdmv file in the source file section. :)

[Megalith]

Creating UHD files is proving to be a huge nightmare for me because nobody has updated their tools. BDInfo, for instance, errors out on .MPLS files, so I have no idea what the correct playlist is.

Is there a way to update MKVToolNix so Input > Source files can be sorted via the column headers? File size would be particularly helpful for rooting out relevant playlists.

[Mosu]

Is there a way to update MKVToolNix so Input > Source files can be sorted via the column headers? File size would be particularly helpful for rooting out relevant playlists.

No, and there won't be as the order of files is relevant to mkvmerge's processing. Therefore sorting would change the outcome in hard to understand ways.

What you can do, though, is use the "scan for playlists" dialog because in it you can sort by each column, including total length and total size.