MKVToolNix v24.0.0 released

[Mosu]

Everyone, please just STOP this discussion about pros and cos of various Windows versions. This is way offtopic here. Thanks.

[stax76]

Interesting chart though sometimes a number is just a number and the most popular thing is also the most idiotic thing. I'm clueless about QT but I'm rather sure they wouldn't have pulled the plug without good reason. In my case (staxrip) it was .NET 4.5 which ended XP support 2012, so 11 years after XP and 3 years after Windows 7. Windows 10 was released 2015, if you add 3 years to that then 2018 would be the year they pull the plug for Win 7, I don't think they'll do it before 2019 though. For me to give it up they would have to add a significant feature, the only significant thing I'm aware of that is probably coming are non-nullable types but since I never used it in another language I don't know if it's important enough to give up Win 7 support. In .NET 4.5 2012 it was new asynchronous language features I couldn't resist, I said that it's important and I don't remember being criticized a lot for it. It's fun using improved tools and of course it improves the quality of the code and application so the users benefit as well, most open source authors don't want to let many people behind, it's a difficult decision.

I've started Lua programming to extend the mpv media player, if that don't work out well maybe I'll be soon building a GUI around libmpv, lav filters and madvr using QT, it seem to be a extremely popular toolkit and unlike MFC I've only heard good things about it, maybe then I'll understand the issue better. I hope it's OK to post this here, mkvtoolnix is essential for most of us and GUI authors have to follow all tool threads, the work you are doing is outstanding, there is no doubt about it.

[hello_hello]

Answers who mocking me, so my last post here:

I do not have the knowledge to compile a custom version. If there is someone out there with knowledge about that, it would be great to see a xp-compatible build.

XP is probably still more widely used than all the non-Windows operating systems combined, so it does seem a little odd from that perspective. Still, it's up to Mosu to support the operating systems he wants to support, although I do envy the five people running NetBSD. ;)

Anyway.... you can use mkvtooknixgui.exe version 10 with the current mkvmerge.exe. You just have to put up with a warning message when you first open it.
Or if you happen to be a MeGUI user, it's MKV muxer uses MKVMerge to do the work and the latest mkvmerge.exe works fine with MeGUI, even though it's capable of going "ding" when it finishes running the jobs in the queue, if you're into that sort of thing.

For the record, the latest MKVCleaver & gMKVExtractGUI both work fine with MKVToolnix 13 on XP.

I've never compiled software myself, although I did briefly consider learning how to in this case, but I didn't look into it further when it appeared the software required to compile an XP compatible version won't run on XP. If anyone knows differently and can point me in the right direction I'll have another look, or I might try again when I get around to re-installing Linux on my second PC and finding my way around it.

Interesting chart though sometimes a number is just a number and the most popular thing is also the most idiotic thing. I'm clueless about QT but I'm rather sure they wouldn't have pulled the plug without good reason.

Qt version 5.6 supports XP and it's supported until March 2019. Qt 5.7 and newer don't officially support XP although that's probably due to the switch to Media Foundation for some multimedia functions. Maybe newer versions would work too if non-XP compatible functions weren't enabled. I'm not sure,
I suspect many popular QT based programs (VLC, SMPlayer, XNView etc) will drop XP support when Qt stops supporting version 5.6, or some time later, but for MKVToolNixGUI the XP line appears to have been drawn and set in stone before Qt 5.6 was even released.

[stax76]

@hello_hello

You could use vmware player or VirtualBox if you find a old enough version.

[SeeMoreDigital]

Everyone, please just STOP this discussion about pros and cos of various Windows versions. This is way offtopic here. Thanks.Indeed, perhaps there should be a dedicated topic for these 'windows' support discussions ;)

Cheers

[Mosu]

Is this known limitation of MKVMerge that .w64 is being detected as AVC

I'd like some more sample files. Could you upload one, please (see signature)? Thanks.

[manolito]

This is for satmonk and other WinXP users who still want to use the latest MKVToolNix version...

It is just a dirty hack, I do not have the knowledge to compile ToolNix myself. What it does is just replacing mkvtoolnix-gui.exe and the mkvinfo files with the older v10.0.0 versions. Plus it automatically kills the warning message which always pops up when mkvtoolnix-gui.exe is started. For nostalgic reasons I called the replacement file "mmg.exe".
Thanks to hello_hello for the idea...

Download here:
http://www80.zippyshare.com/v/yv5ki2q8/file.html


Cheers
manolito

[stax76]

here are two w64 samples:

https://drive.google.com/drive/folders/0B-gPKiJYuKuIQnhxVldrcWhYaVU

[Mosu]

Thank you, stax76.

[hello_hello]

This is for satmonk and other WinXP users who still want to use the latest MKVToolNix version...

Thanks to hello_hello for the idea....

You're welcome. :)
I was using AutoHotkey to kill the warning message for a while, until I discovered monitoring for MKVToolNix complaints was keeping CPU usage at 10% and as yet I haven't tried alternatives.

Unfortunately.... because your method seems like a clever idea.... right-click SendTo/mmg.exe can't be used to open files and I'm stuck in my ways....

[manolito]

Unfortunately.... because your method seems like a clever idea.... right-click SendTo/mmg.exe can't be used to open files and I'm stuck in my ways....

This was an easy one... :cool:
Since I never use the SendTo feature I simply forgot to pass command line parameters to mkvtoolnix-gui.exe. It is fixed, please redownload...

//EDIT//
Just tested it with the new version 14.0.0... No problems. BTW now you can also copy&paste or drag&drop an input file on mmg.exe.


Regarding the high CPU load with AutoHotkey you should probably add a "sleep" command within the loop. A value like 250ms should do.


Cheers
manolito

[Mosu]

I'm releasing MKVToolNix v14.0.0. It strikes a nice balance between bug fixes and new features/enhancements.

Changes for package maintainers: a new translation of the programs to Romanian (ro.po) has been added. There are two other minor changes you should be aware of. Please see the NEWS section "Build system changes" below for details.

Deprecation warning

This is a reminder that certain features having been deprecated since v9.7.0. They're scheduled to be removed in the first release of 2018. These features are:

mkvmerge: the options "--identify-verbose", "--identify-for-gui", "--identify-for-mmg" and "--identification-format verbose" (use "--identification-format json --identify" or its short form "-J" instead)
all command line tools: the old, proprietary format used for option files (use JSON option files instead)

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 have already been built and uploaded. Linux binaries are still being built and will be available shortly.

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

# Version 14.0.0 "Flow" 2017-07-23

## New features and enhancements

* mkvmerge: AAC: implemented support for AAC with 960 samples per frame. Implements #2031 (https://github.com/mbunkus/mkvtoolnix/issues/2031).
* mkvmerge: identification: if the encoding/character set of a text subtitle track is known (e.g. because a byte order mark is present in the file), then it will be output during identification as the `encoding` property. Implements mkvmerge's part of #2053 (https://github.com/mbunkus/mkvtoolnix/issues/2053).
* mkvmerge: WAV reader: added support for Wave64 files. Implements #2042 (https://github.com/mbunkus/mkvtoolnix/issues/2042).
* mkvmerge, mkvpropedit, MKVToolNix GUI (chapter editor): added support for chapters in WebM files that is spec-compliant by removing all tag elements not supported by the WebM spec. Implements #2002 (https://github.com/mbunkus/mkvtoolnix/issues/2002).
* mkvpropedit: added support for tags in WebM files that is spec-compliant by removing all tag elements not supported by the WebM spec.
* MKVToolNix GUI: multiplexer: if the encoding/character set of a subtitle track cannot be changed, the GUI will deactivate the "subtitle character set" drop-down box and ignore changes to it when multiple tracks are selected. Additionally, if the track's encoding is known and cannot be changed (e.g. due to a byte order mark in the file), that encoding will be selected in the drop-down box automatically. Both changes signal to the user that she doesn't have to take care of the encoding herself. Implements the GUI's part of #2053 (https://github.com/mbunkus/mkvtoolnix/issues/2053).
* MKVToolNix GUI: chapter editor: added a function to the "additional modifications" dialog for calculating and setting the end timestamps. Implements #1887 (https://github.com/mbunkus/mkvtoolnix/issues/1887).
* MKVToolNix GUI: changed the shortcuts for switching between the various tools from `Alt+number` (e.g. `Alt+1` for the multiplexer tool) to `Ctrl+Alt+number` in order to avoid clashing with Windows' input method for arbitrary characters (pressing and holding `Alt` and typing the codepoint on the number pad). Implements #2034 (https://github.com/mbunkus/mkvtoolnix/issues/2034).
* MKVToolNix GUI: added a "Window" menu and entries with shortcuts for selecting the next (`Ctrl+F6`) respectively previous tab (`Ctrl+Shift+F6`) in the current tool. Implements #1972 (https://github.com/mbunkus/mkvtoolnix/issues/1972), #2032 (https://github.com/mbunkus/mkvtoolnix/issues/2032).
* MKVToolNix GUI: on Windows the GUI will now determine the default font to use by querying Windows for the default UI/message box font instead of using the hardcoded `Segoe UI`. This might fix issues such as #2003 (https://github.com/mbunkus/mkvtoolnix/issues/2003) (unverified).
* translations: added a Romanian translation of the programs by Daniel (see AUTHORS).


## Bug fixes

* mkvmerge: AVC/h.264 parser: fixed wrong frame order & timestamp calculation in certain situations when SPS (sequence parameter sets) or PPS (picture parameter sets) change mid-stream. Fixes #2028 (https://github.com/mbunkus/mkvtoolnix/issues/2028).
* mkvmerge: HEVC/h.265 parser: fixed wrong frame order & timestamp calculation in certain situations when SPS (sequence parameter sets) or PPS (picture parameter sets) change mid-stream. This is the HEVC/h.265 equivalent of #2028 (https://github.com/mbunkus/mkvtoolnix/issues/2028).
* mkvmerge: MPEG-1/-2 video: the "remove stuffing bytes" feature introduced in v5.8.0 (feature request #734 (https://github.com/mbunkus/mkvtoolnix/issues/734)) was broken. In a lot of situations it did not detect the end of a slice correctly and removed 0 bytes that were actually part of the slice structure. Often there were no visual problems as decoders were able to ignore such errors, but in other cases there are visual artifacts upon decoding. As detecting the slice end properly requires parsing the whole slice structure, this feature has been removed again. Fixes #2045 (https://github.com/mbunkus/mkvtoolnix/issues/2045).
* mkvmerge: MPEG PS reader: fixed mkvmerge trying to handle an "end" code the same way as a "program stream map" code.
* mkvmerge: MPEG TS reader: mkvmerge won't emit warnings if the system's `iconv` library doesn't support the ISO 6937 character set. Fixes #2023 (https://github.com/mbunkus/mkvtoolnix/issues/2023).
* mkvmerge: when appending fails the error message details (e.g. "the number of channels differs: 1 and 2") were often not output. Fixes #2046 (https://github.com/mbunkus/mkvtoolnix/issues/2046).
* MKVToolNix GUI: multiplex tool: implemented a workaround for a crash that could occur during drag & drop if at least one of the columns is hidden. Fixes #2009 (https://github.com/mbunkus/mkvtoolnix/issues/2009).
* MKVToolNix GUI: multiplex tool: appended tracks can no longer be enabled (selected for multiplexing) if the track they're going to be appended to is not enabled. Fixes #2039 (https://github.com/mbunkus/mkvtoolnix/issues/2039).
* MKVToolNix GUI: multiplex tool: if the GUI is set to ensure unique output file names, it will now verify that right before starting to multiplex/adding the job to the queue, too. Fixes #2052 (https://github.com/mbunkus/mkvtoolnix/issues/2052).
* MKVToolNix GUI: fixed the total progress reverting to 0% instead of staying at 100% when all jobs have finished. This was introduced by the attempt at fixing the computation of the value of total progress bar for multiple jobs running. Fixes #2005 (https://github.com/mbunkus/mkvtoolnix/issues/2005).
* configure: fixed DocBook detection if `/bin/sh` is `dash`. Patch by Steve Dibb. Fixes #2054 (https://github.com/mbunkus/mkvtoolnix/issues/2054).

## Build system changes

* Boost: the minimum required version has been bumped to 1.49.0. Earlier releases fail to build on my current systems and will therefore not be supported anymore.
* configure: when looking for the "nlohnmann JSON" include files configure will now try the path "nlohmann/json.hpp" first, "json.hpp" second (only "json.hpp" was tried before). If neither is found, the copy included in the MKVToolNix sources will be used. Fixes #2048 (https://github.com/mbunkus/mkvtoolnix/issues/2048).

Have fun :)

[ryrynz]

I just gotta ask, why the larger jumps in version numbers since 10.0?

[Mosu]

Because there was no semantic difference between the first two components. I only placed significance on the third component. With every regular release I increased the second component (8.8.0 → 8.9.0), and the first if the second was at 9 (8.9.0 → 9.0.0). With every quick bugfix/emergency release I increased the third component (7.9.0 → 7.9.1).

So changes in the first component did not signal anything significant, just that the second would be 10 or higher otherwise.

So why keep two components if there's no significant difference between the two?

The new scheme is: first component is increased with every regular release (13.0.0 → 14.0.0), and emergency releases increase the second component (14.0.0 → 14.1.0).

The reason there's still a third component is simply that older MKVToolNix code wasn't built for parsing two-component version numbers. I will probably keep that third component around for a year or so and phase it out then.

[Atak_Snajpera]

How does MKVExtract treat 4GiB+ PCMs in mkv? Does it automatically use wave64 format during extraction or it always extracts to regular wave regardless of the size?

[Mosu]

mkvextract doesn't write Wave64. It'll write to WAV, but I guess the result may or may not work.

[hello_hello]

This was an easy one... :cool:
Since I never use the SendTo feature I simply forgot to pass command line parameters to mkvtoolnix-gui.exe. It is fixed, please redownload...

You never use the SendTo menu? One of the first things I do after a fresh install it fill it up with shortcuts.
Using some sort of "File/Open/Navigate To Folder" method all the time would slowly kill my soul.

Regarding the high CPU load with AutoHotkey you should probably add a "sleep" command within the loop. A value like 250ms should do.

I'd intended to investigate as soon as apathy permitted, but so far your new version is working normally with MKVToolNix 14.0.0 and the SendTo menu is functional again, so thanks for that.

[Perenista]

Is there a way to create a video with multiple angles? I have here with me a DVD that has 3 angles, and while using MAKEMKV it creates 3 MKV lossless files, each one with 700 MB and its respective audio stream.

Files 1, 2 and 3 -> http://imgur.com/a/5s5eC

At first MAKEMKV didn`t even select angles 2-3. If MKVToolnix can`t do this, what software do you recommend? Note - I don`t want to reencode.

[stax76]

@hello_hello

Instead of Send To you can also check out a shell extension called Open++

[qyot27]

Is there a way to create a video with multiple angles? I have here with me a DVD that has 3 angles, and while using MAKEMKV it creates 3 MKV lossless files, each one with 700 MB and its respective audio stream.

Files 1, 2 and 3 -> http://imgur.com/a/5s5eC

At first MAKEMKV didn`t even select angles 2-3. If MKVToolnix can`t do this, what software do you recommend? Note - I don`t want to reencode.
Multiple video streams have been possible with Matroska for as long as I can remember, and I started playing around with Matroska and MKVToolNix in 2003 or 2004.

Just use the 'Add' button and load the additional .mkv files, then disable the 2nd and 3rd audio streams, since there should be no use for them.

[hubblec4]

Is there a way to create a video with multiple angles? I have here with me a DVD that has 3 angles, and while using MAKEMKV it creates 3 MKV lossless files, each one with 700 MB and its respective audio stream.

Files 1, 2 and 3 -> http://imgur.com/a/5s5eC

At first MAKEMKV didn`t even select angles 2-3. If MKVToolnix can`t do this, what software do you recommend? Note - I don`t want to reencode.


Yes, there is a tool which can make it for you.
chapterEditor -> DVD2mkv: Multi-Edition-MKV mode.
This mode can be also used for Multi-Angle-MKV's.

[hubblec4]

Multiple video streams have been possible with Matroska for as long as I can remember, and I started playing around with Matroska and MKVToolNix in 2003 or 2004.

Just use the 'Add' button and load the additional .mkv files, then disable the 2nd and 3rd audio streams, since there should be no use for them.

Multiple video streams are not the same like Multi-Angle(or Multi-Edition)

[Ripman]

mkvextract doesn't write Wave64. It'll write to WAV, but I guess the result may or may not work.

Thanks for the w64 support in v14.

I have added up to 30+gb of pcm audio to an mka/mkv -- it (seems to) work properly etc. But I've never tried to extract it knowing the limitations with wav. It's a "one-way street" at this time. (e.g., like multi-ch dxd audio @ 352.8khz -- pretty big stuff)

A few times in at least the last year I've asked about implementing dsf audio file support in mkvtoolnix/mkvmerge -- maybe within the last 10-20 pages. You shot those down, and I figured it was due to your workload and the proprietary nature of the format - it's from Sony. I recognize that implementing w64 was probably close to functionality that already exists in mkvmerge due to its support of wav/pcm audio.

Why w64 but not dsf mosu - are my assumptions above accurate?

[mkver]

Thanks for the w64 support in v14.

I have added up to 30+gb of pcm audio to an mka/mkv -- it (seems to) work properly etc. But I've never tried to extract it knowing the limitations with wav. It's a "one-way street" at this time. (e.g., like multi-ch dxd audio @ 352.8khz -- pretty big stuff)

Why should it be a one-way street? After all, ffmpeg can read pcm in Matroska and can write it to a w64 file (as can eac3to).
(And if you want to stick to mkvextract: It has a --raw extraction mode which will extract the pcm data. If fed with the right parameters, some programs can make use of this.)

[Mosu]

Why w64 but not dsf mosu - are my assumptions above accurate?

Because it was simple enough to add support to the already existing WAV reader code. Wave64 isn't fundamentally different. Quite the opposite; it's very similar to WAV, the only real difference being that the tags use GUIDs and 64-bit size fields instead of 32-bit tags & 32-bit size fields.

Adding support for a whole new container format is much more work.

[qyot27]

Multiple video streams are not the same like Multi-Angle(or Multi-Edition)
On a DVD, the other angles play with the same audio, only providing different video. The construction of the MPEG-2 stream in the VOB container is different than MKV using multiple video streams, but the angles are synced to the same audio track. It can be either simple and be a whole track by itself, as the example given clearly would have to be, or they can be complex and on a scene-by-scene basis (where MKV's more advanced features like editions and ordered chapters would be needed).

They didn't mention anything about how complex it needed to be, only that MakeMKV split the different angles into separate files (so the difference in the way the MPEG-2 stream had been in the VOB no longer matters or could be recovered), meaning that to approximate the original DVD with the files they have, multiple video streams is the only option left. Unless chapterEditor's DVD2mkv can decrypt, they'll still be stuck because they made the mistake of using MakeMKV to rip a DVD (and unlike its ability to make a nearly 1:1 backup of the file structure for Blu-ray Discs, MakeMKV doesn't allow a simple decrypted backup of a DVD's file structure, unless that was just recently added).

If they were going to redo the operation again from the DVD, then sure. But they've already got the disassembled video angles as discrete tracks and wanted to put it back into a single file.

[hubblec4]

On a DVD, the other angles play with the same audio, only providing different video. The construction of the MPEG-2 stream in the VOB container is different than MKV using multiple video streams, but the angles are synced to the same audio track. It can be either simple and be a whole track by itself, as the example given clearly would have to be, or they can be complex and on a scene-by-scene basis (where MKV's more advanced features like editions and ordered chapters would be needed).
I'm not an expert in DVD authoring but I know how to store a Multi-Angles/Editions DVD in an MKV. Ordered editions with ordered chapters are required and the structure of this special chapter.xml is a bit complex.


They didn't mention anything about how complex it needed to be, only that MakeMKV split the different angles into separate files (so the difference in the way the MPEG-2 stream had been in the VOB no longer matters or could be recovered), meaning that to approximate the original DVD with the files they have, multiple video streams is the only option left.
Makemkv is (and maybe will never) able to build Multi-Edition nor Multi-Angle MKVs.
All Angles from a DVD can be stored in a full separate mkv and this is a waste of space.


Unless chapterEditor's DVD2mkv can decrypt, they'll still be stuck because they made the mistake of using MakeMKV to rip a DVD (and unlike its ability to make a nearly 1:1 backup of the file structure for Blu-ray Discs, MakeMKV doesn't allow a simple decrypted backup of a DVD's file structure, unless that was just recently added).
Makemkv is not the "best" decryption program and not the "best" MKV-muxing app! The advantage of Makemkv is to get simple and fast an MKV without knowledge about decrytion or Matroska stuff.

My program MUST not a decryption.
But when you have a decrypted DVD on your hard disk then can MKVToolNix mux such Multi-Angle/Edition MKVs with the help of chapterEditor.


If they were going to redo the operation again from the DVD, then sure. But they've already got the disassembled video angles as discrete tracks and wanted to put it back into a single file.
I know many people uses Makemkv and I had planed a "Makemkv-Multi-Edition" mode in my DVD2mkv Editor which allows you to mux a Multi-Edition-MKV from the "full separated" Makemkv Angle-MKVs. But I have no time for tests.

[Ripman]

Why should it be a one-way street? After all, ffmpeg can read pcm in Matroska and can write it to a w64 file (as can eac3to).
(And if you want to stick to mkvextract: It has a --raw extraction mode which will extract the pcm data. If fed with the right parameters, some programs can make use of this.)

I see your point and I am aware of the raw opts etc.

The reason an approach as such wouldn't be helpful for me is bc if I'm editing or splitting or merging or applying gain or what have you - I'm always back at the source. The Mka approach is mostly for organization -- at least for me (e.g., wavs CDs BDAs DVDAS SACDs HDdownloads etc.). In this respect, mkvtoolnix/mkvmerge supports all relevant "music collection" formats, sans dsf, which we discussed above.

[hubblec4]

Hi Mosu

In your new version(14) is something changed which changes "Target Filenames" when I click start multiplex.
I have nothing changed in my settings. I load a mtxcfg file: MTX open and in the output file name edit is the correct path and filename.
Now I will mux it and get:
--- Fehler ausgegeben von Job »Multiplexe in Datei »00000.mkv« im Verzeichnis »H:\BDMV\STREAM«« gestartet am 2017-07-28 11:50:51 ---
Die Datei »H:\BDMV\STREAM\00000.mkv« konnte nicht zum Schreiben geöffnet werden: open file error.

You see that the filename has changed.
To get the prior behaviour I disabled the "automatic function for the destination filenames".

[Mosu]

Yes, what's changed is that the "adjust file name if necessary" algorithm is not only triggered when the user adds/removes files or toggles tracks, but also directly before muxing is started. Only if the user wants automatic destination file name generation, of course, and manual changes to the file name will be preserved.

The background for the change is this issue (https://github.com/mbunkus/mkvtoolnix/issues/2052).

[hubblec4]

Mmh, and that means you fix issue 2052 and I have to life with the new issue?

[Mosu]

Can you send me that job file you've opened? I'm not sure why the GUI changes the file name in your case.

[hubblec4]

The mtxcfg is uploaded to your FTP.

[Mosu]

We were able to answer the question why this is happening and what he can do about it via PMs.

[sneaker_ger]

Upload a sample file (input and output). Show us how you are trying to do it (e.g. via Screenshot) and show the mkvtoolnix log.

[fadedfedor]

Upload a sample file (input and output). Show us how you are trying to do it (e.g. via Screenshot) and show the mkvtoolnix log.
Thanks for the prompt reply. I figured it out, it was just user error, I didn't know what I was doing. I know I've used this before, but it's been quite awhile. I tried it three wrong ways instead of the one right way.

[Ripman]

I updated my main mkvmerge script to use json options. Here are some notes.
- List of characters that need to be escaped: / \ " --- legacy options had to escape spaces and others
- I initialize the mkvmerge options file with a BOM --- no issues
- Since json entries are quoted, you need to escape each value going to mkvmerge --- in the old version, you could just escape the whole options file at once
- Options files require a .json extension
- I believe the new json option files must be utf-8 encoded --- just about sure this was optional for the legacy format

Enhancement idea: Sure would be cool to have an option to append formatted json options to the output logs; like appended to the end of the file supplied with --redirect-output. If this is something you think would be useful, say as much, and I'll write it up in github.

[Mosu]

I updated my main mkvmerge script to use json options. Here are some notes.
- List of characters that need to be escaped: / \ " --- legacy options had to escape spaces and others

That's not entirely correct. Forward slashes can but don't have to be escaped, only backslashes and quote characters have to be (see page 4 of ECMA 404 (http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf), the JSON specification).

- I initialize the mkvmerge options file with a BOM --- no issues
- I believe the new json option files must be utf-8 encoded --- just about sure this was optional for the legacy format

That's correct. mkvmerge requires the files to be UTF-8 encoded. An existing UTF-8 BOM is supported/ignored, but any other BOM won't work.

- Since json entries are quoted, you need to escape each value going to mkvmerge --- in the old version, you could just escape the whole options file at once

Correct. In general JSON requires that strings must always be fully quoted. The only thing that doesn't have to be quoted are numbers, Boolean values "true"/"false" and the special value "null". However, mkvmerge further requires that all entries in the option files are strings, even if an entry might just be a number (e.g. "--title 8" would require two strings in the JSON file: … "--title", "8", …).

- Options files require a .json extension

That's correct, at least for the time being. In January 2018 I will remove certain deprecated options and features as announced at the start of 2017. Those features include the old option file format. From that point on all option files will be treated as JSON files, no matter what their extension might be.

Enhancement idea: Sure would be cool to have an option to append formatted json options to the output logs; like appended to the end of the file supplied with --redirect-output. If this is something you think would be useful, say as much, and I'll write it up in github.

That wouldn't make much sense from a practical point of view. There are basically three options: 1. write partial JSON output each time a message would be printed, 2. collect all messages and only output them as one big JSON document once mkvmerge has finished, 3. write one JSON document for each message.

The first option might produce a format such as this:

[
{ "type": "info", "message": "Using the AC-3 packetizer for…" },
{ "type": "warning", "message": "Read error in Matroska file; re-syncing…" },
{ "type": "progress", "progress_percentage": 21 },


As you can see I've intentionally left the document unfinished to indicate that mkvmerge is still running.

The problem with such a scheme is that most JSON parsers out there require that the JSON document is complete. They try to parse the whole document in one go and will return a data structure with all the data. They don't support reading part of a document, returning that data, and continue parsing the document at a later point.

Unlike XML JSON files were never meant to carry such huge loads of data to make partial parsing a necessity. Additionally JSON doesn't have named nodes like XML does. In XML a partial parser can return data and say "this is only partial, but it's one whole node called <Message>". In JSON all a parser could do is say "this is a hash from somewhere in the structure".

Of course you could write your own JSON parser that supports partial parsing. JSON is simple enough that writing such a parser for this particular use case isn't that hard. However, I certainly don't want all users of mkvmerge to have to do that, and writing your own parser usually means that a) it'll contain bugs and b) it'll be a lot slower than existing, optimized and well-tested parsers.

Option 2 from above (and not writing your own parser from option 1) basically means that you can only act on the output once mkvmerge has finished. This doesn't sound very useful to me either.

Option 3 looks similar to option 1 above. In JSON one document is either an object ("{ "key": "value"… }") or an array ("[ … ]"). Multiple objects one after the other are not really valid. The output might look like this:

{ "type": "info", "message": "Using the AC-3 packetizer for…" }
{ "type": "warning", "message": "Read error in Matroska file; re-syncing…" }
{ "type": "progress", "progress_percentage": 21 }

Note two differences: 1. no leading "[" and 2. no commas after each document.

The problem is again that there are few parsers that cope well with multiple documents. A program trying to read this would have to separate each object from the others and pass one object at a time to the actual JSON parser. Again, I don't want to force mkvmerge's users to have to write their own parsers.

Those are the reasons why I won't add such an option.

[Ripman]

Thanks for the answer regarding json option appending to output logs. I hadn't considered partial job completion etc. The impetus for this request was the old code I had supporting the legacy options. So, programmatically generate an mkvmerge options file, and escape everything, like spaces and colons and brackets. This would be tough to read or troubleshoot, so my function resolved all the escape sequences and appended the resolved options file to the mkvmerge processing log after successful completion.

I read the json web doc you have linked in the mkvmerge man page. Here is the section that had me thinking I needed to do both slashes (and control characters). No biggie - works either way, as you confirmed, and my Sunday test results confirmed also.


escape (
%x22 / ; " quotation mark U+0022
%x5C / ; \ reverse solidus U+005C
%x2F / ; / solidus U+002F
%x62 / ; b backspace U+0008
%x66 / ; f form feed U+000C
%x6E / ; n line feed U+000A
%x72 / ; r carriage return U+000D
%x74 / ; t tab U+0009
%x75 4HEXDIG ) ; uXXXX U+XXXX

escape = %x5C ; \

quotation-mark = %x22 ; "

unescaped = %x20-21 / %x23-5B / %x5D-10FFFF



I'm leaving a "blank last line" (viz., ^$) in my json files after the closing right bracket. I notice the gui doesn't do that. I may be against the standard in this regard. Thoughts or problems?

[Mosu]

I read the json web doc you have linked in the mkvmerge man page. Here is the section that had me thinking I needed to do both slashes (and control characters).

Yeah, it's a bit confusing, and I'm not sure why they've written it the way they have. There are several two-letter escape sequences for strings a parser has to recognize. However, a producer only has to escape two that are relevant for MKVToolNix: the quotation mark (as that would otherwise terminate the string), the escape character itself (= the backslash or reverse solidus), and potentially the newline and linefeed characters. The relevant passage is this (ECMA-404, section 9 on page 4, first paragraph):

All characters may be placed within the quotation marks except for the characters that must be escaped: quotation mark (U+0022), reverse solidus (U+005C), and the control characters U+0000 to U+001F.

The control characters (such as the tab character) aren't relevant safe for newline and linefeed, I guess.

I'm leaving a "blank last line" (viz., ^$) in my json files after the closing right bracket. I notice the gui doesn't do that. I may be against the standard in this regard. Thoughts or problems?

That's perfectly fine. Whitespace before, between and after elements must be completely ignored by JSON parsers; see ECMA-404 section 4, page 2, last paragraph of the section:

Insignificant whitespace is allowed before or after any token. The whitespace characters are: character tabulation (U+0009), line feed (U+000A), carriage return (U+000D), and space (U+0020).

The one in MKVToolNix can deal with blank lines anywhere just fine. No need to worry.

[Snowknight26]

Suggestion: when clicking on a track in the Track panel, can the Track name field receive focus, like it used to in the old GUI?

[Mosu]

Most likely not. First of all, the new GUI's track selection works quite a bit differently than the old GUI's: you can select multiple tracks, operate on all of them at once, and the new GUI has good support for keyboard navigation and selection. Focusing another element breaks all of those interactions in a bad way.

Second, focusing does not necessarily cause the panel to scroll back up so that the input is visible. If it isn't visible, then that's bad because the user doesn't realize that input is now focused, and she cannot see what she's typing. However, if I change this to scroll up automatically, then it'll annoy all users that have legtimiate business in the lower parts of the track properties panel because now they have to scroll down again.

Third, if you want to jump to the track name quickly just hit Alt+k (that's the keyboard shortcut for that input field if the GUI's language is English). You're putting your fingers on the keyboard anyway, so why not use that?

Getting such functionality right with the new GUI would be very tricky and therefore prone to annoying the users until I've gotten it right. I wouldn't rule it out completely, but it's a strong "not likely".

[Snowknight26]

Alt+K should work, just have to remember to use it.

[iSeries]

Hi,

I have a concert bluray, which is 1080i 29.97fps. I have re-encoded it to 720p 59.94fps - however using latest mkvtoolnix, muxing the 264 stream and the audio and then checking the file with Mediainfo, it shows a frame rate of 60fps, with an 'original' frame rate of 59.94fps. Even when I specify 6000/1001p in mkvtoolnix, the fps gets changed to 60fps. Any tips?

[sneaker_ger]

Is the file in-sync to the end (and long enough for the difference between 60.0 fps and 59.94 fps to result in perceivable desync)? Then everything is fine and it's probably just MediaInfo misdetecting the fps. Timecodes in mkv have limited accuracy and it is not trivial to detect "correct" fps in every case - especially if only looking at the start of a file instead of parsing it completely.

If not: upload a sample and show mkvmerge command and log.

[iSeries]

Should have played the file first, I guess. You're right - everything is fine :-)

[Ripman]

>v14 wave64 support

Anyone play with this yet in mkvtoolnix?

SoX did a build that supported wave64 with some additional libs -- anyone remember where that is?

Thanks again for wave64 support.

[Mosu]

Here's the brand new version 15.0.0 of MKVToolNix. A lot of work has gone into improving support for new track header elements important for video archival purposes. A couple of bugs have been fixed, too, as usual.

Changes for package maintainers: libEBML v1.3.5 is now required. An option has been added to 'configure' for compiling without the code that checks online for new releases. See below for details.

Deprecation warning

This is a reminder that certain features having been deprecated since v9.7.0. They're scheduled to be removed in the first release of 2018. These features are:

mkvmerge: the options "--identify-verbose", "--identify-for-gui", "--identify-for-mmg" and "--identification-format verbose" (use "--identification-format json --identify" or its short form "-J" instead)
all command line tools: the old, proprietary format used for option files (use JSON option files instead)

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 have already been built and uploaded. Linux binaries are still being built and will be available shortly.

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

# Version 15.0.0 "Duel with the Devil" 2017-08-19

## Important notes

* mkvmerge, mkvpropedit, GUI's header and chapter editors: the programs will no longer add most missing Matroska elements that are mandatory but have a default value in the Matroska specification (e.g. the `TagLanguage` element with a value of `und` if it isn't present in its `SimpleTag` parent). Due to this change libEBML v1.3.5 is now required.

## New features and enhancements

* MKVToolNix GUI: multiplex tool: added a new entry to the "source files" context menu labeled "Set destination file name from selected file's name". It will force the GUI to consider the selected file to be the reference for automatically setting the file name, no matter which file was originally added as the first file. It will also force setting the destination file name once if automatic destination file name generation is turned off in the preferences. Implements part of #2058 (https://github.com/mbunkus/mkvtoolnix/issues/2058).
* MKVToolNix GUI: multiplex tool: added an option in the preferences on "Multiplexer" → "Output" labeled "Only use the first source file that contains a video track". If enabled, only source files containing video tracks will be used for setting the destination file name. Other files that are added are ignore. Implements the rest of #2058 (https://github.com/mbunkus/mkvtoolnix/issues/2058).
* MKVToolNix GUI: header editor: added support for editing the video colour attributes. Implements the second half of #2038 (https://github.com/mbunkus/mkvtoolnix/issues/2038).
* MKVToolNix GUI: header editor: added support for the "video projection" track header attributes. Part of the implementation of #2064 (https://github.com/mbunkus/mkvtoolnix/issues/2064).
* MKVToolNix GUI: job queue: selected jobs can now be move up and down by pressing the `Ctrl+Up` and `Ctrl+Down` keys. Additionally, push buttons to move them up & down are shown if the corresponding option is enabled in the preferences. Implements #2060 (https://github.com/mbunkus/mkvtoolnix/issues/2060).
* mkvmerge: added support for the "video projection" track header attributes. Part of the implementation of #2064 (https://github.com/mbunkus/mkvtoolnix/issues/2064).
* mkvinfo: added support for the "video projection" track header attributes. Part of the implementation of #2064 (https://github.com/mbunkus/mkvtoolnix/issues/2064).
* mkvpropedit: added support for editing the video colour attributes. Implements one half of #2038 (https://github.com/mbunkus/mkvtoolnix/issues/2038).
* mkvpropedit: added support for the "video projection" track header attributes. Part of the implementation of #2064 (https://github.com/mbunkus/mkvtoolnix/issues/2064).

## Bug fixes

* all: selecting the program's language (e.g. via the `--ui-language` command-line option or via the GUI's preferences) did not work on Linux & Unix if the `LANGUAGE` environment variable was set and didn't include the desired language. Fixes #2070 (https://github.com/mbunkus/mkvtoolnix/issues/2070).
* MKVToolNix GUI: removed the keyboard shortcuts for switching between the different tools (e.g. `Ctrl+Alt+1` for the multiplexer). They overlapped with basic functionality on keyboards that use an `AltGr` key, e.g. German ones, where `AltGr+7` emits `{`. As `AltGr+key` is implemented as `Ctrl+Alt+key` under the hood, this means that `AltGr+7` is really `Ctrl+Alt+7` which the GUI now took to mean "switch to the job queue" instead of "insert `{`". Fixes #2056 (https://github.com/mbunkus/mkvtoolnix/issues/2056).
* MKVToolNix GUI: header editor: after saving the file the GUI wasn't updating its internal file modification timestamp. That lead to the GUI wrongfully claiming that the file had been modified externally when the user wanted to save the file once more, requiring a reload of the file losing all modifications made since saving the first time.
* mkvmerge: DTS handling: some source files provide timestamps for audio tracks only once every `n` audio frames. In such situations mkvmerge was buffering too much data resulting in a single gap in the timestamps of one frame duration after frame number `n - 1` (the second audio timestamp read from the source file was used one output frame too early). Fixes #2071 (https://github.com/mbunkus/mkvtoolnix/issues/2071).
* mkvinfo: fixed a null pointer dereference if an `EbmlBinary` element's data pointer is a null pointer. Fixes #2072 (https://github.com/mbunkus/mkvtoolnix/issues/2072).

## Build system changes

* configure: added option `--disable-update-check`. If given, the code checking online for available updates will be disabled. The update check is enabled and included in the GUI by default.
* libEBML v1.3.5 is now required.

## Other changes

* mkvmerge: the option `--colour-matrix` has been renamed to `--colour-matrix-coefficients` in order to match the specification more closely. The old option name will continue to be recognized as well.

Have fun :)

[manolito]

Thanks for the new version...

For hello_hello and all other Win XP users:
The workaround from this post:
https://forum.doom9.org/showthread.php?p=1813131#post1813131
still worlks.

Cheers
manolito

[hubblec4]

Hi Mosu

I set the TrackDefaultFlag to true for an audio track(the first track), and a second audio track these Flag is set to false.
After the muxing I load the mkv to the Header-Editor and there is no TrackDefaultFlag Element present. Same in mkvInfo-GUI.
I tried version 14 and 15 of MKVToolNix x64 with the GUI and CLI with the Options.json file.