MKVToolNix v24.0.0 released

[Perenista]

I was looking into my uploaded Matroska files to Google Drive and discovered that one of them had playback issues, meaning that the entire video was fine, but at 4:18 the player freezes and no sound can be heard, then you can see macroblocks after 4:22 (that means it was skipped, and no one can see what goes between 4:18-22). At 18:00 the same thing happens for a few seconds. I downloaded the original file and noticed the same issue using MPC-HC, with a difference that MPC skips from 4 to 18 minutes.

Here's the thing:

1) The Blu-ray decrypted to my HDD looks fine in both these moments (if you look into the original authoring);

2) I used MakeMKV, plus MKVToolnix to edit the thing.

3) The MKVToolnix version was old, from the time Mosu didn't change how it looked like. It was used to split the files, since Google Drive allows only 15 GB for free users.

I don't remember if in those scenes the defect was already there.

However, using THE LAST MKVTOOLNIX version to do the same thing, the entire movie is fine.

My theory is that either it was a bug from this old MKVToolnix version or Google itself damaged the original file. As you can see from here:
https://productforums.google.com/forum/#!topic/youtube/lwJmU45tARI

There were reports of truncated files with shorter lengths in the past. What I never heard was that Google could modify the digital fingerprint of a video you upload there. As we all know, Youtube doesn't keep the original files, only the reencoded ones, while Google Drive gives us BOTH.

I mean, if I upload a 10 GB matroska, the original 10 GB file (unaltered) remains in their servers and when we try to watch, only the reencoded version (with smaller size and lossy) is available for streaming. In my case, I only noticed the problem because 50 minutes were remaining in file 2 and it stopped at 4 minutes.

(File 1 has 62 minutes and file 2 the remaining 50).

So I need to ask you if there's a possibility that ancient MKVToolnix versions could have done this, or perhaps the file-hash was altered and Google itself damaged those parts. Or maybe MakeMKV didn't create a MKV properly, even though this was an untouched/decrypted Blu-ray in my Hard Drive.

I need to know if there has been a similar case in the past, of course corrected in future versions, because I am relying on GD to store my backups. I would not like to find out that in the future some video I don't have a copy is damaged.

Another possibility is that the file itself was somehow damaged in my Hard Drive prior to uploading to Google Drive. I don't know how is that possible since my 1 TB Hard Drive is new and doesn't present any signs of defect, using a software like HDTune Pro to evaluate its health.

P.S. The video only had a DTS-HD MA 5.1 (plus DTS 5.1) track, and an english PGS track (subtitles). Video codec was AVC, High@L4.1 (codec ID: V_MPEG4/ISO/AVC).

[Mosu]

I've never heard of such a case before.

[hubblec4]

Hi Mosu

The "h264/MVC (right eye) stream" of a 3D Bluray is not handled by your GUI. Any plans to add MVC support?

[sneaker_ger]

https://github.com/mbunkus/mkvtoolnix/issues/1106

[kuchikirukia]

What's the difference between mkv segment linking specified in ordered chapters and the "previous/next segment UID" function of MKVToolNix?
mpv works with ordered chapters but it ignores linking the other way.
MPC-HC works great either way.
I don't want to install VLC to check, but I hear it has problems with the previous/next, too. Only one of them will work.

[MGarret]

What's the difference between mkv segment linking specified in ordered chapters and the "previous/next segment UID" function of MKVToolNix?
mpv works with ordered chapters but it ignores linking the other way.
MPC-HC works great either way.
I don't want to install VLC to check, but I hear it has problems with the previous/next, too. Only one of them will work.

I just want to know what I'm talking about when I put in a feature request to mpv.

With "previous/next segment UID" you don't need to make chapter file at all. You can use header editor (or use splitting feature and check "link files" option) to manually add Segment UID of the next/previous file to use as a segment. Players (splitter?) that support this feature should scan mkv's from the same folder to check for their Segment UID's.

I just checked this in recent VLC and it works.

[kuchikirukia]

Well, apparently wm4 can't understand the difference and he threw a rather big hissy fit about it. So apparently mpv won't be fully supporting mkv.

[hubblec4]

What's the difference between mkv segment linking specified in ordered chapters and the "previous/next segment UID" function of MKVToolNix?
mpv works with ordered chapters but it ignores linking the other way.
MPC-HC works great either way.
I don't want to install VLC to check, but I hear it has problems with the previous/next, too. Only one of them will work.

I just want to know what I'm talking about when I put in a feature request to mpv.

Segment linking is in my opinion not the best choice.
Ordered chapters are better. You can enter the "file(segment)-uid" easy at ChapterSegementUID.

For an automatic generation of such a xml-ordered chapter file you can use my chapterEditor->Matroska Menu.

[kuchikirukia]

Is there a way to do ordered chapters that will automatically enter the segment length? Because ordered chapters are nicer, but episode lengths aren't exactly identical so it becomes a major hassle to write them. If the series has an OP and ED at its very beginning and end you can mux a season in a minute with linked segments. To write chapters you need to fetch the UID for the episode and manually enter its length every time.

[sneaker_ger]

To write chapters you need to fetch the UID for the episode and manually enter its length every time.
You shouldn't need to fetch the UID of the episode. No segment UID given means "use current segment".

[kuchikirukia]

You shouldn't need to fetch the UID of the episode. No segment UID given means "use current segment".

Ah, true, I was thinking of the fact you need it to come back to that segment.
But you still need to manually enter the length and then save the chapter to the mkv, when with segment linking you can reuse the same mkvmerge input window and they'll all mux with the same setting. It ensures no stupid timing errors will be made. Missing a fraction of a second at the end of an episode can be missing something very important.
I strive to "me-proof" my workflows.

[nevcairiel]

So apparently mpv won't be fully supporting mkv.

No player on this planet "fully" supports mkv, it has way too many stupid/silly features that noone uses for nothing useful. :p

[hubblec4]

Is there a way to do ordered chapters that will automatically enter the segment length?
This feature is on my todo list. Segment UID and the lenght of the segment(mkv file) will be entered.

Because ordered chapters are nicer, but episode lengths aren't exactly identical so it becomes a major hassle to write them. If the series has an OP and ED at its very beginning and end you can mux a season in a minute with linked segments. To write chapters you need to fetch the UID for the episode and manually enter its length every time.

Therefor I wrote the Matroska Menu Editor.
Creating an ordered chapter xml (and a tags.xml) with all episodes and there linkings is done in less a minute.

[hubblec4]

No player on this planet "fully" supports mkv, it has way too many stupid/silly features that noone uses for nothing useful. :p

The player is the second one, and the first one is the splitter.
You're our man could change that. Your splitter is the only one where mkv works best.

[kuchikirukia]

This feature is on my todo list. Segment UID and the lenght of the segment(mkv file) will be entered.

oooooooooh, nice.

[hubblec4]

Hi Mosu
There are updates on DVDMenuXtractor (https://github.com/Matroska-Org/dvdmenuxtractor). Is robUx4 back and work again on the DMX?

[Mosu]

No idea, to be honest. He's working for VideoLan now, and he is doing work on the Matroska specs, especially in combination with IETF's CELLAR (https://datatracker.ietf.org/wg/cellar/charter/) working group. What his plans for DVDMenuXtractor are I cannot say; you should probably contact him directly.

[hubblec4]

Thanks for this info. I will try it to contact him.

[Perenista]

I've never heard of such a case before.Found a second file corrupted today, this time a MKV with 2 GB instead of more than 10 GB. This is no doubt a server issue from Google. And it was indeed a surprise for me, I thought anything uploaded there would be safe from this kind of problem. This is very odd, because the file was 100% OK when uploaded there (I am positive - others still are, from the same disc and several other contents), and all of sudden, this happens. Other people in the past reported the same thing.

How is it possible that a video file sitting in a Google server can become corrupted? If a Hard Drive fails, don't they have measures to prevent this from happening? If I knew this was going to happen, I would have generated hash values for all files prior to uploading them.

I don't even remember the last time this happened in my Hard Drive. If it happened, it must have happened with a very old Hard Drive, years ago, and the Hard Drive was already gone by the time that happened.

Nowadays I thought it was impossible for this kind of issue to ever happen. Guess I was mistaken and we can't even trust a company like Google with our data.

And I here thinking this was MKVToolnix's fault...

[hubblec4]

mmh..
I have the same issue with same mkv's stored on my extern HDD's.
On the first HDD I have stored Futurama episodes.
On another HDD(5) there are lot of movies.
Both HDD's were at the same time connected to my PC.
2 Years later I check the movies on HDD(5) and the last movies (in different folders) play Futurama video without sound.

Thats so strange that I thougt it is an HDD-issue.

[Boulder]

I've learnt that my computer needs to have the write caching enabled for external drives, otherwise it'll corrupt data randomly, it seems to concern large files such as movies. I always use mkvalidator on files I've processed to make sure that the transferred file is OK in the beginning, and then use Teracopy to copy (and verify) to the final location.

[Mosu]

Hey,

here's another release of MKVToolNix. There were tons of bug fixes all over the place. The most important one is probably in the HEVC handler which won't drop certain SEI NALUs anymore. This was a regression introduced in v8.7.0.

A change a lot of users of Windows and Mac OS will hopefully welcome is that mkvinfo launches with its GUI by default now unless the option "--no-gui" is given. Users of these two OSes often start mkvinfo by clicking on the executable instead of using start menu entries making adding the parameter "--gui" somewhat difficult. The behavior for other OSes has not been changed.

One of the new features is mkvmerge's capability to generate chapters automatically whenever a new file is appended. Additionally it can also generate chapters in fixed intervals. This can be turned on in the GUI, of course.

There's one change for package maintainers: a Korean translation of the programs and the man pages has been added.

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

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's the full ChangeLog (https://mkvtoolnix.download/doc/ChangeLog) since the previous release:

2016-03-26 Moritz Bunkus <moritz@bunkus.org>
* Released v9.0.0 "Power to progress".

2016-03-25 Mike <kona8lend@gmail.com>
* build system: implemented support for explicit pre-compiled headers for Linux and Mac OS.

2016-03-25 Moritz Bunkus <moritz@bunkus.org>
* Installer: fixed support for silent installation and uninstallation.

2016-03-24 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed two more issues in the conversion of teletext subtitles to SRT subtitles: 1. Packets belonging to pages that don't contain subtitles were used as valid end points for subtitles causing entries to become very short (e.g. 40ms). 2. Sometimes the timestamps of wrong packets were used as entry's start and end points causing start timestamps and durations that were slightly off. Second part of the fix for #1623 (https://github.com/mbunkus/mkvtoolnix/issues/1623).

2016-03-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: MP4/QuickTime reader: audio tracks with the FourCC 'lpcm' are muxed as A_PCM/INT/LIT instead of A_QUICKTIME.
* mkvmerge: bug fix: MP4/QuickTime reader: audio tracks can contain two instances of certain header fields (channel count, bits/sample & channel, sample rate) in the STSD atom: one instance in the version 0 header and one in the version 2 header parts. So far mkvmerge has used those from the version 0 header only and ignored the ones from the version 2 header. This has been changed to match the behavior of other players and MP4 readers like ffmpeg. If the STSD atom contains a version 2 structure then the fields from it will be used. Otherwise the fields from the version 0 part will be used. Fixes #1633 (https://github.com/mbunkus/mkvtoolnix/issues/1633).

2016-03-21 Moritz Bunkus <moritz@bunkus.org>
* all: new feature: added a new translation of both the programs and the man pages to Korean by Potato (see AUTHORS).
* MKVToolNix GUI: chapter editor enhancement: added a button next to the 'segment UID' controls that enable the user to select a Matroska file. The GUI reads that file's segment UID and enters its value into the input field.

2016-03-20 Moritz Bunkus <moritz@bunkus.org>
* build system: added an option to configure »--without-qt-pkg-config«. Normally configure uses pkg-config for detecting Qt and setting QT_CFLAGS and QT_LIBS. With this option configure won't use pkg-config and rely on the user having set both variables before running configure. This enables using Qt on systems where no pkg-config files are generated (e.g. Qt 5.6.0 on MacOS with frameworks enabled).

2016-03-18 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: change: on Windows and Mac OS mkvinfo will now launch the GUI by default unless the option »--no-gui« (or »-G«) has been given. This is due to the fact that on both OS users often use portable versions respectively disk images and launch the executable directly and not via start menu entries. In those situations adding command line options for launching the GUI is unnecessarily difficult.

2016-03-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed two issues in the conversion of teletext subtitles to SRT subtitles: 1. Consecutive teletext packets with the same content are now merged into a single entry instead of resulting in multiple entries. 2. The calculation of a packet's duration was wrong in certain situations. Part of the fix for #1623 (https://github.com/mbunkus/mkvtoolnix/issues/1623).

2016-03-14 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool (playlist selection dialog) enhancement: the playlist items are sorted by their position within the playlist by default.
* MKVToolNix GUI: merge tool (playlist selection dialog) enhancement: double-clicking on a playlist will select and add that playlist.

2016-03-12 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: added the number of bits per sample to the verbose/JSON identification output for FLAC files.

2016-03-11 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: fixed the duplication of VPS, SPS, PPS and SEI NALUs when extracting h.265/HEVC tracks. See #1076 (https://github.com/mbunkus/mkvtoolnix/issues/1076) and #1621 (https://github.com/mbunkus/mkvtoolnix/issues/1621).
* mkvmerge: bug fix: reverted the patch by Vladimír Pilný that made the h.265/HEVC not store SEI NALUs with the frames during muxing. It was supposed to prevent having the SEI NALUs present twice when extracting HEVC due to some SEI information also being stored in the codec private data, but it dropped a lot of other SEI NALUs irrevocably. Fixes #1621 (https://github.com/mbunkus/mkvtoolnix/issues/1621).

2016-03-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: the --sub-charset option is now ignored for text subtitle files that start with a byte-order mark (BOM) bringing the behavior in line with the documentation. Fixes #1620 (https://github.com/mbunkus/mkvtoolnix/issues/1620).

2016-03-07 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: new feature: implemented the extraction of Big Endian PCM (codec ID A_PCM/INT/BIG) to WAV files. The content will be byte-swapped into Little Endian PCM in the process.
* mkvmerge: enhancement: Big Endian PCM tracks will now be byte-swapped into Little Endian PCM, and the codec ID A_PCM/INT/LIT will be used. This was done due to a lot of players not supporting Big Endian PCM inside Matroska.

2016-03-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, MKVToolNix GUI: new feature: added switches (»--generate-chapters« and »--generate-chapter-name-template«) and their corresponding UI items for generating chapters while muxing. Two modes are currently supported: »when-appending« which creates one chapter at the beginning and an additional one each time a file is appended and »interval:…« which generates chapters in fixed intervals. Implements mkvmerge's and the GUI's part of #1586 (https://github.com/mbunkus/mkvtoolnix/issues/1586).

2016-02-28 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: job queue enhancement: completed jobs will now be removed from the queue automatically on exit if the job has been added more than 14 days ago in order not to let the queue grow arbitrarily large. This feature can be turned off and the number of days can be adjusted in the preferences.

2016-02-27 Moritz Bunkus <moritz@bunkus.org>
* mkvpropedit, MKVToolNix GUI's header editor: bug fix: fixed the handling of files where the last level 1 element has an unknown size. The programs will now either fix this element to have a known size or abort the process with an appropriate error message but without modifying the file. Fixes #1601 (https://github.com/mbunkus/mkvtoolnix/issues/1601).

2016-02-25 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: enhancement: when extracting chapters in the simple format the user can use the new option »--simple-language …« for selecting the chapter names that are output. Normally the first chapter name found in each atom is used. With this option mkvextract looks for a chapter name whose language matches the specified one. Implements the feature enhancement part of #1610 (https://github.com/mbunkus/mkvtoolnix/issues/1610).
* mkvextract: several issues regarding the extraction of chapters in the simple format have been fixed: if multiple names with different languages were present then an entry had been written for each name; the total number of entries written was wrong; the wrong entries were written. The new code only writes the first name found from the top-most chapter atoms of all editions. Chapters flagged as hidden or as not enabled are not extracted at all. Fixes the bug part of #1610 (https://github.com/mbunkus/mkvtoolnix/issues/1610).

2016-02-24 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new chapter editor feature: added an option to multiply all chapter timecodes by a factor to the "additional modifications" dialog. Implements #1609 (https://github.com/mbunkus/mkvtoolnix/issues/1609).

Have fun :)

[73ChargerFan]

Cool, I tried auto chapter creation to combine a bunch of 3 minute "sing alongs" from an HD-DVD and it worked great. After the file was created, I used Edit Chapters existing MKV to change the chapter names.

Thank you very much!

[hubblec4]

Hi Mosu

I should you remember to my feature request after new versions.

Now seems a good time, cause you have change a bit the mkvinfo.exe. (I know its a little and not the "output info")

But could you now implement a output of the Duration in nano-sec?

This is a part of an info text

|+ Segment information size 131
| + Timecode scale: 1000000 size 7
| + Muxing application: libebml v1.3.3 + libmatroska v1.4.4 size 38
| + Writing application: mkvmerge v8.8.0 ('Wind at my back') 32bit size 44
| + Duration: 2763.744s (00:46:03.744) size 7
| + Date: Tue Mar 01 19:27:08 2016 UTC size 11
| + Segment UID: 0x98 0x7e 0xe4 0x54 0x5a 0xdf 0x74 0x96 0xa6 0xa2 0xc4 0xb1 0x44 0xd1 0x54 0xd9 size 19

How you calculate this duration? Is in the info output enaugh information to calculate the duration by my self?

[Mosu]

No, I'm sorry. As I've said before changing the existing format is a recipe for breaking other people's tools.

If you need the file duration in a higher resolution then use mkvmerge's JSON (or verbose) identification mode. It includes the segment duration in nanoseconds.

Neither mkvinfo nor mkvmerge calculates the duration; it's a header field in the file whose value is output.

mkvmerge calculates the duration and sets the header field during muxing, of course. It's the difference between the highest sum of a frame's timestamp and its duration in the segment minus the lowest timestamp of all frames in the segment. Note that the header field itself is based on the segment's timestamp scaling value. This means that with standard settings (timestamp scaling at 1000000) its resolution is milliseconds even if mkvmerge's JSON identification mode always outputs nanoseconds.

[SeeMoreDigital]

Thanks for the new version :)

[Sparktank]

:thanks: Appreciate the A_PCM/INT/BIG conversion to A_PCM/INT/LIT on the fly.

[hubblec4]

No, I'm sorry. ...

If you need the file duration in a higher resolution then use mkvmerge's JSON (or verbose) identification mode. It includes the segment duration in nanoseconds.
...

Perfect, I will have a look.

[Fullmetal Encoder]

2016-03-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, MKVToolNix GUI: new feature: added switches (»--generate-chapters« and »--generate-chapter-name-template«) and their corresponding UI items for generating chapters while muxing. Two modes are currently supported: »when-appending« which creates one chapter at the beginning and an additional one each time a file is appended and »interval:…« which generates chapters in fixed intervals. Implements mkvmerge's and the GUI's part of #1586.


Thank you very much for seriously considering and implementing this. I think it's a huge leap forward in giving users practical access to one of Mastroska's most powerful features. And, as always, thanks for all your continued work on this terrific software.

[filler56789]

1) @Mosu: many :thanks: for the new version.

2)
mmh..
I have the same issue with same mkv's stored on my extern HDD's.
On the first HDD I have stored Futurama episodes.
On another HDD(5) there are lot of movies.
Both HDD's were at the same time connected to my PC.
2 Years later I check the movies on HDD(5) and the last movies (in different folders) play Futurama video without sound.

Thats so strange that I thougt it is an HDD-issue.
&&
I've learnt that my computer needs to have the write caching enabled for external drives, otherwise it'll corrupt data randomly, it seems to concern large files such as movies. I always use mkvalidator on files I've processed to make sure that the transferred file is OK in the beginning, and then use Teracopy to copy (and verify) to the final location.

Yes... FWIW:

http://forum.videohelp.com/threads/367509-Files-corrupted-when-copying-to-external-usb3-hdd

[isidroco]

mmh.. I have the same issue with same mkv's stored on my extern HDD's.....

Unfortunately, it happens that some bytes are changed. Now I always generate a MD5 checksum list of all files (with total commander) before making a backup. Then test backup's MD5 to exclude corruption. Sometimes a couple of bytes per Tb become corrupted, even with internal HDs. Usually SATA cables to blame.

PS: Thanks for this new version!

[hubblec4]

Thanks for this info to copying mkv's to an external HDD.
I have used "SuperCopier" for copy data over usb2/usb3 (I know the Win7 bug). I should use this software (or Teracopy -but its not 100% freeware) in future for all copys.

[Mosu]

Guys, this is a thread about MKVToolNix, not one about fighting with your OS or your hardware. Can we please drop the topic of USB drives and the associated file corruption? Thanks.

[hubblec4]

Hi Mosu

I have tried the identification with JSON and it seems to me the duration in nanosec is not really good calculated.
Only 0-digits fill the rest of nanosecs.


.....
"container": {
"properties": {
"container_type": 17,
"duration": 2763136000000,
"is_providing_timecodes": true,
"segment_uid": "bca9e279b82f5fba9f315cfd3655add8"
},
"recognized": true,
"supported": true,
"type": "Matroska"
...

[Groucho2004]

I suppose it's by design that the new mkvmerge switch "--generate-chapters interval:xxx" only supports chapter marks at intervals >= 300 seconds?

[Mosu]

Hi Mosu

I have tried the identification with JSON and it seems to me the duration in nanosec is not really good calculated.
Only 0-digits fill the rest of nanosecs.

Please re-read what I've written above (http://forum.doom9.org/showthread.php?p=1762154#post1762154). The header field's resolution is determined by the file's timestamp scaling.

[Mosu]

I suppose it's by design that the new mkvmerge switch "--generate-chapters interval:xxx" only supports chapter marks at intervals >= 300 seconds?

No, you can use any duration. I've just given 10s a try, and it works just fine:

[0 mosu@sweet-chili (master) ~/prog/video/data] mkvmerge -o v.mkv v.avi --generate-chapters interval:10s
mkvmerge v9.0.0 ('Power to progress') 64bit
'v.avi': Using the demultiplexer for the format 'AVI'.
'v.avi' track 0: Using the output module for the format 'AVC/h.264 (unframed)'.
'v.avi' track 1: Using the output module for the format 'AAC'.
Using the track with the ID 0 from the file 'v.avi' as the reference for chapter generation.
The file 'v.mkv' has been opened for writing.
'v.avi' track 0: Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 640/352.
Progress: 100%
The cue entries (the index) are being written...
Muxing took 0 seconds.
[0 mosu@sweet-chili (master) ~/prog/video/data] mkvextract chapters v.mkv
<?xml version="1.0"?>
<!-- <!DOCTYPE Chapters SYSTEM "matroskachapters.dtd"> -->
<Chapters>
<EditionEntry>
<EditionFlagHidden>0</EditionFlagHidden>
<EditionFlagDefault>0</EditionFlagDefault>
<EditionUID>15387469689991544545</EditionUID>
<ChapterAtom>
<ChapterUID>5188743258543738188</ChapterUID>
<ChapterTimeStart>00:00:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 01</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>1343074347162551858</ChapterUID>
<ChapterTimeStart>00:00:10.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 02</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>12827577923699787492</ChapterUID>
<ChapterTimeStart>00:00:20.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 03</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>14365894815514065430</ChapterUID>
<ChapterTimeStart>00:00:30.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 04</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>15150422538290076290</ChapterUID>
<ChapterTimeStart>00:00:40.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 05</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>14737049900229639724</ChapterUID>
<ChapterTimeStart>00:00:50.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 06</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>17067655115020329310</ChapterUID>
<ChapterTimeStart>00:01:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 07</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>273832462594112675</ChapterUID>
<ChapterTimeStart>00:01:10.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 08</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
</EditionEntry>
</Chapters>

[hubblec4]

Please re-read what I've written above (http://forum.doom9.org/showthread.php?p=1762154#post1762154). The header field's resolution is determined by the file's timestamp scaling.

Ok sorry, its not possible to get nanosec precision, cause is the timestamp scaling is limited to millisec.

Can I extract the FPS and the frames info with mkvmerge or info.exe?

[Mosu]

No. A Matroska file doesn't have a number of frames per second, it only has distinctly timestamped frames. See this FAQ entry (https://github.com/mbunkus/mkvtoolnix/wiki/Wrong-frame-rate-displayed). The video track's default duration field (output by both mkvmerge and mkvinfo) is only an approximation as it is scaled by timestamp scaling, too.

[hubblec4]

OK. Than the spec should updated there :-)
Is this possible?

[Mosu]

You're welcome to work on this and suggest appropriate specs. The places to talk about spec changes are the Matroska-devel (https://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel) and the IETF CELLAR (https://datatracker.ietf.org/wg/cellar/documents/) working group.

[Groucho2004]

No, you can use any duration. I've just given 10s a try, and it works just fine
I tried this:
mkvmerge --output "test.mkv" --language 0:eng --compression 0:none --default-duration 0:24000/1001p ( "test.264" ) --language 0:eng ( "test.m4a" ) --track-order 0:0,1:0 --generate-chapters interval:300s
MediaInfo correctly reports the chapters:
Menu
Count : 109
Count of stream of this kind : 1
Kind of stream : Menu
Kind of stream : Menu
Stream identifier : 0
Chapters_Pos_Begin : 90
Chapters_Pos_End : 109
00:00:00.000 : en:Chapter 01
00:05:00.000 : en:Chapter 02
00:10:00.000 : en:Chapter 03
00:15:00.000 : en:Chapter 04
00:20:00.000 : en:Chapter 05
00:25:00.000 : en:Chapter 06
00:30:00.000 : en:Chapter 07
00:35:00.000 : en:Chapter 08
00:40:00.000 : en:Chapter 09
00:45:00.000 : en:Chapter 10
00:50:00.000 : en:Chapter 11
00:55:00.000 : en:Chapter 12
01:00:00.000 : en:Chapter 13
01:05:00.000 : en:Chapter 14
01:10:00.000 : en:Chapter 15
01:15:00.000 : en:Chapter 16
01:20:00.000 : en:Chapter 17
01:25:00.000 : en:Chapter 18
01:30:00.000 : en:Chapter 19

If I change "interval" to "250s", there are no chapter marks visible in mpc-hc and there is no "Menu" section present in the MediaInfo export.

[Mosu]

I just tried 250s (with the GUI on Windows this time); works just fine here, too. I highly suspect an error on your part (e.g. you've opened the wrong file in the player, or you actually didn't mux and only added the job to the queue or something like that).

[Groucho2004]

I highly suspect an error on your part (e.g. you've opened the wrong file in the player, or you actually didn't mux and only added the job to the queue or something like that).
It would have been sufficient to say that you can't reproduce this behaviour. Accusing me of being an idiot/noob is not necessary, I have been using mkvmerge for many years.

Never used the gui but just for the fun of it just tried it. Same result.

Until now I have been using a tool I wrote that parses the streams and generates a chapter file for import into mkvmerge. I was hoping that the new option would eliminate that step.

So, just ignore my posts, I'll stick with my current method.

[Mosu]

I'm sorry you feel put down, but I wasn't calling you names, nor a noob, and I definitely didn't intend to. There have been countless times where users have reported supposed problems and it turned out they were making some kind of error when checking the result. Hell, I do it often enough myself, especially when I'm debugging code (e.g. I'm outputting the wrong variables leading me to think there is a bug when there actually isn't). To err is fundamentally human. It's not a character defect.

Typical issues that users including myself have made in the past: playing the wrong file instead of the one mkvmerge has just created (wrong file name, wrong directory…); not actually having run mkvmerge after changing some options; not looking at mkvmerge's output and not seeing that an error message was output (e.g. trying to write to a file which is still open in a player and locked by it). Making any of these errors says nothing at all about a person's proficiency. One can do a task correctly a hundred times only to make an error the next time. Does that make him an idiot? Far from it.

Now back to mkvmerge not creating chapters. Can you please take the command line you've written above and run the following modifications of it:

mkvmerge --output "test-300.mkv" --language 0:eng --compression 0:none --default-duration 0:24000/1001p ( "test.264" ) --language 0:eng ( "test.m4a" ) --track-order 0:0,1:0 --generate-chapters interval:300s
mkvmerge --output "test-250.mkv" --language 0:eng --compression 0:none --default-duration 0:24000/1001p ( "test.264" ) --language 0:eng ( "test.m4a" ) --track-order 0:0,1:0 --generate-chapters interval:250s
mkvextract chapters test-300.mkv
mkvextract chapters test-250.mkv

What is the output of the two mkvextract commands?

[Groucho2004]

Sorry, I guess I over-reacted a bit. Before I report something like this I always double- or triple-check the results to be sure that it's not a silly user error as you mentioned.

I ran your command lines and "test-300" outputs what was to be expected:
<?xml version="1.0"?>
<!-- <!DOCTYPE Chapters SYSTEM "matroskachapters.dtd"> -->
<Chapters>
<EditionEntry>
<EditionFlagHidden>0</EditionFlagHidden>
<EditionFlagDefault>0</EditionFlagDefault>
<EditionUID>15240921881376772994</EditionUID>
<ChapterAtom>
<ChapterUID>6755968388673756333</ChapterUID>
<ChapterTimeStart>00:00:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 01</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>10765774132084890519</ChapterUID>
<ChapterTimeStart>00:05:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 02</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>15181808861288630163</ChapterUID>
<ChapterTimeStart>00:10:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 03</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>11211224267078624444</ChapterUID>
<ChapterTimeStart>00:15:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 04</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>12772237345159149743</ChapterUID>
<ChapterTimeStart>00:20:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 05</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>6027843348120838316</ChapterUID>
<ChapterTimeStart>00:25:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 06</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>8309850999047443333</ChapterUID>
<ChapterTimeStart>00:30:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 07</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>7090206436313069997</ChapterUID>
<ChapterTimeStart>00:35:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 08</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>10302068659269412522</ChapterUID>
<ChapterTimeStart>00:40:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 09</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>6516520102347956407</ChapterUID>
<ChapterTimeStart>00:45:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 10</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>17909294277027573424</ChapterUID>
<ChapterTimeStart>00:50:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 11</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>10533455910740190633</ChapterUID>
<ChapterTimeStart>00:55:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 12</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>8062765570784066221</ChapterUID>
<ChapterTimeStart>01:00:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 13</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>14454955690992927150</ChapterUID>
<ChapterTimeStart>01:05:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 14</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>9588557843478759354</ChapterUID>
<ChapterTimeStart>01:10:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 15</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>3736210551441426074</ChapterUID>
<ChapterTimeStart>01:15:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 16</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>11616954146485479823</ChapterUID>
<ChapterTimeStart>01:20:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 17</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>14130439254598456491</ChapterUID>
<ChapterTimeStart>01:25:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 18</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>1388229754696499842</ChapterUID>
<ChapterTimeStart>01:30:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 19</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
</EditionEntry>
</Chapters>


"test-250" outputs nothing.

I'll try it with different streams later to see if the same happens.

[Mosu]

Huh… Very strange. I honestly have no idea yet why no chapters are generated for you. As I said I cannot reproduce it at the moment; I've even tried the very same command line I've posted (the 250s one) with the same file types. Maybe it depends on the actual files in question.

[Mosu]

Hah, I can reproduce it now. It seems that it's a question of the number of chapters that are created whether or not it breaks. So far I had only tried 250s with a 45min movie, but when I use 25s no chapters are present in the output file. I'll investigate. Thanks for pointing it out.

[Mosu]

The issue with the chapter generation should be fixed in pre-builds 01163 and higher (https://mkvtoolnix.download/windows/pre/).

[manolito]

Until now I have been using a tool I wrote that parses the streams and generates a chapter file for import into mkvmerge. I was hoping that the new option would eliminate that step.


Since I am stuck with version 0.7.80 (I'm still using XP), would you consider publishing your tool?

So far I have been using a software called MKV Chapterizer for this task, but it is not always reliable.


Cheers
manolito

[sneaker_ger]

I don't have XP to test it but wasn't XP compatibility restored in version 8.0.0?

[Groucho2004]

Since I am stuck with version 0.7.80 (I'm still using XP), would you consider publishing your tool?

So far I have been using a software called MKV Chapterizer for this task, but it is not always reliable.

Cheers
manolito
mkvmerge v9 works fine on XP32SP3.

[Groucho2004]

The issue with the chapter generation should be fixed in pre-builds 01163 and higher (https://mkvtoolnix.download/windows/pre/).
Confirmed. Thanks for the fix.

[manolito]

mkvmerge v9 works fine on XP32SP3.

Oops, after these posts
http://forum.doom9.org/showthread.php?p=1721140#post1721140
http://forum.doom9.org/showthread.php?p=1721161#post1721161
http://forum.doom9.org/showthread.php?p=1721792#post1721792

where Mosu confirmed that v 7.80 would be the last version to work under XP I did not follow this thread any longer. Also because v 7.80 does everything I need, and I also got used to the old GUI over time.

Just checked v.9, and it really does work under XP, even with my non-SSE2 CPU. Great, thanks a lot Mosu...

Now I just have to get used to the new GUI, lots of new things to discover.
Quick question: Still no message or chime after a merging job has finished? At least I could not find it after a few minutes.


Cheers
manolito

[sneaker_ger]

There is no feature specifically for playing sounds but you can achieve it via the "executing programs" feature. (at the very bottom of the settings list)
https://github.com/mbunkus/mkvtoolnix/issues/1570#issuecomment-170256692

[manolito]

Thanks...

[Mosu]

Hey,

Due to two nasty bugs in v9.0.0 I've decided to release a hotfix with v9.0.1 today. The first bug is a regression from v8.9.0 in the code handling character sets for text subtitle files. The other bug is in the new code for generating chapters automatically.

As the prior release v9.0.0 is only two days old I'm including v9.0.0's full release announcement here:

Here's another release of MKVToolNix. There were tons of bug fixes all over the place. The most important one is probably in the HEVC handler which won't drop certain SEI NALUs anymore. This was a regression introduced in v8.7.0.

A change a lot of users of Windows and Mac OS will hopefully welcome is that mkvinfo launches with its GUI by default now unless the option "--no-gui" is given. Users of these two OSes often start mkvinfo by clicking on the executable instead of using start menu entries making adding the parameter "--gui" somewhat difficult. The behavior for other OSes has not been changed.

One of the new features is mkvmerge's capability to generate chapters automatically whenever a new file is appended. Additionally it can also generate chapters in fixed intervals. This can be turned on in the GUI, of course.

There's one change for package maintainers: a Korean translation of the programs and the man pages has been added.

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

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's the full ChangeLog (https://mkvtoolnix.download/doc/ChangeLog) since v8.9.0:

2016-03-28 Moritz Bunkus <moritz@bunkus.org>
* Released v9.0.1 "Obstacles".
* mkvmerge: bug fix: regression in v9.0.0: the text subtitle packetizer was wrongfully assuming an encoding of UTF-8 if none was given instead of assuming the system's encoding. Fixes #1639 (https://github.com/mbunkus/mkvtoolnix/issues/1639).

2016-03-27 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: if too many chapters had been generated with --generate-chapters then mkvmerge created a bogus entry in the meta seek element and did not actually write the chapters to the file.
* mkvmerge: bug fix: the DTS packetizer was setting the number of channels wrong sometimes when reducing to the DTS core. It was using the number of channels including the extensions instead of the channels of the core only.

2016-03-26 Moritz Bunkus <moritz@bunkus.org>
* Released v9.0.0 "Power to progress".

2016-03-25 Mike <kona8lend@gmail.com>
* build system: implemented support for explicit pre-compiled headers for Linux and Mac OS.

2016-03-25 Moritz Bunkus <moritz@bunkus.org>
* Installer: fixed support for silent installation and uninstallation.

2016-03-24 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed two more issues in the conversion of teletext subtitles to SRT subtitles: 1. Packets belonging to pages that don't contain subtitles were used as valid end points for subtitles causing entries to become very short (e.g. 40ms). 2. Sometimes the timestamps of wrong packets were used as entry's start and end points causing start timestamps and durations that were slightly off. Second part of the fix for #1623 (https://github.com/mbunkus/mkvtoolnix/issues/1623).

2016-03-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: MP4/QuickTime reader: audio tracks with the FourCC 'lpcm' are muxed as A_PCM/INT/LIT instead of A_QUICKTIME.
* mkvmerge: bug fix: MP4/QuickTime reader: audio tracks can contain two instances of certain header fields (channel count, bits/sample & channel, sample rate) in the STSD atom: one instance in the version 0 header and one in the version 2 header parts. So far mkvmerge has used those from the version 0 header only and ignored the ones from the version 2 header. This has been changed to match the behavior of other players and MP4 readers like ffmpeg. If the STSD atom contains a version 2 structure then the fields from it will be used. Otherwise the fields from the version 0 part will be used. Fixes #1633 (https://github.com/mbunkus/mkvtoolnix/issues/1633).

2016-03-21 Moritz Bunkus <moritz@bunkus.org>
* all: new feature: added a new translation of both the programs and the man pages to Korean by Potato (see AUTHORS).
* MKVToolNix GUI: chapter editor enhancement: added a button next to the 'segment UID' controls that enable the user to select a Matroska file. The GUI reads that file's segment UID and enters its value into the input field.

2016-03-20 Moritz Bunkus <moritz@bunkus.org>
* build system: added an option to configure »--without-qt-pkg-config«. Normally configure uses pkg-config for detecting Qt and setting QT_CFLAGS and QT_LIBS. With this option configure won't use pkg-config and rely on the user having set both variables before running configure. This enables using Qt on systems where no pkg-config files are generated (e.g. Qt 5.6.0 on MacOS with frameworks enabled).

2016-03-18 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: change: on Windows and Mac OS mkvinfo will now launch the GUI by default unless the option »--no-gui« (or »-G«) has been given. This is due to the fact that on both OS users often use portable versions respectively disk images and launch the executable directly and not via start menu entries. In those situations adding command line options for launching the GUI is unnecessarily difficult.

2016-03-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed two issues in the conversion of teletext subtitles to SRT subtitles: 1. Consecutive teletext packets with the same content are now merged into a single entry instead of resulting in multiple entries. 2. The calculation of a packet's duration was wrong in certain situations. Part of the fix for #1623 (https://github.com/mbunkus/mkvtoolnix/issues/1623).

2016-03-14 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool (playlist selection dialog) enhancement: the playlist items are sorted by their position within the playlist by default.
* MKVToolNix GUI: merge tool (playlist selection dialog) enhancement: double-clicking on a playlist will select and add that playlist.

2016-03-12 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: added the number of bits per sample to the verbose/JSON identification output for FLAC files.

2016-03-11 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: fixed the duplication of VPS, SPS, PPS and SEI NALUs when extracting h.265/HEVC tracks. See #1076 (https://github.com/mbunkus/mkvtoolnix/issues/1076) and #1621 (https://github.com/mbunkus/mkvtoolnix/issues/1621).
* mkvmerge: bug fix: reverted the patch by Vladimír Pilný that made the h.265/HEVC not store SEI NALUs with the frames during muxing. It was supposed to prevent having the SEI NALUs present twice when extracting HEVC due to some SEI information also being stored in the codec private data, but it dropped a lot of other SEI NALUs irrevocably. Fixes #1621 (https://github.com/mbunkus/mkvtoolnix/issues/1621).

2016-03-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: the --sub-charset option is now ignored for text subtitle files that start with a byte-order mark (BOM) bringing the behavior in line with the documentation. Fixes #1620 (https://github.com/mbunkus/mkvtoolnix/issues/1620).

2016-03-07 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: new feature: implemented the extraction of Big Endian PCM (codec ID A_PCM/INT/BIG) to WAV files. The content will be byte-swapped into Little Endian PCM in the process.
* mkvmerge: enhancement: Big Endian PCM tracks will now be byte-swapped into Little Endian PCM, and the codec ID A_PCM/INT/LIT will be used. This was done due to a lot of players not supporting Big Endian PCM inside Matroska.

2016-03-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, MKVToolNix GUI: new feature: added switches (»--generate-chapters« and »--generate-chapter-name-template«) and their corresponding UI items for generating chapters while muxing. Two modes are currently supported: »when-appending« which creates one chapter at the beginning and an additional one each time a file is appended and »interval:…« which generates chapters in fixed intervals. Implements mkvmerge's and the GUI's part of #1586 (https://github.com/mbunkus/mkvtoolnix/issues/1586).

2016-02-28 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: job queue enhancement: completed jobs will now be removed from the queue automatically on exit if the job has been added more than 14 days ago in order not to let the queue grow arbitrarily large. This feature can be turned off and the number of days can be adjusted in the preferences.

2016-02-27 Moritz Bunkus <moritz@bunkus.org>
* mkvpropedit, MKVToolNix GUI's header editor: bug fix: fixed the handling of files where the last level 1 element has an unknown size. The programs will now either fix this element to have a known size or abort the process with an appropriate error message but without modifying the file. Fixes #1601 (https://github.com/mbunkus/mkvtoolnix/issues/1601).

2016-02-25 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: enhancement: when extracting chapters in the simple format the user can use the new option »--simple-language …« for selecting the chapter names that are output. Normally the first chapter name found in each atom is used. With this option mkvextract looks for a chapter name whose language matches the specified one. Implements the feature enhancement part of #1610 (https://github.com/mbunkus/mkvtoolnix/issues/1610).
* mkvextract: several issues regarding the extraction of chapters in the simple format have been fixed: if multiple names with different languages were present then an entry had been written for each name; the total number of entries written was wrong; the wrong entries were written. The new code only writes the first name found from the top-most chapter atoms of all editions. Chapters flagged as hidden or as not enabled are not extracted at all. Fixes the bug part of #1610 (https://github.com/mbunkus/mkvtoolnix/issues/1610).

2016-02-24 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new chapter editor feature: added an option to multiply all chapter timecodes by a factor to the "additional modifications" dialog. Implements #1609 (https://github.com/mbunkus/mkvtoolnix/issues/1609).

Have fun :)

[AYColumbia]

Thank you Mosu for the continued updates. Not crazy about the change below though as it'll require changing all my batch files, but thanks for providing the no GUI option.
... A change a lot of users of Windows and Mac OS will hopefully welcome is that mkvinfo launches with its GUI by default now unless the option "--no-gui" is given. Users of these two OSes often start mkvinfo by clicking on the executable instead of using start menu entries making adding the parameter "--gui" somewhat difficult. The behavior for other OSes has not been changed. ...
I just did a test run with --no-gui and works great. Thanks again.

[Mosu]

AYColumbia: what exactly are you using mkvinfo in batch files for? mkvinfo's output is NOT designed to be parsed; e.g. attachments located at the back are not listed by default. Instead mkvmerge's identification output (e.g. "mkvmerge --identification-format json --identify yourfile.mkv") is and is the preferred way. It's also the only supported way to get the track IDs for mkvmerge and mkvextract.

[AYColumbia]

AYColumbia: what exactly are you using mkvinfo in batch files for? mkvinfo's output is NOT designed to be parsed; e.g. attachments located at the back are not listed by default. Instead mkvmerge's identification output (e.g. "mkvmerge --identification-format json --identify yourfile.mkv") is and is the preferred way. It's also the only supported way to get the track IDs for mkvmerge and mkvextract.
Oh wow. I didn't even know that mkvmerge had that option. Very useful and it's essentially why I'm using mkvinfo, i.e., I dump output to a file, parse though it to find number tracks, which are video, audio, subtitles, chapters, etc.

Thank you for the info on the JSON info which I will be looking into to see about updating my processes to use this instead.

[hubblec4]

Hi Mosu

The entry "ChapterSegmentEditionUID" is this the same like "ChapterSegmentUID"?
Also when I use the CSE-UID instead of the CS-UID, play then a complete edition of the file as segment?

[Mosu]

The intention is to use both together. You use ChapterSegmentUID to tell the player which segment to play and you can refine that selection by telling it to only play a certain chapter edition with the ChapterSegmentEditionUID. Obviously the edition referred to with ChapterSegmentEditionUID must be part of the segment referred to with ChapterSegmentUID.

I don't understand your second question, though, it doesn't make much sense to me yet.

[hubblec4]

The intention is to use both together. You use ChapterSegmentUID to tell the player which segment to play and you can refine that selection by telling it to only play a certain chapter edition with the ChapterSegmentEditionUID. Obviously the edition referred to with ChapterSegmentEditionUID must be part of the segment referred to with ChapterSegmentUID.
Ok that's clear.

I don't understand your second question, though, it doesn't make much sense to me yet.

(I had even just think about it again.)

A Segment means another file, identified by the SegmentID.
Chapter-Segment-Linking works only with ordered chapters.

When I use chapter segment linking, then from a
another file a video part played. The duration of the video part is determined by the start and end times in the chapter.

So far so good.

An edition has multiple chapters, will all these played when I specify a ChapterSegementEditionUID?
What is with the timestamps in the chapter where the linking is set? Will these ignored?

[Mosu]

Note that I wasn't involved in speccing the ordered chapter stuff, that was all Steve Lhomme, and I haven't used ordered chapters myself. Therefore I cannot really answer this with authority. I would guess that if an edition is referenced via ChapterSegmentEditionUID that all chapters in said edition will be played in the order given by their start timestamps. I don't know how timestamps in the link sources will be handled though for the aforementioned reasons.

[hubblec4]

Note that I wasn't involved in speccing the ordered chapter stuff, that was all Steve Lhomme, ....
But you're the only one who is so easy to reach and always responds. Thanks a lot.

[Ex0rcist]

MKVExtractGUI doesn't work anymore with MKVToolNix since version 9. It must be something related to "mkvinfo.exe".

[Mosu]

See here (https://github.com/mbunkus/mkvtoolnix/issues/1636).

[hubblec4]

MKVExtractGUI doesn't work anymore with MKVToolNix since version 9. It must be something related to "mkvinfo.exe".

No, I'm sorry. As I've said before changing the existing format is a recipe for breaking other people's tools.

A bit confusing...
Ok, the format has not changed, but the result is the same.
Breaking other tools.

[Mosu]

True, of course. But in this case usability for a LOT of Windows and Mac users trumps keeping backwards compatibility. Changing the output format, on the other hand, only benefits a small number of users while potentially breaking a number of parsers. I haven't done this on a whim. Over time I've received quite a lot of mails by people using the portable version of the Mac OS DMG who were confused that they couldn't start mkvinfo's GUI.

[LeXXuz]

I've remuxed a couple of Matroska files with the latest version.
I noticed the usual "Encoder Settings" information of x264 encoded video tracks is gone.

At least MediaInfo does not show them any more. Have there been some changes to this lately?

[Mosu]

No changes come to mind.

[Mosu]

Additionally I cannot reproduce this:

[0 mosu@sweet-chili ~/prog/video/data] x264 --crf 24 -o before-remux.264 v.avi
…
encoded 1672 frames, 257.41 fps, 288.88 kb/s
[0 mosu@sweet-chili ~/prog/video/data] mediainfo before-remux.264
…
Writing library : x264 core 148 r2643 5c65704
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=24.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
…
[0 mosu@sweet-chili ~/prog/video/data] mkvmerge -o v.mkv before-remux.264
…
[0 mosu@sweet-chili ~/prog/video/data] mediainfo v.mkv
…
Writing library : x264 core 148 r2643 5c65704
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=24.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
…
[0 mosu@sweet-chili ~/prog/video/data] mkvmerge -o v2.mkv v.mkv
…
[0 mosu@sweet-chili ~/prog/video/data] mediainfo v2.mkv
Writing library : x264 core 148 r2643 5c65704
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=24.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
…
[0 mosu@sweet-chili ~/prog/video/data] mkvextract tracks v2.mkv 0:after-remux-and-extraction.264
…
[0 mosu@sweet-chili ~/prog/video/data] mediainfo after-remux-and-extraction.264
Writing library : x264 core 148 r2643 5c65704
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=24.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
…
[0 mosu@sweet-chili ~/prog/video/data] x264 --version
x264 0.148.2643 5c65704
(libswscale 4.0.100)
(libavformat 57.25.100)
built on Feb 15 2016, gcc: 5.3.0
x264 configuration: --bit-depth=8 --chroma-format=all
libx264 configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat license: GPL version 3 or later
[0 mosu@sweet-chili ~/prog/video/data] mediainfo --version
MediaInfo Command line,
MediaInfoLib - v0.7.84
[255 mosu@sweet-chili ~/prog/video/data] mkvmerge --version
mkvmerge v9.0.1 ('Obstacles') 64bit

[sneaker_ger]

I can't reproduce either.
Note: the x264 settings are stored at the beginning of the encode. If you split it into several parts only the very first part will have them. (if you use split parts to skip the beginning none will)

[sl1pkn07]

split mkv/mka (using mkvmerge) with concatenate timecodes gets intermediate files with 6 or more Kb of size (useless)


┌─┤[$]|[sl1pkn07]|[sL1pKn07]|[/run/media/sl1pkn07/WDGP3TB-3/[BDMV][151209] RWBY Vol.1 [JP]/RWBY_VOLUME1/prueba]|
└───╼ mkvmerge -o split.avs.mka.split.mka --sync 0:0 audio_2.0.ac3 --split timecodes:00:00:05.005,00:00:05.005,00:11:11.838,00:11:11.838,00:12:25.612,00:12:25.612,00:23:47.059,00:23:47.059,00:34:34.039,00:34:34.039,00:45:16.914,00:45:16.914,00:58:34.544,00:58:34.544,01:09:44.147,01:09:44.147,01:20:38.667,01:20:38.667,01:31:42.864,01:31:42.864,01:41:48.402,01:41:48.402,01:56:42.162
mkvmerge v9.0.1 ('Obstacles') 64bit
'audio_2.0.ac3': Usando el desmultiplexador para el formato 'AC-3'.
'audio_2.0.ac3' pista 0: Usando el módulo de salida para el formato 'AC-3'.
El archivo split.avs.mka.split-001.mka ha sido abierto para su escritura.
Progreso: 0%
Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-002.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-003.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-004.mka ha sido abierto para su escritura.
Progreso: 9%
Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-005.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-006.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-007.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-008.mka ha sido abierto para su escritura.
Progreso: 20%
Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-009.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-010.mka ha sido abierto para su escritura.
Progreso: 29%
Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-011.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-012.mka ha sido abierto para su escritura.
Progreso: 38%
Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-013.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-014.mka ha sido abierto para su escritura.
Progreso: 49%
Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-015.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-016.mka ha sido abierto para su escritura.
Progreso: 59%
Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-017.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-018.mka ha sido abierto para su escritura.
Progreso: 68%
Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-019.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-020.mka ha sido abierto para su escritura.
Progreso: 77%
Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-021.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-022.mka ha sido abierto para su escritura.
Progreso: 86%
Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-023.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo split.avs.mka.split-024.mka ha sido abierto para su escritura.
Progreso: 100%
Los registros del cue (el índice) están siendo escritos...
El multiplexado tardó 7 segundos.
┌─┤[$]|[sl1pkn07]|[sL1pKn07]|[/run/media/sl1pkn07/WDGP3TB-3/[BDMV][151209] RWBY Vol.1 [JP]/RWBY_VOLUME1/prueba]|
└───╼ ls *mka -h
-rw-r--r-- 1 sl1pkn07 users 399K abr 4 20:57 split.avs.mka.split-001.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 20:57 split.avs.mka.split-002.mka
-rw-r--r-- 1 sl1pkn07 users 51M abr 4 20:57 split.avs.mka.split-003.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 20:57 split.avs.mka.split-004.mka
-rw-r--r-- 1 sl1pkn07 users 5,7M abr 4 20:57 split.avs.mka.split-005.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 20:57 split.avs.mka.split-006.mka
-rw-r--r-- 1 sl1pkn07 users 53M abr 4 20:57 split.avs.mka.split-007.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 20:57 split.avs.mka.split-008.mka
-rw-r--r-- 1 sl1pkn07 users 50M abr 4 20:57 split.avs.mka.split-009.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 20:57 split.avs.mka.split-010.mka
-rw-r--r-- 1 sl1pkn07 users 50M abr 4 20:57 split.avs.mka.split-011.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 20:57 split.avs.mka.split-012.mka
-rw-r--r-- 1 sl1pkn07 users 61M abr 4 20:57 split.avs.mka.split-013.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 20:57 split.avs.mka.split-014.mka
-rw-r--r-- 1 sl1pkn07 users 52M abr 4 20:57 split.avs.mka.split-015.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 20:57 split.avs.mka.split-016.mka
-rw-r--r-- 1 sl1pkn07 users 50M abr 4 20:57 split.avs.mka.split-017.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 20:57 split.avs.mka.split-018.mka
-rw-r--r-- 1 sl1pkn07 users 51M abr 4 20:57 split.avs.mka.split-019.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 20:57 split.avs.mka.split-020.mka
-rw-r--r-- 1 sl1pkn07 users 47M abr 4 20:57 split.avs.mka.split-021.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 20:57 split.avs.mka.split-022.mka
-rw-r--r-- 1 sl1pkn07 users 69M abr 4 20:57 split.avs.mka.split-023.mka
-rw-r--r-- 1 sl1pkn07 users 5,8M abr 4 20:57 split.avs.mka.split-024.mka

[Mosu]

"00:00:05.005,00:00:05.005,00:11:11.838,00…" means:

Start the first file at 00:00:00.000
Start the second file at 00:00:05.005 or the first key frame afterwards
Start the third file at 00:00:05.005 or the first key frame afterwards, too

This doesn't make sense. You're probably looking for "splitting by parts".

[sl1pkn07]

is generated by split_aud perl script http://mod16.org/hurfdurf/?p=33

edit: the trim line:
Trim(0,149)++Trim(150,20134)++Trim(20135,22345)++Trim(22346,42768)++Trim(42769,62158)++Trim(62159,81425)++Trim(81426,105330)++Trim(105331,125398)++Trim(125399,145014)++Trim(145015,164920)++Trim(164921,183068)++Trim(183069,209854)

[Mosu]

Yeah, well, that's not really my problem. Sorry. You're feeding mkvmerge somewhat useless parameters. No wonder the results are what they are. If you're having trouble with that Perl script then please contact the script's author.

[sl1pkn07]

@TheFluff, i summon you!

[TheFluff]

I haven't maintained that garbage since like 2010, fix it yourself or take a look at vfr.py

e: but just by taking a cursory glance at your trim line I can already tell you that your problem is that your first trim statement is useless, try removing it and replacing 150 in the second statement with 0, split_aud.pl isn't smart enough to figure out that there's a continuity there

[sl1pkn07]

ok. thanks

[TheFluff]

see edit, some of your trim statements are redundant (i.e. trim(0,149)+trim(150,0) is a no-op) and split_aud.pl won't figure that out for you

[sl1pkn07]

The trim line is generated by avspmod, chapters file (from BD, edited for remove some unused ones) and "bookmarks from chapter.py/qpfile from bookmarks.py" avspmod plugins, not by hand.

and yea. only the first trim (0,149) is redundant, the others trims is because is a "big file" m2ts with all episodes concatenated one each other

[sl1pkn07]

if remove the first trim the output is different (less generated files). but have the same issue:


└───╼ perl split_aud.pl -v -i audio_2.0.ac3 trims.avs
Executing: mkvmerge -o trims.avs.mka.split.mka --sync 0:0 audio_2.0.ac3 --split timecodes:00:00:05.005,00:11:11.838,00:11:11.838,00:12:25.612,00:12:25.612,00:23:47.059,00:23:47.059,00:34:34.039,00:34:34.039,00:45:16.914,00:45:16.914,00:58:34.544,00:58:34.544,01:09:44.147,01:09:44.147,01:20:38.667,01:20:38.667,01:31:42.864,01:31:42.864,01:41:48.402,01:41:48.402,01:56:42.162

mkvmerge v9.0.1 ('Obstacles') 64bit
'audio_2.0.ac3': Usando el desmultiplexador para el formato 'AC-3'.
'audio_2.0.ac3' pista 0: Usando el módulo de salida para el formato 'AC-3'.
El archivo trims.avs.mka.split-001.mka ha sido abierto para su escritura.
Progreso: 0%
Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-002.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-003.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-004.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-005.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-006.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-007.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-008.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-009.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-010.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-011.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-012.mka ha sido abierto para su escritura.
Progreso: 40%
Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-013.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-014.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-015.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-016.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-017.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-018.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-019.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-020.mka ha sido abierto para su escritura.
Progreso: 81%
Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-021.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-022.mka ha sido abierto para su escritura.

Los registros del cue (el índice) están siendo escritos...
El archivo trims.avs.mka.split-023.mka ha sido abierto para su escritura.
Progreso: 100%
Los registros del cue (el índice) están siendo escritos...
El multiplexado tardó 1 segundo.
┌─┤[$]|[sl1pkn07]|[sL1pKn07]|[/run/media/sl1pkn07/WDGP3TB-3/[BDMV][151209] RWBY Vol.1 [JP]/RWBY_VOLUME1/prueba]|
└───╼ ls -h *mka
-rw-r--r-- 1 sl1pkn07 users 399K abr 4 22:15 trims.avs.mka.split-001.mka
-rw-r--r-- 1 sl1pkn07 users 51M abr 4 22:15 trims.avs.mka.split-002.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 22:15 trims.avs.mka.split-003.mka
-rw-r--r-- 1 sl1pkn07 users 5,7M abr 4 22:15 trims.avs.mka.split-004.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 22:15 trims.avs.mka.split-005.mka
-rw-r--r-- 1 sl1pkn07 users 53M abr 4 22:15 trims.avs.mka.split-006.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 22:15 trims.avs.mka.split-007.mka
-rw-r--r-- 1 sl1pkn07 users 50M abr 4 22:15 trims.avs.mka.split-008.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 22:15 trims.avs.mka.split-009.mka
-rw-r--r-- 1 sl1pkn07 users 50M abr 4 22:15 trims.avs.mka.split-010.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 22:15 trims.avs.mka.split-011.mka
-rw-r--r-- 1 sl1pkn07 users 61M abr 4 22:15 trims.avs.mka.split-012.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 22:15 trims.avs.mka.split-013.mka
-rw-r--r-- 1 sl1pkn07 users 52M abr 4 22:15 trims.avs.mka.split-014.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 22:15 trims.avs.mka.split-015.mka
-rw-r--r-- 1 sl1pkn07 users 50M abr 4 22:15 trims.avs.mka.split-016.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 22:15 trims.avs.mka.split-017.mka
-rw-r--r-- 1 sl1pkn07 users 51M abr 4 22:15 trims.avs.mka.split-018.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 22:15 trims.avs.mka.split-019.mka
-rw-r--r-- 1 sl1pkn07 users 47M abr 4 22:15 trims.avs.mka.split-020.mka
-rw-r--r-- 1 sl1pkn07 users 8,2K abr 4 22:15 trims.avs.mka.split-021.mka
-rw-r--r-- 1 sl1pkn07 users 69M abr 4 22:15 trims.avs.mka.split-022.mka
-rw-r--r-- 1 sl1pkn07 users 5,8M abr 4 22:15 trims.avs.mka.split-023.mka


with vfr.py script (wiiaboo git) generate a big file instead of multiple files

[Mosu]

You're still using the script wrong, I guess, as it still spits out the same split points multiple times: …00:11:11.838,00:11:11.838,00…

Now can we please stop this about that script? This is the MKVToolNix support thread. If you're having trouble with using those scripts then create a new thread for it or discuss it elsewhere. Thanks.

[sl1pkn07]

with accient version of mkvtoolnix (<8.4.x, not remember exactly) that script work without this "issue"

and yes, i now stop talk about this "regression(?)"

greetings

edit: works without problem with vfr.py. sorry for the noise

[Chetwood]

Mosu, I've muxed 3 BDs from HDD1 to HDD2 with MakeMKV, then remuxed them again from HDD2 to HDD1 with MKVToolnix to rearrange tracks. Despite MKVToolnix not having to extract the main movie from a complete BD, it took quite longer to simply remux the same files; something I've been noticing for a while. Any idea why this might be?

movie 1
06:55 <- MakeMKV
11:57 <- MKVToolnix

movie 2
05:54 <- MakeMKV
10:22 <- MKVToolnix

movie 3
09:54 <- MakeMKV
15:11 <- MKVToolnix

[Mosu]

mkvmerge's memory handling and format parsing is not the most efficient on the planet.

[73ChargerFan]

But the GUI starts so amazingly fast! :D

[Gravitator]

Хай!
It possible to add display the size of the audio and video tracks in the table? And when disconnecting audio or video tracks show the change of the final file size.

[Mosu]

No, it's not, as that information is simply not available for a lot of the supported input file types (e.g. MPEG-TS, MPEG-PS, Matroska if no track statistic tags are present, FLV, Ogg/OGM, AC3 if it contains TrueHD as well…).

[Ex0rcist]

Does anyone know if you extract streams from mkv container with MKVExtract for example, what happens to audio delay if there's any?

[sneaker_ger]

Mkvextract (unlike eac3to) does not add any silence to neutralize the delay so you have to write it down and account for it in the processing chain you are using.

[gpower2]

You can use gMKVExtractGUI, that finds the delay of the audio tracks and writes them to the extracted filename. ;)

[stax76]

Does anyone know if you extract streams from mkv container with MKVExtract for example, what happens to audio delay if there's any?

StaxRip has also a very rich demuxing GUI for mkvextract, mp4box and eac3to, it writes the delay to the audio file name and detects delays from file names. While demuxing is recommended StaxRip however does not require audio or subtitles to be demuxed.

[hubblec4]

Hi Mosu

Is that intention or mishap you broke loading of mtxcfg's which are created before Version 9.0.0?

http://forum.gleitz.info/attachment.php?attachmentid=99113&d=1460585832

[Mosu]

Of course I intentionally implement functionality that causes crashes ;) Just kidding, obviously. That's definitely a bug. I'm trying hard to preserve compatibility with older settings files in newer releases of the GUI.

As the attachment is still pending approval I cannot look into it yet. Can you please upload the file to my FTP server? Thanks.

[hubblec4]

The file is uploaded to your FTP.


Edit:

What is with the mtxcfg's are created with V9.0.0 and higer, these are backward compatible to older versions of the GUI?

[Mosu]

Thanks, I'll look into it. No, I don't make any guarantees that config files from newer versions can be read by older ones. The most recent change incompatible with older versions was the attachment handling.

Edit: The change I meant is this one (https://github.com/mbunkus/mkvtoolnix/commit/7a60d3d6d344b37825a00f0e17fc05ea0b3ca5a9?diff=unified).

[Mosu]

@hubblec4: The file cannot be loaded by release 9.0.1, that's true, but it can be loaded just fine by the current development version. I'm pretty confident that the commit that fixed this behavior is this one (https://github.com/mbunkus/mkvtoolnix/commit/42271f5c5737dc3f62e51689207855a9b98ecde8).

[hubblec4]

Yes the file has more then 650Kb and thats the issue. Crazy.
But nice to know, I thought I have to rewrite my mtxcfg-procedure....puh.

[Mosu]

Hey,

here's another release of MKVToolNix. Several bugs have been fixed. A rather important one is an update to the JSON library used which fixes immense memory consumption when loading stored settings (e.g. a ~500 KB JSON file leading to consumption of more than 2 GB of memory).

Enhancements include support for WebVTT subtitles, much improved support for teletext subtitles in MPEG transport streams and several more fields in the JSON/verbose identification formats.

There have been no changes for package maintainers since the previous release.

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

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's the full ChangeLog (https://mkvtoolnix.download/doc/ChangeLog) since v9.1.0:

2016-04-23 Moritz Bunkus <moritz@bunkus.org>
* Released v9.1.0 "Little Earthquakes".
* mkvmerge: MPEG TS/teletext enhancement: included the teletext page number in the JSON/verbose identification output as track property "teletext_page".
* mkvmerge: MPEG TS bug fix: the "text_subtitles" property of the JSON/verbose identification modes was always set to true for all subtitle tracks, even for those that aren't text subtitles (VobSub, PG).
* mkvmerge: MPEG TS/teletext enhancement: if a teletext track contains multiple teletext pages then mkvmerge will now recognize all of those pages as separate tracks to merge instead of only merging the first page. See #1662 (https://github.com/mbunkus/mkvtoolnix/issues/1662).

2016-04-21 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: MPEG TS/teletext enhancement: mkvmerge will now ignore obviously bogus PTS values for teletext tracks and use PTS from earlier audio or video packets instead. See #1662 (https://github.com/mbunkus/mkvtoolnix/issues/1662).

2016-04-20 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: MPEG TS/teletext bug fix: the language code signaled in the MPEG TS PMT is taken into account when selecting the character encoding to use during decoding of the teletext subtitles, not just the "national character set" stored in the teletext page headers. For example, a German teletext page may signal "national character set" 0 (English) whereas it's actually 4 (German). See #1662 (https://github.com/mbunkus/mkvtoolnix/issues/1662).
* mkvmerge: teletext decoding bug fix: fixed dropping of certain non-ASCII characters in rare circumstances due to wrong filtering of already UTF-8 encoded strings.
* mkvmerge: MPEG TS reader enhancement: teletext tracks of type 5 (hearing impaired) are recognized as subtitles, too. Implements #1662 (https://github.com/mbunkus/mkvtoolnix/issues/1662).

2016-04-16 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: characters that aren't valid in path names are automatically removed from the output file name. Implements #1647 (https://github.com/mbunkus/mkvtoolnix/issues/1647).
* MKVToolNix GUI: bug fix (Windows only): the GUI didn't start if the USERNAME environment variable contained characters that aren't allowed in file names (e.g. : or ?).

2016-04-13 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: AVI reader bug fix: fixed reading files where the file ends in the middle of an audio chunk. Fixes #1657 (https://github.com/mbunkus/mkvtoolnix/issues/1657).

2016-04-11 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: new feature: added support for extracting WebVTT subtitles. Implements the extraction part of #1592 (https://github.com/mbunkus/mkvtoolnix/issues/1592).
* mkvmerge: new feature: added support for reading WebVTT subtitles from WebVTT and Matroska files. Implements the merge part of #1592 (https://github.com/mbunkus/mkvtoolnix/issues/1592).
* mkvmerge: enhancement: when reading Matroska files not created by mkvmerge that contain chapters the existing edition UIDs and chapter UIDs are removed and random ones created. This is necessary as not only HandBrake but other tools assign sequential numbers starting at 1 for each file. Therefore there are two chapter entries with the UID 1, two with the UID 2 etc. and those should, strictly speaking, be treated as if they were a single chapter whereas the user expects those entries to stay separate entries.

2016-04-09 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature: added an option in the preferences ("Merge" → "Output") for controlling whether or not the GUI clears the "output file name" input upon removal of the last file.
* MKVToolNix GUI: new feature: added an option in the preferences ("Merge" → "Default values") for controlling whether or not the GUI clears the "file title" input upon removal of the last file.
* mkvmerge: bug fix: mkvmerge will no longer abort reading a Matroska file with a structural error right before the first cluster. Fixes #1654 (https://github.com/mbunkus/mkvtoolnix/issues/1654).

2016-04-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: added the muxing date in both local time zone and UTC to verbose/JSON identification outputs (keys "date_local" and "date_utc", formatted after ISO 8601) when identifying Matroska files.

2016-04-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: added the minimum timestamp for each track in verbose/JSON identification outputs (key "minimum_timestamp") when identifying Matroska files. At most the first ten seconds are probed; if no block is found for a track within that range then the key is not output for the track. Also added "muxing_application" and "writing_application" to the "container" section of the output. Currently those are only set for Matroska files.

2016-03-31 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool change: attachments from source files have been moved from the "Tracks, chapters, tags and attachments" list on the "sources" tab to a new list on the "attachments" tab. That way all existing attachments and all the ones to newly add will be shown in a single tab. This makes it easier to decide which attachments will have to be added and which can be removed.
* MKVToolNix: merge tool bug fix: when adding playlists the GUI won't ask the user whether or not to scan if there's only a single playlist in that directory.

2016-03-29 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: AVC/h.264: fixed handling of interlaced frames with bottom field first.
* MKVToolNix GUI: bug fix: fixed huge memory consumption (e.g. allocation of 2 GB for a JSON file of 650 KB) in the JSON library by updating said JSON library. Fixes #1631 (https://github.com/mbunkus/mkvtoolnix/issues/1631).

Have fun :)

[kalehrl]

Is there a tool which uses mkvtoolnix's ability to cut mkvs?
I would like to be able to preview the file and then choose cut points.
Now, it is very time consuming having to use a video player, pause at cut points and then manually add the numbers in mkvtoolnix.
Thank you.

[Selur]

@kalehri: I wrote a smart cutter for progressive x264 content as a proof-of-concept some time ago called MKV Cutter (http://forum.selur.de/topic220-mkv-cutter-tool-to-cut-h264-mkv-files-frame-accurate.html), which might be interesting to you.

[kalehrl]

Thanks for the suggestion.
I couldn't download the file from the page you linked to.
I found the mkv cutter on videohelp forum and made a couple of cut points but it started encoding the cut mkvs.
I just need it to cut the mkvs and leave them alone or maybe join them into a new mkv file without reencoding.
Maybe I'm missing this option to just mux them?

[stax76]

Here is a new mkvextract GUI, it supports an incredibly hard to implement feature called High DPI awareness. ;)

http://forum.doom9.org/showthread.php?p=1765213#post1765213

[kalehrl]

It can't cut mkv files. It just demuxes them.

[stax76]

I wasn't relating to your request. Create a feature request on the StaxRip issue tracker.

[Selur]

I couldn't download the file from the page you linked to.
That site offers some general info about MKV Cutter and links to my Google Drive where the last three versions are available for download,..

[stax76]

@kalehrl

I saw your request on the tracker and added it, StaxRip already uses mkvmerge to cut audio so it was only a matter of copy and paste 2 lines codes and modifying 2 other locations, ten minutes overall.

You can find a test build here: https://github.com/stax76/StaxRip#download

Small tutorial:

Choose 'Just Mux' as video encoder
Choose 'Just Mux' as audio encoder, you can also re-encode audio
Choose DSS2 as source filter if you don't want to wait for indexing, for DSS2 LAV Filters are recommended

If you cut often you can save this settings as project template.

In the preview dialog is where you cut, F1 shows you the shortcuts, it does not show key frame locations.

It's implemented using --split parts-frames, I don't know how if it has an advantage or disadvantage over the time based method.

[kalehrl]

Hi Stax
I just tried it and it seems to work fine.
Is it possible to choose whether to join the resulting files into one or single-cut them?
It seems it joins them all into one file but sometimes I need separate ones.
I don't know how if it has an advantage or disadvantage over the time based method.
I think times-based method cuts a I frames which may be 'cleaner' than cutting at random frames.

[sneaker_ger]

Mkvmerge will always cut at I frames no matter whether time or frame count based syntax.

[stax76]

It seems it joins them all into one file but sometimes I need separate ones.

A splitting feature wouldn't be trivial to implement, you have to add a job for every split.

[hubblec4]

Hi Mosu

Maybe a next issue: I get this output with identification JSON


"D:\mkvtoolnix-32bit\mkvmerge.exe" -i -F JSON "D:\Test.mkv"
{
"attachments": [],
"chapters": [
{
"num_entries": 32
}
],
"container": {
"properties": {
terminate called after throwing an instance of 'utf8::invalid_utf8'
what(): Invalid UTF-8

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

D:\>pause
Drücken Sie eine beliebige Taste . . .

With version 8.9.0 works.

[arrgh]

hi
a new Feature is that mkv can hold "3d-plane" info for subtitles, stored in track specific tags...

but how can I extract those individual track-tags?
At the time being it seems there is only the Option to extract everything into one single tags-file...

http://www.bilder-upload.eu/thumb/776751-1461960996.jpg (http://www.bilder-upload.eu/show.php?file=776751-1461960996.jpg)

[Jamaika]

Hi Mosu
I'm interested in the text 'verbose' merge multiple files.
Why it shows progress change only up to 50%?
hevc: VPS ID 0000 changed; checksum old 37e504da new 388b04fc
hevc: SPS ID 0000 changed; checksum old a73b0943 new ace30981

[Mosu]

Those messages are only emittet if a VPS or SPS NALU is encountered with an ID that's already been encountered earlier but whose contents do not match. This can happen e.g. if multiple encodings are appended in the source. For a single encoding no such messages should show up at all.

[Jamaika]

So understand well. The film I connected with five equal parts. Messages mergers NALU are only half the film.

[bin_ch]

Hi Mosu

Maybe a next issue: I get this output with identification JSON


Hi Mosu
I am getting this, too. '-F verbose-text' also gives similar error

Some additional info:
On Windows (tested with 7 and 10), the string for the 'date_local' is something like '2015-03-26T12:38:22Pacific Daylight Ti:me'. I am not sure what a correct ISO 8601 format should be like, but the 'Ti:me' part doesn't look quite right.
Maybe the program expects a timezone offset while Windows returns the name of the timezone.

The 'Pacific Daylight Ti:me' part will be a localized string under Non-English Windows. I think this is the cause of the invalid_utf8 issue.
If I redirect the output with either '--redirect-output' or the system redirection (>), and open the output file with a text editor, I can see the string for 'date_local' is encoded with system default character set, instead of UTF-8 which the rest of the file uses.

Hope the info helps.

[Mosu]

Thanks for the information. That's very good input. The intention was to have the numerical time zone appear there, and it seems that the format string I'm using is returning the zone's name (instead of its offset).

The intended format looks something like this: "2015-03-26T12:38:22+02:00".

[Mosu]

Maybe a next issue: I get this output with identification JSON

and

I am getting this, too. '-F verbose-text' also gives similar error

This should be fixed in pre-builds 01201 and higher (https://mkvtoolnix.download/windows/pre/).

[Megalith]

Is it even technically possible for mkvmerge to do frame accurate cutting? It doesn't bother me that much, but I wish there was a way to detect whether the frame I am on in MPC-HC is an iframe or not so I don't have to experiment so much with timecodes/frames.

[hello_hello]

Is it even technically possible for mkvmerge to do frame accurate cutting? It doesn't bother me that much, but I wish there was a way to detect whether the frame I am on in MPC-HC is an iframe or not so I don't have to experiment so much with timecodes/frames.

If you navigate using Shift + Left/Right Arrows, MPC-HC will jump between keyframes.
If you have "seek on keyframes" checked in MPC-HC's options under Tweaks, using the navigation bar will always land on a keyframe.

If you don't mind using ffdshow for decoding, it's on-screen-display might be useful. It can display the frame type and frame number etc. Even if you don't want to use ffdshow for decoding you can still use it to process the decoded raw video and once again, it's on-screen-display.

If you open most video types with VirtualDub via the FFMpeg Input Driver plugin (https://sourceforge.net/projects/virtualdubffmpeginputplugin/), I'm pretty sure VirtualDub's keyframe navigation buttons will still work, and unlike decoding with a VFW codec, navigating will probably be accurate.

AviDemux has keyframe navigation buttons.

Probably none of the above methods for navigating between keyframes will work if you open an MKV that's been created by the x264 encoder (rather than the x264 encoder output being a raw avc file). You'd need to remux it with MKVToolnixGUI first.

[sneaker_ger]

And mkvmerge splitting isn't safe with OpenGOP.

[tp4tissue]

Hey guys , why does mkvtoolnix run at ~60MB/s

it doesn't seem to be saturating my drive's write speed, or cpu speed, I'm remuxing from ssd to ssd..

where is the bottleneck

[Atak_Snajpera]

Hey guys , why does mkvtoolnix run at ~60MB/s

it doesn't seem to be saturating my drive's write speed, or cpu speed, I'm remuxing from ssd to ssd..

where is the bottleneck

My glass ball tells me that mkvmerge may use too small blocks of data. SSDs work more efficient when controller can use all channels in parallel.

Copying larger chunks of data is always faster
http://i.cubeupload.com/q4Yu6d.png

[hello_hello]

I recently discovered MKVToolNix works with XP again. I didn't know, so I hadn't updated it since version 7.8.0, and I hadn't even seen the new GUI until a couple of days ago.

So, better later than never..... I'm just posting to say thanks to Mosu. Once I pushed through the initial "hating change" period, I found I quite like the new GUI. It seems well thought out. I'm still getting my head around some of the things it does differently, but thanks again Mosu!

Actually.... a quick question while I'm here.....
Why does MKVToolnixGUI display file paths with a forward slash rather than the backward one? ie "E:/video.mkv". It's no big deal but I'm curious. Thanks.

[Mosu]

Hey guys , why does mkvtoolnix run at ~60MB/s

it doesn't seem to be saturating my drive's write speed, or cpu speed, I'm remuxing from ssd to ssd..

where is the bottleneck

mkvmerge's memory handling is what it is: correct but not especially fast.

File read/write operations are properly cached; that's definitely not the issue; the issue is too many memory copies & too many memory scanning.

I've looked into that once or twice but there are no low hanging fruit anymore. It's not a priority for me.

[Mosu]

I recently discovered MKVToolNix works with XP again. I didn't know, so I hadn't updated it since version 7.8.0, and I hadn't even seen the new GUI until a couple of days ago.

Just as a warning: I still don't support XP. That it works is accidental. If it breaks it won't be fixed. That being said: I'm glad you like the new design.

Why does MKVToolnixGUI display file paths with a forward slash rather than the backward one? ie "E:/video.mkv". It's no big deal but I'm curious. Thanks.

The GUI library I'm using (Qt) defaults to forward slashes on all operating systems as all operating systems support forward slashes (yes, including Windows). I haven't found the time (more like the motivation) do change all the places where paths are displayed to show backward slashes instead (which isn't that hard to do, it's just time I prefer to spend on other things as it's a purely cosmetic nuisance).

[Ripman]

MKVToolnix Suggestions
----------------------

I have used your tools for some time now, and they are rock-solid. I am currently using mkvtoolnix 9.1.0 portable 64 on win8.1, which is very nice. I definitely like the new smaller font default too. I have been taking these notes since the switchover in v8-ish or so. I add/delete/edit these notes as new releases come so as not to nag you (too much).


Please consider the following suggestions for the mkvtoolnix GUI. These notes are mostly usability issues. The notes on mkvinfo below are a little more than cosmetic.

1. Write a "completed OK" log entry to the job output. The job output window shows a "completed OK" message, but there is no indication of success in saved job output otherwise. Essentially, make the job output dialog exactly match the job output file, including start/stop times, job duration, etc.

2. Please do not use mkv output file names for tab names. The interface becomes unruly with long mkv/mka file names because they are used as the tab names. Just show a session/job number and the first "n" characters, and ellipses, which is the most common approach. As an extra, you could create an option to specify the length up to some maximum of names displayed on tabs.

3. Create an option to set the default "Default" values (e.g., yes, no, determine automatically). If I set the default value as "no" and save settings, the value is saved and retrieved as "no". If I create an option file of the same, the value is "no". If I reopen the same mkv file it shows as "determine automatically". (I realize this is a touchy subject.)

4. The length of the title box has decreased. That part of the interface is pretty clean right now, and real estate is limited. You could put a longer title box under the output file text box; they really belong together anyway. Here are some example mka titles that I have.
Aaron Copland, Rodeo - Dance Panels - El Salón México - Danzón Cubano (2012) --- Slatkin, DSO --- (24-96-2ch) [Naxos BDA 2013 730099 003768]
Eivind Buene, Possible Cities - Essential Landscapes (2010) --- Christian Eggen, Cikada --- (24-192-2ch) [Lindberg Lyd 2L 083 SABD]
George Gershwin, Rhapsody in Blue - “Strike Up the Band” Overture - Promenade - Catfish Row --- Falleta, BPO --- (24-96-2ch) [Naxos BDA 2013 730099 003360]
Pink Floyd, Wish You Were Here -- Immersion Edition Boxset (1975) --- (24-96-6ch) [EMI BDA 2011 50999D2 943527]

5. Create an option that sets the title based on the output file name. In this regard, the title changes when the file name is updated. It would be free-form edit otherwise.

6. When settings are saved, a file is created or overwritten. On subsequent saves, the settings file gets updated. Please put a status message indicating the settings were saved, maybe even including the settings file name. Maybe you can use one of the areas by the progress bars.

7. Please consider setting the path "globally" for a particular session/job based on the folder source files are initially added from. As an example, if I add a source file from c:\01, and then add another source file, the browse dialog comes up in c:\01. If I save settings, the save dialog points somewhere else.

-----

8. Please consider a different approach for the command line utility/interface of mkvinfo. I can use the --no-gui option to forgo launching the application in a window. Is there a way to recognize "common" command line syntax to avoid launching the gui? As an example, if either the -v or -r options are used, then the gui shouldn't launch. Or, could you instead require the use of a "--use-gui" option to launch the gui, thereby defaulting to the (formerly) typical behaviour. My point is that all previous command line uses of mkvinfo are now invalid since the --no-gui option is required to prevent the gui from launching.

As another example, I shouldn't be able to do something like this, but I can: mkvinfo -v "c:\1\1.mkv" -r "c:\1\1_keys.txt", which launches the gui, but also locks a file "c:\1\1_keys.txt" until the gui is closed. The text file will contain nothing of course.

A different thought... If I do a -v dump on an mkv sourced from BD, that's going to be >100mb when loaded in the gui. You want to be in that business - that's like UltraEdit territory: peeling through 100+mb for searching, scrolling, etc.?

If you opt "not" to change the way options are used, can you have the gui display the mkv info as the command line requested. As an example, I shouldn't have to load anything or use the menus if I pass the -v option with a valid mkv file.

The easy answer on these types of changes would be to require a "--use-gui" option, but that would make it more difficult for new users.

9. Please do not alter the mkvextract command line interface as has been done with mkvinfo so as to render all prior uses invalid.

[Mosu]

Hey,

thanks for your suggestions. They would have been better entered as separate issues on my bug tracker (https://github.com/mbunkus/mkvtoolnix/issues/) as chances are high that I will forget about some of them if they're not present there, and a forum makes a very poor place for discussing multiple separate issues simultaneously. Therefore I will only reply to your points here once.

1. Write a "completed OK" log entry to the job output.

The job output window contains the output of all runs. The separator lines are only present so that it's easier to tell the output of two different jobs apart. They're NOT emitted by mkvmerge itself.

When you open the output of an already-run job then there's only ever the output of this single run to view. Therefore such sparator lines aren't necessary.

The status itself is shown at the top already.

I don't see the difference you're referring too. Screenshots would help, and again, the bug tracker (https://github.com/mbunkus/mkvtoolnix/issues/) is a much better place for in-depth talk about such things.

2. Please do not use mkv output file names for tab names.

Using ellipsis has a disadvantage for people dealing with a lot of episodes (e.g. "Battlestar Galactica – Season 1 Episode 9.mkv"). If all of those are abbreviated as "Battlestar Gala…" then that doesn't help the user at all. At the moment I tend not to change this.

3. Create an option to set the default "Default" values (e.g., yes, no, determine automatically).

To me this doesn't make a lot of sense safe for one option: the "default track" property. And for that property there is an option to turn it off already.

If that isn't the property you're talking about then please describe your particular use case in an issue on the bug tracker.

4. The length of the title box has decreased.

People still complain that the GUI is too high. I will therefore not move the title next to the destination file name control.

Instead you can do two things: widen the GUI's window and move the slider on the output tab more to the right:

https://mkvtoolnix.download/images/other/MKVToolNix-GUI-more-space-for-the-title.png

5. Create an option that sets the title based on the output file name.

I don't like forcing one control to always follow another and consider it poor design as you often need to deviate from such rigid schemes, and having to toggle a setting only to be able to edit the control can be highly annoying. I've already added commands in the "Merge" menu that you can use for quickly copying the output file's name (or the first input file's name) to the title. Please use those when you need them.

6. When settings are saved, a file is created or overwritten. On subsequent saves, the settings file gets updated. Please put a status message indicating the settings were saved

I'll consider it.

7. Please consider setting the path "globally" for a particular session/job based on the folder source files are initially added from.

That's how you work, but that's not necessarily how other people work. A lot of people strictly keeping their sources and destinations separate. I highly doubt there's any one way that'll please everyone.

That being said I will look into how the initial location for saving settings is determined, though (that was the concrete example you cited), as its behavior doesn't make much sense to me at the moment either.

8. Please consider a different approach for the command line utility/interface of mkvinfo.

That is something that I'm thinking about. I haven't decided how to change it yet, though. I do realize that the change was more disruptive that I would have liked and am perfectly willing to revert it partially (meaning everyone using the new --no-gui option shouldn't suddenly run into an error either). It will likely not stay the way it is now.

9. Please do not alter the mkvextract command line interface as has been done with mkvinfo so as to render all prior uses invalid.

mkvextract doesn't have a GUI. Therefore this specific issue won't trouble mkvextract. Apart from that I'm pretty careful not to change the command line interface in incompatible ways for any of the tools included in MKVToolNix. One exception is mkvmerge's --engage flags as those are explicitly marked as development hacks that the public shouldn't use.

[tp4tissue]

mkvmerge's memory handling is what it is: correct but not especially fast.

File read/write operations are properly cached; that's definitely not the issue; the issue is too many memory copies & too many memory scanning.

I've looked into that once or twice but there are no low hanging fruit anymore. It's not a priority for me.

Just want to say that I'm not complaining.. I was just wondering if there was something wrong with my configuration..

Thanks for the explanation.

[bin_ch]

This should be fixed in pre-builds 01201 and higher (https://mkvtoolnix.download/windows/pre/).

Thanks. It works as intended in the pre build.

[Mosu]

I've just reverted the change to mkvinfo's behavior regarding starting the GUI. Now running "mkvinfo.exe" again only starts the GUI if the parameter "--gui" is used as well. The newly-introduced parameter "--no-gui" is still supported but won't do anything. It will stay that way in order not to mess up people's scripts again.

In order to provide the people using the portable version with a convenient way to start mkvinfo's GUI a new executable is included with the Windows builds: "mkvinfo-gui.exe". Basically all it does is running "mkvinfo.exe --gui" (including all the arguments you may have passed to "mkvinfo-gui.exe"). It must be located within the same directory "mkvinfo.exe" is located in, otherwise it won't find the executable.

I'd appreciate some tests and/or feedback in order to avoid a fiasco come the next release :) Changing the CLI in an incompatible way once is quite enough. New pre-builds (https://mkvtoolnix.download/windows/pre/) are up. Build numbers 01207 and higher contain the change.

[Mosu]

6. When settings are saved, a file is created or overwritten. On subsequent saves, the settings file gets updated. Please put a status message indicating the settings were saved.

Such a message is already shown in the left-most area of the status bar and has been since v8.0.0.

[Ripman]

Such a message is already shown in the left-most area of the status bar and has been since v8.0.0.

Yep. Cannot reproduce. Tried back to 8.1. Sorry about that.

[Ripman]

5. Create an option that sets the title based on the output file name.

I believe the ctrl-u under the menu should work fine. Another miss on my part. Sorry.

1. Write a "completed OK" log entry to the job output.

Here is a graphic of what I meant about the output window and the output log.

[arrgh]

hi
a new Feature is that mkv can hold "3d-plane" info for subtitles, stored in track specific tags...

but how can I extract those individual track-tags?
At the time being it seems there is only the Option to extract everything into one single tags-file...

http://www.bilder-upload.eu/thumb/776751-1461960996.jpg (http://www.bilder-upload.eu/show.php?file=776751-1461960996.jpg)

...sorry to insist....
but the question stays. Why can Medianinfo Show the 3d-plane for subtitles in mkv files while mkvtoolnix does not allow to set them and the "Kopfdateneditor" neither Shows them nor allows to set them...?

http://www.bilder-upload.eu/thumb/bed239-1462999242.jpg (http://www.bilder-upload.eu/show.php?file=bed239-1462999242.jpg)

with madVR/LAV/MPC-BE being able to Play back 3d-mkv this becomes a very usefull item, so, please consider to add such Options.

all in all super tool which I'm using already for many, many years. Thanks!

Best regards

[Mosu]

There is no header field specified for this yet. What MediaInfo shows is stored directly in the PGS bitstream,not at the container level. That is why neither mkvmerge nor mkvpropedit/the header editor support changing it.

If you're interested in having such a field at the container level then please join the existing but stalled discussion about this on the Matroska-devel mailing list.

[arrgh]

thanks for the reply...

still, I don't understand.... in the MakeMKV-Files this tag is present and seems to work in the madVR/LAV/MPC-BE Environment....
what is there left to be discussed/requested...?


"...die normative Kraft des faktischen..."

[Mosu]

I repeat, there is no header field for it in Matroska. If such a field is present in the _bitstream_ then that is highly codec dependent (= part of the codec specs, has nothing to do with the container) and not a general solution. The aforementioned discussion was about providing a container-level field for this kind of information so that formats that don't include such information at the bistream level can profit from it, too. The most obvious candidates that need this kind of information are all text subtitle formats when you use them together with a 3D video.

Here's the link to the discussion: https://mailarchive.ietf.org/arch/msg/cellar/T93aDLU5uoE9p6k1XLHIeoOkpxE

[nevcairiel]

"3d-plane" is just a ordinary metadata tag on a track level (ie. a SimpleTag for the track). We wanted something specific to interpreting MVC 3D planes, which didn't seem like something being officially specified in this capacity anytime soon.

[Mosu]

While I can understand that, nevcairiel, it's also disappointing to see time being invested in a hackish workaround that only a handful of tools will use instead of investing the time to hash out a proper solution. I know that a proper solution isn't that easy; I've read the whole discussion. But doing quick hacks is what brought us fun stuff like OGM.

[arrgh]

Here's the link to the discussion: https://mailarchive.ietf.org/arch/msg/cellar/T93aDLU5uoE9p6k1XLHIeoOkpxE

ok, have read this... seemed somehow to have died away, though...

what is confusing me is, that, if I'm not cross-eyed :), StereoskopicPlayer seems to be able to produce the correct 3d-depth out of MakeMKV-files (MPC-BE not ?!)...
how Comes, if there is no Standard?

[nevcairiel]

While I can understand that, nevcairiel, it's also disappointing to see time being invested in a hackish workaround that only a handful of tools will use instead of investing the time to hash out a proper solution. I know that a proper solution isn't that easy; I've read the whole discussion. But doing quick hacks is what brought us fun stuff like OGM.

The discussion didn't sound like it would ever get us a simple tag to assign the MVC plane to a track, rather re-implement the entire structures on a per frame basis, which MKV doesn't even have the correct structures for yet. So don't blame us for wanting something that works in 2016 and doesn't require writing a complex handling system for one container, while still keeping the MVC stuff for other containers.

Wanting something generic that works with everything is nice and all, but I prefer to remain realistic.

It's not like we implemented a proprietary field or something, just storing the info in tags, plain as day and mostly self documenting.

[arrgh]

... So don't blame us for wanting something that works in 2016 and doesn't require writing a complex handling system for one container, while still keeping the MVC stuff for other containers.

Wanting something generic that works with everything is nice and all, but I prefer to remain realistic.

It's not like we implemented a proprietary field or something, just storing the info in tags, plain as day and mostly self documenting.

...I could not agree more...

as said before : ...die normative Kraft des Faktischen...
let's do something simple/reasonable/working... should it fail, one can correct/improve...

[hello_hello]

Am I missing the obvious here?

I have an MKV with a video and audio stream. The default flag for each is set to "no" when I open it with MKVMergeGUI 7.8.0 to check it. When I open the MKV with version 9.1.0, I see this:

https://cdn.pbrd.co/images/SSstoFY.gif

Even though both streams show "default track in output" as "yes", has it been foolish of me to assume the default flag for each stream should be set to "yes" when muxing? The result seems to be for it to remain set to "no".

Thanks.

[foxyshadis]

Am I missing the obvious here?

I have an MKV with a video and audio stream. The default flag for each is set to "no" when I open it with MKVMergeGUI 7.8.0 to check it. When I open the MKV with version 9.1.0, I see this:

https://cdn.pbrd.co/images/SSstoFY.gif

Even though both streams show "default track in output" as "yes", has it been foolish of me to assume the default flag for each stream should be set to "yes" when muxing? The result seems to be for it to remain set to "no".

Thanks.

mkvmerge always sets one track of each type to default, unless you explicitly set every track to default:no. It'll try to make a good guess which tracks should be default -- and obviously, if there's only one of each type of track, those will be default. The old GUI might've shown what the original status of the track was, as opposed to what it would be set to in the output, which is more important; I'm not sure.

[hello_hello]

mkvmerge always sets one track of each type to default, unless you explicitly set every track to default:no.

That's not how it seems to work when you open an MKV with streams that have previously had their default track status set to "no". The MKV I opened in my previous screenshot was such an MKV, and after muxing with the GUI displaying exactly as it was in the screenshot, the resulting MKV had a video and audio track with a default status of "no".

I can open the MKV below using the old GUI and see the default status of the each stream (yes or no). That's something you can't always do with the new GUI as "determine automatically" doesn't tell you anything, unless you can rely on the "default track in output" column being correct.

When I open the MKV in the screenshot below with version 7.8.0, I can see the video stream and AAC stream have their default status set to "yes", while the AC3 and subtitle streams are both set to "no". To me the new GUI seems to be saying "I'm going to set the subtitle track's default status to "yes" (I've left it set to "determine automatically"), but it doesn't.

https://cdn.pbrd.co/images/TontwcO.gif

Also in the "what are you really doing" department, if I deselect the AAC audio stream I see this:

https://cdn.pbrd.co/images/TosDkZq.gif

It seems reasonable to assume it's saying, "if you don't want the AAC stream I'll change the AC3 stream's default status to yes", but it doesn't. After remuxing that MKV exactly as above, only one stream has it's default status set to "yes" and that's the video stream. The rest remain set to "no" as they were previously.

As it turns out, the behaviour is consistent with the old GUI. I just didn't expect it to be because the old GUI didn't display "determine automatically" or have a "default track in output" column showing "yes" as the output status while it does something else.
That's basically the issue.... being able to trust what's being displayed in the "default track in output" column. If it's going to leave the default status unchanged and it was previously set to "no", it should display "no" rather than "yes".

Unless I'm completely misinterpreting what the "default track in output" column is telling me, but I'm not sure what else it could be.

Thanks.

[Stereodude]

Why does the : after the drive letter get deleted automatically when I delete the drive letter in the output field? Like I want to change the target from e: to f: I put the cursor in front of the e and hit delete and both the e and the : are deleted. Also, if I only type an f and forget to add the : because I didn't notice or remember the missing : after the drive letter the job still runs and put the file somewhere. :confused: It doesn't flag the output path as being bad.

This is on W10 x64

[hello_hello]

There's a difference between the way the new and old GUI's handle duplicate file names and the old GUI's method was more fun. ;)
I have a file on my E drive named video.mkv
I open streams for muxing and set the output file name to E:/video.mkv
When I click "start muxing", MKVToolNixGUI warns me about over-writing the existing file.
All is good. However....

If I do the same thing again while enabling splitting, the resulting output files would be:
E:/video-001.mkv
E:/video-002.mkv
E:/video-003.mkv and so on.....
The old GUI is clever enough to know it wouldn't be over-writing E:/video.mkv and therefore doesn't enquire as to whether it should. The new GUI asks even though it wouldn't be over-writing it anyway.
On the other hand, the old GUI is quite keen on checking whether E:/video-001.mkv, E:/video-002.mkv and E:/video-003.mkv already exist when splitting is enabled, and offers a warning accordingly. The new GUI isn't keen at all and simply over-writes them without asking.

File splitting....
When enabling splitting and setting the "maximum number of files" to "1", this sort of thing tends to happen:
--- Errors emitted by job 'merging to file "video.mkv" in directory "E:/"' started on 2016-05-14 06:27:18 ---
Wrong argument to '--split-max-files'.
Unless there's a circumstance under which setting a value of "1" as the maximum number of files is acceptable, might it be an idea for the GUI not to allow you to set "1" via the up/down arrows?
It'd be nice if it could just output one part though, given it's fairly similar to splitting, only without writing the additional parts. Sometimes splitting "after x" is desirable, but I only want the first part. Normally I'd wait for MKVToolNixGUI to start writing the second part, then abort the muxing job, but that's a little harder since the "Abort" button retired.

Aborting Jobs....
I'm prepared to accept I'm just too silly to work it out, but how do you abort a running job? It might be (dare I say it) an XP thing, but the "Job Queue/Stop Job Queue" menu appears not to function. The "Stop Job Queue" menu has an arrow, indicating it may lead to a sub-menu, but it doesn't open to anything.

The Job Queue.....
I'm a little curious. Why are there no buttons at the bottom of the job queue window? "Start Jobs", Abort Jobs", "Pause Jobs".... that sort of thing.
I've been using the new GUI for a while now, yet every time I switch to the Job Queue window I still move the cursor down to click on the "Start Muxing" button.... only it's not there.

Start Muxing.....
MKVToolNix has a setting in preferences labelled "clearing settings automatically". I have it set to "remove input files". Sometimes though, I don't want to, for example when remuxing an MKV while adjusting the audio delay, knowing it might require a few attempts to get it right. I wish there was a way to tell the GUI "please don't remove the input files this time". Maybe the "Start muxing" button could have a drop down arrow similar to the "Add source files" button? Maybe the "Add job to queue" button could have a drop down arrow too?

The Merge Window, part 1....
Browsers usually come with a similar annoyance out of the box. You close a single open tab and it closes, leaving you with software sitting on your screen that can't do anything until you open a fresh tab. Or closing the last tab shuts the browser down completely.
I don't think option B is a good one, but when closing MKVToolNixGUI's only "output file" tab, it seems sensible for it to automatically create a fresh one.

The Merge Window, part 2....
When I'm ruler of the world, any program using tabs will have to include an option to remove the red "x" from each tab so you can click on a tab without accidentally closing it. The red "x" option would be substituted with middle click. A right click close tab option might be considered on an individual basis.
Double left clicking on a tab would duplicate it, allowing the GUI to remove the input files when muxing starts while at the same time retaining them, and double left clicking next to the last open tab would create a new one.
All those tab features will be compulsory when I rule the world. ;)

Default language....
There's an option in preferences to set a default language when opening certain streams without a language previously set. I'm still struggling with the rules for this one but one annoyance for me is the way AAC audio is handled.
A RAW AAC stream will automatically be assigned the default language when it's added for muxing. AAC in an m4a/mp4 file.... not so much. Which is a little disappointing given AAC audio is generally written to an M4A/MP4 file as it's encoded, without a language being set. I've checked QAAC and NeroAAC and in both cases opening the m4a they write prevents MKVToolNix GUI from setting the default language as I expected (hoped) it would. Even remuxing the m4a as an MKV while leaving the language as "undefined" doesn't allow MKVToolNix to set the default language for the AAC stream when the mka is added for muxing. Is the preference for RAW streams only?

Thanks for the continued work on MKVToolNix!

[Nico8583]

Hi Mosu,

Does the last mkvmerge is able to create TrackOperation (http://www.matroska.org/technical/specs/index.html#TrackOperation) entries ? If yes, how to do that exactly ?
Is there any improvement about TrackOperation since 2011 ?
Thank you !

[Mosu]

The discussion didn't sound like it would ever get us a simple tag to assign the MVC plane to a track, rather re-implement the entire structures on a per frame basis, which MKV doesn't even have the correct structures for yet. So don't blame us for wanting something that works in 2016 and doesn't require writing a complex handling system for one container, while still keeping the MVC stuff for other containers.

Wanting something generic that works with everything is nice and all, but I prefer to remain realistic.

And those would have been arguments that could have changed the discussion to focus on a solution that's simpler and quicker to implement while leaving a more complex solution for the future. Instead you've added a field that other software started to use already and that is already confusing users and other developers of Matroska-related software.

Please don't take this is assigning blame. I'm not about who's right and who's wrong; that doesn't get us anywhere.

I'd much rather restart the discussion from January/February with some new facts. Could you list some more information about what typical 3D videos use and need today? I'll gladly post those on the relevant mailing lists. Neither Steve Lhomme nor I have a lot of experience with 3D video (if at all), therefore the first step for us is to understand the requirements; both the ones for the common cases as well as the ones for complex cases.

If all you need for 95% of the files is a simple integer field (call it "3D plane" or something like that) that's to be interpreted like a corresponding field from the 3D video specs of some codec then adding that in both the official specs and MKVToolNix is easy; it can be done within a couple of days. Such a system could later be expanded with additional header fields that specify the mode that the "3D plane" field is to be interpreted. But those additional fields don't have to be specced out right away.

Thanks.

[Mosu]

I have an MKV with a video and audio stream. The default flag for each is set to "no" when I open it with MKVMergeGUI 7.8.0 to check it. When I open the MKV with version 9.1.0, I see this:

I've just verified this. It is a bug, plain and simple. The intention of the column "default track in output file" is to show exactly how mkvmerge will set the flag when muxing taking all the different pieces of information into account that exist: order & types of tracks; existing states of this flag in input files; current settings.

I'll fix this.

[Mosu]

Why does the : after the drive letter get deleted automatically when I delete the drive letter in the output field?

A couple of weeks ago I've implemented a mechanism for sanitizing the output file name so that characters that aren't allowed within a file name are removed automatically. This includes : which may only occur as the second character in which case the first character denotes the drive letter.

Unfortunately this is indeed interfering with changing the drive letter the way you've just described. I'll look into this and think of a way to improve it. As a workaround you can first select the wrong drive letter and then type the intended letter which will instantly replace the selected text. That way the colon will be preserved.

Also, if I only type an f and forget to add the : because I didn't notice or remember the missing : after the drive letter the job still runs and put the file somewhere. :confused: It doesn't flag the output path as being bad.

That's because such a path isn't bad. It's a relative path instead of an absolute one. It's relative to the GUI's working directory which is your user's profile directory. You should therefore look into e.g. C:\Users\YourUserName\f\… for the resulting file.

[Mosu]

mkvmerge always sets one track of each type to default, unless you explicitly set every track to default:no.

That's not entirely correct. It will also take the state of the "default track" flag from the source containers into account. At the moment the only container to provide such flags is Matroska.

The nit & grit of how mkvmerge decides the flag's states is listed in this FAQ entry (https://github.com/mbunkus/mkvtoolnix/wiki/Default-and-forced-flags-and-default-yes-no-in-the-GUI).

[Mosu]

@hello_hello: Thanks for your detailed observations & requests.

There's a difference between the way the new and old GUI's handle duplicate file names and the old GUI's method was more fun. ;)

I see your points, but I'm currently not that interested in fixing this. It should be fixed in the long run, though. It'd be nice if you could open an issue in my bug tracker (https://github.com/mbunkus/mkvtoolnix/issues/) for it; otherwise chances are I'll forget about it again. Thanks.

Unless there's a circumstance under which setting a value of "1" as the maximum number of files is acceptable, might it be an idea for the GUI not to allow you to set "1" via the up/down arrows?

Same as above.

It'd be nice if it could just output one part though, given it's fairly similar to splitting, only without writing the additional parts.

That's exactly what the "split by parts" functionality was introduced for. If all you need is a single piece of the file (e.g. the first 10 minutes) then use "split by parts" and use the syntax "-00:10:00" as the split points. That way it'll keep everything from the start of the file up to the ten minute mark. mkvmerge won't even append the "-001" splitting suffix in such a case, and you don't have to mess around with "maximum number of files" either.

I'm prepared to accept I'm just too silly to work it out, but how do you abort a running job?

Go to the "job output" tool and hit the "abort" button.

It might be (dare I say it) an XP thing, but the "Job Queue/Stop Job Queue" menu appears not to function. The "Stop Job Queue" menu has an arrow, indicating it may lead to a sub-menu, but it doesn't open to anything.

That entry does indeed have a sub-menu with two entries, "stop after all running jobs have finished" and "abort all running jobs and stop immediately" which hopefully should be self-explanatory. If that sub-menu doesn't show up then it may indeed by an XP thing.

I'm a little curious. Why are there no buttons at the bottom of the job queue window? "Start Jobs", Abort Jobs", "Pause Jobs".... that sort of thing.

I've tried to minimize the number of buttons that are shown somewhat. The reason is that the GUI has so many more options than the old one ever had (just look at the context menus for what I mean). The whole idea of the job queue is that you usually don't interact with it that much. Ideally it should sit in the background doing its thing.

MKVToolNix has a setting in preferences labelled "clearing settings automatically". I have it set to "remove input files". Sometimes though, I don't want to, for example when remuxing an MKV while adjusting the audio delay, knowing it might require a few attempts to get it right. I wish there was a way to tell the GUI "please don't remove the input files this time". Maybe the "Start muxing" button could have a drop down arrow similar to the "Add source files" button? Maybe the "Add job to queue" button could have a drop down arrow too?

That's not such a bad idea. Can you please open an issue in my bug tracker (https://github.com/mbunkus/mkvtoolnix/issues/) for this one, too? Again with forgetting about it otherwise.

I don't think option B is a good one, but when closing MKVToolNixGUI's only "output file" tab, it seems sensible for it to automatically create a fresh one.

Maybe, maybe not. You could also load an existing setting file. You wouldn't need that extra blank tab in that case.

When I'm ruler of the world, any program using tabs will have to include an option to remove the red "x" from each tab so you can click on a tab without accidentally closing it. The red "x" option would be substituted with middle click. A right click close tab option might be considered on an individual basis.

The GUI is already very flexible regarding its configuration. The cost of this is improved complexity in development, testing and maintenance (including bug tracking!). Another cost is that the preferences dialog becomes more and more complex with each choice a user can make.

This is fine for a certain group of users (I'm one of those; I prefer configurabitly and flexibility over convention), but for others it's very off-putting. I'm therefore hesitant to make each and every thing in the program configurable, and not showing the close buttons is one of them for the time being. Sorry.

There's an option in preferences to set a default language when opening certain streams without a language previously set. I'm still struggling with the rules for this one but one annoyance for me is the way AAC audio is handled.

This option is only taken into account if the source container format doesn't provide a language. The MP4 container does; therefore the option isn't used in such cases. This is by design.

What I may think about is making the option apply to tracks whose language is currently set to "undefined" ("und"), too. Again, please open an issue for it (https://github.com/mbunkus/mkvtoolnix/issues/). Thanks.

[Mosu]

Is there any improvement about TrackOperation since 2011 ?

No. I haven't worked on this at all yet.

[Nico8583]

No. I haven't worked on this at all yet.
Ok thank you, do you plan to work on this feature in your to-do list ?

[Mosu]

Ok thank you, do you plan to work on this feature in your to-do list ?

Not really, sorry. I have so many things I'd rather work on for the time being… Patches would be very welcome, though.

[Mosu]

The intention of the column "default track in output file" is to show exactly how mkvmerge will set the flag when muxing taking all the different pieces of information into account that exist: order & types of tracks; existing states of this flag in input files; current settings.

New pre-builds (https://mkvtoolnix.download/windows/pre/) are available. Build numbers 01213 and higher contain the fix.

[Nico8583]

Not really, sorry. I have so many things I'd rather work on for the time being… Patches would be very welcome, though.
Ok thank you, perhaps someone will release a patch. I think MakeMKV use this specification to create MK3D but I'm not sure.

[hello_hello]

I've just verified this. It is a bug, plain and simple. The intention of the column "default track in output file" is to show exactly how mkvmerge will set the flag when muxing taking all the different pieces of information into account that exist: order & types of tracks; existing states of this flag in input files; current settings.

Awesome! Thanks.


(re splitting and duplicate name checking)

I see your points, but I'm currently not that interested in fixing this. It should be fixed in the long run, though. It'd be nice if you could open an issue in my bug tracker (https://github.com/mbunkus/mkvtoolnix/issues/) for it; otherwise chances are I'll forget about it again. Thanks.

Will do. Cheers.

That's exactly what the "split by parts" functionality was introduced for. If all you need is a single piece of the file (e.g. the first 10 minutes) then use "split by parts" and use the syntax "-00:10:00" as the split points. That way it'll keep everything from the start of the file up to the ten minute mark. mkvmerge won't even append the "-001" splitting suffix in such a case, and you don't have to mess around with "maximum number of files" either.

Thanks. Obviously I haven't been paying enough attention.
Probably because it's previously been easy enough to split "after duration" and then abort the job after the first part is written.
Probably because it never occurred to me there's a "split by parts" equivalent to "split after duration".
I think the penny is droping and I'm understanding the distinction now. I'll play around....

Go to the "job output" tool and hit the "abort" button.

That's the button I expected to find at the bottom of the job queue window... or one of them. ;)
It never occurred to me to look for it there. Thanks. Although...
When there's multiple jobs in the queue and it's running, the Abort button only aborts the current job, then the next one in the queue commences, so maybe I tried it and forgot about it when I realised it didn't stop the job queue from running.

That entry does indeed have a sub-menu with two entries, "stop after all running jobs have finished" and "abort all running jobs and stop immediately" which hopefully should be self-explanatory. If that sub-menu doesn't show up then it may indeed by an XP thing.

I think it's the only problem I've found that might be XP related. I have a Linux PC set up now. It'll be a while before I'm ready to jump ship completely but I probably should wander over there for future testing. I'll install MKVToolNix on it later.
The problem may also be menu timing related. I have XP configured so hovering the cursor over menus doesn't automatically open them unless I hover for a really long time, so in practice menus don't open until I click on them. Very occasionally a particular program is unhappy about that. The rest of the MKVToolNixGUI menus seem to be following the rules, but I'll change the setting later when I can reboot to see if the sub-menu starts working and if it does I'll report back, otherwise I'll assume it's XP's fault.

I've tried to minimize the number of buttons that are shown somewhat. The reason is that the GUI has so many more options than the old one ever had (just look at the context menus for what I mean). The whole idea of the job queue is that you usually don't interact with it that much. Ideally it should sit in the background doing its thing.

I'd wonder if it's at least as equally important to be able to interact with the job queue easily. When there's lots of jobs in the queue that could take a long time to run it's nice to have some simple "pause/stop/abort/continue" control.
To me it just "feels" like that's where buttons should be, rather than in a drop down menu at the top, because that's where I still keep expecting to find them. Probably because you set a precedent by endowing the Merge and Job Output windows with buttons. Just my 2 cents worth from a user perspective, but I'll get used to it. :)

The GUI is already very flexible regarding its configuration. The cost of this is improved complexity in development, testing and maintenance (including bug tracking!). Another cost is that the preferences dialog becomes more and more complex with each choice a user can make.

I thought I was being a tad optimistic with the tab features but I was on a bit of a roll. I have one more optimistic tab related feature request though. I'll save it for the next post.....

What I may think about is making the option apply to tracks whose language is currently set to "undefined" ("und"), too. Again, please open an issue for it (https://github.com/mbunkus/mkvtoolnix/issues/). Thanks.

The M4A files created by QAAC don't appear to have a language set. Opening one in MKVMergeGUI 7.8.0 shows the language as "undefined" and there's no language displayed when opening the M4A with MediaInfo.
I'll wander over to the bug tracker. Thanks again.

Edit: I've added the requested issues to the bug tracker under the ID "this-username-is-already-taken".

Cheers.

[hello_hello]

Tab feature request for the Merge window.....

I'd like to be able to see, by looking at the Input/Output/Attachment tabs, whether any setting under each tab is currently something other than the default. By "default" I mean the default setting for the GUI combined with any user preference that might change those settings.
Something simple would do. Changing the colour of the tab's text, or changing the text to italic etc.
The reason for this request is simply to over-come my being to stupid to always check things for myself.

In the past I'd most often forget to check the File Title. This seems to be less of a problem now as the "remove all files" function resets it, but still it'd be nice to know by glancing at the tabs if I've forgotten to disable splitting, or there's an attachment I didn't know about, or even to remind me I haven't specified a File Title. That sort of thing.

Speaking of the Attachments tab, I'd become quite used to the "enable all" and "disable all" buttons, and what could once be achieved with a single left click now requires 2x menu opening and 4x clicks. Or two clicks if you manually highlight all the attachments first.
While I'd not complain if those buttons were to re-appear, any chance of including "enable all" and "disable all" under the right click menu? I might take the liberty of adding this request to the tracker now, while I'm adding the others. I'll leave the request regarding the tabs until I know I'm not being silly.

Cheers.

[Mosu]

I'd like to be able to see, by looking at the Input/Output/Attachment tabs, whether any setting under each tab is currently something other than the default.

Sorry, but that won't be implemented. It would be very time-consuming to do, it would be confusing to users (why is that tab displayed differently!?), it's for your special use-case. Consider starting with new settings instead of re-using the existing settings if you're so concerned about forgetting to reset settings.

Speaking of the Attachments tab, I'd become quite used to the "enable all" and "disable all" buttons, and what could once be achieved with a single left click now requires 2x menu opening and 4x clicks. Or two clicks if you manually highlight all the attachments first.

Sorry, won't be implemented either as I consider that to be a duplication of already-existing functionality for the sake of saving two mouse clicks tops.

[Mosu]

The M4A files created by QAAC don't appear to have a language set. Opening one in MKVMergeGUI 7.8.0 shows the language as "undefined" and there's no language displayed when opening the M4A with MediaInfo.

Each MP4 file can have a language stored in its "mvhd" atom ("movie header"). If if contains a valid ISO 639-2 language code then mkvmerge will use it and the GUI will see that as the container providing the language. If the MP4 file doesn't contain such a valid code or if it's simply empty then mkvmerge won't emit the language tag and the GUI will use the default. I have files here for both cases and have just verified that when adding a file without a valid ISO 639-2 language code the GUI will set the default language specified in the preferences.

The thing is that "und" is a valid ISO 639-2 language code. That's probably what you have in your files. Hence the proposed extension to apply the default if the provided language is "und".

Edit: I've added the requested issues to the bug tracker under the ID "this-username-is-already-taken".

Much appreciated. Thanks.

[hello_hello]

Sorry, but that won't be implemented. It would be very time-consuming to do, it would be confusing to users (why is that tab displayed differently!?), it's for your special use-case.

Fair enough if it'd be time consuming. I thought as much, but you never know if you don't ask. I don't think I'd blame it on the average user being too silly to understand though. Working out when the default flag is going to be applied to a stream has traditionally required years of study by comparison. ;)

Sorry, won't be implemented either as I consider that to be a duplication of already-existing functionality for the sake of saving two mouse clicks tops.

Compared to a single click for the old GUI, it's mostly a difference of.... a right click to open a menu, a left click to "select all", a right click to open the menu again, and a left click to "disable all".
Personally I think the "select all" right click option is somewhat redundant because it would be better split into "enable all" and "disable all" options, unless there's another reason for wanting to "select all" attachments? I don't think there's any other choices though, so you'd have enable/disable options for selected attachments and the same again for all attachments. The latter two wouldn't need to change which attachments are selected, so they could also help out by allowing you to... for example.... select some of the attachments, click the "disable all" option, then the "enable selected" option, which would leave you with just the selected attachments enabled. That sort of thing. I'm pretty sure "select all" could retire.

While resisting writing an essay on duplicated MKVToolNixGUI functionality, I was just wanting to point out the "Enable/Disable all" thing is a step backwards compared to the old GUI, even if it's a minor one in the grand scheme of things.

The thing is that "und" is a valid ISO 639-2 language code. That's probably what you have in your files. Hence the proposed extension to apply the default if the provided language is "und".

With MediaInfo in gobbledygook mode, and looking at an M4A written by QAAC, I found four instances of "language".

Language: 21956 (0x55C4)
Language: 0 (0x00000000) (three instances)

Which means nothing to me, but it probably means something to you. In normal text or html view MediaInfo doesn't display a language field.

Much appreciated. Thanks.

You're welcome. :)

[hello_hello]

Just a little AAC oddity.....
For some reason MKVToolNixGUI shows LC-AAC audio as having a bitdepth of 16 bits when it's an an M4A/MP4 container. When it's in an MKA container or it's RAW AAC, MKVToolNixGUI correctly shows no bitdepth.

For HE-AAC, which aside from being "HE" would be stereo 44100Hz, MKVToolNix displays it as 22050Hz, 1 channel, 16 bit. It does whether it's in an M4A or MKA container, or whether it's RAW AAC (minus the 16 bit part for MKA or RAW AAC).

Something I've never quite understood.....
When muxing RAW LC-AAC, MKVToolNix offers a warning about not being able to automatically detect if it's HE-AAC, which seems a little odd as every time I've loaded RAW HE-AAC for muxing it's been automatically detected. The old GUI was the same.
The new GUI adds to the fun by displaying "determine automatically" in the field for AAC audio, but for LC-AAC it then offers a warning when muxing that it can't be determined automatically after-all.

Anyway..... would there be any chance of an option to disable the warning regarding muxing RAW AAC and it being muxed the wrong way?
Mind you in a perfect world it'd probably better to know when there's warnings, so would there be a chance of an additional option for the job queue? Currently "remove completed jobs from queue even if there were warnings" stops the warning icon from flashing when muxing is completed. Could there also be an "even if there were warnings" option that doesn't?

Thanks.

[hello_hello]

Re the problem with the "Job queue/Stop Job queue" sub menu not opening:

I changed the menu opening setting in the Windows registry and the menu started working (no reboot required, as it turned out).
I discovered there's another effected MKVToolNixGUI menu too, so there's:
"Job queue/Stop Job queue"
and the right click option in the merge window:
"Select all tracks of a specific type".
Both have sub menus that failed to open for me. I'm guessing this mightn't just be an XP issue, so you may want to check. The registry entry in question is.... (this is the default setting)

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Control Panel\Desktop]
"MenuShowDelay"="400"

That means there's normally a 400ms delay before a sub-menu opens automatically. I had it set to it's maximum value of 65534, so you've either got to be very patient, or a sub menu won't open until you click. That's the part that's not behaving for MKVToolNixGUI (at least on XP). Clicking does nothing. When I reset the registry entry to it's default value, both menus open automatically after a short hover of the cursor (how do people use menus like that, it's so annoying?).
I've reduced the registry value to 5000 for the moment so the rest of the Windows menus are tolerable and I can use those two MKVToolNix sub-menus if I highlight the menus with the cursor and wait five seconds for them to open.

I had a similar problem recently with the fork of the Extension Preferences Menu add-on for Pale Moon. It's menu wasn't following the rules, but the author fixed it for me. He's a very nice fellow.
Prior to the fix the add-ons menu and the arrow to the right were a single menu, and the sub-menu opened whenever the menu was highlighted (the opposite problem). He somehow changed it so the arrow to the right was like the arrow for a drop down arrow next to a button (same as the rest of those menus). I don't understand how any of that works, but the add-ons menu then started behaving like the rest of the Pale Moon menus.
I don't know if any of that will help, but I thought I'd mention it in case it's not just an XP problem, you want to look at it, and it does. :)

http://s32.postimg.org/7qzkabd3p/Pale_Moon.gif

[Mosu]

I'm guessing this mightn't just be an XP issue, so you may want to check. The registry entry in question is.... (this is the default setting)

I'm sorry, but I don't support changing such things in such a way. I'm using default menu classes from Qt; if they work with your custom setting: great. If they don't then I don't consider this to be my problem.

[Mosu]

What mkvmerge reads and shows is the bit depth header field that's part of the MP4 container.

[quote]When it's in an MKA container or it's RAW AAC, MKVToolNixGUI correctly shows no bitdepth.

Correct, and it most likely never will as that information is not easily available by decoding the raw AAC headers themselves.

For HE-AAC, which aside from being "HE" would be stereo 44100Hz, MKVToolNix displays it as 22050Hz, 1 channel, 16 bit. It does whether it's in an M4A or MKA container, or whether it's RAW AAC (minus the 16 bit part for MKA or RAW AAC).

Yeah, and? That's the value signalled by HE-AAC headers: _half_ of the _output_ sampling frequency. This is correct, too.

When muxing RAW LC-AAC, MKVToolNix offers a warning about not being able to automatically detect if it's HE-AAC, which seems a little odd as every time I've loaded RAW HE-AAC for muxing it's been automatically detected. The old GUI was the same.

There are two ways to differentiate between normal AAC and HE-AAC:

if the AudioSpecificConfig() element signals it (such an element is only present if AAC is read from certain container formats such as MP4 and Matroska but not in a raw AAC bitstream)
if the encoded AAC bitstream contains SBR extension elements

As mkvmerge doesn't decode the whole AAC bitstream it cannot use method 2 and must rely on method 1.

As stated above method 1 doesn't apply to raw AAC bitstreams (ADTS files), though, as they don't contain an AudioSpecificConfig() element. For such raw files mkvmerge employs a simple heuristic: if the signaled sampling frequency is 24.000 or less it assumes the input to be HE-AAC; otherwise it assumes normal AAC. As "heuristic" is just a fancy word for "guessing" mkvmerge may be wrong about particular files; hence the warning.

I don't want to clutter the GUI and mkvmerge with special-case options such as the one you've just described. I may think about getting rid of the warning entirely, though.

[Mosu]

Personally I think the "select all" right click option is somewhat redundant because it would be better split into "enable all" and "disable all" options, unless there's another reason for wanting to "select all" attachments?

The thing is that enabling/disabling all is in fact not the only thing a user might want to do. She might also just want to disable nine of the twelve attachments; therefore changing "enable selected" to "enable all" would rob her of that functionality.

So can we please drop this particular topic? I'm certain that you've already spent way more time talking to me about that feature than you will ever lose by having to open the context menu twice instead of once. Thanks.

With MediaInfo in gobbledygook mode, and looking at an M4A written by QAAC, I found four instances of "language".

Language: 21956 (0x55C4)

This is where it comes from. In MP4 language tags are stored as two bytes encoding three characters (each character takes five bites). The value 0x55C4 is decoded as follows:

0x55c4 = 0b10101 01110 00100
0b10101 + 0x60 = 0x75 = 'u'
0b01110 + 0x60 = 0x6e = 'n'
0b00100 + 0x60 = 0x64 = 'd'

Your file does have a language tag, it's "und".

[Mosu]

Mind you in a perfect world it'd probably better to know when there's warnings, so would there be a chance of an additional option for the job queue? Currently "remove completed jobs from queue even if there were warnings" stops the warning icon from flashing when muxing is completed.

That doesn't make any sense. If the job emitted a warning and is removed from the queue why should the warning indicator flash? You couldn't even tell which job caused the warning, never mind check what the warning was about.

[foxyshadis]

I'm not sure why bit-depth is even reported for a lossy audio format at all. It can be decoded to 16- or 24-bit, or float for that matter, as the decoder wishes, it's completely separate from what was fed to the encoder. Only lossless should have a defined bit-depth.

[Mosu]

Due to user requests. And mkvmerge doesn't set those header fields in MP4, it only reports them if they are set.

[hello_hello]

I'm sorry, but I don't support changing such things in such a way. I'm using default menu classes from Qt; if they work with your custom setting: great. If they don't then I don't consider this to be my problem.

Fair enough, but what if I'm not doing something as basic as changing a legitimate registry entry? What if I'm using a different Windows theme and something breaks? I'm just wondering where the line is and what bugs I shouldn't bother trying to track down and report.
For the record, I didn't change that registry entry on a whim. In fact I had no idea which registry entry was involved until I investigated yesterday. TweakUI is an official Microsoft utility. It works for XP, Vista and Windows 7. If it breaks Qt, it probably should be reported as a Qt bug. I can't imagine I'm the only person using TweakUI to tweak Windows, but maybe the other 99.999% of people who think MKVToolNixGUI has broken menus haven't gone to the trouble of working out why and reporting the problem.

What mkvmerge reads and shows is the bit depth header field that's part of the MP4 container.

Correct, and it most likely never will as that information is not easily available by decoding the raw AAC headers themselves.

Lossy audio has no bitdepth. I don't know why there's bit depth information in the M4A container for AAC.
Maybe bitdepth information is compulsory? Maybe it's supposed to indicate the bitdepth of the source? Maybe it's supposed to state the bitdepth to which the audio should be decoded? I don't know, but AAC has no bitdepth.

Yeah, and? That's the value signalled by HE-AAC headers: _half_ of the _output_ sampling frequency. This is correct, too.

It's obviously not correct for the whole audio, and it seems misleading to me. Stereo 44100Hz AAC audio isn't single channel 22050Hz, 16 bit, even if it is HE. Only the HE part is (except it's not 16 bit).

Depending who's writing the file, MediaInfo displays something that's technically correct, or it can get confused, but you've got to give it credit for trying.

QAAC:
Channel positions : Front: L R
Sampling rate : 44.1 KHz / 22.05 KHz

NeroAAC:
Channel(s) : 2 channels / 1 channel / 1 channel
Channel positions : Front: L R / Front: C / Front: C
Sampling rate : 44.1 KHz / 44.1 KHz / 22.05 KHz


As stated above method 1 doesn't apply to raw AAC bitstreams (ADTS files), though, as they don't contain an AudioSpecificConfig() element. For such raw files mkvmerge employs a simple heuristic: if the signaled sampling frequency is 24.000 or less it assumes the input to be HE-AAC; otherwise it assumes normal AAC. As "heuristic" is just a fancy word for "guessing" mkvmerge may be wrong about particular files; hence the warning.

Thanks for the info.

I don't want to clutter the GUI and mkvmerge with special-case options such as the one you've just described. I may think about getting rid of the warning entirely, though.

I admire your belief that every suggestion you wouldn't necessarily use yourself falls under "special case".

The thing is that enabling/disabling all is in fact not the only thing a user might want to do. She might also just want to disable nine of the twelve attachments; therefore changing "enable selected" to "enable all" would rob her of that functionality.

I never said to touch the "enable selected" option, only to split "select all" into "disable all' and "enable all". I even went to the trouble of explaining how they'd probably be more useful than "select all", so I assume you didn't understand what I wrote.

Have a look at the right click options for individual streams in your own MKVToolNixGUI software under the Merge window. It has the "enable all" and "disable all" options I've requested, yet for some reason they're appropriate for multiple streams but not for multiple attachments. I don't understand why, or why you'd prefer a lack of consistency.

So can we please drop this particular topic? I'm certain that you've already spent way more time talking to me about that feature than you will ever lose by having to open the context menu twice instead of once. Thanks.

You can stop discussing the subject any time you like. You're welcome.

You dragged the "way more time" argument out a while ago when I went to the trouble of reporting bugs and making suggestions for the old GUI, making me wish I hadn't bothered. I think I've read that one several times now. It's a strawman argument and comes across as refusing to acknowledge you mightn't be right.
Mind you, I'm sure you could have implemented the requested feature in the time you've spent arguing against it. Does saying that help you see how irrelevant.... and to be honest.... a little offensive.... the "way more time" argument is?

Your file does have a language tag, it's "und".

That's fine, I just didn't know either way, but I thought you might want to confirm that's the case.

That doesn't make any sense. If the job emitted a warning and is removed from the queue why should the warning indicator flash? You couldn't even tell which job caused the warning, never mind check what the warning was about.

What's the Job Output window for? Does a job have to remain in the queue for it to display the warning?
I haven't really looked at the Job Output window too closely yet, but I'll admit I assumed if it contained warnings it'd be obvious which jobs those warnings were for even if they were no longer in the job queue. That's not the case?

Thanks.

[isidroco]

1) Is there a way to generate chapters based on Filename?

2)
I have some problems with mkvmerge help file, it's localized to my language, but parameters in single brackets should NOT be translated. Another issue is that special characters "áéíóúñ" are incorrectly displayed in Command window (it would be better to avoid them). It is VERY important to offer IN ENGLISH a way to display english help, as a portable application I used it in Germany on a lent computer and can't get any command line help as I don't understand german.

--generate-chapters <modo>
Genera capítulos automáticamente según
el modo ('al-unir' o 'intervalo:<duración>').
--generate-chapters-name-template <plantilla>
Plantilla para los nombres de capítulos recién creados
(por defecto: 'Capítulo <NUM:2>').

[Mosu]

1) Is there a way to generate chapters based on Filename?

No.

2) I have some problems with mkvmerge help file, it's localized to my language, but parameters in single brackets should NOT be translated.

I'll forward this to the appropriate translator. Which language is used?

Another issue is that special characters "áéíóúñ" are incorrectly displayed in Command window (it would be better to avoid them).

Non-ASCII characters show up just fine on my German Windows with a German translation as well as with e.g. the Portuguese translation. So this works in general; I have no idea why it doesn't in your case.

It is VERY important to offer IN ENGLISH a way to display english help

That's easy: "mkvmerge --ui-language en --help"

[Mosu]

Fair enough, but what if I'm not doing something as basic as changing a legitimate registry entry? What if I'm using a different Windows theme and something breaks? I'm just wondering where the line is and what bugs I shouldn't bother trying to track down and report.

Hmm, I don't have strict rules. It's a combination of "how often do users do that", "how much work would it require to fix", "is it a problem in my program or in one of the libraries it uses" and a couple of other soft factors. Another example where I drew the line is third-party theme engines that enforce that progress bars are very wide (they probably assume that a top-level window will always contain a single progress bar only – but MKVToolNix GUI contains two, making the main window unusably huge with such themes). See this issue (https://github.com/mbunkus/mkvtoolnix/issues/1349) for an in-depth discussion and how it was discovered.

It works for XP, Vista and Windows 7. If it breaks Qt, it probably should be reported as a Qt bug.

Indeed, that's where it should be fixed.

but maybe the other 99.999% of people who think MKVToolNixGUI has broken menus haven't gone to the trouble of working out why and reporting the problem.

I cannot judge how many people have problems with the menus in MKVToolNix GUI as you're the only one who has reported such issues ever. Therefore I'd guess "not many". The number of people having reported problems with the aforementioned wide GUI due to 3rd party theming issues is higher than that.

Lossy audio has no bitdepth. I don't know why there's bit depth information in the M4A container for AAC. Maybe bitdepth information is compulsory? Maybe it's supposed to indicate the bitdepth of the source?

Me neither :) That it's the source's bit depth seems like a sound assumption. Users have requested the information to be present, therefore I expose it.

It's obviously not correct for the whole audio, and it seems misleading to me. Stereo 44100Hz AAC audio isn't single channel 22050Hz, 16 bit, even if it is HE. Only the HE part is (except it's not 16 bit).

mkvmerge only reports the raw values from the container; it doesn't interpret them a lot. That's not what I designed it for (and I certainly don't want to turn it into a bad and half-assed MediaInfo clone). For such in-depth information people should use other tools, and that's why the GUI provides an easy way to start MediaInfo for any file added to the GUI.

Depending who's writing the file, MediaInfo displays something that's technically correct, or it can get confused, but you've got to give it credit for trying.

To be honest I don't give MediaInfo much credit for trying as I've had countless reports of confused users who think MediaInfo is always correct and where it turned out that it wasn't, that it was just guessing and users took it at face value etc. I do recognize the usefulness of MediaInfo, but it has been a source of a lot of support requests (and therefore work for me) even though the problem wasn't on my end. But that's my personal beef with MediaInfo; it remains highly useful, of course.

I never said to touch the "enable selected" option, only to split "select all" into "disable all' and "enable all". I even went to the trouble of explaining how they'd probably be more useful than "select all", so I assume you didn't understand what I wrote.

That assumption is indeed correct – I misunderstood you. I'm sorry for not reading your earlier comment properly. Splitting "select all" is useful; I'll implement it.

I admire your belief that every suggestion you wouldn't necessarily use yourself falls under "special case".

I definitely don't think that. My thought process was more along the lines of adding a feature to circumvent a certain warning will only help those that know that the feature actually exists, and I'd prefer a solution that helps more users out of the box. Hence me saying that I'd think about removing the warning altogether – it would remove the need for such an option.

You dragged the "way more time" argument out a while ago when I went to the trouble of reporting bugs and making suggestions for the old GUI, making me wish I hadn't bothered. I think I've read that one several times now. It's a strawman argument and comes across as refusing to acknowledge you mightn't be right.

I'm wrong often enough, and yes, I can be stubborn (as I like being right…). I'm aware of that fault.

In this case the "too much time" argument was meant for one and only one specific feature request: making visible to the user which settings have changed since saving/starting a job. I do have code in place that checks whether the whole configuration has changed since it's been saved – by mis-using the "save merge settings" functionality (I save the current settings to a temporary file and compare that to a saved state from the last save point). However, that functionality is decoupled from the GUI completely, and adding change detection for each and every GUI control would indeed be a lot of work. It would certainly take a couple of days to implement and iron out all bugs.

The other features I've refused to implement are not due to immense amounts of work required.

And I do spend a lot of time answering your posts as you've spent a lot of time writing them. When a user invests so much time in posts & bug reports then (s)he deserves as much effort on my end. Therefore I try to explain my choices and reasons in more detail than for simple requests such as "please implement support for format XYZ kkthxbye".

What's the Job Output window for? Does a job have to remain in the queue for it to display the warning?

The number of warnings and errors displayed in the status bar are from the jobs still present in the queue, yes.

I haven't really looked at the Job Output window too closely yet, but I'll admit I assumed if it contained warnings it'd be obvious which jobs those warnings were for even if they were no longer in the job queue. That's not the case?

The default job output window contains the output of all jobs run in the current session (depending on the GUI's configuration). As soon as you restart the GUI the window will be empty again losing any information about warnings and errors that have occurred during earlier jobs.

However, the job queue defaults to not removing problematic jobs, especially to allow the user to look at results of problematic jobs later and not just while the GUI's still running. The user can then go to the job queue and double-click on the job in question, and a new job output tab is opened solely for this job.

If the warning and error indicators in the status bar would include both jobs still in the queue and ones visible in the default job output tab then it would be confusing which warnings those indicators refer to.

[hello_hello]

Mosu,
Thanks for the reply. I'm not upset or anything. Sometimes communication via forum posts can be a bit frustrating when it comes to getting a point across, but it's all good.
If I do go into "shitty mode" which happens now and then, I've usually forgotten why 10 minutes after I post. Life's too short.

Thanks for reconsidering the "enable/disable all" options.
Any chance I'd be able to wear you down and get you to reconsider some buttons at the bottom of the Job Queue window? I swear they should be there because I keep looking for them. Every single time.
The other button "wish" I have would be for an Abort button at the bottom of the Merge window. I know it's never been there before but the job window automatically opened for the old GUI and presented you with an abort button. For the new GUI I go to click on "Abort"..... wonder for a second where the button went.... ahhh that's right it's under the Job Queue window. Switch to the Job Queue window..... damn..... I think the muxing has finished anyway..... I'll get used to it one day. ;)

The warning messages are no big deal, but I'd hoped there'd be a combination of settings that'd remove jobs with warnings from the queue but still let me know if there were warnings so I could have a look..... to save having to manually delete those jobs while not missing out on anything.
What about something to click on (ie the warning indicator) that'd reset the warnings and delete any jobs with warnings from the queue? Too hard?? It's no big deal anyway. It was just a thought I had at the time.

By the way.... if a feature request is too time consuming to implement.... I get that. I wouldn't expect you to waste a lot of time you could be spending on other things, such as rethinking whether MKVToolNixGUI should check for and set any language written to the audio stream as it does for delays. I still think that'd be a good idea. ;)
MKVCleaver can write the language info now (although it uses the wrong format at the moment). gMKVExtractGUI writes it. MeGUI writes it and will use it when muxing. It'd be great if MKVToolNix could join the party. :)

I might have a look at reporting the Qt menu bug at some stage (fairly soon). It'd be nice if it was fixed. The default Windows menu settings drive me nutty. If I say "XP" though I might get laughed at, but I haven't got any newer Windows handy yet to check it's the same for Win7. Oh well.....

Cheers.

[Mosu]

Any chance I'd be able to wear you down and get you to reconsider some buttons at the bottom of the Job Queue window?

I don't think so, sorry :)

The other button "wish" I have would be for an Abort button at the bottom of the Merge window.

That won't happen either. Due to the queue running asynchronously the currently shown job in the merge tool doesn't have to have anything to do with the currently running one.

But you should give the following setting a try: "Preferences" → "Jobs & job queue" → "Always switch to the job output tool after starting one immediately". Maybe that'll suit your workflow better.

What about something to click on (ie the warning indicator) that'd reset the warnings and delete any jobs with warnings from the queue?

You can already right-click on those indicators and a menu will open with a couple of actions. I might extend that to such a functionality.

On the other hand: please give the option "Preferences" → "Jobs & job queue" → "Remove completed jobs older than x days" a try. It defaults to 14 days, but you might want to try setting it to 1 day and see if that's enough for you to keep the queue tidy without me having to implement anything else.

…such as rethinking whether MKVToolNixGUI should check for and set any language written to the audio stream as it does for delays. I still think that'd be a good idea. ;)

I'm sorry, but I have reasons (https://github.com/mbunkus/mkvtoolnix/wiki/Detecting-track-language-from-filename) why I won't implement such functionality.

[hello_hello]

I'm sorry, but I have reasons (https://github.com/mbunkus/mkvtoolnix/wiki/Detecting-track-language-from-filename) why I won't implement such functionality.

As briefly as I can, given the amount of wrong to be refuted.... :)

A sample audio extracted with gMKVExtractGUI:
S01E05 Affairs (1992)_track2_eng_DELAY -33ms

How would a muxer know the language is English? Probably the same way it'd know there's not supposed to be an audio delay of 01E, or 05, or 1992.... I suspect.

However you could take it a step further easily enough:
S01E05 Affairs (19912)_track2_[eng]_DELAY -33ms

I'm sure one of the extraction programs does that already. If you can find a legitimately named file including square brackets containing something that could be mistaken for a language code.... well after eating several hats I'd suggest everyone make this a new standard.

S01E05 Affairs_track2_[[eng]]_DELAY -33ms

MeGUI will automatically apply a language when using MKVToolNix for muxing if it's a full word (ie English) or if it's a three letter language code. Unfortunately MKVCleaver currently uses a two letter code if I remember correctly, but I think MeGUI would automatically set the following audio to French:
the_french_connection.ac3
or maybe this:
the_connection_french.ac3
so the current lack of a standard way to do things means very occasionally it does make a mistake. I'm still yet to read a complaint about it in the MeGUI thread though. Given you took the time to write that explanation I suspect you could reduce support questions by implementing the feature rather than not implementing it. You might even be able to reduce questions on the topic to zero as is the case for MeGUI. :)

I wouldn't take the language from a container file name. Only if it's specified for the individual streams, and if it's wrong there.... well if it comes down to that are there many settings that can't be set incorrectly at some stage? Automating a feature doesn't mean the user shouldn't still check things.

Realistically, MKVToolNix already does most of this. As long as it's opening streams in a container such as an MKV or MP4 etc, but if you extract the audio first it's every man for himself. Well these days MKVToolNixGUI will automatically set a language based on your preferences which may or may not be correct.

It does seem a pity the three letter language code would be restricted to English versions..... but there's a lot of English speaking MKVToolNix users out there. I suspect most people would come to recognise their commonly used language codes even if they don't speak English, but they could still set languages manually as they currently would.

Cheers.

[Ripman]

If someone can please confirm the problem I am having, as described below, I
will add the appropriate bug tracker request. Thank you.

mkvtoolnix 9.1.0 / win8.1

----------

Issue overview:
When appending wav files in mkvtoolnix gui to create an mka audio file, the
resultant mka file does not play properly.

----------

Issue process:
- Downloaded 96/24/2ch wav files from hdtracks. The tracks play in vlc.

- Added the first track to the mkvtoolnix gui.
- Selected the option to create chapters.
- Appended the other 18 tracks.
- Ensured the tracks were ordered properly.
- Merged. Resultant mka plays in vlc and has chapters at the appropriate times.

- Using the gui and the Edit Chapters function - opened the mka.
- Edited each chapter name. Changed each chapter's country to the USA.
- Saved the chapters to the mka file successfully.
- Saved the chapters to an xml file.
- mka plays in vlc and has chapters with names at the appropriate times.

- Added merged mka with chapter names to the mkvtoolnix gui.
- Added a title.
- Muxed.
- Resultant mka does not play in vlc. Time does not advance. Mediainfo shows
a one frame difference.

----------

Issue retry:
- Created a bin/cue CD image in roxio nxt2 disc copier. Used roxio nxt2 music
disc creator to extract 16-44-2ch wav's from the bin/cue CD image.
- Added the first wav to the mkvtoolnix gui.
- Appended other tracks.
- Resultant mka does not play in vlc. Time advances in 3-5s increments.

[edit] hdt wavs are extensible. Roxio wavs are 16bit Microsoft compliant.

[Ripman]

If someone can please confirm the following, I will add the appropriate bug
tracker request. Thank you.

mkvtoolnix 9.1.0 / win8.1

----------

Issue overview:
An mkvtoolnix settings file can be saved/created when the gui contains nothing.

----------

Issue process:
- Open mkvtoolnix gui 9.1.0. Add nothing. The gui is completely clear.
- Under the menu, select: "Save Settings." A file-save dialog is presented so
the user.
- Save the settings.

[Ripman]

That's not how it seems to work when you open an MKV with streams that have previously had their default track status set to "no". The MKV I opened in my previous screenshot was such an MKV, and after muxing with the GUI displaying exactly as it was in the screenshot, the resulting MKV had a video and audio track with a default status of "no".

...


Unless I'm completely misinterpreting what the "default track in output" column is telling me, but I'm not sure what else it could be.


My first post on p207 tried to explain this behavior as well. I've yet to post my subsequent reply to Mosu's questions, but I did type it out already.

[Mosu]

An mkvtoolnix settings file can be saved/created when the gui contains nothing.

I'm intentionally not restricting when a configuration can be saved. This is not a bug.

[Mosu]

My first post on p207 tried to explain this behavior as well. I've yet to post my subsequent reply to Mosu's questions, but I did type it out already.

Like I've said (http://forum.doom9.org/showthread.php?p=1767596#post1767596) this was a bug that I've fixed (http://forum.doom9.org/showthread.php?p=1767609#post1767609) since.

[Ripman]

I'm intentionally not restricting when a configuration can be saved. This is not a bug.

Very good; now I know. Thanks for responding.

[Ripman]

Like I've said (http://forum.doom9.org/showthread.php?p=1767596#post1767596) this was a bug that I've fixed (http://forum.doom9.org/showthread.php?p=1767609#post1767609) since.

I may have missed your announcement in that respect. Thanks for fixing that, though.

[Mosu]

Hey,

time for MKVToolNix v9.2.0. It's a somewhat unremarkable release with Several smaller issues having been addressed and no huge changes or enhancements.

One important change for Windows and Mac OS users of mkvinfo is that the change to start the GUI by default has been reverted. Instead a separate executable (mkvinfo-gui) is included for those platforms which starts the GUI by default. The newly introduced option "--no-gui" will remain valid but won't have any effect when used with the "mkvinfo" executable.

There have been no changes for package maintainers since the previous release.

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

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.

2016-05-28 Moritz Bunkus <moritz@bunkus.org>
* Released v9.2.0 "Photograph".

2016-05-20 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: the action "select all attached files" in the popup menu actions for the attached files view has been split up into "enable all attached files" and "disable all attached files". Implements #1698 (https://github.com/mbunkus/mkvtoolnix/issues/1698).

2016-05-15 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix on Windows: removing the drive letter does not cause the colon to be removed automatically anymore. Fixes #1692 (https://github.com/mbunkus/mkvtoolnix/issues/1692).
* MKVToolNix GUI: merge tool bug fix: it's no longer possible to select "1" as the maximum number of files to split into as mkvmerge doesn't accept that value. Fixes #1695 (https://github.com/mbunkus/mkvtoolnix/issues/1695).
* mkvmerge: bug fix: the "interval" chapter generation mode was always creating one chapter too many.
* mkvmerge: bug fix: if a certain number of chapters had been generated with --generate-chapters then mkvmerge wasn't replacing the void placerholder with the actual chapters. Fixes #1693 (https://github.com/mbunkus/mkvtoolnix/issues/1693).

2016-05-14 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool bug fix: the track column "default track in output" wasn't taking into account if the track had its "default track" flag set to "no" in the source file. This would result in the column showing "yes" in certain situations even though mkvmerge would assign "no".

2016-05-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed detection of (E-)AC-3 in MPEG TS files with unusual stream types (e.g. 0x87) but with (E-)AC-3 PMT descriptors. Fixes #1684 (https://github.com/mbunkus/mkvtoolnix/issues/1684).

2016-05-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mkvextract: bug fix: fixed handling of Big Endian PCM with a bit depth other than 16, 32 or 64 bits/sample. Other formats were using the Little Endian codec ID, but their content was actually not byte-swapped to match it. Now those other bit depths are byte-swapped to Little Endian, too. Fixes #1683 (https://github.com/mbunkus/mkvtoolnix/issues/1683).
* mkvinfo: the change to start the GUI by default on Windows and Mac OS has been reverted. Instead a separate executable (mkvinfo-gui) will be included for those platforms which starts the GUI by default. The newly introduced option "--no-gui" will remain valid but won't have any effect when used with mkvinfo.

2016-05-04 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo GUI: enhancement: the window title now includes the file name. Implements #1679 (https://github.com/mbunkus/mkvtoolnix/issues/1679).
* mkvmerge: enhancement: the "bit depth" track header field will be set for DTS tracks from the first DTS core header. Implements #1680 (https://github.com/mbunkus/mkvtoolnix/issues/1680).

2016-05-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: the time zone portion of the "date_local" member of the JSON and verbose identification formats contained the time zone's name instead of its offset on Windows due to the Visual C++ runtime's std::strftime not being C++11 compliant. Additionally this resulted in errors about invalid UTF-8 strings for locales where the time zone's name contained non-ASCII characters.

Have fun :)

[Mosu]

Addendum: Please note that the Windows installers (but not the actual programs) accidentally include a build number from the start of May (20160504-01204). This is a solely cosmetic issue which can be ignored.

[hello_hello]

Thanks for the new version. Just a little spelling error to report.......

--- Errors emitted by job 'merging to file "video.mkv" in directory "D:/"' started on 2016-05-29 19:59:26 ---
Invalid start/end specification for '--split' in '--split parts:00:05:30' (curent part: 00:05:30).

Cheers.

Mosu,
I gave reporting the Qt menu problem a shot, and I created an account for doing so, but reporting it in the right way was all too daunting. I wouldn't even know what category to file it under. The bug reporting system might make sense to someone using Qt to create software, but it's obviously not designed for the end user. I tried though.

[AngelGraves13]

I have an issue remuxing a file with a TrueHD stream that is 96KHz. The output file has no working audio and the timecode for the audio is messed up.

Guessing it's a bug with 96KHz audio files, as MakeMKV fixed the bug on their end a while ago.

[Mosu]

Thanks for the heads-up. Can you please upload such a TrueHD file (the one before remuxing) to my FTP server (see signature)? I'd like to investigate and fix this. Thanks.

[meridius75]

Hi all

Wanted to ask a question as I have been using MKV tool Nix for couple of years and now find that it introduces video errors into the picture when creating a new mkv.

I find this strange since I thought MKVToolNix did not alter the picture ?

I Rip my movies with MakeMKV and then dump the video into MKVToolNix To edit and remove some parts of the video and edit names and when I come to play back some films not all there seems to be video corruption for a spilt second.

I tried the movie that was created with MakeMKV and its perfect but MKVToolNix creates errors in the video picture sometimes.

Now I have noticed this in a few versions and its took months to figure out why some of my videos have these corrupt errors in the video.

Some videos I did years ago and just watched now and see the same thing.

So I kept two files the MakeMKV file and the MKVToolNix file and when I seen the error I went back and redid the video with MKVToolNix since the MakeMKV file was fine and no errors in the same video using MKVToolNix, its just random and happens just sometimes.

Its random when this happens and I don't know why its doing it but its very annoying because I have to redo alot of videos because of this and I don't use MKVToolNix that often now because its not reliable but need to use it.

can anyone help me or can I help you sort this problem out or does anyone know or had the same problem


thanks

[AngelGraves13]

Thanks for the heads-up. Can you please upload such a TrueHD file (the one before remuxing) to my FTP server (see signature)? I'd like to investigate and fix this. Thanks.

Sure, I just have to use mkvcleaver to extract it out of the file. The movie I'm remuxing in question is the remastered My Fair Lady, which comes with a 96KHz audio track. Another film I ran into an issue with was the isolated music track 96KHz TrueHD stream of the film Oblivion.

[Mosu]

Its random when this happens and I don't know why its doing it but its very annoying because I have to redo alot of videos because of this and I don't use MKVToolNix that often now because its not reliable but need to use it.

Please see e.g. bugs 651 (https://github.com/mbunkus/mkvtoolnix/issues/651), 830 (https://github.com/mbunkus/mkvtoolnix/issues/830), 1045 (https://github.com/mbunkus/mkvtoolnix/issues/1045), 1666 (https://github.com/mbunkus/mkvtoolnix/issues/1666).

Kind regards,
mosu

[meridius75]

Please see e.g. bugs 651 (https://github.com/mbunkus/mkvtoolnix/issues/651), 830 (https://github.com/mbunkus/mkvtoolnix/issues/830), 1045 (https://github.com/mbunkus/mkvtoolnix/issues/1045), 1666 (https://github.com/mbunkus/mkvtoolnix/issues/1666).

Kind regards,
mosu

Oh dear no solution in fixing this then as its random. that's a shame as I know its not my hardware as I now use makemkv and I never have any problem with that in all the videos I have done in the past month not one glitch in the video.

there is some sort of fault with MKVToolnix and its random and a nasty bug because of what it does but it is MKVToolnix causing it as MAKEMKV does not have this problem.

I have even redone the same movie a 2nd time using the same machine and same video with MKVToolnix and its been perfect.

I will keep a log of what version does this and what version does not as I have used MKVToolNix for over 4 years and I will try to figure out which version have been doing this.

[Ripman]

Sure, I just have to use mkvcleaver to extract it out of the file. The movie I'm remuxing in question is the remastered My Fair Lady, which comes with a 96KHz audio track. Another film I ran into an issue with was the isolated music track 96KHz TrueHD stream of the film Oblivion.

I originally found the truhd problem in Mmg 64 v8.1 win8.1 portable. I hit the problem while trying to add srt subs to mkvs that I previously ripped, which in this case was Chinatown & Dr. Strangelove.

The reason I didn't post my notes was bc I was still on the road, and bc there is a work-around. Basically, only mux once. So, in my case, prepare the srt subs before ripping, and then add the subs and mux. (Usually I do a post mux to set defaults and track order, and then subsequent muxes to add subs, etc.)

There are also work arounds for the My Fair Lady / Oblivion BDs posted above.
- Use the flac profile in makemkv and rip the truhd track as flac 5.1. It will easier to edit anyway (so you can remove the dead space in the iso scores).
- You could also open the mkv from makemkv in audacity, which will allow you to edit the truhd track - you need to point audacity at the proper ffmpeg bin.
- Lastly, you could use eac3to with the mkv from makemkv as input, specify the track #, and the target format (e.g., flac).
- (Mkvextract should have no problem with the flac tracks.)
- Hi-Rez audio for Previn's My Fair Lady is available on the oop Sony sacd. In this case, the sacd is a mono recording.

If the op can't get a truhd sample uploaded, I'll get one up when I'm back in town.

[Z-95]

Thanks for the heads-up. Can you please upload such a TrueHD file (the one before remuxing) to my FTP server (see signature)? I'd like to investigate and fix this. Thanks.

I've uploaded a small sample file to your FTP server that has TrueHD 96kHz named 96kHz.mkv. I used mkvtoolnix 7.9.0 to cut it since that version seems to handle 96kHz ok.

The same issues happen on 192kHz TrueHD as well--I can upload a sample with that if needed.

[Mosu]

Thanks. I'll be out of town for ~two weeks; therefore I won't have time to look into it right away. I'll keep you updated.

[Z-95]

Thanks. I'll be out of town for ~two weeks; therefore I won't have time to look into it right away. I'll keep you updated.

Rgr, did a bit more research into it to help narrow it down--it works in 8.6.1 but is broken in 8.7.0

[kuchikirukia]

Any idea where to find technical info on MKV segment linking? How hard linking should be implemented vs soft linking?

Oh, and didn't MKVToolNix used to auto-load the UIDs under Segment Linking when a mkv was loaded? I no longer see any UIDs when I drop in one of my linked mkvs.

[sneaker_ger]

There are two different ways to do segment linking. One is via the "File/segment linking" options. The other is via ordered chapters:
http://mod16.org/hurfdurf/?p=8

[Mosu]

I've uploaded a small sample file to your FTP server that has TrueHD 96kHz named 96kHz.mkv.

I've just fixed this in the latest pre-builds (https://mkvtoolnix.download/windows/pre/). Please give them a try, both with 96 kHz as well as 192 kHz. Thanks.

[Z-95]

I've just fixed this in the latest pre-builds (https://mkvtoolnix.download/windows/pre/). Please give them a try, both with 96 kHz as well as 192 kHz. Thanks.

Tested with 96 kHz and 192 kHz and both work with the latest build--thanks!

[Mosu]

Thanks for the confirmation.

[hubblec4]

Hello Mosu

Can you have a look from here (http://forum.doom9.org/showthread.php?p=1772244#post1772244)?

What is with the country code "uk"? It's not present in the MTX-GUI.

[Ripman]

Issue overview:
When appending wav files in mkvtoolnix gui to create an mka audio file, the
resultant mka file does not play properly.


Problem had to be on my side since no one could confirm.

Problem was with vlc 2.1.5. Upgraded vlc to 2.2.4 and the problem was resolved. I posted the same on GitHub.

[Z-95]

Quick question about whether something is possible to do with MKVToolNix--is it possible to get the timecode of the first cluster of an MKV file without scanning the entire file?

I currently have a personal tool written in Java that uses a modified version of jEBML to only read to the first cluster and extract the timecode and then resync the file if the first cluster timecode is not 0 using mkvmerge --sync. (I do this because mkvmerge when splitting by chapters on MPLS from blu-rays will sometimes produce files with non-zero timecodes that cause some players to not seek or display chapters correctly). However, since jEBML is unmaintained and I like to learn new things, I am considering porting my tool to python and would like all mkv operations to be done through external calls to MKVToolNix utils.

I know I could fully read the file with mkvinfo, but I have a SAN of ~56TB of MKVs that currently only takes about 90 minutes to scan while fully scanning the files would take days.

I was looking at mkvextract timecodes as well, but you must supply a track number so I wonder if the earliest timecode for the video track would match the actual cluster timecode?

[Mosu]

The first frame's timestamp is not necessarily 0 (e.g. think of a video with B frames in a file where audio starts somewhat after the video). Therefore I'd suggest you start mkvinfo as an external process and parse its output on the fly. Let mkvinfo parse the very first cluster and use the minimum of all timestamps in that cluster as your point of reference. Once the first chapter's been parsed shut down the mkvinfo process. That way you're relatively sure you actually have the minimum timestamp (instead of the first one which might not be the minimum) and you don't have to scan the whole file.

[Z-95]

Yea, I wouldn't want to use the first frame/simpleblock's timecode in case others are earlier; currently I pull the cluster timecode (the level 2 one) and treat that as the offset to pass to --sync and don't look inside the cluster's blocks. I rarely run into having to use it since it only happens with discs where 3+ episodes are all in one large M2TS but still check files for it for sanity.

I hadn't thought about killing the mkvinfo process once it spits out the first cluster timecode--that should work as long as the kill actually terminates relatively immediately (which depends on the language and OS I suppose--Java docs say it may remain alive after destruction for a short while for instance). Will have to test--even short waits is better than nothing.

Thanks for the idea!

[Mosu]

Here we go, MKVToolNix v9.3.0. It implements several enhancements requested by users, and of course it contains the usual list of bug fixes. Nothing major, mind you. But see below.

Dear package maintainers: please note that MKVToolNix v9.3.0 requires the recently released libEBML v1.3.4 and libMatroska v1.4.5.

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

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's the full ChangeLog since v9.2.0:

2016-07-13 Moritz Bunkus <moritz@bunkus.org>
* Released v9.3.0 "Second Sight".

2016-07-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, MKVToolNix GUI: new chapter generation feature: two new placeholders have been introduced when generating chapters for appended files, <FILE_NAME> and <FILE_NAME_WITH_EXT>. The former will be replaced by the appended file's name without its extension; the latter with its extension. Implements #1737 (https://github.com/mbunkus/mkvtoolnix/issues/1737).
* MKVToolNix GUI: merge tool enhancement: when opening a saved configuration (via the menu as well as via drag & drop) the current tab will be replaced if it is empty ( = in the same state it is in right after creating new mux settings). Implements #1738 (https://github.com/mbunkus/mkvtoolnix/issues/1738).
* mkvmerge, MKVToolNix GUI: added an option for specifying how much of a MPEG PS or TS file is probed for tracks (--probe-range-percentage). Implements #1734 (https://github.com/mbunkus/mkvtoolnix/issues/1734).

2016-07-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: MPEG TS: considerable parts of the module have been rewritten. Due to its convoluted structure didn't buffer PES packets properly before trying to parse the PES header leading to invalid memory accesses in certain cases.

2016-07-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed overly long file type detection in some cases when text subtitle type probing read a lot of data due to there being no carriage returns near the start of the file.
* mkvmerge, mkvextract, MKVToolNix GUI: bug fix: several fixes to the handling of country codes. The list has been updated to reflect the currently valid top level domain country codes. Deprecated codes such as "gb" for "Great Britain" are now mapped to their updated values ("uk" for "United Kingdom" in this case). Fixes #1731 (https://github.com/mbunkus/mkvtoolnix/issues/1731).
* mkvmerge: WavPack4 bug fix: relaxed the stream detection criteria to only require the major version to be 4 and not to check the minor version. Fixes #1720 (https://github.com/mbunkus/mkvtoolnix/issues/1720).

2016-07-02 Chao Chen <tochenchao@gmail.com>
* mkvmerge, mkvinfo: new feature: added flags to support the Colour elements in the video tracks of Matroska containers. Users can use those flags to specify the colour space, transfer function, chromaticity coordinates etc. These properties are useful for correct colour reproduction of high dynamic range / wide colour gamut videos.

2016-07-02 Moritz Bunkus <moritz@bunkus.org>
* configure: fixed the Qt detection with Qt 5.7.0 which now requires the compiler to be in C++11 mode.
* build system: libEBML v1.3.4 and libMatroska v1.4.5 are now required due to the usage of new elements introduced in libMatroska v1.4.5. The copies included in the MKVToolNix source code have been updated to those releases as well.

2016-06-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: MP4 bug fix wrt. DTS handling: mkvmerge will re-derive parameters such as number of channels and sampling frequency from the DTS bitstream circumventing invalid values in the track headers (e.g. a channel count of 0). Fixes #1727 (https://github.com/mbunkus/mkvtoolnix/issues/1727)/1728.

2016-06-27 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: TrueHD bug fix: fixed detection of 96 kHz sampling frequency.

2016-06-24 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo's GUI: fix a crash due to wrong usage of referenced temporary objects. Fixes #1725 (https://github.com/mbunkus/mkvtoolnix/issues/1725).

2016-06-05 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: the default track languages to set can now also be set whenever the language in the source file is 'undefined' ('und'). This is now the default and can be changed back to the old behavior (only set if the source file doesn't contain a language attribute) in the preferences. Implements #1697 (https://github.com/mbunkus/mkvtoolnix/issues/1697).

2016-06-04 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: menus have been added to both the "start muxing" and the "add to job queue" buttons. The menus let the user override the preferences regarding clearing merge settings after starting to mux and after adding a job to the queue respectively. Implements #1696 (https://github.com/mbunkus/mkvtoolnix/issues/1696).
* mkvmerge: the warning about not being able to determine whether a raw AAC file contains HE-AAC/AAC+/SBR has been removed. Implements #1701 (https://github.com/mbunkus/mkvtoolnix/issues/1701).
* MKVToolNix GUI: enhancement: all file names are now displayed with their native path separators (e.g. "C:\some\where\output.mkv" on Windows). Implements #1298 (https://github.com/mbunkus/mkvtoolnix/issues/1298), #1456 (https://github.com/mbunkus/mkvtoolnix/issues/1456).
* MKVToolNix GUI: merge tool bug fix: the GUI now takes into account whether splitting is activated when looking for and warning due to existing destination files. Fixes #1694 (https://github.com/mbunkus/mkvtoolnix/issues/1694).
* mkvmerge: bug fix: the parser for the --default-duration argument was wrongfully handling arguments of the form "123/456i" (only this specific syntax and only with "i" as the unit; other formats and units were fine). This is part of #1673 (https://github.com/mbunkus/mkvtoolnix/issues/1673). Additionally the parser doesn't use the "double" data type internally anymore fixing loss of precision and failing test cases on certain 32bit platforms. This fixes #1705 (https://github.com/mbunkus/mkvtoolnix/issues/1705).

Have fun :)

[Perenista]

Now I can't append files that were split into multiple parts. It's always returning the "probe percentage" error.

Tested with the 9.3.0 version.

P.S. Tested with old version, and this is not happening. It's exclusive from 9.3.0..

[Mosu]

What "probe percentage" error are you talking about (post a screenshot, please)?

[Jamaika]

I'm sorry that I butting. This is a simple recompile MKV. File names must be in English because otherwise no export.

[me7]

Same problem here. The Error message says: The probe range percentage '3.71878e-316' is invalid.

[mbcd]

What "probe percentage" error are you talking about (post a screenshot, please)?

Hi Mosu,

getting the same problem, muxing failes with every file:

Der Prozentsatz der zu untersuchenden Daten »4.03371e-316« ist ungültig.

I am using the 64bit Version for Windows (Installation)
Value in Settings is at 0,3, tried to exchange the comma to a decinal point, but the GUI is not accepting it in this field.
It doesnt matter what value I input there, the errorvalue (4.03371e-316) is always the same, looks like some limit or wrong formatconversation.

And again:
Thanks for your continouing hard work !!!!!

[Mosu]

I hate floating point numbers :(

As a workaround you can try opening the preferences, go to "merge", set "probe range percentage" to e.g. 0.4 (which is different from the default value of 0.3) and close it again.

Edit: changed the proposed value to try to 0.4.

[Mosu]

I'm sorry that I butting. This is a simple recompile MKV. File names must be in English because otherwise no import.

I don't really understand what you're trying to say. Do you mean that when you try to add a file to MKVToolNix GUI it fails if the file's name contains any non-ASCII character? If so I cannot reproduce that here. I've tried characters like German Umlauts (ä ö ü ß etc.), guillemets (» «) and others. In all cases both adding the file as well as muxing it works fine.

[me7]

For me, the input only accepts the European ',' comma. Can you tell me where the settings file is stored? I'd like to try to edit it manually.

[me7]

I just had a breakthrough setting it to '2,0'

[Mosu]

@mbcd & @me7:

At the moment I cannot reproduce triggering the issue, though I have a pretty good understanding what the problem is. I'd just like to have a way to reproduce it so that I can actually test any fix I'm going to implement for this.

If you haven't entered the preferences dialog yet, can you please send me your mkvtoolnix-gui.ini file to moritz@bunkus.org? See here (https://github.com/mbunkus/mkvtoolnix/wiki/Location-of-settings-and-the-job-queue) where it's stored.

Can you please also tell me if this is a stored config you've loaded, if it's a job that has already been sitting in the queue from before the upgrade, or if this is a new configuration you've created with 9.3.0? Thanks.

Value in Settings is at 0,3, tried to exchange the comma to a decinal point, but the GUI is not accepting in in this field.

That's to be expected as Qt (the GUI library I'm using) is using the OS's locale setting for displaying the decimal point. Internally the GUI and both are both only using the "." regardless of the locale. This is definitely not an issue; the issue is that somehow a very, very small floating point number that is not exactly 0.0 is finding its way into the GUI's processing. This shouldn't happen; if the value isn't present in the stored settings then the default 0.3 should be used. However, it obviously does happen.

Thanks for your continouing hard work !!!!!

You're welcome :)

[Mosu]

For me, the input only accepts the European ',' comma. Can you tell me where the settings file is stored? I'd like to try to edit it manually.

Like I said in my other post: the comma is definitely not a problem. I'm running the GUI on a German Windows here, too, and for me the GUI's control uses a comma, too, but mkvmerge is still being called with the point as the decimal point instead of the comma. It's definitely something else. Please don't focus on the comma being present there. Thanks.

[Jamaika]

I've tried characters like German Umlauts (ä ö ü ß etc.), guillemets (» «) and others. In all cases both adding the file as well as muxing it works fine.
I have a letter "ó" in polish and don't want to export a. I had to replace the name on 111.mkv

[Mosu]

Sorry, Jamaika, but I still don't get it. I've just named a file "rękopiśmiennych.avi" and muxed it successfully to "główną rolę w rozwoju książki.mkv". No, I don't understand those words, I just copy them from Wikipedia, but my point is: I cannot reproduce a problem with non-ASCII (non-English) characters here. And your English doesn't seem to be good enough to explain clearly what you perceive to be the problem.

[Jamaika]

Sorry, but there are some exceptions and I can't clarify. "Wybór.mkv". It's worry the others.

[Mosu]

Same problem here. The Error message says: The probe range percentage '3.71878e-316' is invalid.

Alright, I can finally reproduce this :) Will be fixed.

[Mosu]

I've fixed the issue causing the probe range percentage errors and uploaded new pre-builds for Windows (https://mkvtoolnix.download/windows/pre/). I'd appreciate some testing, and if the feedback is positive I'll release v9.3.1 ASAP.

Thanks for the quick feedback so far! I highly appreciate it.

[MGarret]

Just tried new 32bit pre-build and it works as it should. I tested 9.3.0 just few minutes ago and it failed on many files. Thanks for the quick fix :)

[mbcd]

I've fixed the issue causing the probe range percentage errors and uploaded new pre-builds for Windows (https://mkvtoolnix.download/windows/pre/). I'd appreciate some testing, and if the feedback is positive I'll release v9.3.1 ASAP.

Thanks for the quick feedback so far! I highly appreciate it.

"Made in Germany" - Quality ... your fix works like a charm. :thanks:
I deleted my old config-file and now it works with the standard "0.3" -value.

We have to appreciate your hard work, you spend a lot of your lifetime for us ... for free ... thanks again Mosu !

[Ripman]

Issue:
If I mux an mkv file with a DTS-HD MA audio track @ 192KHz, the resultant DTS-HD MA audio track has a sample rate @ 48KHz. v9.3.0/win8.1.

Process:
1. Used MakeMkv 1.9.10 to rip a blu ray audio disc that contains a DTS-HD MA 5.1 audio track sampled at 192KHz.
2. Used Mkvtoolnix 9.3.0 to mux. Mkvtoolnix shows the DTS-HD MA 5.1 audio track as 192KHz. (Included files: screen shot of audio track showing sample rate, options-log files.)
3. Used Mkvtoolnix 9.3.0 to open the muxed file. DTS-HD MA 5.1 audio track now at 48KHz. (Included files: screen shot of muxed audio track.)

I tried creating a sample that could be uploaded, but the split doesn't work (same reason as described above). What tool can I use to cut a sample (if needed)?

pre-mux: dts-hd ma 5.1@192khz
https://www.dropbox.com/s/7g24fznde9ms8m6/02%20mkvtoolnix%209.3.0%2C%20DTS-HD%20MA%20%40%20192khz.jpg?dl=0

post-mux: dts-hd ma 5.1@48khz
https://www.dropbox.com/s/yfe2y01obwuxpou/04%20mkvtoolnix%209.3.0%2C%20DTS-HD%20MA%20%40%2048khz.jpg?dl=0

I'll add this to the GitHub in a week or so if someone else cannot confirm. Thanks for the new version too.


options

--ui-language
en
--output
C\c\\1\\Part_II_t00_30secs.mkv
--language
0\ceng
--compression
0\cnone
--language
1\ceng
--track-name
1\cSurround\s5.1
--default-track
1\cyes
--compression
1\cnone
--language
2\ceng
--track-name
2\cSurround\s5.1
--compression
2\cnone
--language
3\cmis
--track-name
3\cSurround\s5.1
--compression
3\cnone
--language
4\cmis
--track-name
4\cSurround\s5.1
--compression
4\cnone
--language
5\cmis
--track-name
5\cSurround\s7.1
--compression
5\cnone
--language
6\cmis
--track-name
6\cSurround\s5.1
--compression
6\cnone
--language
7\cmis
--track-name
7\cStereo
--compression
7\cnone
(
C\c\\1\\Part_II_t00.mkv
)
--split
timecodes\c30s
--title
Part_II
--track-order
0\c0,0\c1,0\c2,0\c3,0\c4,0\c5,0\c6,0\c7


log

--- Output of job 'merging to file "Part_II_t00_30secs.mkv" in directory "C:/1"' started on 2016-07-13 21:41:10 ---
mkvmerge v9.3.0 ('Second Sight') 64bit
'C:\1\Part_II_t00.mkv': Using the demultiplexer for the format 'Matroska'.
'C:\1\Part_II_t00.mkv' track 0: Using the output module for the format 'AVC/h.264'.
'C:\1\Part_II_t00.mkv' track 1: Using the output module for the format 'DTS'.
'C:\1\Part_II_t00.mkv' track 2: Using the output module for the format 'DTS'.
'C:\1\Part_II_t00.mkv' track 3: Using the output module for the format 'DTS'.
'C:\1\Part_II_t00.mkv' track 4: Using the output module for the format 'DTS'.
'C:\1\Part_II_t00.mkv' track 5: Using the output module for the format 'DTS'.
'C:\1\Part_II_t00.mkv' track 6: Using the output module for the format 'DTS'.
'C:\1\Part_II_t00.mkv' track 7: Using the output module for the format 'PCM'.
The file 'C:\1\Part_II_t00_30secs-001.mkv' has been opened for writing.
The cue entries (the index) are being written...
The file 'C:\1\Part_II_t00_30secs-002.mkv' has been opened for writing.
The cue entries (the index) are being written...
Muxing took 7 minutes 45 seconds.

[Sparktank]

I've fixed the issue causing the probe range percentage errors and uploaded new pre-builds for Windows (https://mkvtoolnix.download/windows/pre/).

I have a remuxed clip from my Interstellar Bluray stored for testing various things.
It was remuxed using: mkvmerge v8.9.0 ('Father Daughter') 64bit

The pre-build works whereas the official build fails for probe.

using: mkvtoolnix-64bit-9.3.0-build20160713-01262-0b20466

Thanks for the pre-build fix. :goodpost:

[Mosu]

Thanks for the feedback. A new release with the fix included will be out later today.

[Mosu]

Issue:
If I mux an mkv file with a DTS-HD MA audio track @ 192KHz, the resultant DTS-HD MA audio track has a sample rate @ 48KHz. v9.3.0/win8.1.

Thanks for the report; so far I'm not aware of such an issue.

Please do create an issue on Github for and, and please upload a sample DTS file to my FTP server. You can create one with MakeMKV and split the resulting MKV with e.g. WinSplit — it shouldn't matter that the resulting file is missing certain Matroska structures; the important ones (segment header, track headers) should all be at the beginning.

[Mosu]

"Nothing major, mind you" I said. Maybe I shouldn't have ;)

Yesterday's release v9.3.0 contains a rather nasty one causing a lot of errors from mkvmerge about an "invalid probe range percentage". As this affects everyone I've fixed the issue and am now releasing v9.3.1.

Apart from that fix it's the same as v9.3.0. It implements several enhancements requested by users, and of course it contains the usual list of bug fixes. Nothing major, mind you. But see below.

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

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's the full ChangeLog since v9.2.0:

2016-07-14 Moritz Bunkus <moritz@bunkus.org>
* Released v9.3.1 "Mask Machine".

2016-07-13 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool bug fix: the GUI v9.3.0 was often creating an invalid syntax for the --probe-range-percentage parameter for mkvmerge due to uninitialized memory. Fixes #1741 (https://github.com/mbunkus/mkvtoolnix/issues/1741).
* Released v9.3.0 "Second Sight".

2016-07-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, MKVToolNix GUI: new chapter generation feature: two new placeholders have been introduced when generating chapters for appended files, <FILE_NAME> and <FILE_NAME_WITH_EXT>. The former will be replaced by the appended file's name without its extension; the latter with its extension. Implements #1737 (https://github.com/mbunkus/mkvtoolnix/issues/1737).
* MKVToolNix GUI: merge tool enhancement: when opening a saved configuration (via the menu as well as via drag & drop) the current tab will be replaced if it is empty ( = in the same state it is in right after creating new mux settings). Implements #1738 (https://github.com/mbunkus/mkvtoolnix/issues/1738).
* mkvmerge, MKVToolNix GUI: added an option for specifying how much of a MPEG PS or TS file is probed for tracks (--probe-range-percentage). Implements #1734 (https://github.com/mbunkus/mkvtoolnix/issues/1734).

2016-07-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: MPEG TS: considerable parts of the module have been rewritten. Due to its convoluted structure didn't buffer PES packets properly before trying to parse the PES header leading to invalid memory accesses in certain cases.

2016-07-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed overly long file type detection in some cases when text subtitle type probing read a lot of data due to there being no carriage returns near the start of the file.
* mkvmerge, mkvextract, MKVToolNix GUI: bug fix: several fixes to the handling of country codes. The list has been updated to reflect the currently valid top level domain country codes. Deprecated codes such as "gb" for "Great Britain" are now mapped to their updated values ("uk" for "United Kingdom" in this case). Fixes #1731 (https://github.com/mbunkus/mkvtoolnix/issues/1731).
* mkvmerge: WavPack4 bug fix: relaxed the stream detection criteria to only require the major version to be 4 and not to check the minor version. Fixes #1720 (https://github.com/mbunkus/mkvtoolnix/issues/1720).

2016-07-02 Chao Chen <tochenchao@gmail.com>
* mkvmerge, mkvinfo: new feature: added flags to support the Colour elements in the video tracks of Matroska containers. Users can use those flags to specify the colour space, transfer function, chromaticity coordinates etc. These properties are useful for correct colour reproduction of high dynamic range / wide colour gamut videos.

2016-07-02 Moritz Bunkus <moritz@bunkus.org>
* configure: fixed the Qt detection with Qt 5.7.0 which now requires the compiler to be in C++11 mode.
* build system: libEBML v1.3.4 and libMatroska v1.4.5 are now required due to the usage of new elements introduced in libMatroska v1.4.5. The copies included in the MKVToolNix source code have been updated to those releases as well.

2016-06-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: MP4 bug fix wrt. DTS handling: mkvmerge will re-derive parameters such as number of channels and sampling frequency from the DTS bitstream circumventing invalid values in the track headers (e.g. a channel count of 0). Fixes #1727 (https://github.com/mbunkus/mkvtoolnix/issues/1727)/1728.

2016-06-27 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: TrueHD bug fix: fixed detection of 96 kHz sampling frequency.

2016-06-24 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo's GUI: fix a crash due to wrong usage of referenced temporary objects. Fixes #1725 (https://github.com/mbunkus/mkvtoolnix/issues/1725).

2016-06-05 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: the default track languages to set can now also be set whenever the language in the source file is 'undefined' ('und'). This is now the default and can be changed back to the old behavior (only set if the source file doesn't contain a language attribute) in the preferences. Implements #1697 (https://github.com/mbunkus/mkvtoolnix/issues/1697).

2016-06-04 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: menus have been added to both the "start muxing" and the "add to job queue" buttons. The menus let the user override the preferences regarding clearing merge settings after starting to mux and after adding a job to the queue respectively. Implements #1696 (https://github.com/mbunkus/mkvtoolnix/issues/1696).
* mkvmerge: the warning about not being able to determine whether a raw AAC file contains HE-AAC/AAC+/SBR has been removed. Implements #1701 (https://github.com/mbunkus/mkvtoolnix/issues/1701).
* MKVToolNix GUI: enhancement: all file names are now displayed with their native path separators (e.g. "C:\some\where\output.mkv" on Windows). Implements #1298 (https://github.com/mbunkus/mkvtoolnix/issues/1298), #1456 (https://github.com/mbunkus/mkvtoolnix/issues/1456).
* MKVToolNix GUI: merge tool bug fix: the GUI now takes into account whether splitting is activated when looking for and warning due to existing destination files. Fixes #1694 (https://github.com/mbunkus/mkvtoolnix/issues/1694).
* mkvmerge: bug fix: the parser for the --default-duration argument was wrongfully handling arguments of the form "123/456i" (only this specific syntax and only with "i" as the unit; other formats and units were fine). This is part of #1673 (https://github.com/mbunkus/mkvtoolnix/issues/1673). Additionally the parser doesn't use the "double" data type internally anymore fixing loss of precision and failing test cases on certain 32bit platforms. This fixes #1705 (https://github.com/mbunkus/mkvtoolnix/issues/1705).

Have fun :)

[filler56789]

Released v9.3.1 "Mask Machine"

Thanks :thanks:

[Mosu]

Nothing like releasing a new version while eating breakfast ;) Now I have to hurry to work. Have fun with it, and here's to hoping nothing else rears its ugly head.

[Ripman]

Thanks for the report; so far I'm not aware of such an issue.

Please do create an issue on Github for and, and please upload a sample DTS file to my FTP server. You can create one with MakeMKV and split the resulting MKV with e.g. WinSplit — it shouldn't matter that the resulting file is missing certain Matroska structures; the important ones (segment header, track headers) should all be at the beginning.

I'm having a tough time splitting the source mkv so I can upload a sample. I tried using ffmpeg 2.2.2, and the split works, but the DTS-HD MA track also comes out at 48khz. Since ffmpeg yields a similar "issue," I'm inclined to believe that the source out of MakeMKV is problematic even as it shows as 192khz.

Either way, the first step is generating a sample, so I'm still working on that.

[hello_hello]

Thanks for the updates.

There's one very minor thing, and maybe it's just my brain nitpicking and everyone else will think I'm mental, but there's a couple of right click menu items that slow me down because my brain always does a double-take.
Every time I right click on an input file in the Merge pane to remove it, my brain initially ignores the "Remove files" option until it's checked the menu for "Remove file", and then double-checked the input files to ensure I only have one selected. Could the remove option be singular all the time, or singular when right clicking on a single item and plural for multiple items? Would it be better if it was simply "Remove"? I'm in the Merge pane and clicking on an input file, so I'm pretty much expecting to remove an input file.

In my defence, the old GUI had a button for removing input files instead of a right click menu and it was labelled "Remove", not "Remove File" or "Remove Files". I think it's the button labelling convention causing the right click menu to confuse my brain.

My brain usually does a similar double-take when it has to use "Remove jobs" to remove a single job from the queue. I'm certain I know when I'm only removing one job until the GUI confuses me. ;)

In closing, I'd like to point out the right click option in the Job queue labelled
"Edit in corresponding tool and remove from queue"
isn't called
"Edit jobs in corresponding tool and remove from job queue".

Thanks.

[hello_hello]

I don't switch to the Job Queue pane very much. I create a muxing job, start it, then while it's running I work on the next job and click start so it automatically runs when the first one finishes, and so on.... and from that perspective a little more control over jobs from the Merge pane would be nice. I can add jobs to the queue, start them automatically, but not stop them or stop the job queue etc.

So I thought.... the section down the bottom of the Merge pane where currently some information about running jobs is displayed.... to me it's crying out to function as a kind of "minimised" version of the Job Queue pane, and it's a fair way toward that already, but.....

It displays the progress of the current running job without telling you what it is. Would it be hard to display the name of the currently running job just above where the statistics and progress are displayed? From there you could add a Stop button to stop the currently running job (because now you know what it is) and also an Abort button to stop the whole job queue. Then you'd have all the basic job queue control at the bottom of the Merge pane and switching to the Job Queue pane would only be needed for more "refined" editing of the job queue.
What if the right click "show job queue" menu item opened a sub menu showing you the names of the jobs in the queue instead of just switching you to the Job Queue pane? Maybe you could delete jobs in the queue that way or change their status etc, all from the Merge pane?

One last thought.... the drop down arrows next to the "start muxing" and "add job to queue" buttons are a nice addition.... thanks.... but the arrows are such a tiny little target. Would it be possible to also open the same menu items by right clicking on the buttons, or maybe by holding down the Shift key while clicking on the buttons, or something similar?

Thanks.

[Mosu]

Could the remove option be singular all the time, or singular when right clicking on a single item and plural for multiple items?

I'll look into changing the texts based on the number of items selected. I won't shorten those entries to a simple "remove", though. I actually did use "remove" once upon a time, but users (beta testers? Don't remember exactly) were sometimes confused. Therefore I opted to make the entries state explicitly what they'd operate on.

Contributing to the decision were the translators who had sometimes had problems with a simple "remove" (and similar actions, e.g. "add"). They wanted or even needed to translate those differently depending on what those actions would work on. Using the more explicit "remove tracks" solved that issue, too.

The GUI's not entirely consistent in this regard, though. You've already pointed out one example:

In closing, I'd like to point out the right click option in the Job queue labelled "Edit in corresponding tool and remove from queue" isn't called "Edit jobs in corresponding tool and remove from job queue".

In this particular case I opted for skipping "job" as the entry was very long already.

That being said there are probably still entries that aren't consistent with the ideas mentioned above. "Open in MediaInfo" is one such example; it's used in both the file's and the track's popup menu.

[Mosu]

So I thought.... the section down the bottom of the Merge pane where currently some information about running jobs is displayed.... to me it's crying out to function as a kind of "minimised" version of the Job Queue pane

I'm sorry, but that's not a direction I want to take the GUI in.

[Boulder]

I have some Matroska files with srt subtitles that have problems with the Scandinavic characters. If I've understood correctly, this is because the character set has been set incorrectly when muxing. If I demux the subtitle track and open it in Notepad++, it detects the files as UTF-8 encoded.

Is there a way to remux or fix the Matroska files in some automated way or will I need to demux and then open the subtitle file in Notepad++, copy-paste the contents to a new file and then tell mkvmerge to expect UTF-8 encoded files?

[agressiv]

trying to compile 9.3.1 on arch linux (multiple systems) - all get the same errors:

/usr/bin/ld: cannot find -lmagic
/usr/bin/ld: cannot find -lmatroska
/usr/bin/ld: cannot find -lebml


libmatroska 1.4.5-1,libebml 1.3.4-1, and file 5.28-1 are installed but I don't really know how to troubleshoot the rest. Any tips on pointing me in the right direction?

[Mosu]

Huh… For what it's worth it works fine on my Arch (my primary development system is actually Arch Linux); I just compiled it successfully.

Maybe run ldconfig, make sure that the libraries are actually present in /usr/lib and that the symlinks are correct. If in doubt paste the output of "ls -l /usr/lib/lib{magic,ebml,matroska}*" and attach config.log to your post.

[Mosu]

Is there a way to remux or fix the Matroska files in some automated way or will I need to demux and then open the subtitle file in Notepad++, copy-paste the contents to a new file and then tell mkvmerge to expect UTF-8 encoded files?

If they've all been broken in the same way (e.g. encoded from non-UTF-8 to UTF-8 twice) then it is possible to fix that automatically with a hearty dose of mkvextract (for extracting the affected tracks), iconv (for converting from UTF-8 to the other character set once), mkvmerge (for putting the original file and the modified subtitle track together again) and Perl scripting (or any other scripting language; for automating the whole process for any given number of files).

If you want to go down that road you should probably look at mkvmerge's JSON identification mode (e.g. "mkvmerge --identification-format json --identify source.mkv"). The output is trivial to use in any scripting language for which JSON modules are available, and it can be used to easily determine which tracks are actually text subtitle tracks.

However, if you're looking for a turnkey solution to such a particular problem then I don't know of any. The individual tools are all there, though, and the fact that all of them can be automated with nothing more than freely available scripting (or other programming) languages is one of the greatest strengths of such tools: you can make them do way more than their authors ever thought of themselves.

[Boulder]

It seems that the troublesome files are muxed with mkvmerge v8.6.1. At one point, I had to recover all my encoded files from my DVD archives, demux them (to encode the FLAC audio tracks to Opus to save space on my server) and batch mux them again. V8.6.1 was the latest mkvmerge version at that time. The archived version does not have the problem.

I'll take a look at your suggestion, thanks. I do some stuff with scripts so maybe I'll get things working at least semi-automatically.

[Mosu]

The character set handling hasn't really changed over the last year, it's almost the same in 8.6.1 and 9.3.1. Therefore I guess that either your sources were different (e.g. one set of sources did use BOMs while another didn't) or you used different settings in each case.

That being said, there's one particular bug fix that stands out and that might apply to your situation and explain what you're experiencing (though you haven't given enough details to know for sure). Citing the ChangeLog:

2016-03-09 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: bug fix: the --sub-charset option is now ignored for
text subtitle files that start with a byte-order mark (BOM)
bringing the behavior in line with the documentation. Fixes #1620.

[Mosu]

…demux them … and batch mux them again

Just to point this out once more. You don't have and most likely never should demux all tracks if you're aiming to put them into Matroska later anyway. Valueable meta information is almost lost that way (e.g. timestamps, tags, track names, track language etc. etc.). Always only demux those tracks that you intend to re-encode, not the others.

Additionally the risk of the content being modified in undesired ways (such as your encoding issue) as there's no character set conversion involved at all when you mux from Matroska to Matroska.

[Boulder]

Just to point this out once more. You don't have and most likely never should demux all tracks if you're aiming to put them into Matroska later anyway. Valueable meta information is almost lost that way (e.g. timestamps, tags, track names, track language etc. etc.). Always only demux those tracks that you intend to re-encode, not the others.

Additionally the risk of the content being modified in undesired ways (such as your encoding issue) as there's no character set conversion involved at all when you mux from Matroska to Matroska.Thanks, I'll keep that in mind in the future (but hopefully never ever have to recover everything again) :)

I think I demuxed all tracks because the order is not always the same, or there are PGS subs or SRT subs etc. I probably couldn't find a decent way to automate things so I went the easiest way.

One thing about those character sets. I recall that you changed some default behaviour related to that at some point, not so long ago, but reverted the change later. Do you happen to remember if that could have anything to do with the problem?

EDIT: Found the thing. The change was made in v8.6.0, then reverted back in v8.7.0. It affected all text files output by the tools, which probably caused my issue. I just happened to have bad luck there to use one of those versions with the change.

[Mosu]

Thanks, I'll keep that in mind in the future (but hopefully never ever have to recover everything again) :)

:)

I think I demuxed all tracks because the order is not always the same, or there are PGS subs or SRT subs etc. I probably couldn't find a decent way to automate things so I went the easiest way.

Again, take a look at mkvmerge's JSON identification mode. Combined with any kind of scripting language this makes it nearly trivial to write scripts that do things only on specific tracks or track types or even only for specific CodecIDs — no matter how many there are or what their IDs are.

One thing about those character sets. I recall that you changed some default behaviour related to that at some point, not so long ago, but reverted the change later. Do you happen to remember if that could have anything to do with the problem?

Ah that particular change. Indeed: in release 8.6.0 I changed mkvextract to NOT write a BOM for UTF-8 encoded files. The result was not that great on Windows as mkvmerge on Windows defaults to the system's local character set if none is given and no BOM is present. This meant that a roundtrip from Matroska → mkvextract → SRT → mkvmerge → Matroska required that the user specify UTF-8 as the file's character set (whereas mkvmerge would auto-detect it due to the BOM before the change).

I reverted that change with release 8.7.0, so in 8.6.1 the change was still present and may very well explain the symptoms you've described.

[agressiv]

[agressiv@alienware mkvtoolnix]$ ls -l /usr/lib/lib{magic,ebml,matroska}*
lrwxrwxrwx 1 root root 16 Jul 23 02:55 /usr/lib/libebml.so -> libebml.so.4.0.0
lrwxrwxrwx 1 root root 16 Jul 23 02:55 /usr/lib/libebml.so.4 -> libebml.so.4.0.0
-rwxr-xr-x 1 root root 150872 Jul 23 02:55 /usr/lib/libebml.so.4.0.0
lrwxrwxrwx 1 root root 17 Jun 17 19:55 /usr/lib/libmagic.so -> libmagic.so.1.0.0
lrwxrwxrwx 1 root root 17 Jun 17 19:55 /usr/lib/libmagic.so.1 -> libmagic.so.1.0.0
-rwxr-xr-x 1 root root 138392 Jun 17 19:55 /usr/lib/libmagic.so.1.0.0
lrwxrwxrwx 1 root root 20 Jul 23 03:00 /usr/lib/libmatroska.so -> libmatroska.so.6.0.0
lrwxrwxrwx 1 root root 20 Jul 23 03:00 /usr/lib/libmatroska.so.6 -> libmatroska.so.6.0.0
-rwxr-xr-x 1 root root 758832 Jul 23 03:00 /usr/lib/libmatroska.so.6.0.0


Edit: Getting it on a fresh install of Arch. Hopefully I'm just stupid.

[Mosu]

You should really not use --enable-static during compilation. I don't support it outside of compilation for Windows with MXE.

[agressiv]

Thanks, that was it. It compiled just fine when I removed the static binary setting.

I had 4 other arch systems to copy the binary too so I was just going to do that rather than compile it 5 times. I figured eventually the AUR package would be updated.

[Mosu]

Ah, I see that the Arch packages haven't been updated yet.

In such a case I usually download the corresponding build files (https://www.archlinux.org/packages/extra/x86_64/mkvtoolnix-cli/) (click on the "source files" link on the upper right), adjust the version & checksum, run makepkg on them and copy the generated packages over to the other machines.

[meridius75]

Hi all

Wanted to ask a question as I have been using MKV tool Nix for couple of years and now find that it introduces video errors into the picture when creating a new mkv.

I find this strange since I thought MKVToolNix did not alter the picture ?

I Rip my movies with MakeMKV and then dump the video into MKVToolNix To edit and remove some parts of the video and edit names and when I come to play back some films not all there seems to be video corruption for a spilt second.

I tried the movie that was created with MakeMKV and its perfect but MKVToolNix creates errors in the video picture sometimes.

Now I have noticed this in a few versions and its took months to figure out why some of my videos have these corrupt errors in the video.

Some videos I did years ago and just watched now and see the same thing.

So I kept two files the MakeMKV file and the MKVToolNix file and when I seen the error I went back and redid the video with MKVToolNix since the MakeMKV file was fine and no errors in the same video using MKVToolNix, its just random and happens just sometimes.

Its random when this happens and I don't know why its doing it but its very annoying because I have to redo alot of videos because of this and I don't use MKVToolNix that often now because its not reliable but need to use it.

can anyone help me or can I help you sort this problem out or does anyone know or had the same problem


thanks

Hi all did some more testing and if I use makemkv I never get these errors. I have tried a few movies and never get any video image corruption but if I use mkvtoolnix its 50/50 if I get video error corruption.

has anyone been able to nail down what is causing this.

thanks

[jkauff]

Hey Mosu, were you affected by the FOSSHub attack? Did the attackers try to infect your stuff?

[Mosu]

To the best of my knowledge my binaries weren't infected (even though the attackers definitely had access to them). This is based on:

a comprehensive, internal report by the FossHub admins to the authors who host their software there,
tweeks and other information from the group responsible for the attack,
media reports about it and
the fact that I haven't had a single user report any kind of infection in or malicious behavior from my binaries.

I am affected only insofar as the account database containing the passwords was compromised as well, and therefore my FossHub password might be cracked. However, as I don't re-use passwords across sites or accounts I'm not particularly worried about it.

I plan to write a more comprehensive blog post about his over the weekend including more details about what I know and infer and ways for users to verify that their downloads of MKVToolNix are legit. But as my users don't seem to be in danger I've been pretty relaxed about the whole issue.

[Jamaika]

Hi Mosu.
I would like to ask about the append files?
What are the differences in the specifications the matroska for H264 and HEVC. When a merger of two different files h264, eg. yuv420p and yuv444p this all is well. Decoder MPC/Lav plays both.
When a merger of two different files HEVC, eg. yuv420p and yuv444p this sees only the parameters of the first part. Is this the correct operation?

[Mosu]

I'm sorry, but I don't understand what you mean with "this seens only the parameters of the open parts", and therefore I cannot really answer your question.

[Jamaika]

The film has only eg. you420p

[Mosu]

I still don't really understand your question.

Only the CodecPrivate data (and that's where the HevCC is stored) from the first file will be kept in the resulting file's CodecPrivate element. That's by design. However, if any of the stream parameters change (VPS, SPS, PPS) those new elements will be present as NALUs in the stream. That's also by design.

[Jamaika]

Can container matroska join films with different parameters compilation HEVC?
ex. at first yuv420p and then yuv444p.

[Mosu]

Maybe, partially. If you watch from start to finish it may work as the player will see the new VPS, PPS and SPS NALUs. However, if you start watching and seek to after that change it may not work anymore because the player's not aware new parameters are in effect.

Matroska itself has elements for dealing with changing CodecPrivate data (called "CodecState"), but mkvmerge doesn't use them (yet), and I don't know of a player that supports them either.

[Jamaika]

Maybe, partially. If you watch from start to finish it may work as the player will see the new VPS, PPS and SPS NALUs.
What does it mean? I see only yuv420p. I don't see yuv444p
http://i67.tinypic.com/8vpxk2.jpg

[Mosu]

Looks like it doesn't work *shrug*.

[Ripman]

I'm having a tough time splitting the source mkv so I can upload a sample. I tried using ffmpeg 2.2.2, and the split works, but the DTS-HD MA track also comes out at 48khz. Since ffmpeg yields a similar "issue," I'm inclined to believe that the source out of MakeMKV is problematic even as it shows as 192khz.

Either way, the first step is generating a sample, so I'm still working on that.

I used unix split to create a sample, and I uploaded it to dropbox.

sample (25mb - opens in MkvToolnix 9.3.1 as dts@192khz):
https://www.dropbox.com/s/lkmm7ddlqy972aw/DTSHD_sampling_issue_001.mkv?dl=1

I also opened an issue in GitHub. This is not an mkvtoolnix issue, as handbrake, ffpmpeg, tsmuxer exhibit the same issue. I am documenting the issue so that the information can be directed to the appropriate developers.

[Ripman]

I used unix split to create a sample, and I uploaded it to dropbox.

sample (25mb - opens in MkvToolnix 9.3.1 as dts@192khz):
https://www.dropbox.com/s/lkmm7ddlqy972aw/DTSHD_sampling_issue_001.mkv?dl=1

I also opened an issue in GitHub. This is not an mkvtoolnix issue, as handbrake, ffpmpeg, tsmuxer exhibit the same issue. I am documenting the issue so that the information can be directed to the appropriate developers.

I ran this BDA through MakeMKV 1.10.0 using the flac profile, and received flac "thread emulation" errors. This is usually indicative of issues in MakeMKV and I've posted the relevant information for them here:

http://www.makemkv.com/forum2/viewtopic.php?f=8&t=14739

[Ripman]

Question:
Will the matroska standard be extended to accommodate dsd/dsf audio formats?


Background:
The mka container is very convenient for digital music. I put my hi-Rez wav/flac downloads from HDtracks and others in mka containers.

I've been downloading some 2.8g & 5.6g sampled dsf files from hdt and Analogue Productions. I'm trying to understand if I'll be able to put these into mka containers - maybe sometime in the future if the standard is extended, which is what I'm asking.

[Mosu]

I've never heard of those two audio formats. To my knowledge no one has expressed the intent to work on adding them to Matroska either. So the answer seems to be "no" for the time being.

[mariush]

First time i've heard of them as well. Apparently some kind of SACD disc images or something like that: https://en.wikipedia.org/wiki/Direct_Stream_Digital

Don't see why someone couldn't just convert the files to FLAC with minimal perceptible (if any) loss of audio quality.

[filler56789]

.......
Don't see why someone couldn't just convert the files to FLAC with minimal perceptible (if any) loss of audio quality.

Placebo effect should explain it all :)

According to my memory banks, DSD files are MUCH bigger than their equivalent PCM files :scared:

[Mosu]

Back at the end of 2014 Mike from MakeMKV and I have been implementing support for the text subtitle format used on Blu-rays. Unfortunately I've never finished this — it still sits in my local git repository in a feature branch.

I'd like to finish this. However, I'd like to verify that MakeMKV and mkvmerge still produce the same output (regarding HDMV TextST subtitles) when they're given the same source material. Unfortunately I don't have a single Blu-ray that MakeMKV shows HDMV TextST subtitles for — and information online which discs might contain them is sparse to say the least.

I've bought three discs over the last couple of weeks which supposedly contain TextST subtitles. None did. The first two were German versions bought on Amazon.de whereas the third one was the US version of "The Scorpion King" on Amazon.com. No dice.

Soooooo… Can anyone point me to a Blu-ray he or she is absolutely, 100% positive contains TextST subtitles? With links to concrete products in a web shop? I'm definitely willing to buy them, I just have to find them.

Thanks :)

(All this has lead me to question whether it's worth it in the first place…)

[Overdrive80]

Hi, I detect one thing wrong, I expose my case. I have one matroska file with 2 episodes extracted from Bluray (original bluray has 2 m2ts but extracting using makemkv only can extract to one file) with its chapters, with this form:

https://s4.postimg.org/mfetvryot/Captura.png

If I choose split using time codes, 00:24:21.126333333, the result is split wrong, part of video 2 is in video 1 (I just know IDR Frames, but I dont refer to that, keep calm ^^).

https://s4.postimg.org/opal1nx4t/Captura2.png

If I calcule number frame with 00:24:21.126333333 like reference:

24000 x
-----=-----
1001 1461.126333333

x = round((24000 * 1461,126333333)/1001) = 35032

https://s4.postimg.org/3toaqf0xp/Captura3.png

Now I choose split using frame and work fine.

Thanks in advance

[Mosu]

@Overdrive80: What comes to mind is that M2TS files contain timestamps, and mkvmerge uses them. It's highly likely that the actual timestamp for the frame you're thinking about is not the one you've entered and is in fact smaller.

Note that there's no link between chapter timestamps and frame timestamps at all. They can be the same, they can differ slightly, they can be totally different.

[Ripman]

Placebo effect should explain it all :)

According to my memory banks, DSD files are MUCH bigger than their equivalent PCM files :scared:

The DSD format has been available on SACDs since the late 1990s.

Some use old PS3's on ofw 3.55 with a custom app to rip iso images of SACDs. A Foobar2000 add-in can then be used to generate dsf files or wav/flac files. I've never done this process.

Today, studios/producers make dsf files available.

http://store.acousticsounds.com/d/110038/Arthur_Fiedler-Gershwin_An_American_In_Paris__Rhapsody_In_Blue-DSD_Single_Rate_28MHz64fs_Download

For the example above, only dsf files are available. I converted the dsf files to 24/352 wavs. I'd rather skip the conversion step and maintenance of an encoded copy, and just use the source, hence my question.

This page contains free dsd/dsf samples. There are also many other types of samples too: 352, MQA, studio 24/96, etc.
http://www.2l.no/hires/

----------

Flac:
The flac approach needs consideration in this scenario because it would require maintaining a source copy and a flac encoded copy of the source. It's a different scenario than archiving CDs because there are no discs. My "disc" in this case is the source digital download - and I need to save my "disc" so I might as well use it too.

Flac is an excellent format that I use often. It's not so good at being a container, especially compared to mkv/mka. The gist of my posts lately should make it obvious why I am asking these very atypical questions about MKV.


Web link:
The link is probably a good read about frequency response and the human ear; these are facts of nature, of course.

Some of the titles I get just aren't available in other formats - like the AP example above. There isn't a Bach/Richter/Messe CD reissue - you live with the 1996 version, or grab the new 192khz version.

I enjoy the releases by 2L, and I believe these to be some if the finest modern recordings. I buy the 2L discs because I can literally move between the violins viola cello (viz., quartet) via DTS and Auro-3D audio tracks.

Sometimes, the higher bitrates and sample rates are the producers running the digital masters back through some custom/proprietary DA converter to create a different feel or sound or to "soften the digital edges."

Sometimes, the higher bitrates and sample rates are the producers reducing multi-channel audio to stereo. The increased sample rates help maintain a higher bitrate when going from multi-channel to stereo.

Anyway, it's not a binary approach.

[Snowknight26]

Soooooo… Can anyone point me to a Blu-ray he or she is absolutely, 100% positive contains TextST subtitles? With links to concrete products in a web shop? I'm definitely willing to buy them, I just have to find them.


The problem is, BDInfo doesn't detect TextST streams nor do any websites list the format of subtitles, so at this point you're essentially taking someone's word for it.

Having said that, a lot of Finnish and Norwegian Blu-rays use text subtitles.

With no proof to give you, these have them:
http://www.blu-ray.com/movies/Taalla-Pohjantahden-alla-Blu-ray/32715/
http://www.blu-ray.com/movies/Taalla-Pohjantahden-alla-II-Blu-ray/32716/
http://www.blu-ray.com/movies/Miekkailija-Blu-ray/147676/
http://www.blu-ray.com/movies/Katilo-Blu-ray/139954/
http://www.blu-ray.com/movies/Kekkonen-tulee-Blu-ray/90650/
http://www.blu-ray.com/movies/21-tapaa-pilata-avioliitto-Blu-ray/69926/

[Jamaika]

I downloaded subtitles TEXTS. Indeed ffmpeg it didn't convert, but some have coped.
Sub Edit reads and converts subtitles TEXTST.

[filler56789]

@Ripman:

yes, I already was aware of (almost) everything you wrote.
Many months ago, I gave a try to a program which could convert PCM to DSD and vice-versa, and I also played DSD sample files in foobar2000 through the SACD plugin.

Now, someone please correct me if I am wrong this time: on a PC, it's not possible a «direct playback» of a DSD stream — this latter must be first converted to something that the operating system and the (current) sound cards "understand" (i.o.w., PCM). You have a point about the convenience of the Matroska container though (namely: tagging, chapter points).

[Ripman]

@Ripman:
chapter points.

I think Moritz got a kick out of this one.
https://github.com/mbunkus/mkvtoolnix/issues/1760

[Chetwood]

Soooooo… Can anyone point me to a Blu-ray he or she is absolutely, 100% positive contains TextST subtitles?
I've uploaded some TextST subs I found on the web to your FTP, maybe that'll help.

[Mosu]

I've uploaded some TextST subs I found on the web to your FTP, maybe that'll help.

Thanks. I have those files already; I think they're from ffmpeg's or VLC's samples server (or linked to from a bug report for one of the projects). They don't really help me because MakeMKV cannot open them due to the .M2TS files not being present.

[Mosu]

Having said that, a lot of Finnish and Norwegian Blu-rays use text subtitles.

Thanks. I'll buy one or two of those.

[isidroco]

Recently I used MKVcleaver to demux a bunch of fullHD MKVs to AVI. It uses a faulty AVC2AVI converter which generates an incorrect 1920x1088 avi header. Bug reported here: https://sourceforge.net/p/avc2avi/bugs/
Issue was solved replacing AVC2AVI in MKVcleaver folder with this one: http://www.videohelp.com/software/avc2avi

It would be nice though that MKVmerge detect actual frame height instead of using header's, or at least report discrepancies so as to be aware.

Post this just in case someone else has same problems. Already reported it to MKVcleaver site.

[Chetwood]

Soooooo… Can anyone point me to a Blu-ray he or she is absolutely, 100% positive contains TextST subtitles? With links to concrete products in a web shop?
I've checked with a buddy of mine who's 100% sure the regular versions of 'The Mummy' and 'Van Helsing' containing TextST subs. He's not sure where he bought them, though. Apparently Blödmarkt or Saturn.

[Mosu]

Time for the next release of MKVToolNix. This time it's really just polishing of existing functionality.

Dear package maintainers: I have to say again that MKVToolNix v9.3.1 and later requires the recently released libEBML v1.3.4 and libMatroska v1.4.5. Even though both libraries are API and ABI compatible with their prior releases this only means that a program compiled against an older version of the library will still work when run against a newer version of the library.

However, MKVToolNix v9.3.1 and newer use features newly introduced in libMatroska v1.4.4. This means that you cannot compile MKVToolNix v1.4.5 and try to run it against v1.4.4 — that'll fail with symbol lookup errors from ld.

I've received multiple reports of MKVToolNix v9.3.x packages that could be installed with libMatroska v1.4.4. This won't work. Please make the dependency on v1.4.5+ explicit. Thanks.

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

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's the full ChangeLog (https://mkvtoolnix.download/doc/ChangeLog) since v9.3.1

2016-08-22 Moritz Bunkus <moritz@bunkus.org>
* Released v9.4.0 "Knurl".

2016-08-16 Moritz Bunkus <moritz@bunkus.org>
* mkvpropedit: bug fix: mkvpropedit will no longer say that it's writing the changes if only attachment changes are specified and none of the specified attachments can be found.

2016-08-11 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: chapter editor bug fix: overly long chapter names don't cause the GUI's window to become overly wide anymore. Fixes #1760 (https://github.com/mbunkus/mkvtoolnix/issues/1760).

2016-08-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: DTS bug fix: if present mkvmerge will use an XLL extension's sample rate information as the sample rate to put into the track headers. Fixes #1762 (https://github.com/mbunkus/mkvtoolnix/issues/1762).

2016-08-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: added support for reading Apple ProRes video from MOV/MP4 files. Patch by Chao Chen (see AUTHORS).

2016-08-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: when appending files mkvmerge wasn't starting clusters on video key frame anymore for the first and all following appended files. Fixes #1757 (https://github.com/mbunkus/mkvtoolnix/issues/1757).

2016-07-31 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: when adding attachments the GUI will check if there are attachments or attached files with the same name as the file to add. If so the GUI will tell the user and ask for confirmation.

2016-07-30 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: mkvmerge now accepts file names in square brackets for appending files, e.g. "mvkmerge -o out.mkv [ in1.avi in2.avi in3.avi ]" instead of "mkvmerge -o out.mkv in1.avi + in2.avi + in3.avi".

2016-07-29 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: VP8 in Ogg: fixed dropping the first frame and the timestamp calculation. Fixes #1754 (https://github.com/mbunkus/mkvtoolnix/issues/1754).
* mkvmerge: bug fix: mkvmerge does no longer emit a warning if no comment header packet is found when reading tracks from Ogg/OGM files. See #1754 (https://github.com/mbunkus/mkvtoolnix/issues/1754).

2016-07-19 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: the "select a play list to add" dialog does now contain a column with the number of chapters for each play list found.
* MKVToolNix GUI: job queue enhancement: dragging & dropping a valid .mtxcfg file (either a full job file or one containing only merge settings without the job properties) onto the job queue window will import the dropped .mtxcfg job into the job queue. Rest of the implementation of #1714 (https://github.com/mbunkus/mkvtoolnix/issues/1714).

2016-07-18 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: dragging & dropping a job queue .mtxcfg file onto the merge tool or using one as a command line parameter to the mkvtoolnix-gui executable will import the .mtxcfg job into the job queue. Part of the implementation of #1714 (https://github.com/mbunkus/mkvtoolnix/issues/1714).

2016-07-15 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool bug fix: the automatic adjustments to the output file name based on the track types selected for muxing and the mechanism for keeping output file names unique had been broken since release v9.3.0. Fixes #1743 (https://github.com/mbunkus/mkvtoolnix/issues/1743).
* MKVToolNix GUI: merge tool enhancement: toggling the WebM mode check box will update the output file name's extension automatically.

Have fun :)

[Mosu]

I've checked with a buddy of mine who's 100% sure the regular versions of 'The Mummy' and 'Van Helsing' containing TextST subs. He's not sure where he bought them, though. Apparently Blödmarkt or Saturn.

OMG. Yes, "The Mummy" does contain TextST subtitles, and MakeMKV shows them just fine. My problem was that I hadn't been aware that DVDFab doesn't support TextST subs. Thanks for pointing that out in a PM, Chetwood. And I usually rip the disc to hard disc with DVDFab first (using the "Blu-ray copy" mode) before I do anything else. Consequently MakeMKV doesn't show TextST subs when opening such a ripped image…

Unfortunately this doesn't help me all that much as MKVToolNix cannot read encrypted Blu-rays; therefore I have to rip first in order to have a comparable situation for both programs (MakeMKV & MKVToolNix). Does anyone know whether CloneBD keeps TextST when creating a 1:1 rip?

[Jamaika]

Dear package maintainers: I have to say again that MKVToolNix v9.3.1 and later requires the recently released libEBML v1.3.4 and libMatroska v1.4.5. Even though both libraries are API and ABI compatible with their prior releases this only means that a program compiled against an older version of the library will still work when run against a newer version of the library.

I'm not a package maintainers, but I have a question. I have a container matroska 1.4.4, which was joined with mp4 files. When converting track video H264 decreased a little size file. I would like once again to repack libMatroska (1.4.4) to libMatroska (1.4.5) that I will have bugs or rather not?:stupid:

[Mosu]

Why should there be bugs? Just do it and don't worry about the library version.

[qyot27]

OMG. Yes, "The Mummy" does contain TextST subtitles, and MakeMKV shows them just fine. My problem was that I hadn't been aware that DVDFab doesn't support TextST subs. Thanks for pointing that out in a PM, Chetwood. And I usually rip the disc to hard disc with DVDFab first (using the "Blu-ray copy" mode) before I do anything else. Consequently MakeMKV doesn't show TextST subs when opening such a ripped image…

Unfortunately this doesn't help me all that much as MKVToolNix cannot read encrypted Blu-rays; therefore I have to rip first in order to have a comparable situation for both programs (MakeMKV & MKVToolNix). Does anyone know whether CloneBD keeps TextST when creating a 1:1 rip?
Wouldn't MakeMKV's Backup mode be sufficient?

[Mosu]

Even if I sound like a broken record: I hadn't been aware… ;)

…that MakeMKV has such a feature. Thanks for the pointer. I don't rip Blu-rays all that often, to be honest. Giving it a try now.

[Mosu]

Yay! MakeMKV's backup mode produces exactly what I need. Now I can actually finish TextST support.

[Sparktank]

Great stuff!
Thanks for the update.

[Chetwood]

Even if I sound like a broken record: I hadn't been aware… ;)

…that MakeMKV has such a feature.
MMh, you could have used DVDFab's Passkey for decryption too. Anyway, glad it's worked out now. Still don't get why they used TextST instead of SRT though, or does it allow for positioning like SSA/ASS?

[nevcairiel]

Still don't get why they used TextST instead of SRT though, or does it allow for positioning like SSA/ASS?

They would never use a format thats not standardized and specified properly, which SRT isn't.

[Jamaika]

I understand that the TextST is standard. So, how to understand the use of subtitles Apple MOV Text? Another margin of programming without much use.

[obieobieobie]

nvm works now

[Ripman]

2016-08-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: DTS bug fix: if present mkvmerge will use an XLL extension's sample rate information as the sample rate to put into the track headers. Fixes #1762.


Thanks for the new 9.4.0 release.

I'll check that DTS sampling issue within the next few days.

[hello_hello]

Thanks for the new version but....

2016-07-15 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool bug fix: the automatic adjustments to the output file name based on the track types selected for muxing and the mechanism for keeping output file names unique had been broken since release v9.3.0. Fixes #1743.

Damn..... at first I thought it might be a bug, but then I got used to it, learned to like it that way, and hoped it was deliberate. Could we have a similar "broken" unique file name option in preferences?
Currently if you open a file and MKVToolNix creates a file name it'll make sure it's unique if that option is enabled. ie "video.mkv" will be named "video (1).mkv" if the former already exists. That's fine, but if I mux an MKV and then think to myself "whoops, I forgot to de-select the Latin subtitles" I'd prefer it if MKVToolNix didn't change the file name. I can alter the output name myself if necessary, and if I happen to forget, MKVToolNix will ask me about over-writing the existing file anyway. Two unique file name options in preferences would be nice. One for making sure the output file name is unique when it's first created, and another to allow/prevent MKVToolNix from fiddling with it after that.

Thanks again.

PS. I just noticed the "unique file name" option stops working if the output file name is changed manually. Maybe that's by design, but.....
I mux a file automatically named video.mkv
I de-select the subtitle stream
MKVToolnix changes the output name to video (1).mkv
I change it to new_video.mkv and mux
I add an audio stream
The output name remains new_video.mkv

Is that behaviour intentional? It's basically the behaviour I prefer, only the file name needs to be changed manually to stop MKVToolnix from continuing to fiddle with it.

Cheers.

[Mosu]

Yes, manually changing the file name does disable the automatic adjustment. Intentionally.

I won't add yet another option for tweaking yet another minute detail in its behavior. Each and every option increases the number of things a user has to wade through and it increases the amount of code that I have to test and maintain. Sorry.

[hello_hello]

I won't add yet another option for tweaking yet another minute detail in its behavior. Each and every option increases the number of things a user has to wade through and it increases the amount of code that I have to test and maintain. Sorry.

That's okay. I'd not realised manually changing the output file name disables the automatic file name fiddling until now, so if I want MKVToolnix to stop fiddling, at least I know it can be done that way.

A different question... is there a reason why chapters aren't described very informatively in the streams list? For instance at the moment I'm looking at an MKV where the chapters are listed as "10 entries". Okay, that's enough entries for me to fairly safely guess it refers to chapters, but why isn't it labelled as such?

Also... minor GUI thing....
When you open an MKV containing chapters similar to the one I just described, you can re-order streams... except for the chapters "stream". They're an unmovable object. If there's an audio stream below the chapters in the streams list the audio stream can be moved up, but the chapters can't be moved down.

The location of the chapters in the streams list probably makes no difference to how the file is muxed (does it?) but is the lack of chapter re-ordering intentional?

Thanks.

[hello_hello]

One more question....
MKVToolNix has an option "drop last entry from imported Bluray playlists if it's near the end".

If it doesn't already (I'll confess I've not checked recently), could that option be extended to include any chapters with an entry right at the end?
I generally extract chapters from DVDs with MeGUI's chapter extractor (as a text file) and a fair proportion of them have that infuriating chapter right at the end. I'm almost in the habit of remembering to check and manually delete it before muxing if necessary, but it'd be great if MKVToolnix could do it automatically.

Thanks again.

[Mosu]

A different question... is there a reason why chapters aren't described very informatively in the streams list? For instance at the moment I'm looking at an MKV where the chapters are listed as "10 entries". Okay, that's enough entries for me to fairly safely guess it refers to chapters, but why isn't it labelled as such?

Huh? The "type" column clearly states that the entry is "chapters".

The location of the chapters in the streams list probably makes no difference to how the file is muxed (does it?) but is the lack of chapter re-ordering intentional?

It is intentional as the underlying mkvmerge does't support re-ordering of chapters. They're always processed in the order they're read from source files. Allowing the user to drag & drop such entries would most likley be confusing as it suggests a functionality that simply isn't there.

MKVToolNix has an option "drop last entry from imported Bluray playlists if it's near the end".

mkvmerge only drops the last entry from chapters read from MPLS files. Chapters read from other sources (chapter files, MP4 files, Matroska files…) aren't modified that way. Therefore the corresponding option only applies to Blu-rays, and there's no need for a change.

[hubblec4]

Hi Mosu

How close to the end must be a chapter to drop it?

@hello_hello
You could try my chapterEditor instead of MeGUI. There are few settings to ignore the last chapter.

[Mosu]

How close to the end must be a chapter to drop it?

mkvmerge will drop the last entry if it is within five seconds of the end of the duration indicated by the MPLS file the chapter is read from.

[hubblec4]

Maybe 5 seconds are too long. I had a Bluray with a "real" chapter 2,2 seconds before movie end.

The "Last chapter bug" came with DVD. I dont know exactly why there is a chapter so near the end, but in Matroska(and other containers) it is problematic to play it in MPC-HC(or other players). The player hangs or crashes. why?

[Mosu]

Because there are bugs in players. What else is new?

[hello_hello]

Huh? The "type" column clearly states that the entry is "chapters".

Ah..... that'd be the Type column I disabled almost immediately after I began using the new GUI because at the time it seemed redundant, and I even suspected it might have been mocking me a little, by taking up space and not displaying anything I couldn't learn by checking the codec column.
Except.... I now realise.... in the case of chapters. I probably should enable the Type column again. Maybe I can move it far enough over to the right to only see it when I scroll.....

Ah.... I forgot..... the columns automatically resize for each new Merge job, enabling the Type column to leap back into view. Taunted and mocked at the same time.... :)

It is intentional as the underlying mkvmerge does't support re-ordering of chapters. They're always processed in the order they're read from source files. Allowing the user to drag & drop such entries would most likley be confusing as it suggests a functionality that simply isn't there.

Fair enough if they don't need re-ordering, but my only confusion resulted from being able to move a stream above the chapters entry by dragging it up, while not being able to do the same thing by dragging the chapters entry down instead. Which I still attempt to do, maybe 50% of the time. They're just another entry in the streams list, and there's no warning sign...

mkvmerge only drops the last entry from chapters read from MPLS files. Chapters read from other sources (chapter files, MP4 files, Matroska files…) aren't modified that way. Therefore the corresponding option only applies to Blu-rays, and there's no need for a change.

Sorry but I don't follow the logic....
MKVMergeGUI can drop the last entry from chapters read from MPLS files because MPLS files can contain an annoying last chapter so there's a need, but when DVD chapters, or for that matter any other chapter type, have a similar last entry it's not removed because there's no need?
I can only assume there must be a rule I've missed.....

@hello_hello
You could try my chapterEditor instead of MeGUI. There are few settings to ignore the last chapter.

Cheers. I'll give it a spin.
I encoded an old TV series a few weeks back.... a DVD boxset..... and every single episode had a chapter right at the end. It would have been nice if I didn't have to manually open about 200 text files to remove the last entry from each. After about thirty I seriously considered not muxing the chapters at all this time, given there was generally only five or six per episode anyway, not including the pointless/aggravating one at the end.

The "Last chapter bug" came with DVD. I dont know exactly why there is a chapter so near the end, but in Matroska(and other containers) it is problematic to play it in MPC-HC(or other players). The player hangs or crashes. why?

I've not understood why it's there either. Maybe if I ever played an actual DVD I'd work it out.
I can't say I've had problems with the last chapter causing hangs or crashes, but I have MPC-HC configured to skip to the next file in the folder after it runs out of chapters to skip to (if I click the skip button), but when there's a chapter right at the end it stops playing instead. I've got MPC-HC configured to come out of full-screen mode when it stops.... so instead of skipping when I click "skip", that last chapter effectively results in "exit fullscreen" which just to taunt me a little more, is naturally accompanied by a distinct lack of skipping....

[hubblec4]

Sorry but I don't follow the logic....
MKVMergeGUI can drop the last entry from chapters read from MPLS files because MPLS files can contain an annoying last chapter so there's a need, but when DVD chapters, or for that matter any other chapter type, have a similar last entry it's not removed because there's no need?
I can only assume there must be a rule I've missed.....

Thats very simple to explain.
MTX-GUI is able to open mpls files which contain all infos about chapters, therefore is it easy to check the last chapter entry.
For all other formats the MTX-GUI have to check the chaptertimes(if chapters are present).
Unfortunately is the IFO file not supported.

@Mosu
Feature request: could you add this support for IFO files?
I'm sure you say no, but maybe in future.
DVD is a format what will slowly die out(my opinion) but there are some stuff on DVD only.
It will be great to handle vob-files like m2ts files controlled by the IFO/(mpls).
DVD-sup files are not supported? Could you add this format too?

[Mosu]

Ah.... I forgot..... the columns automatically resize for each new Merge job, enabling the Type column to leap back into view. Taunted and mocked at the same time.... :)

You can re-order the columns via drag & drop (safe for the first column which cannot be moved).

MKVMergeGUI can drop the last entry from chapters read from MPLS files because MPLS files can contain an annoying last chapter so there's a need, but when DVD chapters, or for that matter any other chapter type, have a similar last entry it's not removed because there's no need?
I can only assume there must be a rule I've missed....

When reading chapters from an MPLS file mkvmerge knows that those chpaters come from a Blu-ray disc and that Blu-rays often contain a single chapter entry near the end. Additionally the MPLS file contains the Blu-ray's duration (well, that title's duration). That combination forms a well-defined scenario for which dropping the last entry makes sense.

In all the other cases such information is simply not known. The chpaters in an XML file might come from a Blu-ray, from a DVD, but they might also have been created manually. Even if they come from a Blu-ray they may have been fixed manually already. Additionally there's no information about the concrete length of a title; hence there's nothing to compare the last entry's start time with.

[Mosu]

Feature request: could you add this support for IFO files?
…
DVD-sup files are not supported? Could you add this format too?

I have no intentions on adding any more features regarding DVDs. Sorry.

[hello_hello]

@Mosu
Feature request: could you add this support for IFO files?
I'm sure you say no, but maybe in future.
DVD is a format what will slowly die out(my opinion) but there are some stuff on DVD only.
It will be great to handle vob-files like m2ts files controlled by the IFO/(mpls).
DVD-sup files are not supported? Could you add this format too?

MakeMKV does all that doesn't it?

In all the other cases such information is simply not known. The chpaters in an XML file might come from a Blu-ray, from a DVD, but they might also have been created manually. Even if they come from a Blu-ray they may have been fixed manually already. Additionally there's no information about the concrete length of a title; hence there's nothing to compare the last entry's start time with.

I hadn't thought of that. Now it makes sense.

[hubblec4]

MakeMKV does all that doesn't it?

Yes it does.
But I don't like makemkv's way. All Matroska stuff should be free, and in future you must pay for makemkv.
If Mosu and other people from the Matroska team were not, there would be no Matroska.

[hello_hello]

I don't like the time limited beta idea (if it still works that way). I don't use MakeMKV often, so I install it, use it, then invariably have to do it all again for the next disc, so I'll confess I tend to exhaust all other avenues first.

[Chetwood]

All Matroska stuff should be free
Really? What about decryption?

[hubblec4]

Really? What about decryption?
Yes really, or could you imagine Mosu want money from now on.

What you mean with "about decryption"?

[qyot27]

Yes really, or could you imagine Mosu want money from now on.

What you mean with "about decryption"?
MakeMKV is a ripping program that just happens to use Matroska as the output format when doing title-based rips. Its sole purpose is disc decryption (of which only the Blu-ray ripping is time-limited, the DVD part has been stated repeatedly to remain free); it's not a Matroska muxer.

[hello_hello]

The DVD part has been stated repeatedly to remain free); it's not a Matroska muxer.


I'm sure a couple of times MakeMKV informed the time limit had expired and a new version was required, or was it the temporary license key has to be replaced? I have a memory of both.
I know it's always been said DVD ripping will remain free, but it's not mutually exclusive with time-limiting, as long as the replacement versions always include free DVD ripping capabilities.
Have I remembered it wrong, or has something changed?

[qyot27]

I'm sure a couple of times MakeMKV informed the time limit had expired and a new version was required, or was it the temporary license key has to be replaced? I have a memory of both.
I know it's always been said DVD ripping will remain free, but it's not mutually exclusive with time-limiting, as long as the replacement versions always include free DVD ripping capabilities.
Have I remembered it wrong, or has something changed?
I don't really know, I seem to remember still being able to use DVD functionality after a license expiration a while back, but that could have regressed in later versions.

Not that it really matters in the end: DVD ripping programs are a dime a dozen, including the FOSS ones.

[Mosu]

Somewhat unscheduled I'm releasing v9.4.1. It fixes several errors in mkvmerge, most of which are exploitable via specially crafted file. They were found by fuzzing done by Justin Smith.

Nothing's been changed regarding the packagin since v9.4.0.

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

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's the full ChangeLog (https://mkvtoolnix.download/doc/ChangeLog) since v9.4.0:

2016-09-11 Moritz Bunkus <moritz@bunkus.org>
* Released v9.4.1 "Black Rain".

2016-09-07 Moritz Bunkus <moritz@bunkus.org>
* Note: most of the bugs fixed on 2016-09-06 and 2016-09-07 for issue #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780) are potentially exploitable. The scenario is arbitrary code execution with specially-crafted files. Updating is highly recommended.
* mkvmerge: bug fix: AVC & HEVC readers: the readers will now refuse to handle files where the detected pixel width or height is equal to or less than 0. Before this fix the muxing process aborted with an assertion inside libMatroska. Fixes the last test case of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).
* mkvmerge: bug fix: HEVC parser: fixed another invalid memory access (beyond the end of allocated space). Fixes two test cases of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).

2016-09-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: HEVC parser: fixed another invalid memory access (beyond the end of a fixed-size array). Fixes several test cases of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).
* mkvmerge: bug fix: MP4 reader: an error message will be printed instead of an uncaught exception when an invalid atom chunk size is encountered during resync. Fixes a test case of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).
* mkvmerge: bug fix: AAC reader: fixed mkvmerge throwing an uncaught exception due to the sample rate being 0. Fixes a test case of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).
* mkvmerge: bug fix: MP4 reader: fixed an invalid memory access (beyond the end of allocated space). Fixes several test cases of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).
* mkvmerge: bug fix: HEVC parser: fixed an invalid memory access (beyond the end of allocated space). Fixes several test cases of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).
* mkvmerge: bug fix: fixed an invalid memory access (use after free) during global destruction phase. Fixes several test cases of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).

2016-09-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: using very large --sync values (several minutes) with certain container formats was causing mkvmerge to abort muxing. Fixes #1774 (https://github.com/mbunkus/mkvtoolnix/issues/1774).


Have fun :)

[Jamaika]

It's don't work. I can't import file HEVC.
for %%f in ("%~dp1*.h265") do mkvmerge %%f --disable-track-statistics-tags -o %%~nf.mkv
Error: The file 'x265_v2.0+24_crf08_aqmode0_threads1_hightier.h265' has unknown type. Please have a look at the supported file types ('mkvmerge --list-types') and contact the author Moritz Bunkus <moritz@bunkus.org> if your file type is supported but not recognized properly.
mkvmerge --list-types
HEVC/h.265 elementary streams [265 hevc h265 x265]:(

[Mosu]

Please upload such a file to my FTP server.

[Jamaika]

https://www.sendspace.com/file/6bvdow

[Mosu]

Thanks. I'll take a look.

[Mosu]

I'm currently testing a fix. If that plays nicely with my test suite then I'll prepare release v9.4.2 afterwards.

[Mosu]

Unfortunately the just-released v9.4.2 contained a nasty regression in both the AVC and HEVC readers. I'm therefore releasing v9.4.2 mere hours after v9.4.1. The only difference is the fix to the aforementioned regression. I'm including the whole announcement for v9.4.1 below.

Somewhat unscheduled I'm releasing v9.4.1. It fixes several errors in mkvmerge, most of which are exploitable via specially crafted file. They were found by fuzzing done by Justin Smith.

Nothing's been changed regarding the packagin since v9.4.0.

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

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's the full ChangeLog (https://mkvtoolnix.download/doc/ChangeLog) since v9.4.0:

2016-09-11 Moritz Bunkus <moritz@bunkus.org>
* Released v9.4.2 "So High".
* mkvmerge: bug fix: AVC & HEVC readers: release v9.4.1 contains a change to both readers so that they will refuse to handle files where the detected pixel width or height is equal to or less than 0. This check was wrong in certain cases causing mkvmerge to reject a file as an unsupported file type. This has been fixed while keeping the constraints on width & height having to be positive.
* Released v9.4.1 "Black Rain".

2016-09-07 Moritz Bunkus <moritz@bunkus.org>
* Note: most of the bugs fixed on 2016-09-06 and 2016-09-07 for issue #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780) are potentially exploitable. The scenario is arbitrary code execution with specially-crafted files. Updating is highly recommended.
* mkvmerge: bug fix: AVC & HEVC readers: the readers will now refuse to handle files where the detected pixel width or height is equal to or less than 0. Before this fix the muxing process aborted with an assertion inside libMatroska. Fixes the last test case of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).
* mkvmerge: bug fix: HEVC parser: fixed another invalid memory access (beyond the end of allocated space). Fixes two test cases of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).

2016-09-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: HEVC parser: fixed another invalid memory access (beyond the end of a fixed-size array). Fixes several test cases of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).
* mkvmerge: bug fix: MP4 reader: an error message will be printed instead of an uncaught exception when an invalid atom chunk size is encountered during resync. Fixes a test case of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).
* mkvmerge: bug fix: AAC reader: fixed mkvmerge throwing an uncaught exception due to the sample rate being 0. Fixes a test case of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).
* mkvmerge: bug fix: MP4 reader: fixed an invalid memory access (beyond the end of allocated space). Fixes several test cases of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).
* mkvmerge: bug fix: HEVC parser: fixed an invalid memory access (beyond the end of allocated space). Fixes several test cases of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).
* mkvmerge: bug fix: fixed an invalid memory access (use after free) during global destruction phase. Fixes several test cases of #1780 (https://github.com/mbunkus/mkvtoolnix/issues/1780).

2016-09-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: using very large --sync values (several minutes) with certain container formats was causing mkvmerge to abort muxing. Fixes #1774 (https://github.com/mbunkus/mkvtoolnix/issues/1774).

Have fun :)

[Jamaika]

:thanks:

[Mosu]

You're welcome, and thanks for the quick feedback & the sample file.

[Ripman]

Thanks for the new 9.4.0 release.

I'll check that DTS sampling issue within the next few days.

I checked a DTSHDMA audio track @ 192khz with mkvtoolnix 9.4.0.

The tests I conducted were clean; it works fine, as does the previous flac method I suggested. Here is the GitHub link: https://github.com/mbunkus/mkvtoolnix/issues/1762

Here are the logs from the successful mux with DTSHDMA@192khz.

https://www.dropbox.com/s/sz3nnak52yjkm3d/08.3_mmg_logs---DTSHD_sampling_results---OK%20%289.4.0%29.zip?dl=1

(I realize you did a .1 and .2 release.)

[Ripman]

2016-07-15 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool bug fix: the automatic adjustments to the output file name based on the track types selected for muxing and the mechanism for keeping output file names unique had been broken since release v9.3.0. Fixes #1743.


I still see "my version" of this (1761); I put a comment in there too. I originally reported this because it was different behavior than the old mmg. https://github.com/mbunkus/mkvtoolnix/issues/1761

pic from 9.4.0:
https://www.dropbox.com/s/uiiy9e1iv7kyh7l/10b_mmg_notes---no_vid_mkv%20%289.4.0%29.gif?dl=0

[Mosu]

That behavior is intentional. As soon as the user changes the output file name from the default suggestion the GUI will stop messing around with it. I have no intentions of changing this.

[Ripman]

That behavior is intentional. As soon as the user changes the output file name from the default suggestion the GUI will stop messing around with it. I have no intentions of changing this.

Thanks. I see how it works now - de-select the video, then change the file name. Very good.

Tbh - I thought the functionality in the old Mmg was to prevent users from generating an mkv file without a video track. The new MKVToolnix allows an mkv to be created without a video track and I think you are saying that is by design.

[Mosu]

I'm saying that I don't think that the program always knows better than the user. The program will do stuff automatically, but as soon as the user says "I know better than this bloody device!" (by manually changing the name) the GUI will take the hint and stop messing with it.

The intention has never been to prevent the user from doing something. It has always been to make the common cases easy and fast to achieve. Do the right thing by default, but don't impose your will on the user.

[Ripman]

Thanks for clarifying. I'm usually a command line user, but when you released the new MKVToolnix around 8/8.1 I figured I should help identify "things" in the new gui until everything was stabilized. The new gui is much easier on the eyes tbh.

I'll probably volunteer to do some documentation for you in later q4 -- wish I had more time to help with code/docs/etc.

[VincAlastor]

mkvtoolnix 9.4.x and opus audio frame size 60ms

Since mkvtoolnix version 9.4.x i can't merge mkv files with opus audio streams which have a larger frame size than standard 20ms. Well i normally use the full value of 60ms. I'm confused why mkvtoolnix have a problem with this opus encoder parameter?!?!

[Mosu]

I've just fixed that particular issue. New pre-builds for WIndows (https://mkvtoolnix.download/windows/pre/) that include the fix are available.

[manolito]

Currently I am converting my huge DVD collection to AVC / AAC in an MKV container using MakeMKV and StaxRip. In about every 1 in 50 source files I get a H264 video stream which MKVMerge refuses to recognize.

Here is such a H264 file:
https://we.tl/LrTHNPzcJs

I tried MKVToolNix versions 6.30, 7.80 and 9.42, and they all behave the same. I used X264 r2334 which comes with StaxRip 1.1.90.

The H264 file plays in all my player software, and MP4Box has no problems creating an MP4 file from it. So I believe that MKVMerge is to blame for this issue.

Any thoughts?


Cheers
manolito

[sneaker_ger]

Does this always happen with the same source files? My encodes with new and same x264 differ from yours in the first bytes. I encoded with the x264 included in StaxRip 1.9.0 (direct to raw ES, not mkv/mp4 and then demux). I don't want to keep Mosu from fixing this but maybe you have a hardware error on your hands that's corrupting your files. If you are not directly encoding to raw ES it would be interesting to see what muxer and demuxer steps you used.

[manolito]

Yes, it always happens with the same source files. So far I could not see any pattern to predict if a source file will have this issue.

I don't believe that it is a hardware glitch because it is reproduceable for the same file.

I use the X264 version which ships with StaxRip 1.1.9.0. My workflow is like this:

Convert the source DVD structure to MKV using the current version 1.10.2 of MakeMKV. I then feed this MKV to StaxRip specifying an MKV output file. StaxRip first demuxes the source MKV with MKVExtract, then transcodes audio, then converts the MPEG video to raw H264, and as the last step it muxes the converted streams using MKVMerge. My AviSynth source filter is DSS2Mod, but I tried ffms2 also and got the same result.

With a problematic source the converted raw H264 video cannot be opened by MKVMerge so I end up with a muxed MKV which only contains audio and chapters.

I can save the result using the elementary streams from the StaxRip temp folder. I fire up YAMB, import the video and audio streams and let it create an MP4 file. This MP4 is accepted by MKVMerge just fine, so I only need to import the chapter XML file and mux to MKV.


Cheers
manolito

[SeeMoreDigital]

I fire up YAMB, import the video and audio streams and let it create an MP4 file. This MP4 is accepted by MKVMerge just fine, so I only need to import the chapter XML file and mux to MKV. Just-so-you-know... TSmuxerGUI 2.6.12 also accepts your source ;)

[sneaker_ger]

That's very peculiar.

Anyways, I overlooked some headers and now I get the same bytes at the start and the same error. This also happens with recent x264. Interestingly it triggers only with at least 128 frames. I don't know if that is a coincidence or if it matters (with 128 being a power of 2). :confused:

https://www.sendspace.com/file/5cpeb5

[Mosu]

Hey,

Currently I am converting my huge DVD collection to AVC / AAC in an MKV container using MakeMKV and StaxRip. In about every 1 in 50 source files I get a H264 video stream which MKVMerge refuses to recognize.

and

Anyways, I overlooked some headers and now I get the same bytes at the start and the same error.

Thanks for the report & the sample files. mkvmerge was wrongfully detecting those files to be MPEG transport streams. I've made that detection code more strict, and now both of your sample files are recognized as h.264 elementary streams again.

New pre-builds with the fix included are available from the usual location (https://mkvtoolnix.download/windows/pre/).

[manolito]

:thanks:

[nautilus7]

Hi, what's the current support state of pcm audio muxing?

I am trying to mux a mpls blu-ray playlist directly to mkv. The playlist contains a pcm audio stream (24bit, 48KHz, mono channel). The resulting mkv file plays at half speed when the pcm audio is selected. The audio is correctly detected by lav splitter and sound is heard, but at half the speed (both audio and video at half speed). On the contrary, if I select the other audio stream (dts audio), the mkv file is played correctly at normal speed, despite the pcm being present inside the mkv container.

[Mosu]

It should work, but it obviously doesn't properly. Can you provide a sample file (the source .M2TS) for this, please? The first 200 MB or so should suffice. See my signature where to upload it. Thanks.

[nautilus7]

Currently uploading, but it would take about 1 hour, due to my slow adsl connection.

Unencrypted ftp didn't work, so I used the secured connection.

[Mosu]

Don't worry about it, I'm at work anyway and don't have time to look into it right now.

[nautilus7]

Done uploading.

File is in "upload" folder, name "sample_pcm_nautilus7.m2ts". Thanks!

[Mosu]

Thanks. I will probably not get around to looking into it until the weekend.

[Mosu]

File is in "upload" folder, name "sample_pcm_nautilus7.m2ts". Thanks!

I've fixed the problem which only affected PCM tracks with an odd number of channels (https://github.com/mbunkus/mkvtoolnix/commit/2cac968f958e5c1b3c6fe9a4e84ecc7ddc036d0b). New pre-builds for Windows (https://mkvtoolnix.download/windows/pre/) are available.

[nautilus7]

That was quick. Thank you!

[Perenista]

When I select "determine automatically" in an audio or subtitle track, does that mean I am not forcing the player to select that track by default, and letting the player do the choosing?

I mean, if I select "default track" for english DD 5.1, for example, even if the player is set to prefer the portuguese language and to select by default the Portuguese tracks, will the "default: yes" from the english 5.1 override that setting from the player?

[Mosu]

When I select "determine automatically" in an audio or subtitle track, does that mean I am not forcing the player to select that track by default, and letting the player do the choosing?

It solely means that mkvmerge will determine the corresponding flag on its own. See the "default track in output" column for what it'll be set to.

I mean, if I select "default track" for english DD 5.1, for example, even if the player is set to prefer the portuguese language and to select by default the Portuguese tracks, will the "default: yes" from the english 5.1 override that setting from the player?

The intent of the "default track" flag is to mark a track to play be default unless the user has instructed its player otherwise. That's a big vague, true, but it's vague on purpose. Selecting a language to prefer in the player seems to me a case of the user making such a choice; therefore such a choice should probably override the container's "default track" flag.

[Mosu]

A new release of MKVToolNix with several bug fixes in mkvmerge and minor feature enhancements in the GUI. Nothing critical.

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

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

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's the full ChangeLog (https://mkvtoolnix.download/doc/ChangeLog) since v9.4.2:

2016-10-16 Moritz Bunkus <moritz@bunkus.org>
* Released v9.5.0 "Quiet Fire".
* mkvmerge, mkvextract: VobSub handling bug fix: mkvmerge and mkvextract will now update the duration stored in the SPU bitsream with the duration from the container level if it differs at least 1ms. Fixes #1771 (https://github.com/mbunkus/mkvtoolnix/issues/1771).

2016-10-15 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: h.264 elementary stream handling bug fix: if mkvmerge ever encounters changing SPS or PPS NALUs (ones where their ID has been encountered before with different settings) in the h.264 then it will prepend all following key frames with all currently active SPS and PPS NALUs. This enables playback from arbitrary key frames even if they require other SPS or PPS settings than the ones stored in the AVCC in CodecPrivate. Fixes #1711 (https://github.com/mbunkus/mkvtoolnix/issues/1711).

2016-10-12 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mkvpropedit, MKVToolNix GUI: added support for the "field order" video track header element.
* mkvinfo: added support for the "field order" video track header element. Patch by James Almer (see AUTHORS).
* mkvmerge: MPEG transport stream reader bug fix: fixed the handling of Blu-ray PCM audio with an odd number of channels by removing their alignment bytes.

2016-10-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: MPEG transport stream reader bug fix: fixed mis-detection of certain h.264 files as MPEG transport streams.

2016-10-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: WAV reader bug fix: the track properties (channels, sample rate) for DTS and AC-3 in WAV will now be derived from the decoded bitstream headers instead of the WAV file header as the latter is often incorrect.
* mkvmerge: WAV reader bug fix: fixed detection and merging of DTS in WAV that uses the 14-bytes-in-16-bytes packing method.

2016-10-08 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: added menu entries that execute the "close", "save settings", "start muxing" or "add to job queue" action for all currently open tabs.

2016-10-07 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: when dragging & dropping directories the GUI will process all files within those directories recursively instead.

2016-10-06 Moritz Bunkus <moritz@bunkus.org>
* mkvpropedit, MKVToolNix GUI's header editor: added options to modify the "muxing application" and "writing application" elements in the "segment information" container. Implements #1788 (https://github.com/mbunkus/mkvtoolnix/issues/1788).

2016-09-30 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The Ogg/OGM reader did not recognize Opus files with comment headers anymore. This was broken by the fix to not require Ogg/OGM files to have comment headers in v9.4.0.

Have fun :)

[Mosu]

Like I've stated in issue #1711 (https://github.com/mbunkus/mkvtoolnix/issues/1711) I've tried the samples I had with both VLC and MPC-HC. Prior to the change I was able to observe the problems when seeking to key frames in both players; after the change I haven't been able to reproduce the problems.

If you have a file for which remuxing with v9.5.0 does not produce a proper result I'd like to take a look at it. Note that mkvmerge only dose this kind of processing if it uses the elementary stream packetizer (e.g. when reading h.264 from .h264 files or from MPEG program & transport streams), but not if the h.264 is already packetized (e.g. when reading it from Matroska or MP4 files).

[sneaker_ger]

Sorry, I had already deleted my post. I think I may have misunderstood the purpose of the change and will need to re-read the discussion on the issue tracker. I somehow believed this could also be used for appending differing H.264 streams while keeping playback intact.

[nautilus7]

Hi, I am trying to mux a blu-ray (mpls file) into mkv. The disc is Ran (1985) Remastered Japanese version. It contains 2 seamless branching playlists. First consists of two m2ts files. No problem here. The 2nd is the problematic one. It contains 4 m2ts files, but the 2 of them are not played from start to end, but from a intermediate point. Sequence is like this:

start_of_1st.m2ts --> end_of_1st.m2ts --> middle_of_2nd.m2ts --> end_of_2nd.m2ts -->
start_of_3rd.m2ts --> middle_of_3rd.m2ts --> start_of_4th.m2ts --> end_of_4th.m2ts

Trying to remux this playlist into mkv didn't result in a correct file (3rd and 4th files weren't included at all). I can provide samples, but only the mpls structure, because the m2ts files are huge...

Speaking of seamless branching, how does mkvmerge handle overlapping video or audio frames at the transition points between m2ts files? I know eac3to removes identical frames or frames with the same time stamps.

[Mosu]

Trying to remux this playlist into mkv didn't result in a correct file (3rd and 4th files weren't included at all).

Have you actually _appended_ the second MPLS file? And not _added_ it?

Speaking of seamless branching, how does mkvmerge handle overlapping video or audio frames at the transition points between m2ts files? I know eac3to removes identical frames or frames with the same time stamps.

It doesn't have any special handling for something like that. If there are identical frames then they'll both be included.

[nautilus7]

Sorry, I wan't clear. The 2 playlists are independent. I shouldn't have mention about the first one. It's a playlist, that has 4 m2ts files, that causes the problem. There is not other playlist to append.

[Mosu]

I see. Well, you can upload the MPLS structure if you want, but I doubt I'll be able to do much about it without the accompanying M2TS files…

[hubblec4]

Hi nautilus7

If its not a problem for you, I would like to have this Bluray-structure too.
Like Mosu said, without the M2TS files is not good.

You could try my chapterEditor, Multi Editions Editor: its designed to mux seamless branching Bluray's.

[nautilus7]

@mosu, your ftp server is not working. I am connecting, but I cannot upload any file.

@hubblec4, your program as far as I can see is based on eac3to. eac3to cannot (de-)mux this playlist correctly either.

[Mosu]

@mosu, your ftp server is not working. I am connecting, but I cannot upload any file.

Thanks for the heads-up. Should be fixed now.

[hubblec4]

@hubblec4, your program as far as I can see is based on eac3to. eac3to cannot (de-)mux this playlist correctly either.

Very interessting.
My program is not fully depend on eac3to. Only if you want reencode audio streams or demuxing subtitles. OK there are a function to demux a playlist but you must not use it.

MTX-GUI is the program that generate the mkv directly from the Bluray.
I feed MTX-GUI with the necessary m2ts files (not with the mpls) and then generate my program an ordered chapter.xml which makes all to play.


@Mosu:
It is possible to share the uploaded Bluray content with me?

[Mosu]

@hubblec4: sure, I'll drop you a PM once it's been uploaded.

[nautilus7]

I just uploaded the blu-ray structure, except "stream" folder to Mosu's ftp. Here's a link (https://www.sendspace.com/file/fbd3sr) for others interested.

Mkvmerge muxes 1st and 2nd m2ts files, but stalls (no message, just keeps running and running without increasing output filesize) at the start of the 3rd m2ts.
Hope you can figure out what's wrong...

[hubblec4]

I have downloaded the Ran1985.zip and without the m2ts files is it not possible to check the issue.
Maybe has Mosu better analysis tools which work without the m2ts files.

I see in the 00001.mpls a 5th m2ts file which is used (00017.m2ts).
Can you think about to upload the whole Bluray to Mosu's ftp?

ChapterEditor reads the 00001.mpls (and it seems it's all ok), but I can't test the muxing process.

[Mosu]

Hey,

Mkvmerge muxes 1st and 2nd m2ts files, but stalls (no message, just keeps running and running without increasing output filesize) at the start of the 3rd m2ts.

Without having looked at the file yet. mkvmerge cannot jump directly to the middle of the M2TS file where the MPLS file stated it should start playing from. It simply reads the whole file from start to finish but only processes the frames that fall into the time frame specified by the MPLS file (actually it won't read until the end but only until the end timestamp given by the MPLS file has been reached).

Therefore I suggest you leave it running a lot longer. Maybe it's only doing its job and it simply takes quite a while.

Which of the MPLS files is the one giving you the trouble?

[nautilus7]

Problematic playlist is 00001.mpls.

Mosu, I let mkvmerge run for about 1 hour, without any success.

[Ripman]

I've fixed the problem which only affected PCM tracks with an odd number of channels (https://github.com/mbunkus/mkvtoolnix/commit/2cac968f958e5c1b3c6fe9a4e84ecc7ddc036d0b). New pre-builds for Windows (https://mkvtoolnix.download/windows/pre/) are available.

Hi Mosu. Thanks for this fix.

I could not reproduce this problem in mkv's having an odd number of channels in selected lpcm audio tracks. (Mkv's created with makemkv and muxed with Mmg.) Does the problem only occur for m2ts sources, or if the lpcm audio is default?

As examples, this AM I opened the following CR titles with mono lpcm audio tracks selected, and had no "half-speed" issue: Lola, red river, my darling clementine, L'eclisse, L'aventurra, identification of a woman. (These mkv files were muxed with Mmg v7x.) Thanks.

[Mosu]

LPCM as packaged in M2TS has this problem. Most likely the source of the PCM data were either other container types or the muxer(s) in question already took care of it.

[nautilus7]

I am trying to append some Η264 files (cut from 2 Blu-ray's - theatrical and extended cut of the same movie - on IDR frames using mkvmerge). I get a warning about video parts having different private data lengths:

The codec's private data does not match (lengths: 114 and 114). Please make sure that the resulting file plays correctly the whole time.

But why 114 is different than 114? :( I checked playback and it seems ok though.

Also I noticed a bug (?): I insert a few files for appending. I drag and drop them to change the order and then mux. The resulting file has the initial order (the one the files were loaded into mkvmerge) and not the rearranged one.

[nevcairiel]

The codec's private data does not match (lengths: 114 and 114). Please make sure that the resulting file plays correctly the whole time.

But why 114 is different than 114? :( I checked playback and it seems ok though.


Same length does not imply the same content. When you remux from Blu-ray its usually going to be fine with the majority of players, as the Blu-ray streams contain the required private data in the stream again, but there could be players which don't like that - or when you mux other stream sources, which don't contain it inside the stream, it could break entirely.

[Mosu]

Also I noticed a bug (?): I insert a few files for appending. I drag and drop them to change the order and then mux. The resulting file has the initial order (the one the files were loaded into mkvmerge) and not the rearranged one.

This is not a bug. You change the order of the tracks by dragging & dropping tracks, not by dragging & dropping files.

[nautilus7]

Same length does not imply the same content. When you remux from Blu-ray its usually going to be fine with the majority of players, as the Blu-ray streams contain the required private data in the stream again, but there could be players which don't like that - or when you mux other stream sources, which don't contain it inside the stream, it could break entirely.

Thanks. What do these private data contain?

This is not a bug. You change the order of the tracks by dragging & dropping tracks, not by dragging & dropping files.

Yes, of course.... My bad. :o

[Ripman]

Mkvmerge and Mkvextract can accept options files on the command line via the @ sign.

Can options files be utf-8 encoded?

(I'm thinking about those special angled quotes - 0x93 0x94 - and some of the other accented characters that could be used for filenames, etc.)

[Mosu]

The programs use the same methods for reading option files they use for reading other text files. This means that they will use the system's local character set if the file does not start with a Byte Order Mark (BOM). If it does start with a Byte Order Mark then the encoding signaled by the BOM will be used.

So in order to make sure that UTF-8 is used create option files that start with a UTF-8 BOM.

That's what the GUI does, too, BTW.

[Perenista]

I have been doing some tests here with the app Infuse for iOS (I use in the IPP 9.7 and Apple-TV). The app does not support audio files (one major flaw), so I had the idea to create videos and insert the audios in them.

- It does not support MKA (what is created by MKVToolnix if I only add the audio). If I rename the MKA to MKV, it opens in Infuse, but when I fast-forward (for example), the playback stops (even though it plays from start to end).

So I had the idea to use Sony Vegas to create a video with a static image, saving as .MP4, with the same length as the audio track, which is FLAC.

My question is: if I open MKVToolnix and insert both the MP4 (video mentioned above, with only a static image) and add that FLAC, then save it as a Matroska, will this somehow degrade the audio quality (since FLAC is lossless)? MKVToolnix is using the default settings.

I was going to ask the same question about videos, created by MakeMKV, from DVDs/Blu-rays. I remember someone once said that everything we do with this software does not reencode anything, but it was a long time ago and I don't remember who said that.

[Brother John]

will this somehow degrade the audio quality (since FLAC is lossless)?
No, quality will stay exactly the same. MKVToolnix just muxes and demuxes. It never re-encodes any stream. That’s true for audio and video.

[Mosu]

Problematic playlist is 00001.mpls.

This was rather difficult to figure out for several reasons: a single debug run taking roughly 30 minutes for one thing and there being two completely unrelated bugs for another. Anyway.

I've fixed both issues & uploaded new debug builds (https://mkvtoolnix.download/windows/debug/) for you to test.

[nautilus7]

I will test later today. Thanks!

[nautilus7]

It works fine now! Great job! :D

[Mosu]

Thanks for the feedback!

[filler56789]

Guten Tag, Mosu.

There is a problem in mkvtoolnix.download...

My browser says:

The connection was refused when attempting to contact mkvtoolnix.download

:confused:

[Mosu]

Earlier today the server was down for maintenance. It's up now.

[Perenista]

Unfortunately I am having an unusual problem here, and it's the first time ever this is happening. Since I can't provide the actual files here, I urge you to pay attention to all the details.

- These are all the tracks from the Matroska lossless extracted from the Blu-ray:

http://pastebin.com/Bi96zcXP

I did the following:

- Added 2 SRT subtitle tracks;
- Added another audio file, instructing MKVToolnix this: +750ms (delay). This was done because I noticed the dubbing was not synced with the video.

- And I finally splitted the MKV into 3 parts. Each one with 14500 MB. Which resulted in 3 files, the first two with 14.1 and the 3rd 8.47 GB.

This is how the 1st part looks like:

http://pastebin.com/ytP1r1r2

My problem is this: when I add (option: append files, and this issue happens with all 3 combined or just the first two), in exactly the moment where (in the movie) we have a switch between parts (in the now unique file) the scene hangs from 40:46 to 40:50.

Meaning that exactly at 40:46 it freezes, while the audio continues to be played, and advances to at least 40:48.

What do I mean?

It's like this:

1st part ends at 40:46.
2nd part continues from 40:46 onwards.
3rd part has, let's say, the final 10 minutes.

When we append parts 1-2, this is what is happening:

- Unique file with 28.3 GB and 1h20m.

At 40:46, the bug occurs. Because this is the exact moment where the now unique file had the combination.

I'll do another test here, this time removing the dubbing and its +750ms delay. But it can't be that what is causing all this. What is more strange is that I think that the unique file (without any splitting, the one I created before the actual splitting) wasn't plagued by this problem.

So what changed when I did the splitting and rejoined the files? Can you make a guess what happened?

[sneaker_ger]

Is there a subtitle line in any of the two SRT files that extends from <=40:46 to 40:50? Mkvmerge cannot split such subtitles in the middle. It also has problems with splitting open gop H.264 but since keyframe interval should only be max 1 second on your BluRay it shouldn't result in a 4 second problem by itself.

Btw, usually --append-mode track is better suited to re-append previously split continuous files.
https://mkvtoolnix.download/doc/mkvmerge.html#d4e760

[kuchikirukia]

- And I finally splitted the MKV into 3 parts.

Don't do this.
Problem solved.

[VictorLS]

I am novice here and I want to ask some questions:
1. mkvtoolnix is one freeware application to split h265 without encoding now (as i.e. VideoReDo for h264) or I am wrong?
2. Is there possibility to cut h265 file from some time to the end of file without saving first part from beginning to that some time because I have a little free space on HDD?
3. Is possibility to do first frame of result (read my second question) I-frame in mkvtoolnix only? Or I have to know exactly time of I-frame in another application? What freeware can be proposed for that?

[sneaker_ger]

1. You mean "the only one"? No. For example ffmpeg.
2. "split by parts based on[...]" E.g. "00:05:03.200-". This saves everything from 5 minutes, 3 seconds, 200 ms to the end of the file.
3. Mkvmerge will split on the next following keyframe. You can't look this up using mkvmerge (no preview). You need another application to do that.

https://mkvtoolnix.download/doc/mkvmerge.html#d4e760

[Jamaika]

3. Is possibility to do first frame of result (read my second question) I-frame in mkvtoolnix only? Or I have to know exactly time of I-frame in another application? What freeware can be proposed for that?
Now a few words about praised on forums SolveigMM Video Splitter Business Edition and more. These are the scissors to cut the film. Only every are they worth?
Splitter is currently only codec H264.
Speech was that the frame "P" or "B" will have to be converted. Unfortunately, so when we have a long-GOP. How does it work in practice?
When you want to get rid of "extra frames" we must be aware that the area of frames from the cut to the next frame I must be converted to lossy. -? Consequently, and whether it makes sense to cut short films? Not really, it is better to convert again. :idea:
Easy to use, lossless video editor for AVC/H264, MP4, MOV, WEBM, FLV, MKV, MPEG-2, WMV, ASF, AVI frame-accurate trimming and joining.
http://www.solveigmm.com/en/products/video-splitter/
http://www.solveigmm.com/images/stories/PR/scheme--frame-accuracy--frame-accuracy-eng.jpg

[hubblec4]

@ Perenista

Splitting is ever not so easy and simple.
But it could be a problem of the video decoder.
Sometimes I cut from Bluray series the middle part, and mux part 1 and part 3 together with a stuttering result.
But I changed the video decoder from LAV-h264 to Microsoft DTV DVD video decoder and all works fine.

[Perenista]

Don't do this.
Problem solved.For everything we do there's a reason, and this, of course, wouldn't be any different. I don't need to split at all, since all my devices can read the unique file.

It's just that Google Drive offers only 15 GB of actual free disk space. So you have 2 options:

1) Either split into multiple files and then you can watch the whole thing, even if it's splitted;

2) You leave it as a unique file, but put it inside a RAR with 38 GB, also splitted, meaning each RAR will have 15 GB, but you wouldn't be able to watch any of it, obviously.

Currently I watch all my movies with a PC/Hard Drive (or for some, a NAS) online, from my iPAD, so this isn't necessary. But I would like a watchable copy to exist in GD, also serving as a backup whenever I want to download to my HDD.

What is odd about this case is that this only occurs when I append all the splitted files. I can only assume this is happening due to the excessive number of tracks or maybe it is entirely related wiith the delay inserted for the dubbing, since splittling and appending cannot have caused this. Don't you all said that everything MKVToolnix modifies cannot change the MKVs (meaning they will continue to be lossless)?

I'll report later with more conclusions...

[sneaker_ger]

2) You leave it as a unique file, but put it inside a RAR with 38 GB, also splitted, meaning each RAR will have 15 GB, but you wouldn't be able to watch any of it, obviously.
I don't know how your Google Drive mounting works but players like VLC and MPC-HC can read directly from splitted RAR archives. Just make sure to turn off compression (doesn't do much on modern codecs anyways) and encryption.

What is odd about this case is that this only occurs when I append all the splitted files.
Read my remark about subtitle splitting and the doc about the append modes. Then it may make sense to you.

[Perenista]

sneaker_ger, here's what I discovered so far:

1) The problem happens regardless of the dubbing added with its delay. So disregard that remark about adding 750ms. Let's not even mention this track anymore.

2) It can also occur when this option is used:
http://forum.doom9.org/showthread.php?t=63956

By default, it's disabled. The option makes MPC-HC read as if it was a single file, instead of 3 splitted. But in my case, when I append all 3, the problem is still there.

***************
In case you are wondering, this is what I was doing here. Let's call this movie "X1".

The Blu-ray from "X1" has:

- For the movie:

- DTS-HD MA 5.1
- DTS 5.1
- DTS-HD MA 2.0
- DTS 2.0

Audio commentary #1 in

DTS-HD MA 2.0
DTS 2.0

Audio commentary #2 in

DTS-HD MA 2.0
DTS 2.0

Isolated Score in

DTS-HD MA 2.0
DTS 2.0

Plus: English (CC) track for the movie. All these tracks from the BD.

The video:

Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC

OK, so I have an unique file with all these 11 tracks (total), and more than 30 GB (besides "24 entries", which refer to chapters). Created by MakeMKV from the original BD. This MKV (lossless) is perfectly fine.

What did I do next?

- With MKVToolnix and this file open, I added:

- A single subtitle (SRT) file, that covers the entire movie. This file is not splitted. English (normal) subtitles.
- A second SRT (same condition as above), from another language (portuguese).

Next thing I did was: Split mode: after output size: 14500M. Maximum number of files: Unlimited. And the box "Link files" unchecked.

**********
After all 3 files were created, I opened the 1st (now preparing for Google Drive) and selected: append files, pointing to the 2nd file, then append: and selecting the 3rd.

What happened after all that was what I reported here. In the exact moment we switch between parts in the now unique 30+ GB file, a "delay" of at least 2 seconds occurs, with that stuttering.

Is there a subtitle line in any of the two SRT files that extends from <=40:46 to 40:50? Mkvmerge cannot split such subtitles in the middle. It also has problems with splitting open gop H.264 but since keyframe interval should only be max 1 second on your BluRay it shouldn't result in a 4 second problem by itself.This is happening even if I change the splitted size. So if happened at 40:46, it's now occurring at 41 minutes, after I changed the split size from 14500 to 14600 MB.

Meaning this is entirely MKVToolnix's fault. Even if there was a subtitle line that extended from one point to another, even if it extended from 40:46 to 1h, what difference does that make, since you are instructing the program to split anything, anyway?

I'll do another test, this time including not 13, but 2 tracks. And leaving the rest outside the file. Considering that this issue never affected any movie I tried before, I believe it's due to the excessive number of tracks.

[hubblec4]

....
Next thing I did was: Split mode: after output size: 14500M. Maximum number of files: Unlimited. And the box "Link files" unchecked.
....

What happens if you use the box "Link files" checked?
After muxing start the first part and all other parts should append automaticly by the player (MPC-HC).

[sneaker_ger]

This is happening even if I change the splitted size. So if happened at 40:46, it's now occurring at 41 minutes, after I changed the split size from 14500 to 14600 MB.
Is there or is there not a subtitle line at intended split point (or next keyframe)?

And: did you test other --append-mode like I suggested or did you not?

What happens if you use the box "Link files" checked?
Shouldn't make any difference. This is only for the uid linking tags.

[Perenista]

OK, I tested now with only the DTS-HD MA 5.1 track and the BD subtitle. The issue is not happening again.

As for the SRT, this is what I see inside it (the english one):

00:40:40,274 --> 00:40:41,474 - Dialogue
00:40:44,445 --> 00:40:46,765 - Dialogue
00:40:48,325 --> 00:40:49,725 - Dialogue
00:40:51,452 --> 00:40:54,332 - Dialogue

And the 2nd SRT (in portuguese):

00:40:41,748 --> 00:40:44,615 - Dialogue
00:40:45,652 --> 00:40:47,677 - Dialogue
00:40:48,622 --> 00:40:52,524 - Dialogue

My point is that I never had to worry about any of this. I just did all the procedure described here and uploaded to GB. So what you are saying is that the subtitle itself caused the stuttering? I had to add it because in GD I can make use of a splitted SRT (and it has to be SRT), too, and I used MKVToolnix to do this job of splitting into 3 parts, then MKVExtractGUI2 to collect the SRTs from all 3 files, to be embedded in each part in GD.

Can I assume this stuttering won't even occur if the SRT isn't there, even after I split and try to append the files? If that's the case then it's OK.

This (according to you) is what happened:

1) - Unique file.
1.1) - Added SRTs mentioned above.

2) - Divided into 3 parts with those two SRTs.
3) - Appending all 3 parts into an unique file like 1) = stuttering caused by the SRT.

The solution being creating an unique file again, and only after that adding both SRTs.

[sneaker_ger]

One potential solution. Other potential solutions:
1.) choose split point not in the middle of a subtitle
2.) use different --append-mode

But I'm not 100% sure it's the cause. You can extract the SRTs after the split and see exactly how mkvmerge split them. And you can see how long the video and audio tracks are (mkvinfo). Then compare the lengths.

[Perenista]

One potential solution. Other potential solutions:
1.) choose split point not in the middle of a subtitle
2.) use different --append-mode

But I'm not 100% sure it's the cause. You can extract the SRTs after the split and see exactly how mkvmerge split them. And you can see how long the video and audio tracks are (mkvinfo). Then compare the lengths.Now I am 101% sure (after my last test): the SRT subtitles caused the issue! You were right. :rolleyes:

I splitted and rejoined the 3 parts, except that now I left them out. And I even included the dubbing with the 750ms delay.

It had nothing to do with the number of tracks. And I used the append option to create the unique file.

[sneaker_ger]

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

[VictorLS]

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

[Perenista]

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

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

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

Look at the situation below:

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

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

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

[gpower2]

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

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

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

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

[kuchikirukia]

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

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

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

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

[microchip8]

@Mosu,

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

[Mosu]

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

[SeeMoreDigital]

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

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


Cheers

[sneaker_ger]

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

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

[Mosu]

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

[Mosu]

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

[microchip8]

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

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

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

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

[Jamaika]

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

Edit: Thanks

[sneaker_ger]

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

[Mosu]

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

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

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

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

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

So there are two things to remember for you:

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



If you did use the installer

[kuchikirukia]

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




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

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


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

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

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

[sneaker_ger]

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

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

[kuchikirukia]

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

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

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

[Mosu]

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

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

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

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

Here's the ChangeLog sincee v9.5.0:

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

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

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

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

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

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

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

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

Have fun :)

[hubblec4]

Many thanks for the new version and your continuously work!

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

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


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

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




best regards
hubble

[Mosu]

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

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

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

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

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

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

[hubblec4]

Thanks for this reply.

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

[ChaosKing]

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

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

[Mosu]

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

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

[Mosu]

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

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

[hubblec4]

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

10 times +1 !!!

[hubblec4]

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


Is there a difference when I load the corresponding mpls?

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

(What is PMT?)

[Mosu]

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

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

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

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

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

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

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

Note that mkvextract can already deal with both situations.

[Mosu]

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

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

PGS is not TextST. Distinct codecs, distinct tracks.

[hubblec4]

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

PGS is not TextST. Distinct codecs, distinct tracks.

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

[Mosu]

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

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

[Ripman]

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

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

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

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

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


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

[Mosu]

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

[hubblec4]

Hi Mosu

I have 3 questions.

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

Thanks a lot
hubble

[Mosu]

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

The answer to all three questions is "no".

[hubblec4]

Could you imagine to implement this?

[Mosu]

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

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

[Mosu]

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

[hubblec4]

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

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

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

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

hubble

[Mosu]

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

[hubblec4]

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

Why and how should a better precision break other tools?

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

Or could you add a SimpleTag for the FPS?

hubble

[Mosu]

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

It's just too risky.

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

[filler56789]

@Mosu:

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

0_o

[Mosu]

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

[filler56789]

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

Many thanks for the attention.

[ChaosKing]

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

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

[sneaker_ger]

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

[gpower2]

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

instead of:

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

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

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

[Mosu]

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

[gpower2]

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

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

[Mosu]

I'm definitely planning on deprecating the verbose info API at some point, yes. This particular bug just highlights one of the reasons why; it's a custom format with custom code and custom bugs. It's a rather bad case of NIH syndrome, and the only excuse I have is not wanting to use XML back when I introduced it.

BTW, I'm not sure whether or not I will fix the aforementioned bug. It would require adding more custom codes to the escaping mechanism; I'm simply not convinced that it's actually worth it.

[gpower2]

Fair enough, I'll get to implementing the JSON parser then! ;)
Thanks for the heads up! :)

[Mosu]

I may actually deprecate the --identify-verbose, --identify-for-gui (similar to --identify-verbose but always in English and never translated) and --identify-for-mmg (old alias for --identify-for-gui) options in the next release. If I do, I won't actually remove the options for another year.

This reminds me that I should really do something about option files, too. Option files use the same escaping functions that --identify-verbose does, meaning that it's currently impossible to use option files to embed line feeds and other special characters. Not that that's actually useful, and no one has ever complained about it, but I will likely introduce JSON as another possible format for option files.

[gpower2]

So the up-to-date options should be:

--identify
--identification-format json

instead of just:

--identify-verbose

Did I get this right?

[Mosu]

That's correct, yes.

[gpower2]

I finally got to set up a VM with Ubuntu in order to check gMKVExtractGUI on Linux. Users reported that the progress bar didn't update while the tracks were extracting.
After a lot of head banging, I realized that mkvextract on Linux writes to Standard Output the string "Progress:###%" followed by the "\r" character instead of "\n".
Unfortunately that really ties my hands since .NET only has an event to read the Standard Output line by line.
Is there any way that this behaviour could change? Or could you offer me an alternative solution for checking on progress? How do you do it in MKVToolNix GUI?

[Mosu]

Well, I'm not a .NET developer, but I'm pretty sure it offers an API for reading output character by character. Just tell mkvextract to use UTF-8 as the output character set, read character by character, and determine a line terminated as soon as either \r or \n arrives.

With mkvmerge the GUI uses the special option "--gui-mode". In that mode mkvmerge ouputs certain lines only meant for consumption by a GUI. The progress is handled via such lines. The output looks like this:

mkvmerge v9.6.0 ('Slave To Your Mind') 64bit
…
'v.avi' track 0: Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 640/352.
#GUI#progress 3%
#GUI#progress 100%
#GUI#progress 100%

The cue entries (the index) are being written...
Multiplexing took 0 seconds.

mkvextract doesn't have such an option for such a mode at the moment. I may add one one day.

It's not a problem for MKVToolNix GUI yet as it doesn't offer an extraction mode yet.

[Mosu]

Addendum: I'm currently implementing progress output in GUI mode for mkvextract. The lines will look the same way as the ones I've shown above. They're terminated with a new line character (\n).

[gpower2]

Well that would be great! Thanks a lot for digging into this! :)

[Mosu]

New pre-builds for Windows (https://mkvtoolnix.download/windows/pre/) are up. They include the --gui-mode enhancement to mkvextract I've mentioned.

[Mosu]

This is a more substantial release. There were a lot of enhancements to the GUI all over the place, several bug fixes in mkvmerge, a couple of enhancements there, too.

Note that this release deprecates the options (e.g. "--identify-verbose") and features. These are scheduled to be removed early in 2018. See the first top-most entry in the ChangeLog below for details.

Notes for package maintainers: MKVToolNix now requires a compiler that supports certain features of the C++14 standard. For gcc v4.9.x or later will work, for clang v3.4 or newer is required. Additionally Qt v5.3.x is now required.

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

The Windows and Mac OS binaries have been built already and are available for download. The Linux binaries will be available later today.

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

2016-12-27 Moritz Bunkus <moritz@bunkus.org>
* Released v9.7.0 "Numbers".
* Deprecation warning: Several options and features are now deprecated and will be removed at the start of 2018. These are: - mkvmerge: the options "--identify-verbose", "--identify-for-gui", "--identify-for-mmg" and "--identification-format verbose". Please convert existing users of these interfaces to use mkvmerge's JSON identification output which can be invoked with "--identification-format json --identify …". - all command line tools: the old, proprietary format used for option files. Please convert users of this interface to the new JSON option file format introduced in this release. - all command line tools: the option "--check-for-updates" (the GUI will keep its online check for updates, though). There is and will be no equivalent interface in the tools themselves. Users of this interface can switch to retrieving the information about available updates directly from the MKVToolNix website. The information is available as JSON and XML files at the following URLs: https://mkvtoolnix.download/latest-release.json.gz https://mkvtoolnix.download/latest-release.xml.gz

2016-12-26 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: added a new track property in JSON/verbose identification mode called "multiplexed_tracks". It's an array of track IDs that describe which of the tracks mkvmerge reports as separate ones were originally part of the same source track (e.g. TrueHD+AC-3 in a single track in MPEG transport streams). Implements #1835 (https://github.com/mbunkus/mkvtoolnix/issues/1835).

2016-12-23 James Almer <jamrial@gmail.com>
* mkvmerge: added support for skipping APE(v2) tags in TTA files.

2016-12-22 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: enhancement: added support for reporting progress in --gui-mode the same way mkvmerge does.
* mkvmerge: bug fix: when using --track-order without specifying all tracks, the track numbers could end up in a way the user did not expect. Now mkvmerge will always assign track numbers for those tracks that are listed in --track-order first. The other tracks are assigned numbers afterwards. Fixes the second part of #1832 (https://github.com/mbunkus/mkvtoolnix/issues/1832).
* mkvmerge: bug fix: when reading Matroska files the movie title was always taken from the first Matroska source file, even if that file didn't have a title set. Fixes one part of #1832 (https://github.com/mbunkus/mkvtoolnix/issues/1832).

2016-12-19 Moritz Bunkus <moritz@bunkus.org>
* all: new feature: all command line tools can now read JSON-formatted option files. Such a file's name must have an extension of ".json" (e.g. "mkvmerge @options.json"). Its content must be a valid JSON array consisting solely of JSON strings.

2016-12-17 Moritz Bunkus <moritz@bunkus.org>
* build system: building the GUI components of MKVToolNix now requires Qt v5.3.0 or newer.

2016-12-16 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: header editor & job output enhancement: added menu entries for saving or closing all open tabs.

2016-12-13 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: chapter editor enhancement: added menu entries for saving or closing all open tabs.
* build system: MKVToolNix now requires a compiler that supports the following features of the C++14 standard: "std::make_unique()", "digit separators", "binary literals" and "generic lambdas". For the GNU Compiler Collection (gcc) this means v4.9.x or newer; for clang it means v3.4 or newer.

2016-12-11 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: MPEG TS/MPLS reader improvements: added support for subtitle tracks that are referenced from the MPLS file as sub-paths in other M2TS files than the main tracks.

2016-12-08 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: re-worked the startup code not to use lock files when trying to open a socket for communicating with an already-running instance. This aims to prevent situations with stale lock files not being cleaned up and the GUI not starting anymore as a result. This might fix or prevent issues like #1805 (https://github.com/mbunkus/mkvtoolnix/issues/1805).
* mkvmerge: teletext subtitle bug fix: fixed the handling of DVB teletext subtitles signaled with data unit ID 0x02 and that contain pages from multiple magazines.

2016-12-05 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: multiplexer enhancement: the file identification process has been re-written to be properly multi-threaded. This allows the user to continue working with the GUI while e.g. playlists from a Blu-ray are identified.

2016-12-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: mkvmerge can now handle Blu-ray playlists from the "BACKUP" sub-directory of a Blu-ray disc.
* MKVToolNix GUI: new multiplexer feature: added a menu entry for copying the title to the destination file name. It will replace the destination file's base name but keep its path & extension.
* MKVToolNix GUI: new multiplexer feature: all positive file identification results will now be cached between runs. This speeds up adding the same file a lot, especially when scanning the same Blu-ray playlists again. Cached results are invalidated automatically with newer MKVToolNix releases or when the source file changes.

2016-12-02 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: multiplexer enhancement: when the user tries to add one of the main Blu-ray index files (index.bdmv, MovieObject.bdmv) the GUI will automatically scan the Blu-ray playlist files and offer them for selection.
* mkvmerge: bug fix: files smaller than 4 bytes were wrongly identified as MPEG transport streams.
* MKVToolNix GUI: multiplexer enhancement: tracks, chapters, tags, attachments not selected for multiplexing will be displayed the same way as other disabled controls. Implements #1819 (https://github.com/mbunkus/mkvtoolnix/issues/1819).

2016-11-30 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: the MPEG transport stream reader was using an outdated format for the "CodecPrivate" element for HDMV TextST subtitles. This has been updated to the current format which only contains the "dialog style element". Existing Matroska files using this outdated scheme can be fixed by running them through mkvmerge v9.6.0 itself or any later release as the old format is automatically converted to the new one when it is read from Matroska files.

Have fun :)

[ndjamena]

um...

The 64 bit installer on fosshub points to:
Downloads\Programs\audacity-win-2.1.2.exe

I downloaded it, it's definitely audacity.

[Mosu]

*sigh* I'll contact their support. Thanks for the heads-up.

Edit: doesn't happen to me at the moment. Please try another browser or clear cookies for FossHub, then reload the MKVToolNix download site on FossHub.

[ndjamena]

It's corrected.

[hubblec4]

Hi Mosu
Thanks alot for your hard work.

* all: new feature: all command line tools can now read JSON-formatted option files.
Such a file's name must have an extension of ".json" (e.g. "mkvmerge @options.json").
Its content must be a valid JSON array consisting solely of JSON strings.

Thats sounds interessting. How different is it to the old option.file.
Could you provide some samples?

[Mosu]

Well, just use the same options you've used before and encode them as a JSON array. There are tons of libraries out there, probably more than one for each programming language. Just use one :) That's the biggest advatange of using a standard file format: you don't have to roll your own string encoding code for mkvmerge's old, proprietary format.

If you want to know how such a file looks, just run the GUI, set up the job the way you want it, use the "show command line" functionality and select the JSON escape mechanism.

[Mosu]

Here's v9.7.1, a hotfix for v9.7.0, which in turn was a more substantial release. There were a lot of enhancements to the GUI all over the place, several bug fixes in mkvmerge, a couple of enhancements there, too.

Note that this release deprecates the options (e.g. "--identify-verbose") and features. These are scheduled to be removed early in 2018. See the first top-most entry in the ChangeLog below for details.

Notes for package maintainers: MKVToolNix now requires a compiler that supports certain features of the C++14 standard. For gcc v4.9.x or later will work, for clang v3.4 or newer is required. Additionally Qt v5.3.x is now required.

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

The Windows and Mac OS binaries have been built already and are available for download. The Linux binaries will be available later today.

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

2016-12-27 Moritz Bunkus <moritz@bunkus.org>
* Released v9.7.1 "Pandemonium".
* MKVToolNix GUI: multiplex tool bug fix: under certain circumstances the GUI was creating invalid JSON files when starting to multiplex resulting in an error message ("JSON option files must contain a JSON array consisting solely of JSON strings").
* Released v9.7.0 "Numbers".
* Deprecation warning: Several options and features are now deprecated and will be removed at the start of 2018. These are: - mkvmerge: the options "--identify-verbose", "--identify-for-gui", "--identify-for-mmg" and "--identification-format verbose". Please convert existing users of these interfaces to use mkvmerge's JSON identification output which can be invoked with "--identification-format json --identify …". - all command line tools: the old, proprietary format used for option files. Please convert users of this interface to the new JSON option file format introduced in this release. - all command line tools: the option "--check-for-updates" (the GUI will keep its online check for updates, though). There is and will be no equivalent interface in the tools themselves. Users of this interface can switch to retrieving the information about available updates directly from the MKVToolNix website. The information is available as JSON and XML files at the following URLs: https://mkvtoolnix.download/latest-release.json.gz https://mkvtoolnix.download/latest-release.xml.gz

2016-12-26 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: added a new track property in JSON/verbose identification mode called "multiplexed_tracks". It's an array of track IDs that describe which of the tracks mkvmerge reports as separate ones were originally part of the same source track (e.g. TrueHD+AC-3 in a single track in MPEG transport streams). Implements #1835 (https://github.com/mbunkus/mkvtoolnix/issues/1835).

2016-12-23 James Almer <jamrial@gmail.com>
* mkvmerge: added support for skipping APE(v2) tags in TTA files.

2016-12-22 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: enhancement: added support for reporting progress in --gui-mode the same way mkvmerge does.
* mkvmerge: bug fix: when using --track-order without specifying all tracks, the track numbers could end up in a way the user did not expect. Now mkvmerge will always assign track numbers for those tracks that are listed in --track-order first. The other tracks are assigned numbers afterwards. Fixes the second part of #1832 (https://github.com/mbunkus/mkvtoolnix/issues/1832).
* mkvmerge: bug fix: when reading Matroska files the movie title was always taken from the first Matroska source file, even if that file didn't have a title set. Fixes one part of #1832 (https://github.com/mbunkus/mkvtoolnix/issues/1832).

2016-12-19 Moritz Bunkus <moritz@bunkus.org>
* all: new feature: all command line tools can now read JSON-formatted option files. Such a file's name must have an extension of ".json" (e.g. "mkvmerge @options.json"). Its content must be a valid JSON array consisting solely of JSON strings.

2016-12-17 Moritz Bunkus <moritz@bunkus.org>
* build system: building the GUI components of MKVToolNix now requires Qt v5.3.0 or newer.

2016-12-16 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: header editor & job output enhancement: added menu entries for saving or closing all open tabs.

2016-12-13 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: chapter editor enhancement: added menu entries for saving or closing all open tabs.
* build system: MKVToolNix now requires a compiler that supports the following features of the C++14 standard: "std::make_unique()", "digit separators", "binary literals" and "generic lambdas". For the GNU Compiler Collection (gcc) this means v4.9.x or newer; for clang it means v3.4 or newer.

2016-12-11 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: MPEG TS/MPLS reader improvements: added support for subtitle tracks that are referenced from the MPLS file as sub-paths in other M2TS files than the main tracks.

2016-12-08 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: re-worked the startup code not to use lock files when trying to open a socket for communicating with an already-running instance. This aims to prevent situations with stale lock files not being cleaned up and the GUI not starting anymore as a result. This might fix or prevent issues like #1805 (https://github.com/mbunkus/mkvtoolnix/issues/1805).
* mkvmerge: teletext subtitle bug fix: fixed the handling of DVB teletext subtitles signaled with data unit ID 0x02 and that contain pages from multiple magazines.

2016-12-05 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: multiplexer enhancement: the file identification process has been re-written to be properly multi-threaded. This allows the user to continue working with the GUI while e.g. playlists from a Blu-ray are identified.

2016-12-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: mkvmerge can now handle Blu-ray playlists from the "BACKUP" sub-directory of a Blu-ray disc.
* MKVToolNix GUI: new multiplexer feature: added a menu entry for copying the title to the destination file name. It will replace the destination file's base name but keep its path & extension.
* MKVToolNix GUI: new multiplexer feature: all positive file identification results will now be cached between runs. This speeds up adding the same file a lot, especially when scanning the same Blu-ray playlists again. Cached results are invalidated automatically with newer MKVToolNix releases or when the source file changes.

2016-12-02 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: multiplexer enhancement: when the user tries to add one of the main Blu-ray index files (index.bdmv, MovieObject.bdmv) the GUI will automatically scan the Blu-ray playlist files and offer them for selection.
* mkvmerge: bug fix: files smaller than 4 bytes were wrongly identified as MPEG transport streams.
* MKVToolNix GUI: multiplexer enhancement: tracks, chapters, tags, attachments not selected for multiplexing will be displayed the same way as other disabled controls. Implements #1819 (https://github.com/mbunkus/mkvtoolnix/issues/1819).

2016-11-30 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: the MPEG transport stream reader was using an outdated format for the "CodecPrivate" element for HDMV TextST subtitles. This has been updated to the current format which only contains the "dialog style element". Existing Matroska files using this outdated scheme can be fixed by running them through mkvmerge v9.6.0 itself or any later release as the old format is automatically converted to the new one when it is read from Matroska files.

Have fun :)

[hubblec4]

Yes, JSON format is very cool :-). I need only two lines of code for reading values.

There is a small different, in JSON format is no "escape mechanism". That makes it easier to generate such an option file.

[Mosu]

Well, you still have to escape " and \ with \, but the JSON libraries usually do that for you already, and you don't have to do it yourself.

[Brazil2]

https://mkvtoolnix.download/downloads.html#windows
Supported Windows versions are Vista and newer.

https://github.com/mbunkus/mkvtoolnix/wiki/Officially-supported-operating-systems-and-versions
Windows
Supported are all desktop versions of Windows (meaning Intel architecture) that Microsoft supports. This means Windows Vista or newer, 32bit and 64bit architectures.

So what is the latest version to officially support Windows XP ?
I can't find this info in the News history, there is a lot about Linux but nothing about Windows.

[Mosu]

Well… the version that was current around the time when Microsoft's extended support ended, which was in April 2014. That would be v6.9.1. Some of the newer versions are known not to work, some others are known to work.

The reason I'm adding news entries about the supported Linux versions is that I offer binaries for those versions, and the news entries are supposed to indicate which versions I stop offering binaries for. Traditionally on Linux you have to build one package for each operating system & version, unlike Windows where you usually only have a single binary that runs on all of them. So there are binaries that might still run on XP, but as I don't have XP anymore I cannot test it (and wouldn't even if I still had XP).

Just assume that I don't offer support for Windows versions for which Microsoft's extended support has ended. However, saying that i "support" Vista would be disingenious; I don't, really, as I don't have such an installation and don't intend to set one up in case of bug reports for Vista, even though Microsoft's extended support for Vista ends in April 2017.

[Brazil2]

OK, thanks for the info.

Latest mention to XP in the changelog was for version 8.0.0:
2015-06-19 Moritz Bunkus <moritz@bunkus.org>
* Released v8.0.0.
* all: the detection whether or not the applications are installed on Windows is done by checking for the presence of a special file in the program folder instead of checking for an entry in the registry written by the installer. This enables users to try new portable versions without having to uninstall an installed version first as their settings will be kept separate now. A side effect is that compatibility with Windows XP should be restored.

For the record, I've just tried latest mkvtoolnix-32bit-9.7.1.7z build on XP SP3 with all updates and it still works pretty fine :)

[Inviska]

I want to transition to Linux but I couldn't find a Linux GUI for MKVExtract. On Windows I use MKV Cleaver, so I thought I'd do something similar in C++/Qt:

http://www.inviska.com/mkvextract/

It's mostly the same as MKV Cleaver but with a few additions, like it shows all elements in the file tree instead of just video, audio and subtitle tracks.

I just had one question about supported codecs and output file formats. Some codecs, such as A_DTS, aren't listed in the MKVExtract documentation (https://mkvtoolnix.download/doc/mkvextract.html#mkvextract.output_file_formats), even though MKVExtract can successfully extract them. I looked at the supported codecs in the Matroska documentation and made a list of the ones not present in the MKVExtract documentation. For the below codecs I was wondering if you could tell me if MKV Extract can extract them, and if so what extension should be used for the outputted file:

/*******************************************************
Codec ID Extension Name
********************************************************
V_UNCOMPRESSED ??? Uncompressed
V_MPEG4/ISO/SP ??? DivX4
V_MPEG4/ISO/ASP ??? DivX5/Xvid/FFMPEG
V_MPEG4/MS/V3 ??? Microsoft MPEG4 V3
V_MPEG1 ??? MPEG1
V_MPEG2 ??? MPEG2
V_QUICKTIME ??? QuickTime Video
V_PRORES ??? Apple ProRes

A_MPEG/L1 ??? MPEG Layer I
A_PCM/INT/BIG ??? PCM
A_PCM/FLOAT/IEEE ??? PCM Floating Point
A_MPC ??? MusePack
A_MS/ACM ??? Microsoft ACM
A_QUICKTIME ??? QuickTime Audio

S_TEXT/WEBVTT ??? WebVTT
S_IMAGE/BMP ??? Bitmap

Sorry if this is a stupid question. I don't know much about video/audio formats. I mostly use MKVToolnix to extract subtitles from one video, retime them and mux them into another source.

Thanks for your help, and thanks for the great work on MKVToolnix.

[Mosu]

I want to transition to Linux but I couldn't find a Linux GUI for MKVExtract. On Windows I use MKV Cleaver, so I thought I'd do something similar in C++/Qt:

Nice :)

Note that mkvextract doesn't care about the file extension. It'll happily write TrueHD data to a file called "audio.dts". Naming is up to the caller of mkvextract.

Here's the list:

/*******************************************************
Codec ID Extension Name
********************************************************
V_UNCOMPRESSED ??? unsupported
V_MPEG4/ISO/SP ??? unsupported
V_MPEG4/ISO/ASP ??? unsupported
V_MPEG4/MS/V3 ??? unsupported
V_MPEG1 mpg, mpeg MPEG elementary stream (there's no real standard for the extension)
V_MPEG2 mpg, mpeg MPEG elementary stream (there's no real standard for the extension)
V_QUICKTIME ??? unsupported
V_PRORES ??? unsupported

A_MPEG/L1 mp1 (?) MPEG Layer I
A_PCM/INT/BIG wav PCM (Big Endian audio is byte-swapped to Little Endian upon extraction)
A_PCM/FLOAT/IEEE ??? unsupported
A_MPC ??? unsupported
A_MS/ACM ??? unsupported
A_QUICKTIME ??? unsupported

S_TEXT/WEBVTT ??? WebVTT (this is a custom format invented by myself only readable by mkvmerge, hence there's no real extension)
S_IMAGE/BMP ??? unsupported

[Inviska]

Nice :)

Note that mkvextract doesn't care about the file extension. It'll happily write TrueHD data to a file called "audio.dts". Naming is up to the caller of mkvextract.

Here's the list:


Thanks a lot for the help. I'll update it with that information and upload a final version.

Then I'll flounder around in Linux and make a Linux build :)

Thanks again.

[hello_hello]

I want to transition to Linux but I couldn't find a Linux GUI for MKVExtract. On Windows I use MKV Cleaver, so I thought I'd do something similar in C++/Qt:

http://www.inviska.com/mkvextract/

One step closer to leaving Windows behind. I'm looking forward to it.
Thank you.

[hello_hello]

MKVToolNixGUI doesn't seem to be displaying the status of a default subtitle track correctly if it's forced. I don't know if that's expected behaviour but it behaves differently for an audio track, where if it's the default track and forced it displays both.

Open an MKV with a subtitle track.
Set the subtitle track to default and forced
Mux
Open the newly created MKV. The subtitle track doesn't show as default.

I checked a few different versions of the new GUI and they all behave the same way. When opening the MKV with MKVMergeGUI 7.8.0 the subtitle track will display as both default and forced.

Thanks.

[Mosu]

Hey,

MKVToolNixGUI doesn't seem to be displaying the status of a default subtitle track correctly if it's forced.

Works just fine for me. I've retraced your steps, and in the resulting Matroska file both flags are set.

Note that the multiplexer shows what the flags will be in the output file, not what they're set to in the source file. The user is usually interested in the outcome, not in the current status.

To verify the flags' actual status use the header editor. The "default track" element should be either absent from the file or present and set to "yes" (being absent means that the flag's default value comes into play, and the default value for the "default track" flag is "yes"). The "forced track" flag should be present and set to "yes".

You should also check the preferences: "Multiplexer" → "Default values" → "Disable 'default track' flag for subtitles".

[Ripman]

Thanks for the new release.

With the implementation of json options files does that mean that the legacy options files are no longer supported? Can I still use legacy options files or do I need to update everything to json? Thanks.

[Mosu]

I'll refer you back to the release announcement where I've spelled out what's deprecated and when those things will be removed.

[hello_hello]

You should also check the preferences: "Multiplexer" → "Default values" → "Disable 'default track' flag for subtitles".

That was the problem. Thanks. I guess I forgot you could mux MKVs and they'd appear to be different when opened them again.... at least in respect to subtitle streams.

[Mosu]

Again, those two columns represent the status of the flags as it will be in the output file. The flags could be different from what they were in the source file even if that preferences option is disabled. For example, when a file contains multiple audio tracks all with "default track" flag set (e.g. produced by a buggy program other than mkvmerge), the GUI would still only show one of those tracks having the "default track" flag set in the output file because that's what mkvmerge will do, too.

The "multiplex" tool is the wrong tool for the job of checking the flags' current status!

[Vincent Vega]

hello Moritz, happy new year, thank you again for all the hard work over the years!!

so i have this lpcm 5.1 track in m2ts (pcm_bluray), if i remux that m2ts to mkv SL ends up as SR, and SR->SL, why is this happening?
alternatively, if i first demux the audio to wav by eac3to, then use that as input for muxing then channels play same way as in m2ts.
eac3to log also mentioned something about channel swapping/remapping, thats probably relevant.

second part of the question, as long as the lpcm tarck is inside m2ts the two surround channels are reported by LAV as SL/SR, if remuxed to mkv LAV still does see them as SL/SR, however AC3filter reports them now as BL/BR.

i could send you a sample of the file but not sure what tool is recommended nowadays for cutting m2ts so pls let me know

[ndjamena]

For 5.1, SL/SR and BL/BR are exactly the same thing. They're only distinct positions for 7.1 or above.

[Mosu]

so i have this lpcm 5.1 track in m2ts (pcm_bluray), if i remux that m2ts to mkv SL ends up as SR, and SR->SL, why is this happening?

Probably because the channel mapping on Blu-ray differs from the one normally used for PCM in WAVs. I don't know much about channel mappings, to be honest. Matroska doesn't have proper support for it yet. There was a discussion about it (https://mailarchive.ietf.org/arch/msg/cellar/HzxRVJouLAtFitvTMWF_ZbHuoKE) a couple of months ago, but nothing came from it.

alternatively, if i first demux the audio to wav by eac3to, then use that as input for muxing then channels play same way as in m2ts.
eac3to log also mentioned something about channel swapping/remapping, thats probably relevant.

Interesting. If you want something similar in mkvmerge, then please open a ticket for it (https://github.com/mbunkus/mkvtoolnix/issues/). I won't have a high priority for me, though.

second part of the question, as long as the lpcm tarck is inside m2ts the two surround channels are reported by LAV as SL/SR, if remuxed to mkv LAV still does see them as SL/SR, however AC3filter reports them now as BL/BR.

No idea.

[hello_hello]

Again, those two columns represent the status of the flags as it will be in the output file. The flags could be different from what they were in the source file even if that preferences option is disabled. For example, when a file contains multiple audio tracks all with "default track" flag set (e.g. produced by a buggy program other than mkvmerge), the GUI would still only show one of those tracks having the "default track" flag set in the output file because that's what mkvmerge will do, too.

I guess I'm used to muxing with mkvtoolnix, and after opening the output file, the way the tracks were set when muxing are always the same.
I simply forget there was an option in preferences to force subtitles to be a non-default tracks, because I rarely set subtitles as default (hence having the option enabled). My fault for having a bad memory.

Cheers.

[Mosu]

There are several other options in the preferences that change how a newly added track's attributes are set, especially around the language. The multiplexer tool is a really bad way to check the state of a file :)

[Vincent Vega]

hi Mosu thanks for reply,
so for quick solution for now, using eac3to to wav/flac first, like i did this time, is what you'd recommend as workaround?
also, this channel mapping issue only pertains to lpcm muxing or any other formats affected too?

couple other things, since i rarely visit -)
about a year ago there was this x265vfw release which i often still use for quick reencodes in virtualdub.
the resulting avi plays fine by lav filters (just need to set fourcc option to HEVC in encoder settings).
however if i remux that avi to mkv i get jerky/stuttery playback. did you ever try that?

and about muxing speeds,
i've been using this nice skylake platform this past year, spacious ramdisk and nvme raid0 array @3GByte/s r/w.
cool thing remuxing mkv->mkv from ramdisk -> the raid0 i get these top speeds of 2GB+ as expected.
but remuxing m2ts->mkv is much slower, never seen peaks of more than 500-600MByte/s, and most of the time even slower.
is that some kind of software bottleneck for m2ts sources? anything i can do in the setup/settings to improve that?
(i'm using 64bit installer mkvtoolnix)

[Mosu]

so for quick solution for now, using eac3to to wav/flac first, like i did this time, is what you'd recommend as workaround?

Yes.

also, this channel mapping issue only pertains to lpcm muxing or any other formats affected too?

As far as I know there are formats for which the channel mapping is part of the specs or part of the bitstream format. For PCM there's no such standard. It's possible that there are other audio formats for which this is a problem, too. Maybe others can chime in with more knowledge.

about a year ago there was this x265vfw release which i often still use for quick reencodes in virtualdub.
the resulting avi plays fine by lav filters (just need to set fourcc option to HEVC in encoder settings).
however if i remux that avi to mkv i get jerky/stuttery playback. did you ever try that?

No. I don't encode on Windows. I'm not particularly interested in trying this combination either. Sorry.

but remuxing m2ts->mkv is much slower, never seen peaks of more than 500-600MByte/s

M2TS is very CPU intensive to parse due to its many small packets and how they're set up. Other formats are much less CPU intensive to parse, among them MP4, Matroska, AVI… There's nothing you can do about it on your end.

Edit: mkvmerge isn't the most efficient program on the planet. I usually focus more on correctness (bug fixing) & features than on performance.

[hello_hello]

There are several other options in the preferences that change how a newly added track's attributes are set, especially around the language. The multiplexer tool is a really bad way to check the state of a file :)

I thought I was losing my mind.

I was playing around with the default option for streams of an undefined language nature, and eventually discovered when I opened an MKV with undefined language streams for the first time, MKVToolNix would apply the set language. If I changed the default language and opened the same file again it kept assigning the language I'd set previously.

The relevant part from the 9.7.1 mkvtoolnix-gui.ini file:

[defaults]
defaultAudioTrackLanguage=abk
defaultVideoTrackLanguage=eng
defaultSubtitleTrackLanguage=eng
defaultChapterLanguage=und
defaultChapterCountry=
defaultSubtitleCharset=
defaultAdditionalMergeOptions=--disable-track-statistics-tags
whenToSetDefaultLanguage=1

Version 9.6.0 and 9.7.1 both opening the same MKV.

https://s23.postimg.org/inx4twe0n/960.gif (https://postimg.org/image/inx4twe0n/)

https://s23.postimg.org/p2w5qkkqf/971.gif (https://postimg.org/image/p2w5qkkqf/)

After much banging of my head on the desk I finally discovered the "MKVToolnix\cache" folder and I are now enemies for life. :(

As a side note, I was a little careless at one stage and accidentally opened mkvtoolnix-gui.exe via the Explorer SendTo menu.
Is that what's referred to an an easter egg? I tried remuxing it, but didn't have any luck.

https://s23.postimg.org/xilq82nlj/mkvtoolnix.gif (https://postimg.org/image/xilq82nlj/)

I'm using the 32 bit portable version of MKVToolNix running on........................................... XP.

[Mosu]

I was playing around with the default option for streams of an undefined language nature, and for some reason when I opened an MKV with undefined language streams for the first time, MKVToolNix would apply the set language. If I changed the default language and opened the same file again it kept assigning the language I'd set previously.

…

After much banging of my head on my desk I finally discovered the "MKVToolnix\cache" folder and I are now enemies for life. :(

Oh yikes, that's definitly a bug. The caching seems to happen after the defaults are set whereas it should happen before that. I'll look into it. Thanks for finding the cause.

[Mosu]

Should be fixed now. New pre-builds for Windows (https://mkvtoolnix.download/windows/pre/) are up.

[Perenista]

I am having a problem with MKVToolnix, I am sure there's an easy explanation for it, yet I don't see the logic behind. I'd appreciate if you can explain briefly what I am doing wrong.

I am using an emulator (ePSXe), plus Fraps, to record at 1080p@60fps. Then I used VirtualDub to save the AVI, using these settings:

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

So far I managed to save 5 hours and over 35 GB. All files were created (by FRAPS) as huge AVIs, then reencoded as AVI again, and I used MKVToolnix to save that AVI as MKV.

After that, when two MKVs were available, I used the option "Append".

For example:

- Fraps records file A1.avi.
- Reencoded as AA1.avi using the Imgur settings
- Opened AA1.avi in MKVToolnix, saved as MKV.

- Fraps records file A2.avi.
- Reencoded as AA2.avi using the Imgur settings
- Opened AA2.avi in MKVToolnix, saved as MKV.

--> Opened AA1.mkv in MKVToolnix, then option Append + selected AA2.mkv.

--> Saved as a single MKV.

I repeated this process until the MKV had 35 GB and over 5 hours.

This worked just fine until my last recording.

In the last recording I disabled the Game Shark code (only one code was being used), and proceeded with the recording using FRAPS, in the same way as before.

This is what I did:

- Fraps records file LAST-1.avi.
- Reencoded as LAST-2.avi using the Imgur settings
- Opened LAST-2.avi in MKVToolnix, saved as MKV.

- Opened LAST-2.mkv in MKVToolnix and specified this:

- Output, Split mode:
After output duration: 00:05:00
Maximum number of files: 2

Why did I do that?

Because the first 5 minutes from LAST-1.avi aren't going to be used. If the file has 10 minutes, that means MKVToolnix will create two files:

LAST-2 (001).mkv (first 5 minutes)
LAST-2 (002).mkv (last 5 minutes)

So after this I did the following:

Opened HUGEFILE.mkv, option Append >>>>>> LAST-2 (002).mkv

And this is what went wrong:

*******
The track number 0 from the file 'G:\LAST-2 (002).mkv' cannot be appended to the track number 0 from the file 'G:\HUGEFILE.mkv'. The track parameters do not match.
*******

Why?

[sneaker_ger]

Show us the MediaInfo logs of "HUGEFILE.mkv" and "LAST-2 (002).mkv". Are the resolutions identical?

[Mosu]

Please post the _full_ output produced by mkvmerge, not just that line.

[Perenista]

Show us the MediaInfo logs of "HUGEFILE.mkv" and "LAST-2 (002).mkv". Are the resolutions identical?I discovered that the last recording was in the 1920x1186 resolution instead of 1920x1182. I didn't even bother to look, since all my recordings were using 1920x1182.

That's odd, it must have been some glitch in Fraps or I accidentally changed the window size. I am playing using the Window mode, to make sure it is recording.

I asked if removing a piece from the video could create that error because that was exactly my first suspicion. All files are reencoded the same way.

[Mosu]

I asked if removing a piece from the video could create that error because that was exactly my first suspicion.

Definitely not, no.

[hello_hello]

Should be fixed now. New pre-builds for Windows (https://mkvtoolnix.download/windows/pre/) are up.

Yes the language settings appear to be behaving now.

Thanks.

[hello_hello]

I may have spoken too soon. Now chapters are displaying oddly. I don't seem to be able to blame the cache folder this time and I can't see a setting that would cause it. The stable version of 9.7.1 doesn't do this, just the pre-build. Pictures to explain. These are the same MKV.

https://s28.postimg.org/ph78ih9g9/Merge1.gif (https://postimg.org/image/ph78ih9g9/)

https://s28.postimg.org/qi7h7lqft/Merge3.gif (https://postimg.org/image/qi7h7lqft/)

[kuchikirukia]

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

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

It does it with TrueHD too.

- Split double episode m2ts w/ TrueHD into individual episodes
- Time subs for second ep in Aegisub
- mux with mkvmerge
Result: Timings are off on playback and re-import into Aegusub

[Mosu]

I may have spoken too soon. Now chapters are displaying oddly.

Meh :) Should be fixed in the latest pre-builds (https://mkvtoolnix.download/windows/pre/).

[hello_hello]

Meh :) Should be fixed in the latest pre-builds (https://mkvtoolnix.download/windows/pre/).

Yep. All better again.

Thanks.

[hello_hello]

A command line question....

I've been experimenting with muxing with AnotherGUI and mkvmerge.exe. You probably don't need to know anything about the program to understand the following command line preset for AnotherUI and to appreciate that it works:

--aspect-ratio 0:16/9 --default-track 2:no "<FullSourceFileName>" --output "<OutputPath><OutputFileName>.mkv"

But is there a way to apply the aspect ratio change to any video stream I'm missing? Something like this (which I know doesn't work):

--aspect-ratio V:16/9

As long as the video stream is one of the first four streams I know I can change it's aspect ratio with this command line, and for the non-video streams it'll be ignored:

--aspect-ratio 0:16/9 --aspect-ratio 1:16/9 --aspect-ratio 2:16/9 --aspect-ratio 3:16/9 --default-track 2:no "<FullSourceFileName>" --output "<OutputPath><OutputFileName>.mkv"

But that leaves the problem of applying a setting to a particular stream type if it can apply to more than one type of stream, such as language or default status. In order to set the subtitle stream to default = no, I have to know the specific subtitle stream number(s). ie

--default-track 2:no --default-track 3:no

Is there any way to apply an option to a specific stream type rather than a stream number I'm yet to discover?

Thanks.

[Mosu]

No, there isn't. There's only the magic track ID -1 which matches all tracks, regardless of their type.

[ndjamena]

--aspect-ratio -1:16/9

will apply it to every track it can be applied to.

[hello_hello]

Thanks guys.

My main reason for asking was because I had to use this version of ffmpeg (https://forum.doom9.org/showthread.php?t=152419) to change the aspect ratio written to some h264 streams, but it doesn't set the container aspect ratio, so I got carried away with making an AnotherGUI preset for it, which led me to then try to create and mkvmerge preset to finish the job, but in the end it all got too hard.
I discovered ffmpeg would only copy a single audio stream (I couldn't get the mapping function to work) and it was making a mess of srt subtitles, so I gave up trying to do anything with it aside from fix the stream display aspect ratio, which means I have to use MKVToolNix manually to add back the other streams and mux a second time.

Bummer.

[SeeMoreDigital]

My main reason for asking was because I had to use this version of ffmpeg (https://forum.doom9.org/showthread.php?t=152419) to change the aspect ratio written to some h264 streams, but it doesn't set the container aspect ratio...
Out of interest. What are your reasons to for needing (mkv) 'container' aspect ration support?

[hello_hello]

Out of interest. What are your reasons to for needing (mkv) 'container' aspect ration support?

After changing the stream aspect ratio the container aspect ratio wouldn't be the same (it's not set at all) and some players only pay attention to one or the other.

As a quick test I took a 4:3 720x480 MKV and changed the stream aspect ratio to 16:9 with the ffmpeg version I linked to.

I know my Bluray player would play it with a 3:2 aspect ratio.

MPC-HC - 3:2
MPC-BE - 3:2
SMPlayer - 3:2
VLC - 16:9
Potplayer - 16:9

MediaInfo displays:
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 3:2
Original display aspect ratio : 16:9

You'd imagine given there's no container aspect ratio set at all, players would look at the stream for guidance, but by default they often don't, so it pays to make sure they're both set correctly.

Edit: I tried doing it the other way around... taking a 4:3 MKV and remuxing it as 16:9 with MKVToolNix without changing the video stream, and all the software players displayed it at 16:9. I started to wonder why I'd bother changing the stream aspect ratio, then I remembered the little resizing dance MPC-HC used to do (opening at 4:3 then switching to 16:9). It doesn't seem to do that any more, but I kind of remember a hardware decoding problem.... maybe.... SMPlayer does it very quickly, and I think one of the standalone players gets upset. I'd have to check though.

[nevcairiel]

You'd imagine given there's no container aspect ratio set at all, players would look at the stream for guidance, but by default they often don't, so it pays to make sure they're both set correctly.

Matroska specification says to use the video resolution as aspect ratio (ie. square pixels) when no explicit value is set (ie. DisplayWidth = PixelWidth by default), so any player that obeys the matroska container aspect ratio would be behaving correctly by using 3:2.

In general for containers that can signal an aspect ratio reliably, its usually wise to also use it in a player.

For your last point, MPC-HC probably stopped doing it once it used my decoders. ;)

[Jamaika]

As a quick test I took a 4:3 720x480 MKV and changed the stream aspect ratio to 16:9 with the ffmpeg version I linked to.
So I think that this is an intentional job creators players. If the aspect ratio in the container matroska is treated as a non-standard then why to think about it?

Examples, import&convert file Matorska (pseudo 4K, aspect ratio 16:9) to ASS subtitles editors:
[Script Info]
; Script generated by Aegisub r8898
; http://www.aegisub.org/
ScriptType: v4.00+
PlayResX: 3840
PlayResY: 1600
PlayDepth: 10
WrapStyle: 0
ScaledBorderAndShadow: no
YCbCr Matrix: TV.601

[Aegisub Project Garbage]
Audio File: D:/filmy/Hobbit.Pustkowie.Smauga.(2013).mkv
Video File: D:/filmy/Hobbit.Pustkowie.Smauga.(2013).mkv
Video AR Mode: 4
Video AR Value: 2.400000
Video Zoom Percent: 0.250000
Video Colorspace: TV.2020 NCL
The enormity of mistakes.

For your last point, MPC-HC probably stopped doing it once it used my decoders. ;)
How to define a screenshot? Picture of monitor screen or picture from the original film.;)

How is the transfer of information during the conversion ffmpeg 20161230?
ffmpeg.exe -i 3840x1600.mkv -i subtitle_noinfosize&colorvideo.ass -f matroska -vf scale=3840:1600:out_color_matrix=bt709:out_range=tv,format=yuv420p -aspect 16/9 -c:v libx264 out.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 12.2 MiB
Duration : 19 min 58 s
Overall bit rate mode : Variable
Overall bit rate : 85.5 kb/s
Movie name : Hobbit - Pustkowie Smauga (2013)
Writing application : Lavf57.61.100
Writing library : Lavf57.61.100 / Lavf57.61.100
ErrorDetectionType : Per level 1 ???
...
Color range : Limited
Matrix coefficients : BT.709 <-- No info for file 8bit

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 19 min 58 s
Width : 3 840 pixels
Height : 1 600 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Writing library : x264 core 148 r2744 b97ae06
...
Color range : Limited
Matrix coefficients : BT.709 <-- No info
Default : Yes
Forced : No
DURATION : 00:00:20.983000000

Text
ID : 3
Format : ASS
Codec ID : S_TEXT/ASS <-- No video parameters in the "vsfilter.dll", ie. size video, aspect ratio, color matrix, color range, depth.

[loa-ash]

guys if I append 2 audio files, and I apply a delay onto second file appended, the result file will have the delay that i've choose?

[sneaker_ger]

The delay applied to the second part will be a timecode gap between part 1 and part 2. It will not be at the front of part 1. If you want the delay to apply to the complete track apply it to part 1 only. Leave the delay for the other parts empty.

[loa-ash]

I've add +1000 ms as delay to file appended as testing, but nothing changed...

I've made this:

audio_A = duration 3 sec
audio_B = duration 20 minutes

audio_A(0delay) [APPEND] audio_B(1000delay) = audio_c.mka

If i play audio_c there isn't the 1000ms of delay after 3 sec.

[Mosu]

mkvmerge always shifts timestamps read from a file so that they're 0-based. That's why an existing delay won't be kept.

However, you can apply that delay when you append. On the command line it looks like this:

mkvmerge -o audio_c.mka audio_a.aac + --sync 0:3000 audio_b.aac

In the GUI you select the appended track and enter something in the "delay" field.

[loa-ash]

Ok I understand where I was wrong. After append the two audio, I used mpc-hc for play audio_c.mka just created and didn't see any difference. Instead I had to mux this audio on a video to see the changes. Am I right?

[sneaker_ger]

The gap will be there either way. MPC-HC/LAV might ignore it when playing audio-only linearly. If you seek behind the gap it should be obeyed. I don't know all the logic behind its sync algo.

[Bigmango]

With version 9.7.1 I regularly get a "JSON chain couldn't be analyzed: parse error - unexpected end of input" error when trying to add files to the multiplexer.

It could be caused by FLAC tracks as all my files have FLAC tracks.

And today I could open a file correctly (without FLAC), but when I tried to add 2 FLAC tracks I had just converted with eac3to, the first FLAC gave this JSON error (so I could add it), but the second track was added correctly.

This seems to be happening only to the windows version (windows 10), opening these same files with the linux version seems to work fine.

[Mosu]

Can you upload one such FLAC file to my FTP server (https://github.com/mbunkus/mkvtoolnix/wiki/FTP-server), please? Also see this FAQ entry (https://github.com/mbunkus/mkvtoolnix/wiki/JSON-output-could-not-be-parsed).

[Bigmango]

Can you upload one such FLAC file to my FTP server (https://github.com/mbunkus/mkvtoolnix/wiki/FTP-server), please? Also see this FAQ entry (https://github.com/mbunkus/mkvtoolnix/wiki/JSON-output-could-not-be-parsed).

Disabling antivirus didn't change anything.

I have sent you the file "1_2_audio.flac".

This file is the result of a DTS-HDMA conversion with eac3to. There were 2 DTS-HDMA tracks converted together. The first track (which I sent you) gives this JSON error on windows (but can be added fine with the linux version), and the second track (which I didn't send) can be added properly as it doesn't give this error.

This is very strange.

Furthermore, I also from time to time (not always) get this error when trying to open mkvs which I have created with this same windows version 9.7.1. (but on linux, same version 9.7.1, I can open these files without any problem).

[nautilus7]

Hi, does mkvmerge support DSD format (the audio format found in SACD)? I have some .dff files and can't mux them into .mka container. Any way to do it? Sample (money.dff) in your ftp.

[Bigmango]

Disabling antivirus didn't change anything.

I have sent you the file "1_2_audio.flac".

This file is the result of a DTS-HDMA conversion with eac3to. There were 2 DTS-HDMA tracks converted together. The first track (which I sent you) gives this JSON error on windows (but can be added fine with the linux version), and the second track (which I didn't send) can be added properly as it doesn't give this error.

This is very strange.

Furthermore, I also from time to time (not always) get this error when trying to open mkvs which I have created with this same windows version 9.7.1. (but on linux, same version 9.7.1, I can open these files without any problem).

Just tested with version 9.7.0. Everything is fine again with this version, so this seems to be a bug with 9.7.1.

Thanks.

[Mosu]

Just tested with version 9.7.0. Everything is fine again with this version, so this seems to be a bug with 9.7.1.

I cannot reproduce your problems here on Windows — neither with 9.7.0, nor with 9.7.1 or the current development snapshot.

It's possible that, for some reason, the GUI's file identification cache contained broken data. Using a different version causes the cached data to be removed, hence why it's working with 9.7.0. It's quite possible that it may work now even if you switch back to 9.7.1.

You should try removing the existing cache directory. If you're using the portable version, it's the "cache" directory next to the MKVToolNix executables. For the installed version look in C:\Users\YourUserName\AppData\Local\bunkus.org\mkvtoolnix-gui.

[Mosu]

Hi, does mkvmerge support DSD format (the audio format found in SACD)? I have some .dff files and can't mux them into .mka container. Any way to do it? Sample (money.dff) in your ftp.

No, mkvmerge doesn't, nor does Matroska in general.

[SeeMoreDigital]

No, mkvmerge doesn't, nor does Matroska in general.That's a real shame.

That said, somebody would then need to create a parser/splitter to support playback of such contained streams ;)

[Bigmango]

You should try removing the existing cache directory. If you're using the portable version, it's the "cache" directory next to the MKVToolNix executables. For the installed version look in C:\Users\YourUserName\AppData\Local\bunkus.org\mkvtoolnix-gui.

Removing this cache directory seems to have fixed the problem.

Thanks.

[Perenista]

I have a video recorded by FRAPS that is using these settings (in terms of Aspect Ratio):
http://i.imgur.com/fX3BhbN.png

If I wanted to use these settings:
http://i.imgur.com/FwJzKds.png

And do not reencode the Matroska, what would I need to do in MKVToolnix? I know there's a setting called "Set aspect ratio", but I don't think that will suffice in this case.

[sneaker_ger]

And do not reencode the Matroska, what would I need to do in MKVToolnix? I know there's a setting called "Set aspect ratio", but I don't think that will suffice in this case.
Why not? Do you want to force black bars on all 4 sides? I think that's indeed not possible. Otherwise just choose AR 1.339 (well, basically 4/3) when muxing using mkvmerge (or add/change the values in exisiting Matroska files using the Header Editor).

[hello_hello]

The MKVToolNix cache folder.....

The way I understand it, creating a cache for MKVToolNixGUI allows it to re-open large files quickly once they've been opened initially, however..... when you're working with large numbers of smaller input files, the cache seems to eventually slow the process down.

I almost always add the initial file or stream to be muxed via the Explorer right click SendTo menu. ie Right Click/SendTo/mkvtoolnix-gui.exe. but as the number of files in the cache folder increases, so too does the amount of time it takes MKVMergeGUI to "get itself ready". If MKVMergeGUI isn't running when I add a file that way, the GUI still opens in a speedy manner, but all the input fields are initially "greyed out", I assume until MKVMerge has finished loading the cache files.

I haven't timed it exactly, but at the moment the cache folder contains 894 files totalling 3.9MB, which doesn't seem excessive (in respect to size), however the time between the GUI opening and the input fields becoming usable would now be close to ten seconds.

I doesn't happen every time the GUI is opened. If I close it and open it again in a short period of time, it opens normally, but if too much time has passed between closing and re-opening, it goes back to taking a long time to become ready. I assume that must due to the cached data still being in RAM, or not, as the case may be.

I deleted the contents of the cache folder a short while ago, and so far that seems to have fixed the slow opening problem, but I've only used MKVToolNix a couple of times since then, so time will tell.

Thanks.

[Mosu]

The way I understand it, creating a cache for MKVToolNixGUI allows it to re-open large files quickly once they've been opened initially, however..... when you're working with large numbers of smaller input files, the cache seems to eventually slow the process down.

Obviously, that shouldn't happen.

If MKVMergeGUI isn't running when I add a file that way, the GUI still opens in a speedy manner, but all the input fields are initially "greyed out", I assume until MKVMerge has finished loading the cache files.

Interesting interaction. The GUI has a cleanup process for the cache directory. It is supposed to remove cache files that were created with an older version. It is run in a separate thread as it isn't supposed to affect normal operation of the GUI, and it's started right when the GUI starts.

The problem here is most likely that every access to the cache directory is guarded by a mutex so that only one thread can access it at any given moment. The cleanup process acquires a lock on this mutex when it starts and releases said lock once it finishes. At the same time the file identification tries to acquire a lock on the same mutex which has to wait until the cleanup process is finished.

A fix might be as trivial as to change the cleanup process to release and re-acquire the lock after each file it has processed. That way the file identifier's lock request can be processed, too.

I doesn't happen every time the GUI is opened. If I close it and open it again in a short period of time, it opens normally, but if too much time has passed between closing and re-opening, it goes back to taking a long time to become ready. I assume that must due to the cached data still being in RAM, or not, as the case may be.

Yeah, that's likely due to OS-level caching.

Thanks for describing this so accurately. It's definitely a bug, and I'll definitely fix it.

[hello_hello]

I have another cache question......

In the past I've tended to load video files/streams into MKVMergeGUI for muxing before they're completed, so today I opened an MKV the x264 encoder was in the process of writing as it encoded and checked the cache file info. I closed MKVTookNixGUI and opened the MKV again. The cache file was overwritten but only the two "objectID" values had changed.

Are the "objectID" values important for correct muxing? I ask because there's a very good chance that after having opened the MKV a second time, I'd leave it loaded in MKVToolNixGUI until x264 has finished encoding, then I'd mux it.
If I remove it from the GUI first though, and open it again after the video encoding has finished, I assume the "objectID" values would change again. If I don't do that, they remain the same in the cache file. Does it matter?

Thanks.

[Mosu]

The GUI uses several pieces of inormation to determine whether the cache entry is still valid: the GUI's version, the file's name/size/last modification timestamp. As the latter two properties change with a file that's still written to, the GUI will invalidate the entry the next time the file must be identified.

I don't know which "objectID" values you mean.

[hubblec4]

The "objectID" is very impotant!
MTX-gui needs this for the correct order (display and muxing).
The "objectID" changes every time when you change the input.

[Mosu]

Ah _that_ objectID.

hubblec4 is not entirely correct. The important thing about the objectID is that it is consistent within the same file so that the track order works correctly. However (!), it is totally unimportant that it changes each time such a cache file is created, and even more important, the objectID does NOT depend on the identification output.

So yes, you can continue using the already-loaded file.

[Mosu]

The way I understand it, creating a cache for MKVToolNixGUI allows it to re-open large files quickly once they've been opened initially, however..... when you're working with large numbers of smaller input files, the cache seems to eventually slow the process down.

This has been fixed in the latest pre-builds (01414 and higher) (https://mkvtoolnix.download/windows/pre/64bit/). The cache cleanup will no longer inhibit the file identification from running, and cache cleanup will only be done once per release of MKVToolNix.

[hello_hello]

This has been fixed in the latest pre-builds (01414 and higher) (https://mkvtoolnix.download/windows/pre/64bit/). The cache cleanup will no longer inhibit the file identification from running, and cache cleanup will only be done once per release of MKVToolNix.

Thanks. I'll give it a spin and report back.

[v0lt]

I have a problem with converting some MPEG-2 files. After packing in MKV files are not played back smoothly in MPC-BE and MPC-HC.
The problem would be solved enabling the option "enable time correction". But it's not the best solution.

What is it? Incorrect operation of mkvtoolnix or the player?

Here are the first 10 timestamps that gives spitter.
Frame: 0, TimeCode: 138
Frame: 1, TimeCode: 58
Frame: 2, TimeCode: 98
Frame: 3, TimeCode: 258
Frame: 4, TimeCode: 178
Frame: 5, TimeCode: 218
Frame: 6, TimeCode: 378
Frame: 7, TimeCode: 298
Frame: 8, TimeCode: 338
Frame: 9, TimeCode: 498
Frame: 10, TimeCode: 418

And here is another file. It played good.
Frame: 0, TimeCode: 680
Frame: 1, TimeCode: 720
Frame: 2, TimeCode: 840
Frame: 3, TimeCode: 760
Frame: 4, TimeCode: 800
Frame: 5, TimeCode: 960
Frame: 6, TimeCode: 880
Frame: 7, TimeCode: 920
Frame: 8, TimeCode: 1080
Frame: 9, TimeCode: 1000
Frame: 10, TimeCode: 1040

[Aleksoid1978]

Player must playback such files normal - upload short sample.

[v0lt]

mpeg2_25i_normal.mkv and mpeg2_25i_unsmooth.mkv (https://cloud.mail.ru/public/Lmye/SZQkqtYeU)

PS: I tried to check these files on my Sony TV, but it does not support MPEG-2 video in MKV files.

Added:
Maybe this problem comes from MPC-BE and LAV decoders. This problem occurs on all system renderer. That is not with Haali and madVR.
If I use Microsoft DTV-DVD Video Decoder, the problem goes away for all renderers except Haali (there is a black screen).

[Aleksoid1978]

mpeg2_25i_normal.mkv and mpeg2_25i_unsmooth.mkv (https://cloud.mail.ru/public/Lmye/SZQkqtYeU)

PS: I tried to check these files on my Sony TV, but it does not support MPEG-2 video in MKV files.

"Bug" in video-decoders, in timestamp handle logic. Both files playback smooth with ffplay.exe and also in MPC-BE with MPEG-2 decoder(libmpeg2).

[SeeMoreDigital]

Hi v0lt,

Both files play okay on my Panasonic when cast via UPnP.

However, when I tried de-muxing and re-muxing the .mkv files they both appeared to be buggy :(

[Mosu]

A nice new release is here, v9.8.0. Couple of enhancements, a couple of bug fixes, especially for the new caching functionality introduced in 9.7.0. I recommend upgrading.

Notes for package maintainers: important changes were made to the build process. Please see the NEWS section below for details (both the "important news" and the "build system changes" sections).

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

The Windows and Mac OS binaries have been built already and are available for download. The Linux binaries will be available later today.

Here are the NEWS (https://mkvtoolnix.download/doc/NEWS.md) since v9.7.1:

# Version 9.8.0 "Kuglblids" 2017-01-22

## Important notes

* build system: the included version of the "drake" build tool has been removed. Since Ruby 2.1 rake has supported parallel builds, too. The MKVToolNix build system has been adjusted to enable parallel builds by default.

## New features and enhancements

* mkvmerge: VobSub in Matroska: mkvmerge will now create and use a default index for VobSub tracks read from Matroska files that are missing their CodecPrivate element (which normally contains said index). Implements #1854 (https://github.com/mbunkus/mkvtoolnix/issues/1854).
* GUI: added checks for several common problems with the installation. These checks will be executed when the GUI starts, and any problems will be reported to the user.
* mkvmerge: added the ISO 639-2 language codes "qaa" and "qad" (both are titled "reserved for local use") as both are used often in France. See #1848 (https://github.com/mbunkus/mkvtoolnix/issues/1848) for more information.
* mkvmerge: the JSON identification result now includes a track's codec delay if set (only for Matroska source files). The JSON schema version has been bumped to 6.
* mkvmerge: MPEG TS: added a workaround for files where the subtitle packets are multiplexed properly, but where their timestamps are way off from the audio and video timestamps. Implements #1841 (https://github.com/mbunkus/mkvtoolnix/issues/1841).
* mkvmerge: added support for Digital Video Broadcasting (DVB) subtitles (CodecID `S_DVBSUB`). They can be read from MPEG transport streams and from Matroska files. Implements #1843 (https://github.com/mbunkus/mkvtoolnix/issues/1843).

## Bug fixes

* mkvmerge: MP4 reader: when an MP4 file contained fewer entries for timestamps than frames (which they never should), mkvmerge would use 0 as the timestamp for all the other frames. This resulted in effects such as the last frame of an output file having a timestamp of 0 and in split files having a much longer duration than they should have. Fixes #1847 (https://github.com/mbunkus/mkvtoolnix/issues/1847).
* GUI: the cache cleanup process that's run automatically when the GUI starts no longer blocks file identification until it is finished. Additionally the process will only be run once per release of MKVToolNix. Fixes #1860 (https://github.com/mbunkus/mkvtoolnix/issues/1860).
* GUI: certain failures during file identification that can be traced to broken installations (e.g. mkvmerge being too old) won't be stored in the cache anymore. Without this fix the GUI would still use the cached failed identification result even though the underlying might have already been fixed.
* mkvmerge: fixed that the error message "not enough space on disk" was shown twice on some operating systems. Fixes #1850 (https://github.com/mbunkus/mkvtoolnix/issues/1850).
* mkvmerge, Matroska: if a codec delay is set for a track in the input file, it is kept. Fixes #1849 (https://github.com/mbunkus/mkvtoolnix/issues/1849).
* GUI: multiplexer: changing default values in the preferences (e.g. the default track language to set) did not affect files whose identification results had already been cached.
* mkvmerge, MP4: fixed detection of MP3 audio when the object type ID in the ESDS signals MP2 and the track headers have invalid values for number of channels or sampling frequency. Fixes #1844 (https://github.com/mbunkus/mkvtoolnix/issues/1844).

## Build system changes

* nlohman json-cpp: configure now looks for a system-wide installed version of the nlohmann json-cpp header-only library. If one is found, it is used; otherwise the included version will be used. Implements #1858 (https://github.com/mbunkus/mkvtoolnix/issues/1858).
* If MKVToolNix is built with rake v10.0.0 or newer, its "multitask" feature will be turned on allowing automatic parallel builds.
* CURL is no longer used by MKVToolNix and is therefore not required for building anymore.

## Other changes

* GUI: the update check now uses Qt's networking classes instead of CURL.
* The command line option "--check-for-updates" has been removed, even though the deprecation warning in release 9.7.0 stated that it would be removed in 2018.

Have fun :)

[videoh]

Thanks, Mosu!

Update thread title?

[jmartinr]

On fosshub the link to the 64bit installer points to an android img file.

[Mosu]

Works fine for me. Clear your browser's cookies, reload the download page, try again. If the problem persists, then please contact the [url=https://www.fosshub.com/contact.htmlFossHub staff[/url]. They're usually pretty quick to fix such issues.

[jmartinr]

It's ok now.

[Q-the-STORM]

I have a feature request:
Can you make it possible inject HDR metadata in x264 video?

only applications I know that can do it are from avtop, SEIedit (250€) and HDRmaster (500€).

I found a modified version of mkvmerge that seems to be able to do it: https://github.com/YouTubeHDR/hdr_metadata
but my TV (LG E6) doesn't detect the metadata.

[Selur]

@Q-the-STORM: https://github.com/SK-Hardwired/nv_hevc_hdr_patcher might be worth a look.

[Mosu]

Can you make it possible inject HDR metadata in x264 video?

I won't add such functionality.

[hello_hello]

Originally Posted by Mosu
This has been fixed in the latest pre-builds (01414 and higher). The cache cleanup will no longer inhibit the file identification from running, and cache cleanup will only be done once per release of MKVToolNix.

Thanks. I'll give it a spin and report back.

Just letting you know there's been no slowdown when opening files since prebuild 01414 and version 9.8.0

Thanks.

[kuchikirukia]

Just had a power outage. When I restarted mkvmerge, it attempted to redo the last 7 muxes. Thankfully it only overwrote a BDMV remux, which I can redo.

[Mosu]

The GUI writes the modified job files as soon as they're modified. However, the operating system does its own caching, and it's quite normal that such changes stay cached quite a while before they're finally written to disk — especially if the disk is otherwise fully engaged (by writing files via mkvmerge, for example). When a power outage happens, that cached content is lost. Such is life.

Modern file systems only guarantee that they don't suffer structural damage during outages, not that no data is lost. There are ways (a forced flush of the caches), but those do slow down other operations.

Power outages and similar sudden problems (e.g. pressing the hardware reset button) suck.

[hello_hello]

Currently I have MKVToolNixGUI configured so that completed jobs are only removed from the queue if completed without errors or warnings. Rather than have jobs "completed with warnings" sit in the queue until I manually delete them, or until they're automatically removed after "x number of days" (if that option is enabled), when the right click option in the Multiplex window to acknowledge all warning or errors is used, would it make sense for it to also automatically remove the jobs that created those warnings and errors from the queue? I think it does to me. Thanks.

[Mosu]

I disagree. Sorry.

[hello_hello]

Could there be an option? It's just that I almost never use the Acknowledge All Warnings option because I've still got to manually switch to the job tab to remove those jobs manually, which effectively acknowledges all the warnings when they're removed, making the Acknowledge All Warnings function somewhat obsolete. At least for me.

The only time MKVToolNixGUI makes me want to cry a little is when I have to switch to the Job tab to remove a job with a warning because acknowledging that warning didn't get it done, or when I have to switch to the Job tab to abort running jobs, because I still always click the Job Queue tab first expecting to find the Abort button there (my brain apparently insists I'm aborting a job in the queue and won't accept anything else), or when I move the mouse to click the Start Job Queue button at the bottom of the Job Queue window, because the Multiplex tab has a Start Multiplexing button in exactly the same way the Job Queue tab doesn't have a Start Waiting Jobs button, and that still confuses me. ;)

Seriously though, I don't know what it is about the Abort button. I kind of get why it's to be found under the Job Output tab but my brain thinks of that as the "log file" tab and wants all the Job Queue functionality to be found in the Job Queue tab, and I can't get my brain to stop thinking that way. To this day I've still not managed to go directly to the Job Output tab to abort a running job. Oh well..... :)

[Mosu]

I won't add such an option. I simply don't think that being able to configure each and every tiny little thing makes the program easier to use for the majority of users. Additionally, every option I implement adds complexity that I have to test and maintain. Sorry.

[hello_hello]

That's okay, but still being willing to argue.... :)

There's an option to automatically remove jobs resulting in warnings or errors from the queue. If it makes sense to have an option to acknowledge warnings, and an option to remove jobs resulting in warnings from the queue automatically, but to remove them before they're acknowledged, I'll confess the logic escapes me. It almost like highlighting a file in Explorer, hitting delete, watch it disappear, then have Windows confirm you want to delete it.

The "remove jobs with errors/warnings" option seems a little dumb to me because if you don't notice there's a warning or error till after the job completes and you've closed it in the multiplex tab, you've got to re-create it from scratch instead of editing it from the job queue. If I'd acknowledged the warning first though....

For every "acknowledge warning" menu/button found in the GUI, an additional "acknowledge warning and delete job" button/menu would make sense to me, given you can acknowledge warnings under three different tabs in five different places, making it not so much of a little thing.

All hope is not lost though. You can acknowledge and delete in one go by deleting a job from the queue, although that's not without some irony given there's no way to delete a job from the queue without also acknowledging the warning it created.

It's all perspective I guess..... and of course it's your software and up to you. All the work is appreciated anyway. Cheers. :)

[raymondjpg]

Latest version of mkvextract.exe 9.8.0 throws an error on some (not all) mkvs in MeGUI. Reverted to backup (v9.7.1) which still works OK.

I am no expert, but running version 9.8.0 at the command prompt on one of the "problem" mkvs gives "error in the matroska file structure...Resyncing to the next level 1 element". Seems 9.8.0 doesn't like some older mkvs. The new version seemed to work OK in MeGUI on newer mkvs that I had created using recent version of MKVToolNix GUI.

If I am right in my conclusions, will all future versions of mkvextract.exe have this same difficulty with older mkvs?

[Midzuki]

Latest version of mkvextract.exe 9.8.0 throws an error on some (not all) mkvs in MeGUI. Reverted to backup (v9.7.1) which still works OK.

I am no expert, but running version 9.8.0 at the command prompt on one of the "problem" mkvs gives "error in the matroska file structure...Resyncing to the next level 1 element". Seems 9.8.0 doesn't like some older mkvs. The new version seemed to work OK in MeGUI on newer mkvs that I had created using recent version of MKVToolNix GUI.

If I am right in my conclusions, will all future versions of mkvextract.exe have this same difficulty with older mkvs?

You should have "defined" your "problematic MKVs".
In other words, an MKVinfo report at least, or a sample file if possible.

[raymondjpg]

You should have "defined" your "problematic MKVs".
In other words, an MKVinfo report at least, or a sample file if possible.
MKVinfo report of one of the "problem" files:

+ EBML head
|+ EBML version: 1
|+ EBML read version: 1
|+ EBML maximum ID length: 4
|+ EBML maximum size length: 8
|+ Doc type: matroska
|+ Doc type version: 4
|+ Doc type read version: 2
+ Segment, size 1099639116
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 4044)
|+ Segment information
| + Timecode scale: 1000000
| + Multiplexing application: libebml v1.3.0 + libmatroska v1.4.1
| + Writing application: mkvmerge v7.0.0 ('Where We Going') 64bit built on Jun 22 2014 08:19:39
| + Duration: 2589.088s (00:43:09.088)
| + Date: Thu Oct 01 02:02:40 2015 UTC
| + Segment UID: 0xea 0x4a 0xd7 0xd1 0x3b 0x3e 0xeb 0x42 0x48 0xf0 0x8a 0x12 0x89 0x65 0x10 0x04
|+ Segment tracks
| + A track
| + Track number: 1 (track ID for mkvmerge & mkvextract: 0)
| + Track UID: 1
| + Track type: video
| + Lacing flag: 0
| + MinCache: 1
| + Codec ID: V_MPEG4/ISO/AVC
| + CodecPrivate, length 43 (h.264 profile: High @L4.1)
| + Default duration: 41.708ms (23.976 frames/fields per second for a video track)
| + Video track
| + Pixel width: 1280
| + Pixel height: 720
| + Display width: 1280
| + Display height: 720
| + A track
| + Track number: 2 (track ID for mkvmerge & mkvextract: 1)
| + Track UID: 9028823705323146958
| + Track type: audio
| + Codec ID: A_AC3
| + Default duration: 32.000ms (31.250 frames/fields per second for a video track)
| + Language: und
| + Audio track
| + Sampling frequency: 48000
| + Channels: 6
|+ EbmlVoid (size: 1100)
|+ Cluster

[Mosu]

I am no expert, but running version 9.8.0 at the command prompt on one of the "problem" mkvs gives "error in the matroska file structure...Resyncing to the next level 1 element".

That is not an error, it's a warning. If MeGUI treats warnings as something fatal, then that's a bug in MeGUI. The warning is intentional in that it notifies the user of potential loss of data due to corruption.

My guess (!) is that MeGUI treats an exit code of 0 as success and anything else as a fatal error. That's not how mkvextract (and my other tools) work:

Exit code 0 = everything was OK
Exit code 1 = there were non-fatal warnings
Exit code 2 = there was a fatal error
Anything else = there is a bug in the tool, because this should never happen

Situations such as the one mentioned above should generate a warning and have mkvextract exit with exit code 1. MeGUI should treat that as "well, it did something, and the user probably wants to see the warning in question", not as "that did not work at all".

The problem is really two things: your broken file and MeGUI's handling of such a situation (if my guess at what's happening is correct). The old behavior of mkvextract was just wrong; it was lying about how successful it was — it was still encountering the issue and trying to deal with it. It just wasn't signalling this to the calling process (meaning it would exit with exit code 0 even though there was a warning, which is simply wrong). The new behavior is the correct one as it gives the calling tool more information about what actually happened.

[raymondjpg]

Thanks for your explanation. The mkvextract.exe warning message did indeed appear for both v9.8.0 and v9.7.1 when run with the "problem" file at the command prompt, but delivered output as required in both cases. So it looks as if the issue is with MeGUI tolerating the warning in v9.7.1, but not v9.8.0. I'll keep using v9.7.1 until MeGUI updates to tolerate v9.8.0, if indeed that happens in time.

[hubblec4]

Hi Mosu

Short question:
Are there deprecated language codes which you filter and transform, like country codes(gb,tp)?

[Mosu]

Yes, there are:

scr → hvr
scc → srp
mol → rum

[arrgh]

hi
I have a feature request...
with MPC-BE/LAV-Filters /XySubFilter/madVR one can playback 3D-mkv like those produced with MakeMKV;

if for some reasons one needs to remux/rebuild such files one needs to preserve the individual 3D-plane for each subtitle...

one can do this by adding a small tag file (XML format, see appended txt-example) to each individual subtitle stream...

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE Tags SYSTEM "matroskatags.dtd">

<Tags>
<Tag>
<Simple>
<Name>3d-plane</Name>
<String>6</String>
</Simple>
</Tag>
</Tags>

http://www.bilder-upload.eu/show.php?file=53958d-1486497309.jpg

it would be easier just to input this, like for example the delay...

Best Regards

[raymondjpg]

The problem is really two things: your broken file and MeGUI's handling of such a situation (if my guess at what's happening is correct). The old behavior of mkvextract was just wrong; it was lying about how successful it was — it was still encountering the issue and trying to deal with it. It just wasn't signalling this to the calling process (meaning it would exit with exit code 0 even though there was a warning, which is simply wrong). The new behavior is the correct one as it gives the calling tool more information about what actually happened.
I have found that mkvextract.exe 9.8 causes MeGui to exit with an error when processing most of the mkv files in my archives. The behaviour is not just confined to the one file I posted details on, which you suggest is "broken".

As a result I have reverted to mkvextract.exe 9.7.1 which does not cause MeGui to exit with an error.

I'm sure that non-technical users would prefer a version of mkvextract.exe that works with MeGui than to know that the new behaviour of mkvextract.exe 9.8 is the correct one.

Ideally I'm sure that non-technical users would prefer to see mkvextract.exe 9.8 working well with all mkv files in MeGui.

[Mosu]

If the file structure is really broken, then exiting with a proper warning is the right course of action. It's really up to MeGUI to handle such cases by not aborting. Like I said, a warning isn't fatal, therefore MeGUI shouldn't treat it as such.

That being said: it's possible that there's a bug in mkvextract: it might show a warning about the file structure in situations where none is warranted. If you can provide me with such a file to test, I'll look into it.

[raymondjpg]

That being said: it's possible that there's a bug in mkvextract: it might show a warning about the file structure in situations where none is warranted. If you can provide me with such a file to test, I'll look into it.
Thank you!

I have uploaded the file I first had problems with, Bones S11E01.

[Mosu]

The file you've uploaded is indeed damaged at the end. The last valid element is located at position 1099639165 with a size of three bytes, meaning the valid content ends at 1099639168. However, the file is 1099639253 bytes long. The difference, 85 bytes, is made up solely of 0 bytes. That's not valid Matroska data. Therefore the warning is indeed valid and not bogus.

The header of that file states that it was written by mkvmerge 7.0.0. I don't know why it wrote such trailing 0 bytes, and neither do I remember a bug regarding such behavior.

I consider mkvextract's current behavior to be correct. Please ask the MeGUI author to treat warnings in mkvextract's execution (= exit code 1) as non-fatal.

[raymondjpg]

The file you've uploaded is indeed damaged at the end. The last valid element is located at position 1099639165 with a size of three bytes, meaning the valid content ends at 1099639168. However, the file is 1099639253 bytes long. The difference, 85 bytes, is made up solely of 0 bytes. That's not valid Matroska data. Therefore the warning is indeed valid and not bogus.

The header of that file states that it was written by mkvmerge 7.0.0. I don't know why it wrote such trailing 0 bytes, and neither do I remember a bug regarding such behavior.

I consider mkvextract's current behavior to be correct. Please ask the MeGUI author to treat warnings in mkvextract's execution (= exit code 1) as non-fatal.
Thank you for looking. I will pass the suggestion on in the MeGUI thread.

[hubblec4]

Yes, there are:

scr → hvr
scc → srp
mol → rum

Many thanks for this info.

[raymondjpg]

I consider mkvextract's current behavior to be correct. Please ask the MeGUI author to treat warnings in mkvextract's execution (= exit code 1) as non-fatal.
The issue has been resolved in MeGUI v2703 without me needing to ask the MeGUI author. mkvextract.exe 9.8 is now working in MeGUI v2703 without error.

Thanks again.

[arrgh]

hi
I have a feature request...
with MPC-BE/LAV-Filters /XySubFilter/madVR one can playback 3D-mkv like those produced with MakeMKV;

if for some reasons one needs to remux/rebuild such files one needs to preserve the individual 3D-plane for each subtitle...

one can do this by adding a small tag file (XML format, see appended txt-example) to each individual subtitle stream...

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE Tags SYSTEM "matroskatags.dtd">

<Tags>
<Tag>
<Simple>
<Name>3d-plane</Name>
<String>6</String>
</Simple>
</Tag>
</Tags>

http://www.bilder-upload.eu/show.php?file=53958d-1486497309.jpg

it would be easier just to input this, like for example the delay...

Best Regards

...takes so long to approve even a small txt...

obviously the value "6" is just an example and must be replaced by the correct individual subtitle value

[Mosu]

The issue has been resolved in MeGUI v2703 without me needing to ask the MeGUI author. mkvextract.exe 9.8 is now working in MeGUI v2703 without error.

That's good to hear!

[Mosu]

if for some reasons one needs to remux/rebuild such files one needs to preserve the individual 3D-plane for each subtitle...

If you remux directly from the source Matroska file, then the tags for the track should be kept intact. No need to specify them anew.

[arrgh]

If you remux directly from the source Matroska file, then the tags for the track should be kept intact. No need to specify them anew.

...Mosu,
Sorry, if I might sound harsh, but have you looked lately in the options you provide for subs…?
“language”,.. ”default”,…”forced”,… “delay”,… “stretch”…
But “3d-plane” is not significant…?

I accept it, since I have a work-around and the other 95% do work super-good (don’t get me wrong, I’m happy!), but I think the standardizing process in this respect (handling of 3D-mkv) should be accelerated…

Best Regards
arrgh

[Mosu]

...Mosu,
Sorry, if I might sound harsh, but have you looked lately in the options you provide for subs…?
“language”,.. ”default”,…”forced”,… “delay”,… “stretch”…
But “3d-plane” is not significant…?

"Language", "default", "forced" all correspond to certain track header fields. "delay" and "stretch" affect the timestamp calculation. All of these things are officially supported elements of the Matroska specification.

Your "3d plane" tag is an unofficial tag that some players use to affect something. Big difference.

but I think the standardizing process in this respect (handling of 3D-mkv) should be accelerated…

What's lacking is manpower and people actually knowledgeable and passionate about these things. Regarding 3D video I'm neither. We (as in the Matroska team and the CELLAR working group (https://datatracker.ietf.org/wg/cellar/charter/)) welcome anyone including you to join in the standardization effort (https://www.ietf.org/mailman/listinfo/cellar) that's currently underway. Work on 3D things would most likely be welcome by a lot of people, but it will only get done if people actually step up and do the work. That's how it works with Free/Libre and Open Source software.

[kuchikirukia]

Arrrrgh, it just happened again. Had a power outage and it started remuxing everything muxed since February 8th, and that was a HUUUUUGE list. Thankfully it only screwed one file and was a minor inconvenience for one other since I had to go and fix its UID.

Can we get a big "Abort Job Queue" button?

[sneaker_ger]

How does that happen? Mosu mentioned something about OS caching but February 8th ...

[kuchikirukia]

How does that happen? Mosu mentioned something about OS caching but February 8th ...

Don't know. I don't even have write cache flushing disabled. I'm only using Windows 10's default write cache.

Wasn't just mkvtoolnix, either. I had another program revert a setting I had changed days earlier.
Windows 10 really needs a place to submit bug reports.

[ndjamena]

I just remuxed a recorded ts file, there's a section 50 minutes in where it looks like there were problems with the signal, the audio skips on playback and there's some minor pixelation. The ts plays back fine on MPC-HC but upon remuxing with MKVMerge the audio and video after that point in the resulting MKV goes about a second out of sync.

FFMPEG remuxes it fine and its MKV plays back without issue.

Is this expected behaviour for MKVMerge with this kind of material?

[Mosu]

Can we get a big "Abort Job Queue" button?

Nope. Not every functionality deserves its own button. The function you're looking for is "Job queue" tool → "Job queue" menu → "Stop job queue" → "Abort all running jobs and stop immediately", or Alt+7 Alt+j t i.

Wasn't just mkvtoolnix, either. I had another program revert a setting I had changed days earlier. Windows 10 really needs a place to submit bug reports.

If power outages are such a common occurrence, and if your computer reacts that badly to them, then I highly suggest you buy a UPS. Those nice devices can protect against power surges, bridge short power outages and shut down the computer cleanly in case the power outage lasts longer.

[Mosu]

Is this expected behaviour for MKVMerge with this kind of material?

I'm not quite sure how to take this question. To me it sounds like "is mkvmerge supposed to create defective files", to which the answer is obviously "no". mkvmerge is supposed to produce a properly working Matroska file in case of a properly working source file. If it isn't, then chances are it's a bug.

[Mosu]

It's time for v9.9.0 of MKVToolNix. This is mostly a bug fix release. Especially the MP4 input module has received a lot of love. See below for details.

Important note for packagers: pre-built man pages are no longer included. Instead they're built during compilation requiring xsltproc, the DocBook XSL stylesheets. Additionally the system version of pugixml can now be used. See the news below for details.

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

The Windows and Mac OS binaries have been built already and are available for download. The Linux binaries will be available later today.

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

# Version 9.9.0 "Pick Up" 2017-02-19

## New features and enhancements

* GUI: chapter editor: added a character set selection in the preferences for text files. If a character set is selected there, it will be used instead of asking the user when opening text chapter files. Implements #1874 (https://github.com/mbunkus/mkvtoolnix/issues/1874).
* GUI: multiplexer: added a column "character set" to the "tracks, chapters and tags" list view showing the currently selected character set for that track. Implements #1873 (https://github.com/mbunkus/mkvtoolnix/issues/1873).
* mkvmerge: added an --engage option "all_i_slices_are_key_frames" for treating all I slices of an h.264/AVC stream as key frames in pathological streams that lack real key frames. Implements #1876 (https://github.com/mbunkus/mkvtoolnix/issues/1876).
* GUI: running programs after jobs: added a new variable <MTX_INSTALLATION_DIRECTORY> for the directory the MKVToolNix GUI executable is located in.
* mkvmerge: DVB subtitle tracks whose CodecPrivate data is only four bytes long will now be fixed up to the proper five bytes by adding the subtitling type byte.
* mkvmerge: MP4 reader: "ctts" version 1 atoms are now supported.

## Bug fixes

* mkvmerge: AC-3 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 #1864 (https://github.com/mbunkus/mkvtoolnix/issues/1864).
* mkvmerge: MP4 reader: mkvmerge was only reading a small part of MP4 DASH files where the first "moov" "mdat" atoms occur before the first "moof" atom. This is part of the fix for #1867 (https://github.com/mbunkus/mkvtoolnix/issues/1867).
* mkvmerge: MP4 reader: edit list ("edts" atoms) that are part of the "moof" atoms used in MP4 DASH files weren't parsed. Instead the edit lists from the main track headers inside the "moov" atom were used. This is part of the fix for #1867 (https://github.com/mbunkus/mkvtoolnix/issues/1867).
* mkvmerge: MP4 reader: when an MP4 DASH file contained both normal chunk offset table ("stco"/"co64" atoms) in their regular "moov" atoms, a sample-to-chunk table ("stsc" atom) whose last entry had a "samples per chunk" count greater than 1 and DASH "trun" atoms, then mkvmerge was calculating wrong positions the frame content. This is part of the fix for #1867 (https://github.com/mbunkus/mkvtoolnix/issues/1867).
* mkvmerge: MP4 reader: mkvmerge couldn't deal with the key frame index table having duplicate entries. The result was that only key frames up to and including the first duplicate entry were marked as key frames in the output file. All other frames weren't, even though some of them were referenced from the key frame table after the first duplicate entry. This is part of the fix for #1867 (https://github.com/mbunkus/mkvtoolnix/issues/1867).
* mkvmerge: MP4 reader: when an MP4 file contained more than one copy of the "moov" atom (the track headers etc.), mkvmerge was parsing them all adding tracks multiple times. Fix for #1877 (https://github.com/mbunkus/mkvtoolnix/issues/1877).
* mkvmerge: MP4 reader: fixed an integer overflow during the timestamp calculation leading to files with wrong timestamps. Such files could not be played back properly by most players. Fixes #1883 (https://github.com/mbunkus/mkvtoolnix/issues/1883).
* mkvmerge: MPEG TS reader: if the PMT lists a DVBSUB track, mkvmerge will now recognize it without having to find a packet for it within the probed range.
* mkvmerge: splitting by parts (both the "timestamps" and the "frames" variants): fixed the calculation of track statistics tags. When calculating the duration the skipped portions weren't taken into account leading to a too-high duration. As a consequence the BPS tag (bits per second) was wrong, too. Fixes #1885 (https://github.com/mbunkus/mkvtoolnix/issues/1885).
* mkvmerge: reading files with DVB/HDMV TextSV subtitle tracks with invalid CodecPrivate caused mkvmerge to abort with an error from boost::format about the format string not having enough arguments. Fixes #1894 (https://github.com/mbunkus/mkvtoolnix/issues/1894).
* mkvmerge: fixed misdetection of certain AC-3 files as MP3 files which led to an error message that "the demultiplexer could not be initialized".
* mkvmerge: fixed huge memory consumption when appending big Matroska files with sparse tracks (e.g. forced subtitle tracks). The Matroska reader will now queue at most 128 MB of data. Fixes #1893 (https://github.com/mbunkus/mkvtoolnix/issues/1893).
* mkvmerge: MP4 reader: the timestamps of all multiplexed tracks will now be 0-based properly.
* mkvmerge: MP4 reader: the DTS-to-PTS offsets given by the "ctts" atoms are now applied for all tracks containing a "ctts" atom, not just h.264 & h.265 tracks.

## Build system changes

* Up to and including release 9.8.0 the man pages and their translations came pre-built and bundled with the source code. Those pre-built files have now been removed and must be built during the build process. Therefore the tool "xsltproc" and the DocBook XSL stylesheets for man pages are now required dependencies. Additionally the tool "po4a" must be installed for the translated man pages to be built and installed, though this is optional.
In order to facilitate finding the new requirements new options have been added to confiure: "--with-xsltproc=prog", "--with-docbook-xsl-root=dir", "--with-po4a=prog" and "--with-po4a-translate=prog.
* pugixml detection will be attempted via "pkg-config" first. If that fails, "configure" will fall back to the previous method of trying just to compile and link a test program with the standard include and library locations. Implements #1891 (https://github.com/mbunkus/mkvtoolnix/issues/1891).

Have fun :)

[Midzuki]

Many :thanks: for yet another update.

Hmmm, I wasn't aware that the MP4 container is even more evil than I thought :D

[Rinzler]

Hi, Mosu. I would like to ask about mkvtoolnix and TS files. I have some ts files. Here is Media Info

Video

Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Bit rate : 7 457 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First



Audio

Format : AC-3
Format settings, Endianness : Big
Codec ID : 6
Duration : 2mn 58s
Bit rate mode : Constant
Bit rate : 384 Kbps
Channel(s) : 6 channels


I need to remux them to mkv. Should I use software like tsMuxer first to extract streams and then use mkvtoolnix or I can just safely add those ts files in mkvtoolnix?

[Mosu]

Never demultiplex to elementary streams if at all possible. That loses important information such as but not limited to: the timestamps (regarding potential gaps in the track or mixed frame rate), the relationship between the timestamps of all tracks (e.g. video starts 40ms later than audio), track languages…

Just let mkvmerge read the transport stream directly.

Important exception: if you're multiplexing from Blu-rays, don't use the .m2ts files directly. Use the playlists instead (the .mpls files). mkvmerge is able to retrieve much more data from them, e.g. which .m2ts make up that particular playlist, track languages, chapter information. The GUI, if used, can also scan all playlists for you and present you with a nice dialog with information about all playlists such as length, number and types of tracks, size, where you can decide which playlist to actually use.

[Rinzler]

One more question about frame rate. Original ts files are 25.000 fps. I noticed that some file (basically with 720x576 resolution, it does not affect HD videos for some reason) after remux have 50fps in mediainfo. I guess this is because of interlaced video. Is there a way to change it? And should I bother about it at all?

[Mosu]

Matroska does not have an FPS setting. See this FAQ entry (https://github.com/mbunkus/mkvtoolnix/wiki/Wrong-frame-rate-displayed). Don't try to play with it unless you know what you're doing as mkvmerge is already doing the right thing.

[ndjamena]

One more question about frame rate. Original ts files are 25.000 fps. I noticed that some file (basically with 720x576 resolution, it does not affect HD videos for some reason) after remux have 50fps in mediainfo. I guess this is because of interlaced video. Is there a way to change it? And should I bother about it at all?

I think you'll find those files are h264 (h265) where the fields are stored separately rather than as a single frame. MKVMerge puts each of the fields in their own packet, leaving 50 packets per second. MKVMerge then writes the number of packets into the NUMBER_OF_FRAMES track statistics tag and MediaInfo translates that as being 50fps.

I assume this would be the cause of your issue:
Scan type, store method : Separated fields

[Rinzler]

Got it. Thank you for the explanation.

[hubblec4]

Important exception: if you're multiplexing from Blu-rays, don't use the .m2ts files directly. Use the playlists instead (the .mpls files). mkvmerge is able to retrieve much more data from them, e.g. which .m2ts make up that particular playlist, track languages, chapter information. The GUI, if used, can also scan all playlists for you and present you with a nice dialog with information about all playlists such as length, number and types of tracks, size, where you can decide which playlist to actually use.

There is one limitation:
If the Bluray have seamless branching multi-editions, you should demux the streams first (with eac3to).
MTX is not able to skip the identical frames.

[73ChargerFan]

I did not know that! I assumed the different versions would be stored linearly in unique playlists, like Disney BDs which offer multiple playlists that localize the written language, e.g. signs, titles, credits.

Any limitation on duplicate audio packets being removed? Does mkvmerge not function the same as eac3to's second pass?

[hubblec4]

I did not know that! I assumed the different versions would be stored linearly in unique playlists, like Disney BDs which offer multiple playlists that localize the written language, e.g. signs, titles, credits.

What you mean, are Multi-Angle-Blurays and there is the same behaviour like Multi-Edition-Blurays. All different content of the movie is stored in different m2ts files.


Any limitation on duplicate audio packets being removed? Does mkvmerge not function the same as eac3to's second pass?

No and no.

I have much Multi-Edition-Blurays tested. With some there was no problems, and for the other: all play fine but the chapter marks don't match correctly. After using my Multi-Editon-Editor from cE with "demux-mode" all works excellent.

Hey Mosu,
Could you implement such functionality? Or is it to much work?

[Overdrive80]

Hi, folks.

I am merging ts files with mkvmerge but I can not get that all characters of teletex subtitle be shown properly. In concrete, characters: á, é, í, ó, ú, ñ. One sample here (mega:///#!MRAzTaDA!JwYZf8xOEk-LICwW2M16ea6XcfuJomaT5RoZURrbfR0).

I tried several charset without being able to get it. Any help?? Thanks.

[Mosu]

MTX is not able to skip the identical frames.

That is correct. I currently don't have plans to implement such functionality.

[Mosu]

I am merging ts files with mkvmerge but I can not get that all characters of teletex subtitle be shown properly. In concrete, characters: á, é, í, ó, ú, ñ.

Teletext pages use their own, country-dependent character sets. There's no way to detect them unambiguously. Therefore mkvmerge uses a mapping that depends on the track language, and there's currently no way to override this.

[hubblec4]

Hey Mosu,

Could you explain/show me where and how VOB-Buttons are stored in Matroska.
I found no info in Matroska specs, expect you can use/save such data.

[Mosu]

Not really. Yes, mkvmerge supports such files, but that code was contributed by Steve Lhomme who did some experiments with the whole DVD menu system. I've never used it myself. Sorry.

[ndjamena]

I just ripped a vob file from an NTSC DVD using MKVMerge, remuxed the resulting MKV using TS muxer, then ran the ts file through ccextractor and the 608 captions were still in the video stream...

Is that intentional behaviour? Theoretically if a player could be told they're there those captions should be playable directly from the MKV. In the same situation MakeMKV simply removes them.

What is the correct Matroska way of handling 608 captions in a video stream?

[hubblec4]

Not really. Yes, mkvmerge supports such files, but that code was contributed by Steve Lhomme who did some experiments with the whole DVD menu system. I've never used it myself. Sorry.

I have here a VOB-Button test file. I could find out the VOB-Buttons will be stored as a "normal" track.

[Ripman]

Thanks for the 9.9 update.

I mostly use the command line, but have tried to use the GUI also since the switchover - to help identify things after the big changes.

Anyway, I thought we could use Ctrl-U to set the mkv title in the new GUI. Did this feature get retired?

Not important or anything tbh - if it something to address say as much and I'll put it in github.

[Ripman]

A few months back I asked if MKVToolnix would ever support dsf audio files. At the time, I believe you were not aware of the audio format's details and uses, so I supplied some info.

Most of the music download sites offer dsf downloads now (hdtracks, acoustic sounds, etc.).

Would you consider implementing support for dsf/dsd in MKVToolnix?

I'll try to dig up a dsf/dsd specification doc. [edit: here is the dsf file format spec from Sony. http://dsd-guide.com/sites/default/files/white-papers/DSFFileFormatSpec_E.pdf]

[Mosu]

Anyway, I thought we could use Ctrl-U to set the mkv title in the new GUI. Did this feature get retired?

It's still available, but its hotkey has been changed. See the "Multiplexer" menu for which hotkey to use. The reason for that change was to have the global hotkeys match the menu hotkeys (e.g. pressing "f" while the "Multiplexer" menu is open invokes the same action as pressing "Ctrl+F" while not in a menu).

[Mosu]

Would you consider implementing support for dsf/dsd in MKVToolnix?

Not at the moment, no. Nor in the near future.

[VAMET]

Dear Friends

I would like to ask, are there any possibilites to change video and audio tags in .mkv file?

I would like to change tags for video: "Length" and for audio: "Bit rate", "Channels", "Audio sample rate". I know I can use --tags track:a1:audio.xml and leave .xml file empty and audio tags will be removed, but I would like to change them as above. I don't want to autocalculate using --add-track-statistics-tags, I would like to add my custom ones.

I would be glad for your help and support.

Thank you in advance.

Sincerely

[sneaker_ger]

What's preventing you from setting --disable-track-statistics-tags and adding custom tags via xml?

[VAMET]

Dear sneaker_ger

What's preventing you from setting --disable-track-statistics-tags and adding custom tags via xml?

I don't want to double audio tags like "Bit rate", I would like to edit exist tags. So are there any possibility to change audio tags like "Bit rate"? I know I can change via mkvpropedit "Channels", "Audio sample rate", but there is no possibility to override "Bit rate" tag.

Sincerely

[sneaker_ger]

If you want to edit tags you need to extract the tags (as xml), edit the xml and re-add them via mkvpropedit or mkvmerge. (or create them from scratch instead of extracting them first)

https://mkvtoolnix.download/doc/mkvextract.html#mkvextract.description.tags
https://mkvtoolnix.download/doc/mkvmerge.html#mkvmerge.tags
https://mkvtoolnix.download/doc/mkvpropedit.html

That said, I have no idea why you would want to edit the bitrate tag ("BPS"). The one calculated by mkvmerge is correct as far as I can see. So if you edit it you will most likely end up with a wrong value.

[VAMET]

Dear sneaker_ger

Thank you for your time and help. All I need is "BPS", but when I use this below .xml file, I have a result with 0kb/s for video and audio "Bit rate", when I view information about .mkv file. Is something wrong with this .xml file? File contains only two tracks: 1 - video, 2 - audio.

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE Tags SYSTEM "matroskatags.dtd">

<Tags>
<Tag>
<Targets>
<TrackUID>1</TrackUID>
<TrackUID>2</TrackUID>
</Targets>
<Simple>
<Name>BPS</Name>
<String>700kb/s</String>
</Simple>
</Tag>
</Tags>

I will be glad for your help and support.

Sincerely

[sneaker_ger]

Yes, something like that. But drop the "kb/s", the unit is already implied. Of course I can't see if the UIDs are correct without the complete mkv file. But if this achieves your end goal (which you have not explained) is a different question altogether. You say "I have a result with 0kb/s for video and audio "Bit rate"" but I don't know what you are talking about. I still recommend to let mkvmerge calculate everything automatically instead.

[VAMET]

Dear sneaker_ger

I don't think NAME=BPS and STRING=<SOME_BPS> is working, when I use NAME=TITLE and STRING=<SOME_TITLE> it's OK.

I just want to put BPS to be custom thats all and it's for my private purpose. But as I said earlier I cannot manage to do it. Maybe I am doing something wrong with this .xml file. Maybe you will try on any media file of your own and change BPS to any other value.

Thank you for your time and help.

EDIT

OK, I know what was the problem with BPS :) I want to set 640kb/s and in string I put 640 and everytime I have a result of 0kb/s. BPS should be set as 640000 for 640kb/s. My fault, everything works as it should. Thank you once again for your help.

Sincerely

[sneaker_ger]

Yes, "BPS" is short for "bits per second", not "kilobits per second". I overlooked that as well.

[hubblec4]

@VAMET

You could use my chapterEditor, there is a Matroska Tags editor which can read Tags directly from a Matroska file.
Tags editing was never so easy :-)

[VAMET]

Dear Friends

I have used command: mkvmerge.exe --identify <input> and have the below results:

Track ID 0: video (MPEG-H/HEVC/h.265)
Track ID 1: audio (DTS)
Track ID 2: audio (AC-3/E-AC-3)
Track ID 3: audio (DTS-HD Master Audio)
Track ID 4: audio (DTS-HD Master Audio)
Track ID 5: subtitles (SubRip/SRT)
Track ID 6: subtitles (SubRip/SRT)
Track ID 7: subtitles (SubRip/SRT)
Track ID 8: subtitles (SubRip/SRT)
Track ID 9: subtitles (SubRip/SRT)
Track ID 10: subtitles (SubRip/SRT)
Track ID 11: subtitles (SubRip/SRT)
Track ID 12: subtitles (SubRip/SRT)
Chapters: 28 entries

As you can see Track ID 3 and 4 have got the same name DTS-HD Master Audio. When I use MKVToolNix I can see language of this audio track, but when using command line there is no such possibility. Maybe there is other command used with --identify to have something like below:

Track ID 0: video (MPEG-H/HEVC/h.265)
Track ID 1: audio (DTS) eng
Track ID 2: audio (AC-3/E-AC-3) eng
Track ID 3: audio (DTS-HD Master Audio) eng
Track ID 4: audio (DTS-HD Master Audio) spa
Track ID 5: subtitles (SubRip/SRT) eng
Track ID 6: subtitles (SubRip/SRT) spa
Track ID 7: subtitles (SubRip/SRT) rus
Track ID 8: subtitles (SubRip/SRT) myn
Track ID 9: subtitles (SubRip/SRT) pol
Track ID 10: subtitles (SubRip/SRT) hun
Track ID 11: subtitles (SubRip/SRT) nor
Track ID 12: subtitles (SubRip/SRT) swe
Chapters: 28 entries

EDIT

I am preparing my own script and I would like to recognize language of audio and subtitles tracks via command line.

Thank you in advance for your help and support.

Sincerely

[Mosu]

Use mkvmerge's JSON output. It includes the language, among other things, and is trivial to parse as there are JSON parsers for pretty much every language out there:

mkvmerge --identification-format json --identify your-file.ext

or its much shorter version:

mkvmerge -J your-file.ext

[VAMET]

Dear Friends

I have got .mkv file with below tracks:

Track ID 0: video (MPEG-H/HEVC/h.265)
Track ID 1: audio (AC-3/E-AC-3)
Track ID 2: audio (AAC)
Track ID 3: audio (TrueHD Atmos)
Track ID 4: subtitles (SubRip/SRT)
Track ID 5: subtitles (SubRip/SRT)
Track ID 6: subtitles (SubRip/SRT)
Track ID 7: subtitles (SubRip/SRT)
Track ID 8: subtitles (SubRip/SRT)
Chapters: 10 entries

I have used command:

mkvmerge --output <output.mkv> --video-tracks 0 --compression 0:none --audio-tracks 3 --compression 3:none --no-subtitles --no-buttons --no-track-tags --no-chapters --no-attachments --no-global-tags <input.mkv>

After that I have checked properties of the file <output.mkv> under Windows 10 and there are video and audio tabs. For video everything is correct - "Duration", "Resolution", "BPS", "Total BPS" and "FPS", but for audio there is only visible value for "BPS". For two other fields: "Channels", "Audio sample rate" there are empty fields without any values. I have checked headers under MKVToolNix and in audio section there are 48000Hz and 8 Channels.

I have also tested the same for .mkv file with DTS-HD MA 7.1 and in this case properties of such .mkv file under Windows 10 is correct for every field in video and audio section.

Why there is a problem for TrueHD Atmos 7.1 (48000Hz, 24 bit)?

EDIT

I have also used command:

mkvpropedit --add-track-statistics-tags <input.mkv>

...but again for TrueHD Atmos 7.1 there are no values for "Channels" and "Audio sample rate", but for DTS-HD MA 7.1 (48000Hz, 24 bit) there isn't any problem.

I would be glad for any help and support.

Sincerely

[AYColumbia]

Hey, I recorded a video with my phone and had the phone upside down (turned 180 deg) so the mp4 has a rotation of 180 degrees on it. When I remux it to an MKV it plays with the video upside down. So my stupid question is this, did the phone actually record the video upside down since I hastily had it that way and added the 180 deg rotation meta data so players that support it will read it and play the video properly right side up? Or, does the phone record video right side up all the time and uses the meta data to tell the player how it should be played? I guess what I'm getting at is, does the remuxed MKV actually show the video the way it was recorded and does MKV support rotation meta data and that to get it correctly turned right side up I'll have to reencode it? Thanks.

Also, I did some poking around and it doesn't look like the MKV spec has support for rotation which would mean asking for it to be added, I guess to the header editor, would probably not be useful at this point right?

[Mosu]

The Matroska specs has no provisions for rotating the content (or for storing the recording device's orientation). You're out of luck here.

[Mosu]

Another month, another release of MKVToolNix: v10.0.0. It's solely a bug fix release, and the number of fixes in this release is on the small side.

Nothing's changed for packagers.

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

The Windows and macOS binaries have been built already and are available for download. The Linux binaries will be available later today.

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

# Version 10.0.0 "To Drown In You" 2017-03-25

## New features and enhancements

* mkvmerge: AVC/h.264 parser: mkvmerge will now drop all frames before the first key frame as they cannot be decoded properly anyway. See #1908 (https://github.com/mbunkus/mkvtoolnix/issues/1908).
* mkvmerge: HEVC/h.265 parser: mkvmerge will now drop all frames before the first key frame as they cannot be decoded properly anyway. See #1908 (https://github.com/mbunkus/mkvtoolnix/issues/1908).
* mkvmerge: HEVC/h.265 parser: added a workaround for invalid values for the "default display window" in the VUI parameters of sequence parameter sets. Fixes #1907 (https://github.com/mbunkus/mkvtoolnix/issues/1907).

## Bug fixes

* mkvmerge: MP4 reader: fixed track offsets being wrong in certain situations regarding the presence or absence of edit lists ('elst' atoms) & composition timestamps ('ctts' atoms). Fixes #1889 (https://github.com/mbunkus/mkvtoolnix/issues/1889).
* mkvmerge: MP4 reader: offsets in "ctts" are now always treated as signed integers, even with version 0 atoms.
* mkvinfo: the timestamps of SimpleBlocks with negative timestamps are now shown correctly.
* mkvmerge: Matroska reader: fixed handling BlockGroups and SimpleBlocks with negative timestamps.
* mkvmerge: MP3 packetizer: the MP3 packetizer will no longer drop timestamps from source containers if they go backwards. This keeps A/V in sync for files where the source was in sync even though their timestamps aren't monotonic increasing. Fixes #1909 (https://github.com/mbunkus/mkvtoolnix/issues/1909).
* mkvmerge: AVC/h.264 parser: mkvmerge will now drop timestamps from the source container if no frame is emitted for that timestamp. Fixes #1908 (https://github.com/mbunkus/mkvtoolnix/issues/1908).
* mkvmerge: HEVC/h.265 parser: mkvmerge will now drop timestamps from the source container if no frame is emitted for that timestamp. Fixes the HEVC equivalent of the problem with AVC described in #1908 (https://github.com/mbunkus/mkvtoolnix/issues/1908).
* mkvextract: SSA/ASS: fixed extraction when the "Format" line in the "[Events]" section contains less fields than the default for SSA/ASS would indicate. Fixes #1913 (https://github.com/mbunkus/mkvtoolnix/issues/1913).

Have fun :)

[mata7]

hi guys, can someone please tell me if there a way of when i open a file mkv or bluray playlist whit multiple audio and subtitles tracks can mkvtoolnix disable or uncheck all audio and sub and keep only the english check

thanks in advanced

[sneaker_ger]

Preferences>Multiplexer>Enabling tracks

[mata7]

Preferences>Multiplexer>Enabling tracks

thanks that is what i have enable, but every time that i open a file or bluray playlist it have all language track check and i just want the english

[sneaker_ger]

Does mkvextract prepend SPS/PPS from CodecPrivate to an H.264 stream even when using the --raw switch?

[Mosu]

No. "--raw" causes mkvextract to write the block content as-is without any format-specific interpretation. It's not really all that useful.

[vidschlub]

Hi guys, I googled for MKValidator and came across this thread.

I'm re-encoding some files using FFMPeg (x265) and a ALL files are spitting out errors like.
WRN00C: Unknown element in Video [55][B0] at 480 (size 8 total 11)
I've decided this is probably not too bad, since they all do it, yet all the files work.

However, I'm also getting
WRN0C0: First Block for video track #1 in Cluster at 99223249 is not a keyframe
WRN0C0: First Block for video track #1 in Cluster at 204950185 is not a keyframe

For a few files
Problem is I've re-encoded multiple times and keep getting that, yet the source file (x264) doesn't have that error.

Any ideas?

[albt]

I have a feature request:
Can you make it possible inject HDR metadata in x264 video?

only applications I know that can do it are from avtop, SEIedit (250€) and HDRmaster (500€).

I found a modified version of mkvmerge that seems to be able to do it: https://github.com/YouTubeHDR/hdr_metadata
but my TV (LG E6) doesn't detect the metadata.

i have the same problem.

[albt]

@Q-the-STORM: https://github.com/SK-Hardwired/nv_hevc_hdr_patcher might be worth a look.

it says for nvenc.

[Selur]

Yes, but may be it could be adjusted to x265/x264, personally I think this is something that should be done in a separate tool and not in mkvtoolnix, since it is not really mkv specific.

[albt]

Yes, but may be it could be adjusted to x265/x264, personally I think this is something that should be done in a separate tool and not in mkvtoolnix, since it is not really mkv specific.

yes i know, i didn't ask mkvtoolnix to do that as it has nothing to do with mkv, but any other tool, for example can you add it in hybrid? :D

[Selur]

Hybrid is a frontend (GUI) for other tools and doesn't manipulate anything itself. :)
-> if there's a free cli tool I could use in Hybrid I would add support for it.

[albt]

tested the nv_hevc_hdr_patcher but didn't work, gave me a corrupted file.

[Selur]

no surprise there,... never thought it would work without modifications,...

[gpower2]

Hey Mosu, a Linux user of gMKVExtractGUI reported here (https://forum.doom9.org/showthread.php?p=1801448#post1801448) that mkvextract doesn't respect the --ui-language switch and outputs the messages according to the system locale. You could see the gMKVExtractGUI log in this post: https://forum.doom9.org/showthread.php?p=1801465#post1801465
From the log, it seems that mkvmerge does respect the --ui-language switch...

Have you any thoughts on this?

[Mosu]

If you're trying to parse the progress from the program output, then you should use the option "--gui-mode". This will make mkvextract (and also mkvmerge) output specially-formatted lines that

are prefixed with "#GUI#" and
that are always in English no matter which user interface language has been selected.

For the progress those lines look like this: "#GUI#progress 12%".

That's what MKVToolNix GUI does, too, in order to ensure that certain control messages can always be parsed by the controlling GUI.

[gpower2]

Thanks for the quick answer!
Any luck remembering in which version --gui-mode landed on mkvextract?

[Mosu]

The change was commit d6d9f40 (https://github.com/mbunkus/mkvtoolnix/commit/d6d9f4007e279fe208603f540ac9af779f77b884). The first release to contain that commit was 9.7.0.

[gpower2]

Thanks Mosu!

[Mosu]

You're welcome.

[sneaker_ger]

There's a small discussion about HEVC HDR metadata here (https://forum.doom9.org/showthread.php?p=1803902). I'm wondering if mkvmerge should be changed to copy the corresponding SEIs (payLoadTypes 137 and 144) into CodecPrivate. Otherwise the data could be missed on seeking. (I assume the same applies to AVC.)

(HEVC sample with HDR metadata (https://www.sendspace.com/file/jgdvep))

[Mosu]

I can definitely think about it. Please open an issue over on Github for it. Thanks.

[sneaker_ger]

I don't know if you have read the discussion I linked but nevcairiel argued having the SEI only before the first IDR frame might be wrong anyways. I'm currently looking through the HEVC specs and I believe he is (like so often) correct. I guess I'll bring this up to the x265 developers instead.

[Mosu]

thanks that is what i have enable, but every time that i open a file or bluray playlist it have all language track check and i just want the english

As your screenshot shows, you have configured the GUI to *always* enable audio tracks, regardless of what their language is. Therefore the list below isn't even considered. Uncheck the checkboxes "audio" and "subtitles", and the GUI will only enable audio/subtitle tracks whose language is on your "selected" list.

[Mosu]

Here's release v11.0.0 of MKVToolNix. There have been several important bug fixes to the HEVC/h.265 and AVC/h.264 parsers. Among the fixed bugs are some that will silently produce invalid files. I therefore recommend everyone to update.

This release includes a couple of smaller enhancements to the GUI as well. Noteworthy is the implementation of features that have been requested several in the past: playing a sound or shutting down the computer after the current job's been completed. The implementation is very flexible and not limited to those two actions, though.

There have been several changes the package maintainers should be aware of. See the section "build system changes" below for details.

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 11.0.0 "Alive" 2017-04-22

## New features and enhancements

* mkvmerge: FLAC reader: added support for handling embedded pictures as attachments. Implements #1942 (https://github.com/mbunkus/mkvtoolnix/issues/1942).
* mkvmerge: MP4 reader: merged pull request #1804 (https://github.com/mbunkus/mkvtoolnix/issues/1804) adding support for parsing the "COLR" atom and including its values as track headers.
* MKVToolNix GUI: watch jobs: the user can now have the GUI execute an action once as soon as the current job or the whole queue finishes. The actions are the same ones that can be configured to be run automatically after job or queue completion.
* MKVToolNix GUI: implemented several built-in actions that can be executed either on special events or once via the "watch jobs" tool. These are: playing an audio file (implemented for all operating systems); hibernating, sleeping and shutting down the computer (only implemented for Windows and for Linux systems using systemd).
* MKVToolNix GUI: multiplex tool: added a new option for what to do after starting to multiplex/adding to the job queue: "close current settings" will close the current multiplex settings without opening new ones.

## Bug fixes

* mkvmerge: AAC parser: fixed mis-detection of certain data as valid ADTS AAC headers resulting in memory allocation failures. Fixes #1941 (https://github.com/mbunkus/mkvtoolnix/issues/1941).
* mkvmerge: AVC/h.264 parser: mkvmerge will now ignore bogus timing information in the sequence parameter sets (values indicating more than 100000 progressive frames per second). Fixes #1946 (https://github.com/mbunkus/mkvtoolnix/issues/1946).
* mkvmerge: AVC/h.264 & HEVC/h.265 parsers: all trailing zero bytes will now be removed from NALUs. Fixes #1952 (https://github.com/mbunkus/mkvtoolnix/issues/1952).
* mkvmerge: HEVC/h.265 parser: fixed copying the `bitstream_restriction_flag` and all dependent fields in the VUI parameters of the sequence parameter sets. Fixes #1924 (https://github.com/mbunkus/mkvtoolnix/issues/1924).
* mkvmerge: HEVC/h.265 parser: fixed the calculation of the number of parameter set arrays in the HEVCC data structure stored in CodecPrivate. Fixes the video-related part of #1938 (https://github.com/mbunkus/mkvtoolnix/issues/1938).
* mkvmerge: HEVC/h.265 parser: fixed writing superfluous and uninitialized bytes at the end of the HEVCC data structure stored in CodecPrivate. Another fix for the video-related part of #1938 (https://github.com/mbunkus/mkvtoolnix/issues/1938).
* mkvmerge: HEVC/h.265 parser: fixed the assumption that the HEVCC data structure always includes arrays for all parameter set types (VPS, SPS, PPS and SEI), and that the order is always VPS → SPS → PPS → SEI. Instead now only the arrays actually present are parsed, and they can be in any order. This fixes mkvinfo's output for Matroska files created from files such as the one from #1938 (https://github.com/mbunkus/mkvtoolnix/issues/1938).
* mkvmerge: AVC/h.264 packetizer: when reading a framed track (e.g. from Matroska or MP4 files), specifying a default duration as fields (e.g. `50i`) would result in double the actual duration for each frame and the track's default duration header field. Fixes #1916 (https://github.com/mbunkus/mkvtoolnix/issues/1916).
* mkvmerge: Matroska reader: invalid track language elements are now treated as if they were set to `und` = "undetermined". See #1929 (https://github.com/mbunkus/mkvtoolnix/issues/1929) for context.
* mkvmerge: MPEG TS reader, AAC: mkvmerge will now require five consecutive AAC headers with identical parameters before track type determination is considered valid. This avoids false positives and consequently wrong track parameters. Fixes the audio-related part of #1938 (https://github.com/mbunkus/mkvtoolnix/issues/1938).
* mkvmerge: fixed an endless loop in certain circumstances when splitting by `parts` or `parts-frames` and the start of the file is discarded. Fixes #1944 (https://github.com/mbunkus/mkvtoolnix/issues/1944).
* MKVToolNix GUI: multiplexer tool: the "show command line" dialog will no longer include the mkvmerge executable's location as the first argument for the two "MKVToolNix option files" escape modes. Fixes #1949 (https://github.com/mbunkus/mkvtoolnix/issues/1949).
* MKVToolNix GUI, header editor: empty track language elements are now treated the same as those set to invalid ISO 639-2 codes: as if they were set to `und` = "undetermined". See #1929 (https://github.com/mbunkus/mkvtoolnix/issues/1929) for context.

## Build system changes

* bug fix: configure now looks for the `strings` binary by using the `AC_CHECK_TOOL()` autoconf macro. That way it will be found in multiarch setups, too. Fixes #1923 (https://github.com/mbunkus/mkvtoolnix/issues/1923).
* bug fix: the environment variable USER_CXXFLAGS was accidentally removed from the compiler flags in release 9.8.0. It's been re-added. Fixes #1925 (https://github.com/mbunkus/mkvtoolnix/issues/1925).
* The `.desktop` files have been renamed to `org.bunkus.mkvtoolnix-gui.desktop` and `org.bunkus.mkvinfo.desktop`. This allows Wayland compositors to associate the correct icons with running applications for e.g. task switchers. Fixes #1948 (https://github.com/mbunkus/mkvtoolnix/issues/1948).
* Qt's multimedia component is required for compilation of the GUIs since version 11.0.0.

Have fun :)

[NikosD]

Great jump in numbering.

No incremental 10.1.0, 10.2.0 etc versions ?

I think we are going to see "huge" numbers like 20, 40 ... 90 too soon.

[Mosu]

See this reply (https://www.bunkus.org/blog/2017/04/mkvtoolnix-v11-0-0-released/comment-page-1/#comment-25157) for more information about the change to version numbering.

I think we are going to see "huge" numbers like 20, 40 ... 90 too soon.

Sure. At ~ten releases per year we'll get to 90 real soon now (as in: in eight years).

[NikosD]

You maybe right, I hadn't been keeping records of the number of releases per year.

My impression was around at 20 to 30 releases per year.

If it's only 10, we are OK I suppose.

Hope that doesn't keep you from releasing a new version harder than before :)

[Mosu]

Increasing the version number is still the same amount of work. It shouldn't have any influence on the other work at all :)

[sneaker_ger]

Thanks.

So many bug fixes for HEVC and AVC (14 years old!) in every release... Can't wait for their next codec with 1000 pages specification.

[Mosu]

AVC and HEVC are incredibly complex beasts. And I don't get a lot of their decisions. My guess is that the foremost goal is lowest size at high quality. But that isn't really achieved either compared to some simpler methods of storage or bitstream layout.

Let's take two examples:

Determining the length of a NALU. Both bitstreams use three or four byte start codes. Due to the usage of start codes they also have a way of escaping certain byte sequences inside the NALU so that NALU data won't be mistaked for a nother start code. If, however, they'd simply used a length+payload system they wouldn't need such an escaping mechanism, parsing would be much simpler, they'd even save space due to no escaping (and a four byte length field would suffice for every possible bitstream out there). That way leading or trailing zero bytes wouldn't be required either, and neither would the RBSP trailing bit syntax — because a parser would already know how long the NALU is.
Determining where a decoder can start decoding without needed any prior frame for decoding any following frame, aka real key frames. The rules for that are so long and complex that it requires parsing several data structures, keeping track of existing pictures (open GOP situations) etc. etc. mkvmerge still doesn't support this fully because it's so much work, and I honestly don't want to spend the hours. Other video formats (e.g. VC-1) on the other hand use a couple of tiny bits for signaling this important piece of information. Right at the start of each frame. It's ridiculous how much of a difference that makes in complexity, and complexity begets bugs. I haven't received a single bug report for VC-1 in… I don't know… five years or so? Granted, it's much less used, but still.

End of rant :)

[nevcairiel]

The Annex B startcodes are meant for re-synchronization, so you can find a NAL start in a broken stream, and also why double zero bytes are forbidden in the content of a NAL and need to be escaped (to prevent aliasing the synchronization point).
Annex B is primarly used for broadcast, where transmission problems do happen, so this part is quite important (and the mpegts container used in those scenarios does not solve that problem for them, either.)

[Mosu]

I get that. But it's not like AVC elementary streams (or any other format's elementary stream format) are broadcast. What's actually broadcast is e.g. MPEG transport streams, and they have their own method of synchronization and "NALU starts here" markers.

Oh well, there's not really a point of discussing this in this particular thread :)

[Overdrive80]

Minor cosmetic bug: Demo bug (https://www.dropbox.com/s/qrr8zud1brycwjc/Untitled%20Project.mp4?dl=0)

[stax76]

Mosu, there is a issue maybe you can take a look at: https://forum.doom9.org/showthread.php?p=1804785#post1804785

[Mosu]

I won't look at this, sorry. I've got more than enough other things to do. And I'm not the author of MediaInfo; I don't know under which circumstances MI shows what information and I certainly don't want to spend the time to find out.

[stax76]

I thought it probably relates to mkvmerge, mediainfo or x265 so I posted in all three threads to make sure the right dev sees it.

[Mosu]

Well, the person best equipped to say why MediaInfo is showing some information or why not is the MediaInfo author. If he says it's definitely a bug somewhere else, e.g. because the data in the file is invalid or something, then I'll look into this.

[sneaker_ger]

Thx for the quick fix. I can also confirm it makes MediaInfo work like usual again.

[Mosu]

@stax76: please give the latest pre-builds (https://mkvtoolnix.download/windows/pre/) a try. I've just fixed a bug in the HEVC SPS parser that sneaker_ger has reported, and as he writes that fix seems to have solved the issue MediaInfo has with the files, too.

Looks like I may have to do an emergency release tomorrow.

[stax76]

@Mosu

Thanks for the fix and build, MI shows now:

Format_Profile : Main 10@L3.1@Main
Codec_Profile : Main 10@L3.1@Main
Resolution : 10
Resolution/String : 10 bit3
BitDepth : 10
BitDepth/String : 10 bit3

[Mosu]

Minor cosmetic bug: Demo bug (https://www.dropbox.com/s/qrr8zud1brycwjc/Untitled%20Project.mp4?dl=0)

Nothing that I can really fix due to the overly long translations used in the comboboxes and how Qt is calculating the minimum width.

[Mosu]

Thanks for the fix and build, MI shows now:

And that means what? That it's OK now?

[stax76]

It's fine, before there wasn't any info about 10 bit shown.

[Mosu]

Alright. Thanks for the confirmation.

[Overdrive80]

Nothing that I can really fix due to the overly long translations used in the comboboxes and how Qt is calculating the minimum width.

The problem is not recalculate width of comboboxes, either combobox is locked after click on multiplexer option and dont let to resize.

[isidroco]

"The procedure entry point direct3dcreate9ex could not be located in the dynamic link library d3d9.dll"
Error on start in: mkvinfo.exe mkvinfo-gui.exe mkvtoolnix-gui.exe
It worked with in v10.0.0

Is it posible to only copy new "mkvmerge.exe" v11 on old v10 mkvtoolnix package?

It's probably a winXP issue, but I can't change OS because of indispensable and expensive hardware (with no w7+ drivers).

[Selur]

@Mosu: there seems to be an issue with mkvextract. Got some users complaining about subtles not properly extracted (0-byte files) when using something like:
"C:\Program Files\Hybrid\mkvextract.exe" tracks "E:\Anime\Dragonball Super\Dragon Ball Super - 01x01 - The Peace Prize. Wholl Get the 100 Million Zeny!.mkv" 2:"L:\PS3\Coulters\Dragon Ball Super - 01x01 - The Peace Prize. Wholl Get the 100 Million Zeny!_id_2_lang_und_default.ass"" (on Windows 10 with Creator update)
Not sure, but this might only happen if either input or output is located on a mapped network drive. (this already happend with MKVToolnix 10)
Seems to only happen when one extracts multiple subtitles at once.

Cu Selur

[Telion]

"The procedure entry point direct3dcreate9ex could not be located in the dynamic link library d3d9.dll"
Error on start in: mkvinfo.exe mkvinfo-gui.exe mkvtoolnix-gui.exe
This is because now the Qt's multimedia component, which relies upon the Media Foundation Framework and thus doesn't work on XP, is linked to these files. I suppose it's used to play an audio file after chosen events. I can only hope Mosu could do this in a way that won't break the compatibility with XP, e.g. switch Qt to use DirectX instead of MF which is just the default for Qt on Windows. It's really a pity that such a minuscule feature stops us poor XP users from using new versions with less errors.

[Mosu]

This is because now the Qt's multimedia component, which relies upon the Media Foundation Framework and thus doesn't work on XP, is linked to these files. I suppose it's used to play an audio file after chosen events. I can only hope Mosu could do this in a way that won't break the compatibility with XP, e.g. switch Qt to use DirectX instead of MF which is just the default for Qt on Windows. It's really a pity that such a minuscule feature stops us poor XP users from using new versions with less errors.

The reason stated here is correct. As I don't support Windows XP, I won't spend any time on this.

[Mosu]

@Mosu: there seems to be an issue with mkvextract. Got some users complaining about subtles not properly extracted (0-byte files) when using something like:

I cannot reproduce this at the moment, neither with local drives nor with mapped ones. Can you provide sample files for which this happens?

[gpower2]

@Mosu: there seems to be an issue with mkvextract. Got some users complaining about subtles not properly extracted (0-byte files) when using something like:
"C:\Program Files\Hybrid\mkvextract.exe" tracks "E:\Anime\Dragonball Super\Dragon Ball Super - 01x01 - The Peace Prize. Wholl Get the 100 Million Zeny!.mkv" 2:"L:\PS3\Coulters\Dragon Ball Super - 01x01 - The Peace Prize. Wholl Get the 100 Million Zeny!_id_2_lang_und_default.ass"" (on Windows 10 with Creator update)
Not sure, but this might only happen if either input or output is located on a mapped network drive. (this already happend with MKVToolnix 10)
Seems to only happen when one extracts multiple subtitles at once.

Cu Selur

Hi Selur, have you tried extracting the subtitles with a GUI like gMKVExtractGUI? I have tried extracting multiple subs at once on Windows 10 Creator's Update with MKVToolNix v10+ and everything works like a charm...

[stax76]

I would guess it's rather Windows or the network which don't work properly or even how you start the processes, I also get network related bug reports a few times a year, I used to ignore them because I don't have a network to test, now I at least try to reproduce it using wmware. I've not received any bug reports regarding mkvextract. Creators Update brought more changes then anything I experienced before, though everything GUI related.

[isidroco]

The reason stated here is correct. As I don't support Windows XP, I won't spend any time on this.
If reason is trying to make a sound after finishing, maybe you could just build a version without the offending intructions for XP (and sound won't work on those versions). Please consider that for us poor XP users from the third world :( (Argentina :) )
Thanks!

[Mosu]

Like I said, I won't spend _any_ time on anything based on the program working or not working on Windows XP.

[Midzuki]

If reason is trying to make a sound after finishing, maybe you could just build a version without the offending intructions for XP (and sound won't work on those versions). Please consider that for us poor XP users from the third world :( (Argentina :) )
Thanks!

I think you should pester the Qt developers themselves.
If you convince them to stop being *needlessly-"modern"*, then the next releases of MKVtoolnix will automagically become XP-friendly again
(or at least I believe so).

[kuchikirukia]

https://picload.org/image/rcilriww/untitled.png

N versions of Windows don't have these, so it no worky on my Windows 10 N.
10.0.0 works.

[Mosu]

Install the Windows Media Feature Pack for your versions and try again.

[kuchikirukia]

Install the Windows Media Feature Pack for your versions and try again.

Why does it suddenly need components of Windows Media Player? I don't want Windows Media Player. It's terrible.
It looks like I can extract those dll's from a .cab inside the installer, but I don't think most people on Windows N are going to know how to do that.

[Mosu]

MKVToolNix GUI uses Qt's multimedia component for sound playback. Qt's multimedia component uses the Media Foundation framework on Windows. In Windows N and KN, that framework is not available. Installing the Media Feature Pack will install it on those versions, but yes, it also includes Windows Media Player. You don't have to use Windows Media Player, of course.

Your options are:

Install the Media Feature Pack and ignore Windows Media Player
Only get the DLLs from somewhere
Use Linux, e.g. in a virtual machine
Use macOS
Keep on using v10.0.0 indefinitely
Re-compile v11.0.0 yourself and disable all sound-related things (or get someone else to do this for you)
Stop using MKVToolNix altogether

[kuchikirukia]

Is sound enabled by default, and would switching it to disabled allow it to pass without triggering dll complaints? Sound effects probably shouldn't be on by default. I remember, what was it, Imgburn (?) that would scare the hell out of you with its "job done" jingle?

[Mosu]

The sound playback is built-in and available but not active by default. Due to it being built-in, the DLL requirements remain the same. No, I won't spend time on changing that.

[kuchikirukia]

Ok, if anyone is looking for the missing EVR.DLL, MFPLAT.DLL, MF.DLL, and MFCORE.DLL needed to get mkvtoolnix working, I've uploaded them here: http://s000.tinyupload.com/?file_id=56255835202073920387

[VAMET]

Dear Friends

So as far as I understand AACS 2.0 has been cracked. There is also first UHD 1:1 copy over Internet with Dolby Atmos. There is an information, that UHD has the same structure as BD. Here (https://pastebin.com/QTGT5ADS) is an information about .m2ts file. This is a very good information for people, who would like to backup their UHD Blu-ray movie collection from physical disc to HDD. My question, will MKVToolNix be able to convert such copies to .mkv files or there is need to be update of MKVToolNix?

Thank you in advance for any help and support.

Sincerely

[sneaker_ger]

Mkvmerge can read HEVC from (m2)ts but for a definite answer someone needs to actually test it. Also, reading the playlists or just the m2ts might be different.

[hello_hello]

I wasn't expecting MKVToolNix to run on XP forever, although for it to stop working so it can go "ding"....

If MKVToolNix used PowerShell to make ding noises, there'd be no need to download additional dlls (because XP obviously isn't a good enough reason) but as a bonus it could continue working on XP too. I've never written a single line of code so I know nothing about writing software, but it only took a minute with google to work out the command line required to go "ding".

powershell -c (New-Object Media.SoundPlayer "C:\Windows\Media\ding.wav").Play(); Start-Sleep -s 5; Exit;

Mind you, I was under the impression "sounds" went out of fashion with instant messenger programs, Incredimail & Windows 98. Not that I'd know. One of the first things I do after installing Windows is disable most of the sounds. Pop up messages/windows/tooltips are far more civilised. :)

[sneaker_ger]

Mkvtoolnix is MultiOS. You don't have the PowerShell on Linux or Mac. It uses the Qt framework's function for sound so it works on all of them with the same code.

[hello_hello]

Fair enough, although according to the log of changes, MKVToolNix only fires up the brass band for a fanfair when shutting down Windows and Linux, so I guess it can't always work the same way. Whether Mosu wants to make changes for the Windows version so MKVToolNix doesn't require the installation of a media player to mux MKVs would be up to him. I don't know how hard it'd be, or how hard it'd be to switch back to DirectX. Aren't other operating systems devoid of WMP and Media Foundation along with Power Shell? I'm asking because I know nothing about Qt or how it works, so I don't know how the same code translates to other operating systems.

* MKVToolNix GUI: implemented several built-in actions that can be executed either on special events or once via the "watch jobs" tool. These are: playing an audio file (implemented for all operating systems); hibernating, sleeping and shutting down the computer (only implemented for Windows and for Linux systems using systems).

[Midzuki]

As I already said, the actual problem will only be solved when a sufficient quantity of XP users have pestered the QT framework developers.
Playing sounds on Windows requires only the Multimedia API.
Even Visual Basic 4 could use it :)

[nevcairiel]

No serious and self-respecting developer is going to listen to any​ amount of XP users. You need to accept that old OS means running old software.

[hello_hello]

Any self respecting developer would probably know around 3% of desktops connected to the internet (according to the last stats I read) still run XP. There's probably many more that don't see the internet. That's still a lot of desktops. More than any flavour of Linux. Probably more than all Linux flavours combined. Around half the number of PCs running Apple's operating system, way more than Vista, more than Windows 8, and then there's the other supported operating systems such as NetBSD that a couple of people use. That's probably why programs such as Firefox still support XP, because people still use it. In fact XP support is probably still more common than a lack of it. Aside from Handbrake, LSmash, Pale Moon and MKVToolNix, all the open source software I've been using for years still supports XP. Oh and ffmpeg.... there's someone still building XP friendly versions, but not as regularly as the normal releases. If you want to mux an MKV though.... ;)

Doesn't LAV Filters still support XP, or does MPC-HC use a modified version to make it XP friendly?

[nevcairiel]

It does, but mostly because it didn't break yet, once it does break (or present a blocker in any other way) it'll likely just not get fixed/removed. Also, since you listed Firefox, they just discontinued XP support ;)
Such statistics are largely bogus anyway, the majority of those are work PCs that are for some reason not upgrading. The percentage of actual home users running XP willingly is extremely small.

In any case, you can just fork Open Source software and fix it yourself, don't expect developers to spend time fixing things for an OS thats over 15 years old and over 3 years unsupported, probably a gaping security hole by now.

[hello_hello]

Such statistics are largely bogus anyway, the majority of those are work PCs that are for some reason not upgrading. The percentage of actual home users running XP willingly is extremely small.

I tend to suspect it's the other way round. There's four PCs in this house, each used regularly, but the older two never see the internet and only one sees it regularly.

In any case, you can just fork Open Source software and fix it yourself, don't expect developers to spend time fixing things for an OS thats over 15 years old and over 3 years unsupported, probably a gaping security hole by now.

I'm quite fond of the "unsupported" and "security" justifications. The number of people using an OS never rates a mention. Maybe some programs with internet access could be squeezed into the "security" category, but we're muxing MKVs here.

I didn't know Firefox had dropped XP support. Not that I was planning to upgrade it in a hurry either. I'm on the last ESR release that permits installing unsigned extensions, and I was planning to ride that out. By then I'll definitely have the new PC built and hopefully be running Linux. No Windows 10 for me.

[isidroco]

Seems too much hassle for enabling "Ding" when done. I think it's a lot to loose (XP compatibility and obligation to install horrible Windows Media Player) for a useless option. It would be better to disable sound alltogether, or else enable to run an external program when done, so users can run a player if desired.

PS: Here in Argentina there we are still a lot of users with XP which runs well and security holes aren't used by virus anymore, it's easier to convince users to install anything.

[qyot27]

Aside from Handbrake, LSmash, Pale Moon and MKVToolNix, all the open source software I've been using for years still supports XP.
There's nothing about L-SMASH that stops it from working on XP. (http://i.imgur.com/lZGZJ9e.jpg)

[hubblec4]

Hi Mosu

Is it possible to remove the Dialog-Normalization from audio streams (AC3) when MKVmerge mux directly from an m2ts-file or the mpls file?
Or is it to much work?

[hello_hello]

There's nothing about L-SMASH that stops it from working on XP. (http://i.imgur.com/lZGZJ9e.jpg)

It definitely went through an XP unfriendly stage a while back. There's even an XP specific link at the bottom of the Avisynth Lsmash page, so I figured that must be it for XP and haven't re-checked it since. Even MeGUI uses that version when running on XP. The changelog says bye bye to XP support with revision 833.

Obviously you have it working, although if you are using rev 1450 as your screenshot indicates, I can't find it. The latest version I found is r929 here (https://www.dropbox.com/sh/3i81ttxf028m1eh/AAABkQn4Y5w1k-toVhYLasmwa?dl=0) and it's not working for me. I have the Microsoft Visual C++ 2015 Redistributable installed but the following error still occurs. Is there a special incantation I need to use, or a secret handshake, or a different version?

Cheers.

LoadPlugin: Unable to load "E:\LSMASHSource.dll", Proc not found. Update library version?

[qyot27]

It definitely went through an XP unfriendly stage a while back. There's even an XP specific link at the bottom of the Avisynth Lsmash page, so I figured that must be it for XP and haven't re-checked it since. Even MeGUI uses that version when running on XP. The changelog says bye bye to XP support with revision 833.

Obviously you have it working, although if you are using rev 1450 as your screenshot indicates, I can't find it. The latest version I found is r929 here (https://www.dropbox.com/sh/3i81ttxf028m1eh/AAABkQn4Y5w1k-toVhYLasmwa?dl=0) and it's not working for me. I have the Microsoft Visual C++ 2015 Redistributable installed but the following error still occurs. Is there a special incantation I need to use, or a secret handshake, or a different version?

Cheers.

LoadPlugin: Unable to load "E:\LSMASHSource.dll", Proc not found. Update library version?
That's LSMASHSource, which had the toolset in its MSVC project explicitly changed from v120_xp to v120 (before moving up again to v140). L-SMASH itself has no restrictions like that: nothing in its configure script does it, and its MSVC project still uses v120_xp. LSMASHSource doesn't have the option of being built with MinGW, since it's not a C-plugin, but unless there's something deeper in the code, all it would take is overriding the default when you open it up in Visual Studio and forcing the use of the XP toolset before building it like usual.

But I'd rather not continue derailing the MKVToolNix thread about this.

[Mosu]

To make it perfectly clear: I'm not going to spend any time on XP-related problems. There's zero chance you'll change my mind. That means the code I'm using will stay as it is. If you (the general "you", not anyone in particular) want to continue using XP, that's your prerogative. Mine is not spending any time on it.

Now can we please stop the whole XP discussion? Thanks.

[Mosu]

Is it possible to remove the Dialog-Normalization from audio streams (AC3) when MKVmerge mux directly from an m2ts-file or the mpls file?
Or is it to much work?

At the moment mkvmerge has no code whatsoever for removal of dialog normalization. I don't have any plans of implementing such a feature either. Maybe sometime in the future, though — I'm not ruling it out (unlike XP support, for example). If you want to improve the chances of that happening, I'd ask you to open an issue over on Github (https://github.com/mbunkus/mkvtoolnix/issues/) for it. Otherwise I will almost certainly forget about it again.

[hello_hello]

To make it perfectly clear: I'm not going to spend any time on XP-related problems. There's zero chance you'll change my mind. That means the code I'm using will stay as it is. If you (the general "you", not anyone in particular) want to continue using XP, that's your prerogative. Mine is not spending any time on it.

I don't think anyone considered the possibility that happening, only discussing if it'd be a reasonable idea.

Now can we please stop the whole XP discussion? Thanks.
It had pretty much come to a close already.
Aside from XP though, several posters expressed concern over having to download additional WMP dlls, so would you consider changing things to remove that need.... if it can be done without unwanted side effects such as restoring XP compatibility?

No offence, because your work on MKVTYoolNix is definitely appreciated, but I can imagine potential users downloading the program, seeing an error message when they try to run it, and uninstalling. I've done the same thing over the years if I didn't have my heart set on using a program and it wasn't keen to run.

If an error tells me in plain English how to fix the problem I'll usually give it a try, unless it's instructing me to install itunes or upgrade WMP, but even a missing dll error would have me contemplating if I really want to use a program. I suspect many people will skip the contemplation step and go straight to posting about what a piece of crap MKVToolNix is in a forum or two while they uninstall it.

Was there a big demand for a muxing program that goes "ding"? I suspect the number of "sound advocates" would be very low compared to the number of people using errrr....XP....... I mean.... compared to the number of Windows7/10 users that won't get past the installation stage, albeit for a perfectly legitimate and unrelated to XP reason.

Don't mention XP. I mentioned it once, but I think I got away with it. ;)

[Mosu]

No, I'm not changing frameworks/the methods for sound playback. I'm using what my GUI toolkit of choice is offering regarding cross-platform multimedia playback because that's the most sane, most foolproof, least painful, most debugged method of doing such things in a cross-platform way.

I've set up an FAQ entry for that already. If people uninstall the program without searching for the solution, then that's their loss, not really mine, as I'm not trying to make money of this thing called MKVToolNix anyway.

Was there a big demand for a muxing program that goes "ding"?

Playing a sound when muxing finishes has been requested by users time and again.

I've actually typed up quite a long answer listing all the possible choices you have, why I do or do not do certain things, why my choices are the way they are, but all that boiled down to being angry and venting. That's not productive. Therefore I've snipped it.

So my summary is:

I'm satisfied with the system requirements MKVToolNix v11.0.0 has, which is: Windows 7 or newer with the Media Foundation framework.

Edit: fixed requirements

[nevcairiel]

A lot of media applications rely in some form or shape on the so-called "Windows Media Player" components - which include a lot of very low level media components, and not just the player.
Installing a "N" windows version out of spite for Windows Media Player is really just limiting yourself for no good reason. Don't run it if you don't like it, but the media framework parts it includes are important to many other applications. "N" builds exist because of EU politics, but there is no good reason for anyone to really use them.

[mariush]

In Windows there's the old PlaySound API function : https://msdn.microsoft.com/en-us/library/windows/desktop/dd743680(v=vs.85).aspx
sure it's not cross platform but for windows It would have been enough to play some wav file..

if you don't need the absolute latest qt maybe a xp only version could be hacked using this function and a qt that doesn't require those libraries.

anyway we're kinda going offtopic

[hello_hello]

No, I'm not changing frameworks/the methods for sound playback. I'm using what my GUI toolkit of choice is offering regarding cross-platform multimedia playback because that's the most sane, most foolproof, least painful, most debugged method of doing such things in a cross-platform way.

Is that entirely true? Doesn't Qt still support XP? Windows Media Format 11 installs on XP.

Edit. Removed misinformation.
I missed where it says here (http://doc.qt.io/qt-5/qtmultimedia-windows.html) the Media Foundation plug-in only supports Vista and newer, but given DirectShow support appears to be alive and well and Qt supports XP.... doesn't Qt's cross platform cleverness include sound on XP, or would an an XP specific build be required? If using DirectShow is hard or problematic then I'll shut up and go away (I'm trying to understand a bit more, not hassle you for the sake of it), but Media Foundation was instantly problematic enough to require a FAQ on your site, so it's not a perfect choice either.

I don't know much about Qt, but XP compatibility broke once before and then unbroke a while later. I assume you didn't have a change of heart but do you know what happened there?

I've actually typed up quite a long answer listing all the possible choices you have, why I do or do not do certain things, why my choices are the way they are, but all that boiled down to being angry and venting. That's not productive. Therefore I've snipped it.

I wouldn't have minded reading it.
I initially suggesting going "ding" with PowerShell because I thought it might be easy, and eliminate the need to install the Media Foundation, which seems a little ridiculous as a requirement for muxing at first glance, but when it seemed there wasn't an easy solution I let it go and accepted I'd probably be muxing with MKVToolNix 10 for quite a while, as I had previously for version 7.8.0. Nobody expects you to spend a huge amount of time on XP issues. Well I don't at least.

I get it. I really, really, really do. It's your software and you can support whatever you choose, but I'll be honest and say it's frustrating from an user perspective when there's a suggestion such as "tick this box to fix XP" but you won't even look at it, because that effects a lot of people who'd otherwise be using the latest version.

[stax76]

ffmpeg usability feature:


first audio:

-map 0:a:0


second audio:

-map 0:a:1


first subtitle:

-map 0:s:0


Does anybody else find this useful?

[Selur]

nothing new (https://www.ffmpeg.org/ffmpeg-all.html#toc-Advanced-options) + what does this have to do with mkvtoolnix?
(that said: have fun once you play around with filter_complex and the stuff you can do with it :))

[hubblec4]

If you want to improve the chances of that happening, I'd ask you to open an issue over on Github (https://github.com/mbunkus/mkvtoolnix/issues/) for it. Otherwise I will almost certainly forget about it again.

Ok I did it. Only if you have time, Im sure you have many other things to do.

[sneaker_ger]

Does anybody else find this useful?
Yes. The mkvtoolnix system never really made any sense to me. You specify track type and TrackID even though the TrackIDs are unique and not re-used for the different track types.

Well, it does make some sense in that you implicitly deactivate all other tracks of the same type but it is still kinda weird.

[stax76]

nothing new + what does this have to do with mkvtoolnix?

It's new to me :), in the past I used the IDs from MediaInfo for all tools, which was a little bit buggy since every tools using different IDs, for ffmpeg I can use the handy syntax but for mkvmerge text parsing is needed, it's easy to do with .NET though.

Dim stdout = ProcessHelp.GetStdOut(Package.mkvmerge.Path, "-I " + ap.File.Quotes)
Dim values = Regex.Matches(stdout, "Track ID (\d+): audio").OfType(Of Match).Select(Function(match) match.Groups(1).Value.ToInt)
If values.Count = ap.Streams.Count Then tid = values(ap.Stream.Index)

It's a bit slow and fragile in theory, practically only three more lines code.

[kuchikirukia]

Playing a sound when muxing finishes has been requested by users time and again.

Did they list breaking Windows compatibility as an acceptable tradeoff? Breaking the entire N and K lines isn't small.

It may be a nice feature for 0.01% of users who are for some reason incapable of looking down at their taskbars, but it's not exactly vital. It would certainly be the first thing I'd disable.

[Mosu]

ffmpeg usability feature:

Nope, sorry. Changing how IDs are used would require huge changes to the program, and it would be a huge change for all external users of those programs. Meaning it would break a lot of stuff. Definitely not worth the effort.

[Mosu]

I don't know much about Qt, but XP compatibility broke once before and then unbroke a while later. I assume you didn't have a change of heart but do you know what happened there?

It accidentally broke because I used registry access functions that aren't available on XP. It accidentally un-broke when mmg (the old GUI) was removed which meant I simply didn't need that specific code anymore anyway. None of that was intentional as I hadn't supported XP at that point anyway.

[isidroco]

Any chance you'll support win98? :D (now seriously, I still have win98/ XP dual boot :) )

[manolito]

Wow, same here...
I still need Win98 for my WinFax software (which was not maintained by Symantec to work correctly under XP). The built-in WinXP fax application is crap, and I do not want to pay again for a fax softwhere when I already own one which works perfectly...

[Mosu]

Any chance you'll support win98? :D

Sure! I'll get right on it after my breakfast burrito! ;)

[manolito]

Got a problem with DVB-T2 captured streams when the audio stream is in the AAC-LATM format (using the current stable version 11.0.0).

My Xoro receiver stores the captures in a .MTS container. I usually run these files through TS-Doctor, but it makes no difference if I don't.

Before converting the files (using StaxRip) I like to repack them into an MKV container because in the .TS format all seeking operations (to find editing points) are just a pain, no matter if I use LAV Filters or FFMS2 as the source filter.

And this repacking to MKV does not work with MKVMerge. I do not get any error messages, but the resulting file does not play, neither in MPC-HC nor in VLC. If I use a current version of FFmpeg for this repacking, there is no problem whatsoever.

Here is the MediaInfo report for the audio stream in the .TS file:

Audio
ID : 2520 (0x9D8)
Menü-ID : 897 (0x381)
Format : AAC
Format/Info : Advanced Audio Codec
Format-Profil : LC
Muxing-Modus : LATM
Codec-ID : 17
Dauer : 1 h 52 min
Bitraten-Modus : variabel
Kanäle : 2 Kanäle
Kanal-Positionen : Front: L R
Samplingrate : 48,0 kHz
Bildwiederholungsrate : 46,875 FPS (1024 spf)
Video Verzögerung : -248 ms
Sprache : Deutsch

Any ideas?
BTW if the audio stream is in the EAC3 format then MKVMerge works just fine.


Cheers
manolito

[Mosu]

Got a problem with DVB-T2 captured streams when the audio stream is in the AAC-LATM format (using the current stable version 11.0.0).

It's possible that you're hitting this issue (https://github.com/mbunkus/mkvtoolnix/issues/1957), even though the description doesn't seem to indicate a common cause. However, the underlying cause of #1957 was wrong handling of LATM AAC in MPEG TS. Please give the pre-build linked in that issue a try.

[manolito]

Thanks Mosu, yes, the prebuilds from this link do fix the issue... :D

The resulting MKVs play fine now without sync problems, but using them as input for StaxRip is still problematic. For the TS source file MediaInfo reports an audio delay of around -230 ms, the MKV created by MKVMerge has a delay of -1300 ms. This seems awfully high, still the file plays OK. But when I feed it to StaxRip, the conversion result is terribly out of sync.

If I create the MKV using FFmpeg, MediaInfo reports no audio delay at all for the MKV. And StaxRip handles it without sync problems, too. I hate these HEVC files... :devil:


Cheers
manolito

[stax76]

Thanks Mosu, yes, the prebuilds from this link do fix the issue... :D

The resulting MKVs play fine now without sync problems, but using them as input for StaxRip is still problematic. For the TS source file MediaInfo reports an audio delay of around -230 ms, the MKV created by MKVMerge has a delay of -1300 ms. This seems awfully high, still the file plays OK. But when I feed it to StaxRip, the conversion result is terribly out of sync.

If I create the MKV using FFmpeg, MediaInfo reports no audio delay at all for the MKV. And StaxRip handles it without sync problems, too. I hate these HEVC files... :devil:


Cheers
manolito

There is also currently a TS discussion in the German staxrip support thread at gleitz.

http://forum.gleitz.info/showthread.php?26177-StaxRip-Encoding-Frontend-%28Diskussion%29/page999999

What works normally well is to open TS directly with DGDecNV. Other things you can try is demuxing TS with TS Doctor. Delay detection is done with MediaInfo using the Video_Delay property. Unfortunately I don't know the MKV format good enough to know what's causing the async issue with mkvmerge. Good find that ffmpeg works around the issue, so far I only knew Haali muxer works around it, dsmux is integrated in staxrip but the Haali muxer is not really stable.

[sneaker_ger]

If the streams are in-sync within the mkv then it is not an mkv issue. Rather, the mix of tools using to process the video and audio streams aren't harmonized in the way they treat delays and/or vfr or are otherwise used incorrectly.

Comparing all timecodes between the file created by mkvmerge and the one created by ffmpeg should give you enough hints to find the problem.

[stax76]

I would probably need a couple of hours to understand this...

[Mosu]

Hey,

Today I've released v12.0.0 of MKVToolNix. Not too many changes in this one, but at least one rather important bug fix in the HEVC/h.265 code that can result in invalid files. I therefore recommend everyone to update.

Windows users should note that starting with v11.0.0 the GUI requires Microsoft's "Media Foundation" framework to be installed. This is the case out of the box on the consumer versions of Windows other than the N and KN variants of Windows 10. You'll have to download and install it separate on N and KN. On server variants you can install the framework via the server administration console. See this FAQ entry (https://github.com/mbunkus/mkvtoolnix/wiki/DLLs-not-found) for more details.

There have been no additional changes since v11.0.0 that package maintainers should be aware of.

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 12.0.0 "Trust / Lust" 2017-05-20

## New features and enhancements

* MKVToolNix GUI: the key combination Ctrl+Shift+Space will now toggle the selection of the current item in all tree views where multiple selections are allowed. Implements #1983 (https://github.com/mbunkus/mkvtoolnix/issues/1983).
* MKVToolNix GUI: chapter editor: added the extension `*.cue` (for cue sheet files) to the "open chapter file" dialog.
* mkvmerge: cue sheet parser: if the cue sheet contains a non-empty `TITLE` entry and if no other segment title has been set yet, then the segment title will be set to the cue sheet's `TITLE` value. Implements #1977 (https://github.com/mbunkus/mkvtoolnix/issues/1977).
* mkvmerge, MKVToolNix GUI (multiplexer): added an option `--no-date` that prevents the "date" field from being written to the segment information headers. Implements one half of #1964 (https://github.com/mbunkus/mkvtoolnix/issues/1964).
* mkvpropedit, MKVToolNix GUI: header editor: added support for editing the "date" segment information field. Implements the other half of #1964 (https://github.com/mbunkus/mkvtoolnix/issues/1964).

## Bug fixes

* MKVToolNix GUI: preferences → job actions, type "play audio file": the GUI will no longer clear the audio file name input if the user aborts the audio file selection dialog.
* MKVToolNix GUI: preferences → job actions, type "play audio file", on Windows: the default "play audio" action was pointing to the wrong directory. Existing configurations with such a wrong path will be fixed automatically upon starting the GUI. Fixes #1956 (https://github.com/mbunkus/mkvtoolnix/issues/1956).
* mkvmerge: HEVC/h.265 parser: fixed the superfluous copying of the `bitstream_restriction_flag` and its dependent flags in the VUI parameters of the sequence parameter sets if the timing information is present, too. This fixes #1924 (https://github.com/mbunkus/mkvtoolnix/issues/1924) properly, and it also fixes #1958 (https://github.com/mbunkus/mkvtoolnix/issues/1958).
* mkvmerge: MPEG TS reader, AAC parser: the MPEG TS reader will now force the AAC parser to use the multiplex mode that the MPEG TS reader has detected (e.g. LOAS/LATM). This prevents the AAC packetizer from mis-detecting it in its own attempt to identify the mode. Fixes #1957 (https://github.com/mbunkus/mkvtoolnix/issues/1957).
* mkvmerge: MPEG TS reader: valid MPEG transport streams that start with an h.264/h.265 start code (e.g. a file created by cutting at an arbitrary position) were not recognized as a supported file type.
* mkvmerge: MPEG TS reader: fixed a potential read access from invalid memory addresses in the code parsing the program map table (PMT).
* mkvmerge: MPEG TS reader: if packets are encountered that belong to a PID not listed in the program map table (PMT), mkvmerge will attempt to determine their type and codec from the content. This supported content types are AAC (ADTS only) and AC-3. Fixes #1980 (https://github.com/mbunkus/mkvtoolnix/issues/1980).
* mkvmerge: MP4 reader: fixed finding and parsing the `colr` atom if there are more than one video extension atoms and the `colr` atom is not the first one.
* mkvmerge: MP4 reader: the `nclx` colour type of the `colr` atom is now recognized, too (as defined by ISO/IEC 14496-12, "ISO base media format").
* configure: fixed configure aborting if a `moc`, `uic`, `rcc` or `qmake` binary is found, but the binary's version is too old. Fixes #1979 (https://github.com/mbunkus/mkvtoolnix/issues/1979).

Have fun :)

[Selur]

Nice! Thanks for the Update!

[Mosu]

Note that due to a SNAFU in one of my build scripts the installer for both the 32 and the 64bit version claims to install v11.0.0. That's only a cosmetic error in the installer. The included binaries are v12.0.0, and they do show v12.0.0 as their version number.

I'll likely create and upload new builds for both installers later tonight. But that shouldn't prevent you guys & gals from updating now.

[Mosu]

The installers have been replaced with new builds that announce the correct version.

[hello_hello]

Note for XP users....

So far gMKVExtract 1.9.0.0 & MKVCleaver 0.7.0.1 are both working fine with MKVToolNix 12.0.0 on XP, even if mkvtoolnix-gui.exe doesn't. Whether there's an advantage to using them with MKVToolNix 12.0.0. rather than version 10.0.0, I don't know.

MeGUI has MKV and Adaptive muxers under the Tools menu, and they're functioning fine so far with MKVToolNix 12.0.0 on XP, so they could be used as an alternative GUI for muxing MKVs. Admittedly MKVToolNixGUI is probably easier to use if you do a lot of muxing, but at least they're an option if you need to mux with the most recent MKVToolNix.

mkvtoolnix-gui.exe v10.0.0 has also been working fine with mkvmerge.exe v12.0.0 so far, but you have to click the the warning message when you first run it. I don't know if it's necessarily a good idea, but it has worked in my testing so far.

Just thought I'd mention some alternatives.....

[delacroixp]

Can you run multiple instances of MKVToolNix ?

I used to find it useful to run two instances in the passed (eg Appending a short TV series into one file ... but finding that one of the files still needed to have the credits or "next week intro" split out).
I could then run a second instance without reloading the whole sequence of appended files (just modify and replace).

Thanks much ... great app ... love the new interface and customisable options.

It's all good
:) :devil: :D

[Mosu]

No, it's not possible. However, you can edit any job again. Go to the job queue, right-click on the job and select "edit in corresponding tool…" That way you won't have to re-add those files either.

Note that MKVToolNix GUI is fully multi-threaded. You can continue working with it even while jobs are running. You can also configure it not to remove/clear the settings when you start multiplexing (and if you don't want to keep the settings all the time you can just do it once by clicking on the small arrow on the "start multiplexing" and select "afterwards leave the settings as they are" from the popup menu).

Basically there are a ton of options for you to chose from. You really don't need a second instance.

[hello_hello]

Is there any way to kill the warning message MKVToolNix offers when using mkvtoolnix-gui.exe 10.0 with a newer version of mkvmerge.exe?

If there's a switch I'm happy to use it at my own risk, but when running XP, having to click through the warning for the rest of time could get annoying.

I know they're not the same version, but I only need to be told once. ;)

[Mosu]

No, there isn't.

[stax76]

maybe with autoit or autohotkey

[hello_hello]

maybe with autoit or autohotkey

There's an idea.....

Or can we have a special "say goodbye to XP" build of version 10 without the warning? That'll be the last time there'll be a need to disturb the bees in Mosu's XP bonnett, given MKVToolNixGUI will never work on XP again.
Or can AutoHotKey pretend to be a procedure entry point for d3d9.dll? :)

Anyway, I'm off to try autohotkey. I have it installed so I don't know why I didn't think of that myself (smacks self on forehead). Well, a switch would have been easier, I guess.

Don't mention XP. I mentioned it once, but I think I got away with it. ;)

[manolito]

For a much easier solution than AutoHotkey you should try one of those "clicker" applications which are mostly used to automatically click away shareware nag windows. My personal favorite is ClickOff (latest version 1.90). Has not been updated in ages, but still going strong...

Cheers
manolito

[Mosu]

Or can we have a special "say goodbye to XP" build of version 10 without the warning?

It seems I have to repeat myself over and over again: I will not spend any time on anything related to unsupported versions of Windows.

Don't mention XP. I mentioned it once, but I think I got away with it. ;)

Stop trying to be cute. Your whole post was about XP, as was your previous post, as was the one before that. You're not fooling anyone.

[stax76]

If something starts to behave weird some have to remember that some system type of apps might have side effects.

[hello_hello]

It seems I have to repeat myself over and over again: I will not spend any time on anything related to unsupported versions of Windows.

You need to lighten up. I thought following it asking if AutoHotKey could fix the procedure entry point problem would've made it obvious it was tongue in cheek question, but I had no expectation you'd have a change of heart, so self over repeating wasn't required. I was replying to someone else anyway.
Although to paraphrase one of your infamous retorts... because such opportunities are hard to resist and I'm only human.... in the time it's taken you to repeat over and over you won't support XP, you probably could have supported XP. :)

Stop trying to be cute. Your whole post was about XP, as was your previous post, as was the one before that. You're not fooling anyone.

I suspect I've asked XP related questions because I'm using XP, although I'll wait to make sure I don't unexpectedly ask Vista or Win8 related questions in the near future before I'll be confident it's the correct conclusion.
See... that could be construed as being cute. The other thing though....

Seriously... there's tribes of Amazonian pygmies still untouched by western civilization that'd know I was paraphrasing a famous line from Fawlty Towers (http://www.imdb.com/title/tt0578590/quotes) to acknowledge the fact I had mentioned XP a few times.
And the "tribes of Amazonian pygmies" line was lifted from BlackAdder (http://www.thetop100.net/the-entertainment-zone/the-top-100-blackadder-quotes/baldrick-in-the-amazonian-rain-forests-there-are-tribes-of-indians-as-yet-untou/list/z26l54i3106.aspx) in case that's somehow mistaken as not being extremely funny..

[hello_hello]

For a much easier solution than AutoHotkey you should try one of those "clicker" applications which are mostly used to automatically click away shareware nag windows. My personal favorite is ClickOff (latest version 1.90). Has not been updated in ages, but still going strong...

Cheers
manolito

I'll give it a spin. Thanks.

[stax76]

Some thoughts and questions about the command line being easy to generate by a app and easy read by a user:

D:/Software/Medien/mkvtoolnix\mkvmerge.exe --ui-language de --output ^"D:\Temp\staxrip\syl_temp\syl_out1.mkv^" --no-audio --no-subtitles --no-chapters --language 0:eng ^"^(^" ^"D:\Temp\staxrip\syl.mkv^" ^"^)^"

What do the parenthesis and caret/hat symbols mean and why are they needed?

Some additional switch might improve usability:

--only-audio
--only-subs
--only-chapters
--only-attachments
--only-track-tags
--only-global-tags

If --track-order is omitted then file and stream id order is used, it might be more user friendly when the order found in --audio-tracks and --subtitle-tracks instead of the stream id order is used.

[Mosu]

Some thoughts and questions about the command line being easy to generate by a app and easy read by a user:

D:/Software/Medien/mkvtoolnix\mkvmerge.exe --ui-language de --output ^"D:\Temp\staxrip\syl_temp\syl_out1.mkv^" --no-audio --no-subtitles --no-chapters --language 0:eng ^"^(^" ^"D:\Temp\staxrip\syl.mkv^" ^"^)^"

What do the parenthesis and caret/hat symbols mean and why are they needed?

My tools only use the standard "GetCommandLineW" Windows API function. That function provides an array, meaning some of the parsing has already been done at this point, some by cmd.exe itself, some by Microsoft's Visual C runtime library. The carets are due to Microsoft's Visual C runtime library. See this fine blog post by a Microsoft employee (https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/everyone-quotes-command-line-arguments-the-wrong-way/) for all the gritty details on how to escape for cmd.exe properly. In short: it's really, really ugly.

Therefore I highly suggest you use option files (https://mkvtoolnix.download/doc/mkvmerge.html#mkvmerge.option_files) instead. They're plain JSON files following the default JSON rules. You'll find tons of libraries out there producing valid JSON output, so you won't have to worry about writing your own escaping function. That way you'll only have to provide one argument: the path to a temporary file, and you can usually get away with escaping that with quotation marks.

Some additional switch might improve usability:

--only-audio
--only-subs
--only-chapters
--only-attachments
--only-track-tags
--only-global-tags

I won't add such options. I vastly prefer my options to have as little overlap as possible. That way it's much easier to reason about for the end user. For example, an end user might wonder what happens if she used "--only-audio -s 1".

If --track-order is omitted then file and stream id order is used, it might be more user friendly when the order found in --audio-tracks and --subtitle-tracks instead of the stream id order is used.

Again, this would violate my "options don't overlap" rule from above. Additionally it violates two one of my design goals: 1. options do one thing only; 2. I won't change existing behavior unless there's a really good reason to.

[hubblec4]

@stax76

Like Mosu said: You should use the JSON Option file with all your paras.
I'm very happy about this feature, it makes my programming sooo easy.

@Mosu
Few question about the track-order-code in a JSON option file.
If no track-order-code specified then mkvmerge generate in backround a track-order-code?
The same for the "append-to-code"? What happens if this para not specified?

[Mosu]

The default order for tracks is the order in which they're found. This means that the first source file listed will have its tracks output first, in the order in which mkvmerge's identification output lists them.

Similar rules apply to the append specification. Each track in file N will be appended to the corresponding track in file N-1 (the previous one on the command line). For example, if you have two files with three tracks each, then by default track 1 from file 2 will be appended to track 1 from file 1; track 2 from file 2 will be appended to track 2 from file 1; and track 3 from file 2 will be appended to track 3 from file 1.

The design goal for these options is "do the right thing for the common case" and "don't surprise the user". Processing files in the order in which they're listed on the command line is the "don't surprise the user" part. The common case is that files that you want to append usually contain the same number of tracks in the same order; so appending them should work out of the box without having to add the option "--append-to".

The reason the GUI always adds those options is a different one. The command line generated by the GUI is not tailored towards the end user. Instead, its purpose is to be explicit and exact. It should reflect what's currently visible in the GUI. Another reason is that simplifying the command line in the GUI would require extra code that decides that the currently visible configuration allows omitting certain switches such as "--append-to". Such extra code will always mean extra possibilities for hard-to-diagnose bugs.

[hello_hello]

For a much easier solution than AutoHotkey you should try one of those "clicker" applications which are mostly used to automatically click away shareware nag windows.

I thought I'd try AutoHotkey first as I've had scripts running to do text completion for years, but that was the last time I created one so I had to refresh my memory on the basics, but in this case closing the warning message is probably about as simple as a script gets. This is doing the job so far, if anyone else is interested.

Loop {
if WinActive("Problem with MKVToolNix installation")
WinClose
}

[stax76]

Thanks for the explanation. In the past if I had 20 subtitle streams in a mkv file staxrip would write the file path 20 times to the command line. I wanted to have a command line that is shorter so I added some extra logic, today I noticed the track order is wrong with my new command line generation and I'll need to use --track-order but that is tricky to do with my code base.

json might be the most easy to use way for apps but I have doubts that it is so much easier that it justifies starting from scratch. I get tired quickly from terse curly braces syntax and I don't know if .NET 4.7 has easy to use JSON support, usually I avoid third party libraries to make my app lightweight and easy to maintain.

Probably the best thing to do for me would be not to care about what the command line looks like, write the file path for every subtitle stream etc. if it's much easier to implement. If I remember right Win 10 allows about 8000 characters in the command line and many tools staxrip uses have a 260 character limit so about 30 long paths are possible which is probably enough for all staxrip users.

[Mosu]

You don't even have to use an external library for generating a JSON option file. The escaping mechanism is dead simple: for each word, replace all single backslashes by double backslashes and all quotation marks by \". Then write it out. Waaaaay easier than getting cmd.exe escaping right.

Edit: fixed backslash escaping.

[sneaker_ger]

replace all [..] all quotation marks by "
By \". (Damn forum software.)

[Mosu]

Yeah by backslash quotation-mark. Thanks :)

Edit: geeeez, that forum software is indeed prickly. Preview loses one layer of backslashes. Fun times :)

[stax76]

Not sure what you mean with escaping, in VB.NET what I use strings don't use escape sequences, I've searched my code for caret/hat symbols and they are only ever used as arithmetic operators and in regex expressions. I'm not really a CLI interested person, I learn things to make GUIs work and forget most things quickly after unfortunately, all my life I never learned and used dos/batch more then absolutely necessary, let alone linux, I know some powershell but only us it to for building staxrip extensions.

Right now staxrip don't do any escaping in command line generation, at least nothing I remember or am aware of.

[Mosu]

Then that's a source for potential bugs. It's your prerogative to ignore that, of course.

[stax76]

I'll have to investigate it, if somebody creates an issue on the tracker I'll certainly try to fix it, mp4box has a pretty ugly issue btw., practically you can't use any file names that contain a hash sign in the file name, I cannot imagine mkvtoolnix with issues like this.

https://github.com/gpac/gpac/issues/831

[hubblec4]

The default order for tracks is the order in which they're found. This means that the first source file listed will have its tracks output first, in the order in which mkvmerge's identification output lists them.
OK. Thats clear.


Similar rules apply to the append specification. Each track in file N will be appended to the corresponding track in file N-1 (the previous one on the command line). For example, if you have two files with three tracks each, then by default track 1 from file 2 will be appended to track 1 from file 1; track 2 from file 2 will be appended to track 2 from file 1; and track 3 from file 2 will be appended to track 3 from file 1.

Ok, clear too to me. But when the track order of such files has changed then I have to write a --track-order and --append-to switch?

Short sample:
Two(or more) VOB files with
1. Track video
2. Track audio(eng)
3. Track audio(ger)

Now I want to change the order of the audio streams

2. Track audio(ger)
3. track audio(eng)

(I know for the VOBs there is an option "other files" and I have to use these option but also I must use the normal append option too.)




The reason the GUI always adds those options is a different one. The command line generated by the GUI is not tailored towards the end user. Instead, its purpose is to be explicit and exact.
I like "explicit and exact" things. The command line preview is a very nice feature for me. I can quickly compare my generated JSON option file.

[sneaker_ger]

Ok, clear too to me. But when the track order of such files has changed then I have to write a --track-order and --append-to switch?

Short sample:
Two(or more) VOB files with
1. Track video
2. Track audio(eng)
3. Track audio(ger)

Now I want to change the order of the audio streams

2. Track audio(ger)
3. track audio(eng)
--append-to works with input file/track IDs so the order does not need to be changed if you only want to change the output order. Only change --track-order.

[Mosu]

Ok, clear too to me. But when the track order of such files has changed then I have to write a --track-order and --append-to switch?

Short sample:
Two(or more) VOB files with
1. Track video
2. Track audio(eng)
3. Track audio(ger)

Now I want to change the order of the audio streams

2. Track audio(ger)
3. track audio(eng)

You only have to use "--track-order" but not "--append-to". You will still append append source track 2 (audio eng) to track 2 (audio eng), and track 3 (audio ger) to track 3 (audio ger). Hence no need for "--append-to". The only thing you want to do is to change the order in which tracks are output, and that's what "--track-order" does.

What you'd need "--append-to" for is a situation like this:

First file: 1. video, 2. audio (eng), 3. audio (ger)

Appended file: 1. video, 2. audio (ger), 3. audio (eng)

Here you'd need to tell mkvmerge to append track 2 from file 2 to track 3 from file 1 (the two German tracks), and track 3 from file 2 to track 2 from file 1 (the two English tracks).

If you don't use "--track-order" in such a situation then the track order as found in the first source file will be used, meaning the English audio track will remain the second overall track in the output file.

[Mosu]

--append-to works with input file/track IDs so the order does not need to be changed if you only want to change the output order. Only change --track-order.

That's a nice and concise way of putting it. Thanks.

[hubblec4]

You only have to use "--track-order" but not "--append-to". You will still append append source track 2 (audio eng) to track 2 (audio eng), and track 3 (audio ger) to track 3 (audio ger). Hence no need for "--append-to". The only thing you want to do is to change the order in which tracks are output, and that's what "--track-order" does.

Thats nice to know.


What you'd need "--append-to" for is a situation like this:

First file: 1. video, 2. audio (eng), 3. audio (ger)

Appended file: 1. video, 2. audio (ger), 3. audio (eng)

Here you'd need to tell mkvmerge to append track 2 from file 2 to track 3 from file 1 (the two German tracks), and track 3 from file 2 to track 2 from file 1 (the two English tracks).

Ok, such a case will be never found on DVDs. But like you know MTX don't supported fully VOBs. The Subs will be added separately but "append-to" also.

For my simple sample, I will add a Sub(ger) track which consist of two(or more) files.
Have I to use the --append-to switch there?

[Mosu]

Can you be more specific what kind of files you're thinking of and what their respective tracks are?

[hubblec4]

To descirbe a more complex VOB-append with Subs(idx) sample, I have made a mtxcfg (http://forum.gleitz.info/attachment.php?attachmentid=99356&d=1495830791).

And now I found maybe an issue in the MTX-GUI.
I loaded all files, saved the mtxcfg file and want to open the Command line preview. MTX hangs without any message. Closing the MTX-GUI work only via the Task Manager.


EDIT: Reopen MTX-GUI with the mtxcfg file works, but when you open the command line preview the issue occurs again.

[Mosu]

To descirbe a more complex VOB-append with Subs(idx) sample, I have made a mtxcfg (http://forum.gleitz.info/attachment.php?attachmentid=99356&d=1495830791).

You don't need "--apend-to" for the subtitle files in that example .mtxcfg, no. Neither for the VOBs.

I loaded all files, saved the mtxcfg file and want to open the Command line preview. MTX crashes without any message. Closing the MTX-GUI work only via the Task Manager.

I cannot reproduce such a crash without config. The GUI v12.0.0 works fine regarding the "show command line" dialog, no matter which escaping mode I use.

[hubblec4]

You don't need "--apend-to" for the subtitle files in that example .mtxcfg, no. Neither for the VOBs.

Thanks for the info.


I cannot reproduce such a crash without config. The GUI v12.0.0 works fine regarding the "show command line" dialog, no matter which escaping mode I use.
OK, was my fault, sorry.

[Ripman]

Thanks for v12.

I have a question about an mmg gui warning, please. I am using the v12 gui.


'C:\12\wav\05-The Water Music -05. Minuet (From The F Major Suite).wav': Using the demultiplexer for the format 'WAV'.
Warning: DTS_Header problem: invalid source PCM resolution
'C:\12\wav\06-The Water Music -06. Bouree (From The F Major Suite).wav': Using the demultiplexer for the format 'WAV'.
'C:\12\wav\07-The Water Music -07. Hornpipe (From The F Major Suite).wav': Using the demultiplexer for the format 'WAV'.


Here are my mmg settings and options files, and the mmg output log. The package includes an 11mb wav file.
https://www.dropbox.com/s/ldeasv91i8dfcb6/mmg_v12---t06.rar?dl=1

Summary:
- Bought and downloaded an album from hdt @ 16-44.1-2ch.
- Muxed the wav files into one mka file.
- Got an mmg warning message in the v12 gui.
- Track 6 from the downloaded album shows a bitrate with mediainfo of 1412kbps instead of 1411kbps - obviously incorrect.

Question: What is mmg doing in this case: is it ignoring the incorrect header info, grabbing the pcm audio, and merging everything correctly? Thanks mosu.

[hubblec4]

Hi Mosu

Maybe I found a bug.
After appending two VOBs and change appending of two tracks and then move a DTS track, the GUI crashes without a message.

I have made a small video (https://forum.videohelp.com/attachments/41839-1496967627/MTX-Bug.7z) which shows what I have done.

[Mosu]

After appending two VOBs and change appending of two tracks and then move a DTS track, the GUI crashes without a message.

Crashes are definitely bugs. I'm currently out sick for quite a while. Please open an issue for this over on Github. Thanks.

[hubblec4]

Bug report is on Github.

Enjoy your holidays.

[kuchikirukia]

Mosu, I uploaded a mkv to your ftp that mkvtoolnix doesn't detect the TrueHD track 2. It was split from a larger mkv. The first half shows the TrueHD, the second split doesn't.
If I split it without the video track then mkvtoolnix can see both audio tracks. But as long as the video's there the TrueHD doesn't show.

I tried splitting it two seconds later and it's fine. And I've split 20 or so others from this Bluray without issue.
I'll also upload a mkv that straddles the point where I split the first in case you want to play around with it.

[Mosu]

I have a question about an mmg gui warning, please.

There's no such thing as "mmg" anymore. I guess you most likely mean MKVToolNix GUI, but please be precise.

Warning: DTS_Header problem: invalid source PCM resolution

This may happen during the file type detection phase when mkvmerge tries to determine whether a .WAV file actually contains DTS (and not plain uncompressed PCM). There's no consequence of that warning appearing, meaning the DTS detection fails, and mkvmerge will treat the content as PCM. Ideally that warning shouldn't be shown at all; all it does is confuse users. I'll probably remove it, and you can ignore it for files which you know don't contain DTS anyway.

[Mosu]

Mosu, I uploaded a mkv to your ftp that mkvtoolnix doesn't detect the TrueHD track 2. It was split from a larger mkv. The first half shows the TrueHD, the second split doesn't.
If I split it without the video track then mkvtoolnix can see both audio tracks. But as long as the video's there the TrueHD doesn't show.

I tried splitting it two seconds later and it's fine. And I've split 20 or so others from this Bluray without issue.
I'll also upload a mkv that straddles the point where I split the first in case you want to play around with it.

TrueHD is one of the few audio codecs where decoding cannot start from arbitrary frames, but only from so-called "sync" frames. This is similar to the distinction of key frames vs. non-key frames for video codecs.

mkvmerge is rather bad at handling files where more than one track makes such a distinction when it comes to splitting. It will split right before a video key frame, but it won't care whether that point is actually before a TrueHD sync frame or somewhere in the middle of several non-sync frames. The result is that the second file might start with non-sync TrueHD frames, causing mkvmerge not to recognize the track anymore.

You'll see the same issue if you have multiple video tracks whose key frames don't lign up exactly.

Fixing this properly would require quite some time & effort, neither of which I have a lot of at the moment. Therefore don't expect a fix for this behavior.

[Ripman]

TrueHD is one of the few audio codecs where decoding cannot start from arbitrary frames, but only from so-called "sync" frames.....

Fixing this properly would require quite some time & effort, neither of which I have a lot of at the moment. Therefore don't expect a fix for this behavior.


SFS Media make these instructional BDs that provide colour before each movement of a particular work.

The one that I have (viz., Ives) has a 7.1 truehd track @ 48khz. So I used makemkv and then cut the mkv by keyframe such that I had the four movements without the commentary introductions. I then merged those back together and also removed the video track. I believe I did this with mmg (that one is intentional <i>[Laughs]</i>) 7.5. The mkv/mka played fine and sounded nicely. The cut-points between movements sounded clean. About a year later I figured I'd extract the truehd track and re-sample it at a higher frequency so I could mix it down to flac stereo with the ffmpeg pan filters. I got an error with mkvextract on the truehd track - it didn't like the "area" around the first cut/merge, so it failed.

So I went back the the BD and makemkv, this time converting the truehd of track to flac. I did the same cuts. I merged it. It plays fine and sounds fine. I subsequently extracted the flac 7.1 track and re-sampled it with ffmpeg. Everything fine.

So after all that, here's my question: is the truehd to flac conversion process I described the "work-around" for dealing with truehd that needs to be cut in mkvtoolnix?

[Selur]

I got an mkvoptions file (see: https://pastebin.com/LHJ7GcBA) in which I append a few .264 streams and mux them with an audio stream.
Problem is, I now also want to add timecodes ("C:\\Users\\Selur\\Desktop\\psych100clues_timecode_cut.tc") to the merged video, but I'm not sure how I could to that.
I first thought that I would need to place:--timecodes 0:"C:\\Users\\Selur\\Desktop\\psych100clues_timecode_cut.tc" somewhere at the beginning, but that didn't work. :/
-> can someone tell me where I need to add my timecode line (assuming it isn't wrong)?

[sneaker_ger]

It should work if you put it before the first input part. I'm kinda hesitant to look through a 324 line option file for the problem esp. since you didn't seem to have included the problematic bit. Please check a gain with a shorter and human-readable sample and say what the problem is.

[hubblec4]

Hi Selur

Your option file is indeed a bit long, but it works.
You should place the --timcodes switch between the "--no-attachments" and "--forced-track" switches. I'm not sure how important is the order of the switches.


H:\\Output\\cut-001_reencode.264
--no-global-tags
--no-chapters
--no-subtitles
--no-track-tags
--no-buttons
--no-audio
--no-attachments
--timecodes
0:C:\\Users\\Selur\\Desktop\\psych100clues_timecode_cut.tc
--forced-track
0:no
--default-duration
0:59940/1000p
--fix-bitstream-timing-information
0:1

[Selur]

Thanks hubblec4 !! :D

[sneaker_ger]

Assuming "H:\\Output\\cut-001_reencode.264" is the first input part that's not where I would have put it.

[AngelGraves13]

Is there any specific reason why mkvmerge won't split at the timecode I specified? I want to split the mkv of a TV episode after the Netflix logo ends at 5s, but it always creates the split at 11s. Should I just install an older version?

[sneaker_ger]

https://github.com/mbunkus/mkvtoolnix/wiki/Splitting-imprecise

Try to set the split point a bit earlier. Maybe you missed a keyframe. If there really isn't one you need to use a different tool (e.g. SolveigMM Video Splitter). Downgrading mkvtoolnix won't help.

[Mosu]

Hey,

Here's v13.0.0 of MKVToolNix. It contains a few small enhancements and a handful of bug fixes. Nothing major this time around, though I still recommend everyone to update.

There have been no additional changes since v12.0.0 that package maintainers should be aware of.

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 13.0.0 "The Juggler" 2017-06-25

## New features and enhancements

* mkvmerge: MPEG TS reader: information about multiple programs will be output as container properties during verbose/JSON identification. See #1990 (https://github.com/mbunkus/mkvtoolnix/issues/1990) for the use case.
* MKVToolNix GUI: multiplex tool: added a column "program" to the tracks list. Certain container types such as MPEG transport streams can contain multiple programs. The new column will contain the service name (think TV station names such as "arte HD") for such streams. Implements the GUI part of #1990 (https://github.com/mbunkus/mkvtoolnix/issues/1990).
* MKVToolNix GUI: multiplex tool: the dialog asking the user what to do with dropped files (add to current settings, add to new settings etc.) now remembers the previous decision and defaults to it the next time it's shown. Implements #1997 (https://github.com/mbunkus/mkvtoolnix/issues/1997).
* MKVToolNix GUI: tabs can now be closed by pressing the middle mouse button. Implements #1998 (https://github.com/mbunkus/mkvtoolnix/issues/1998).

## Bug fixes

* mkvmerge: MP4 reader: MPEG-1/2 video read from MP4 files was written with an invalid codec ID (e.g. `V_MPEG7`) in certain cases. Fixes #1995 (https://github.com/mbunkus/mkvtoolnix/issues/1995).
* mkvmerge: MPEG PS reader: made the file type detection less strict so that garbage at the start of the file doesn't prevent detection. Fixes #2008 (https://github.com/mbunkus/mkvtoolnix/issues/2008).
* mkvmerge: MPEG PS reader: (E-)AC-3 tracks were not detected if the very first packet for that track didn't contain a full (E-)AC-3 frame. Fixes #2016 (https://github.com/mbunkus/mkvtoolnix/issues/2016).
* mkvmerge: MPEG TS reader: fixed mkvmerge not detecting all tracks in MPEG transport streams containing multiple programs. Fixes one part of #1990 (https://github.com/mbunkus/mkvtoolnix/issues/1990).
* mkvmerge: MPEG TS reader: fixed track content being broken for some tracks read from MPEG transport streams containing multiple programs. Fixes another part of #1990 (https://github.com/mbunkus/mkvtoolnix/issues/1990).
* mkvmerge: JSON identification: the `stream_id` and `sub_stream_id` track properties were output as hexadecimal strings instead of unsigned integers. As the `ts_pid` track property was only used for MPEG transport streams, its value is now output as `stream_id` instead, and the `ts_pid` property has been removed. The JSON schema version has been bumped to 8 due to this change.
* mkvmerge: fixed a crash when appending video tracks where one track has a CodecPrivate member and the other one doesn't.
* mkvmerge: track statistics tags: the `NUMBER_OF_BYTES` tag is supposed to contain the number of bytes in a track before any of the content encoding schemes such as lossless compression is applied; however, mkvmerge was wrongfully using the number of bytes after the schemes had been applied. Fixes #2022 (https://github.com/mbunkus/mkvtoolnix/issues/2022).
* mkvmerge: CLPI & MPLS parsers: MPLS and CLPI files with version number `0300` as used on Ultra HD Blu-ray Discs are now accepted as well. Fixes #2010 (https://github.com/mbunkus/mkvtoolnix/issues/2010).
* mkvpropedit: fixed a crash when the selector used for `--tags` is invalid.
* MKVToolNix GUI: fixed computation of value of total progress bar for multiple jobs running. Fixes #2005 (https://github.com/mbunkus/mkvtoolnix/issues/2005).
* MKVToolNix GUI: multiplexer, adding new attachments: when the GUI checks if there's an attachment with the same name it will now disregard disabled attached files. Fixes #2001 (https://github.com/mbunkus/mkvtoolnix/issues/2001).
* Debian/Ubuntu packaging: during a `dpkg-buildpackage` run the test suite was failing when a non-English locale was active and MKVToolNix packages had already been installed. Fixes #2011 (https://github.com/mbunkus/mkvtoolnix/issues/2011).

Have fun :)

[hubblec4]

Many thanks for all this fixes.
The DVD Salt is now working.

[satmonk]

I know how Microsoft act, and that is no secret: The goal is big business and that means: they want our money for their new OS's

Did Bunkus ever told us why he need Quicktime for a (de-)muxer?
Did he ever gave us a comprehensible answer why he dropped the PC (XP) support?

No.

I tell you why: because he got paid by Microsoft and with this dishonorable descision he works for Microsoft silently. I just want to know how much money he got for that.

Usually it is the codex of freeware programmers to support users of personal computers without large business dependencies.

It is inacceptable that I need a PC with a modern operating system which costs a lot of money for freeware.
That is not the honorable way here.:angry:

And because MS and their people are stronger than me, we will see that my post surely will be deleted soon.

[Mosu]

Haaaaahahahaha. Thanks for the laugh.

If you don't want a "corporate" OS, then just switch to Linux and use MKVToolNix there. I offer packages for various distributions, and as Linux is my primary development OS I'll guarantee that there'll always be Linux versions of MKVToolNix.

[satmonk]

You do not need the media foundation parts for a GUI.
What is your real intention for dropping xp support? Your command line merge tool still works on XP. Many users still use XP and advance PC users know how to protect their OS. You know how to programm software, so it should be easy for you to support a Windows OS which is still in use. MKV is a free data container, so let the usage as free you you can. Do not follow the path that game programmers went (dependeny of DirectX and so on...).

edit: Linux is still no competition for MS. Most people use MS products (i.e. Win10)

but good to hear that your primary development goal is Linux, but bad with xp, i cannot understand that, because this OS is STILL in USE and STILL a very good OS with support of a variety of software which Win Vista/7/8/10 cannot handle

[microchip8]

You do not need the media foundation parts for a GUI.
What is your real intention for dropping xp support? Your command line merge tool still works on XP. Many users still use XP and advance PC users know how to protect their OS. You know how to programm software, so it should be easy for you to support a Windows OS which is still in use. MKV is a free data container, so let the usage as free you you can. Do not follow the path that game programmers went (dependeny of DirectX and so on...).

edit: Linux is still no competition for MS. Most people use MS products (i.e. Win10)

it's time for your medication

[Mosu]

Just as much as it's your prerogative not to upgrade your OS in order to save money (or for any other reason, really), it's my prerogative to offer support only for a limited number of current OS versions in order to ease the burden such support places on me. I do not owe you an explanation, in fact I don't owe you a single thing. I offer free software including source code, and you're free to use it as-is, to modify it to your heart's content, to get others to modify it to your wishes, or not to use it at all.

[lvqcl]

Usually it is the codex of freeware programmers to support users of personal computers without large business dependencies.
Not true. As one of Debian developers wrote (https://lists.debian.org/debian-devel/2016/09/msg00363.html):
we are a community of people building something *for ourselves*, cooperatively. If other people in the world want to use it, great! If we can help them use it, great! Even better if we can attract them to contribute. And if they don't like it, great! They can use something else. Or make it better. They have free choice.

It is inacceptable that I need a PC with a modern operating system which costs a lot of money for freeware.
Then do something yourself. Switch to Linux. Or download MKVToolNix sources, change them as you want, and build your own version.

[Ripman]

I was appending hd flac tracks (24/352/stereo) in the v12 gui. I got warnings about mismatched private codec data. The resultant file seems to be fine - plays fine, sounds fine.

The log is about 60k, so I put it in dropbox, along with 2 flacs.
https://www.dropbox.com/s/5r5dh6a3dxpai2v/v12_private-codec-data.rar?dl=1

Do I need to edit the headers of these flac files to get the private codec data to match? (That can't be right, right?) I am almost positive that I have asked this before, but I cannot find it.

[Ripman]

Notwithstanding the various conspiracy theories regarding mkvtoolnix, and ongoing os religious wars....

How about a disposition regarding the mkvtoolnix/truehd/flac "workaround" from post 4765 above.
http://forum.doom9.org/showpost.php?p=1810118&postcount=4765

Thanks for v13.

(I am almost positive that I have asked this before, too, but I cannot find it.)

[Mosu]

I was appending hd flac tracks (24/352/stereo) in the v12 gui.

Appending and splitting FLAC tracks is not supported. The reason is that several header fields have to be updated in such scenarios, and that in turn would require actually decoding the FLAC data back to uncompressed audio and creating checksums over that uncompressed audio. The existing FLAC libraries are completely unsuited to embedding in other programs with structures such as mkvmerge. Hence me not fixing this.

Even if your file seems to play just fine there are tons of tools out there that will have problems with such a track.

I don't have a method for fixing such files.

In short: don't append or split FLAC with mkvmerge.

[sneaker_ger]

In general: if you encode anyways it is preferable to edit/cut in the lossless domain (e.g. AviSynth or ffmpeg filters) before encoding instead of doing it with mkvmerge. This is true for video and audio. Effective way to avoid problems. And for FLAC you can re-encode losslessly anyways. That will also avoid those TrueHD problems.

[Ripman]

In short: don't append or split FLAC with mkvmerge.

Thanks for that info. I'll try to come up with a different approach.

I'll delete those dbox links...

[Ripman]

In general: if you encode anyways it is preferable to edit/cut in the lossless domain (e.g. AviSynth or ffmpeg filters) before encoding instead of doing it with mkvmerge. This is true for video and audio. Effective way to avoid problems. And for FLAC you can re-encode losslessly anyways. That will also avoid those TrueHD problems.

Regarding truehd, I was trying to skip the ffmpeg step, which, in this scenario, can used from the command line or via the ffmpeg add-in for Audacity.

Regarding appending of flacs: that's how I get them - the separate flacs "are" the source (as they are available to me). One could convert to wav, but with some higher sampled files (e.g., 352.8khz), limits can be hit. [edit: I mostly get these hd audio files from hdtracks and nativedsd. On a personal note, I'd skip the latter site.)

[Ripman]

ffmpeg filters

I definitely appreciate the guidance you guys have given -- the other day and in the past. @sneaker_ger: the relevance of your comment regarding the distinction between ffmpeg and mkvtoolnix is fully understood.

For my purposes, and maybe for others too, the workaround is to simply append flac audio tracks before putting them in an mkv/mka container. A command invocation like "sox *.flac out.flac" would work. A script can be used to generate an xml chapters file from the (mediainfo) durations of the separate tracks. (This is the process I used before the "create chapters for each appended file" option was implemented.)

Happy Friday and thanks for the new version 13.

[Atak_Snajpera]

Is this known limitation of MKVMerge that .w64 is being detected as AVC
http://i.cubeupload.com/cFIDI3.png

[Mosu]

Unknown/unsupported file types are often mis-detected as an AVC/h.264 elementary stream as AVC/h.264 elementary streams have very lose structures.

What is that file supposed to be?

[stax76]

wave > 4 GB

[Mosu]

Presumably they use chunks other than "riff", "fmt " and "data"? If so, can I get a sample file from somewhere, or produce such a file somehow?

[Mosu]

Scratch that, I just found one in the VLC samples archive that mkvmerge doesn't recognize. I'll look into it.

[stax76]

You should also be able to create one by using w64 as output file extension for ffmpeg or eac3to.

[Atak_Snajpera]

Yeah. Wave64 file was created by eac3to.

[nevcairiel]

w64 is an entirely different format to normal wave, but it should be well documented.

[satmonk]

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.

I use XP because it works faster than Win7 and offers much more application compatibility to me. I use a heavily customized xp version which I done by myself for my requirements. Hard to see that a free project dropped xp support. Freeware programmers usually try to support as many OS as they can and try to beat commercial software. Main goal should be to track down capitalism and every programmer who release free software is a LITTLE part to rise up a capitalism-free world. Yes, a dream far away, but everytime I see a new project of freeware released, I'm very happy about that and hope that the business of Microsoft is shrinking. But if a freeware programmer follow Microsofts main path ("only support their new OS to force customers to buy their new OS"), than these programmers are automatically a PART of microsofts cold business strategy :devil:...... sorry for my bad english

[Atak_Snajpera]

Win XP (and win8.1) is almost dead. Deal with it and install win7.
http://i.cubeupload.com/4sSpSK.png

[SeeMoreDigital]

Win XP (and win8.1) is almost dead. Deal with it and install win7.It's a shame this forum doesn't have a like button ;)

[manolito]

Win XP (and win8.1) is almost dead.

Almost dead? Are you kidding?

Having a total market share of almost 7% means it is still number 3 of all desktop operating systems. And this is after having been abandoned for so many years. There must be something about it which a lot of people (including me) still love...


Cheers
manolito

[Atak_Snajpera]

Having a total market share of almost 7% means it is still number 3 of all desktop operating systems.

See trend and you will understand that win8 is doomed. Nothing can save it. It will soon die like "beloved" vista. Besides ~7% is a pure joke if compare to win7 with strong 49% (7 times MoAr!!!)
Personally I don't see anything special in this NT6.2/3 OS. It is basically win7 with more ugly UI and without support for Win2000 classic theme.
If you like it fine not my problem. At least you have more control over updates and your OS has not been degraded to service level like Win10 aka AlwaysUnderConstruction10 aka Beta10 aka Spy10 and so on ;)

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

[Mosu]

Read this fine FAQ entry (https://github.com/mbunkus/mkvtoolnix/wiki/Elements-not-showing-up-in-output-file). The summary is: TrackFlagDefault's default value (= the value a player must use if the element is not present) is "true". As you're setting that flag to "true", mkvmerge does not have to write it and doesn't do so, because its absence means implicitly that it is "true".

[hubblec4]

Ok, fine. I thought I did an issue.

[Nico8583]

Hi,
I've seen some people uses "--clusters-in-meta-seek --disable-track-statistics-tags --engage no_cue_duration --engage no_cue_relative_position" options to improve compatibility. What are the others pros and cons to allways use it ?
Thank you !

[sneaker_ger]

https://github.com/mbunkus/mkvtoolnix/wiki/Improving-playback-compatibility-with-players

If it adds data: more overhead. no_cue_duration/engage no_cue_relative_position: seeking into the middle of a subtitle line works in players that can make use of those (e.g. LAV/MPC-HC).

[hello_hello]

When appending MKVs, MKVToolNix accounts for any existing audio/video delays or gaps etc and maintains sync, unless one of the MKVs being appended contains no audio at all.
For example, if you append three MKVs, and the second MKV contains no audio, in a perfect world it'd be treated as an audio gap and the video/audio sync for the third MKV being appended would be unaffected. What seems to happen though, is the audio in the third MKV is appended to the audio in the first MKV as though individual streams were being appended. I don't know if the same applies to subtitle streams. Is that a bug or intended behaviour?

Cheers.

PS. Keep in mind I'm using manolito's workaround with MKVToolNix version 15 (thanks manolito), given I'm running "no-ding" XP, although I doubt it's related to the problem....

[Nico8583]

https://github.com/mbunkus/mkvtoolnix/wiki/Improving-playback-compatibility-with-players

If it adds data: more overhead. no_cue_duration/engage no_cue_relative_position: seeking into the middle of a subtitle line works in players that can make use of those (e.g. LAV/MPC-HC).
Ok thanks :)
I don't know if I must use it or not, I can test my players now but in few months perhaps I'll use new devices so I can't know if these options will be supported... Difficult choice :rolleyes:

[hubblec4]

Hi Mosu

I have noticed that when I load a UHD-Bluray m2ts or mpls to MTX then all languages are well defined.
In an older version of MTX all languages was set to "und".

Have you improved your UHD-Bluray parser? Where you got this new infos?

[Mosu]

I didn't really change anything regarding languages on Blu-rays. If the language is present in the MPLS/CLPI files, then it is used. Simple as that.

[hubblec4]

Hi Mosu

I have some questions about mpls.

In the identify.json for all streams exists a "stream_id" with a number. This number seems to me not always match with the number in the mpls.

Here is an example (https://forum.videohelp.com/attachments/43114-1505400085/MTX-mpls-PIDs.7z) of the Terminator 2 Bluray.

mpls 00018: there are 2 DTS-Express audio tracks and a second video track.

Video 2: "stream_id": 6912 -> binary 1B 00
DTS 1: "stream_id": 6656 -> binary 1A 00
DTS 2: "stream_id": 6657 -> binary 1A 01

But I don't found this binary values in the mpls.

Why is the order of the streams in MTX different to the order in the mpls?

Best regards

[Mosu]

But I don't found this binary values in the mpls.

Why is the order of the streams in MTX different to the order in the mpls?

For mkvmerge the actual content of the M2TS file(s) is relevant, not what's in the MPLS. mkvmerge reads the M2TS files listed in the MPLS file and uses all streams found in the M2TS files. Track IDs are assigned in the order they're found in the M2TS.

It's quite possible those streams are simply not listed in the MPLS.

[hubblec4]

For mkvmerge the actual content of the M2TS file(s) is relevant, not what's in the MPLS. mkvmerge reads the M2TS files listed in the MPLS file and uses all streams found in the M2TS files. Track IDs are assigned in the order they're found in the M2TS.

Ok, nice to know and that makes now some cases clearly to me.


It's quite possible those streams are simply not listed in the MPLS.

Mmh thats not so fine.
The streams also listed in the mpls but with different stream_id's.
Is there a chance to get the correct mpls stream_id's with the identify-json?

[Mosu]

The streams also listed in the mpls but with different stream_id's.
Is there a chance to get the correct mpls stream_id's with the identify-json?

Uhm… no? There's only one stream ID in the M2TS for each packet, and if that is present in the MPLS, then great; if it isn't, then that's how it is. There's nothing wrong with the stream IDs reported by mkvmerge.

[Mosu]

In fact, one could argue that mkvmerge should not report streams found in the M2TS files that aren't listed in the MPLS if an MPLS is used as an input file. On the other hand, that might be considered to be a step in the wrong direction and taking away functionality that people like.

[hubblec4]

Uhm… no? There's only one stream ID in the M2TS for each packet, and if that is present in the MPLS, then great; if it isn't, then that's how it is. There's nothing wrong with the stream IDs reported by mkvmerge.

I'm sure mkvmerge works fully correct, but I hoped there are more info in the m2ts for the streams.


In fact, one could argue that mkvmerge should not report streams found in the M2TS files that aren't listed in the MPLS if an MPLS is used as an input file. On the other hand, that might be considered to be a step in the wrong direction and taking away functionality that people like.


Mmh...
When I play the 00018.mpls in mpc-hc, I see both DTS-Express streams and I can select them, BUT mpc-hc stops immediately playing (playback button is shown active).

When I play the Bluray in TotalMediaTheater(TMT) both DTS-Express streams are not available (for the Theater Version and the Director's Cut, I can't play the T-1000 Edition, but I guess there are both streams available)

I think TMT is more closer to the Bluray Specs than mpc-hc.

It seems to me this behaviour is same like found on DVD's for Multi/Angle Edition cases.
In the IFO the streams are listed which used, but in some VobID's more audio streams listed.
TMT shows the respective audio streams for each edition only.
No mkv which I muxed played correctly when I select the "extra" audio stream.

Maybe have not all m2ts files all audio streams inside.
I don't know how many m2ts files mkvmerge scaned from an mpls which have more than 30 m2ts files.

If so, only audios which listed should be used.

[hubblec4]

Hi Mosu

As I already suspected it is the same behaviour like on DVD's.
Only the 00020.mpls have the secondary video stream and all other audio(secondary) streams listed and are playable.

I scaned the different m2ts files with MediaInfo and all files have all streams inside.
Maybe thats the reason why I had never problems to mux Multi-Edition-mkvs for such cases.

[Perenista]

Question: if I simply add a file to MKVToolnix and save as MKV, will that change its contents? I mean, will this MKV be lossless or lossy?

Look the info from the .MPG file:

https://pastebin.com/9BikesZS

And now the MKV created by MKVToolnix:

https://pastebin.com/Jzz7WkYC

If nothing changed why the original file has 7.58 and the MKV 7.44 GB? And what about this?


Original file:
Frame rate : 29.970 (30000/1001) FPS

Matroska:

Frame rate : 23.976 (24000/1001) FPS
Original frame rate : 29.970 (30000/1001) FPS

Note: I always like to add files to MKVToolnix and save as MKV to change something specific, such as naming the audio tracks or adding subtitles. Since it's easier to use MKVToolnix for this, I simply add the .AVI, .MPG or whatever file is, and do the procedure there. I am assuming despite the above changes from Pastebin it's still lossless, right?

[Asmodian]

Yes, it will be lossless. The size difference is simply because matroska is a very efficient container.

The change in the frame rate is probably due to the mpeg2 using soft pulldown. This is flagging which generates 29.970 fps video from 23.976 encoded video during playback and mkv doesn't keep this flagging the same way as the mpg container. You generally don't want pulldown unless putting the video on DVD (which do not allow 24fps) because it adds 3/2 judder.

[MrVideo]

I'm sure this has been brought up before, but because there lots of pages and searching for "truehd" leads to too many results, I figure it would be easier to just ask.

AIUI, when a TS/M2TS file is muxed into a MKV wrapped file, and if the the audio is TrueHD, or maybe even DTS-MA, the core is stripped out. That means if the MKV file is imported into tsmuxer, the audio streams are rejected. Why is the core ripped out? Why not leave the TrueHD/DTS-MA streams intact?

[sneaker_ger]

https://github.com/mbunkus/mkvtoolnix/wiki/TrueHD-and-AC-3

This does not apply to DTS-HD MA. The lossless HD part is a "true" extension that needs the core data. It is not independent.

[MrVideo]

Thanks for the reference. IMHO, the spec needs to be changed to allow audio streams like TrueHD to remain intact. But, that's just me.

[nevcairiel]

Thanks for the reference. IMHO, the spec needs to be changed to allow audio streams like TrueHD to remain intact. But, that's just me.

Those streams aren't really "combined" in MPEG-TS either, there is a clear separation in MPEG-TS that allows you to cleanly split it into AC3 and TrueHD streams. It is basically two streams, just muxed in a peculiar way for backwards compatibility for certain players.

In any other container, it should definitely and absolutely be two separate streams.

Maybe you should lobby tsMuxer that it learns to re-combine an AC3 stream with a TrueHD stream, instead? That would be the right thing to do.

[LeMoi]

I have the following error when trying to mux from an mpls playlist (sorry it's in french...):
--- Erreurs émises par la tâche « Multiplexage du fichier « film.mkv » dans le dossier « ***\RIP » » lancée le 2017-09-28 19:59:20 ---
Le fichier n° 0 (« ***\BDMV\PLAYLIST\..\STREAM\00009.m2ts ») ne contient pas de piste d'identifiant 3 ou cette piste ne doit pas être copiée. Aucune piste ne peut donc lui être ajoutée. L'argument de « --append-to » était incorrect.
Here are the tracks that appear in mkvtoolnixGUI:
http://nsa39.casimages.com/img/2017/09/29/170929123258163070.jpg

I think the problem is that the mpls contains 4 files:
http://nsa39.casimages.com/img/2017/09/29/1709291235325377.jpg

One of them contains 4 tracks:
http://nsa39.casimages.com/img/2017/09/29/170929123532135740.jpg

The last 2 only have video track, the 1st one one video and 2 audio.

How to bypass this error?
I think the program should skip the tracks that are not available in every mpls, or a least we could be able to choose...
In my case, I only need the 2 first m2ts with audio and video (or only video), I can arrange myself with the sub track from the 2nd one and last 2 are not useful.
Thanks for your help!

[von Suppé]

a mpls can have multiple streams, it's not uncommon. But as I see your mkvtoolnix window, can't you just check the french or spanish audio box to mux them?

I don't understand the error; it's in French.

[Mosu]

I have the following error when trying to mux from an mpls playlist (sorry it's in french...):

Your error message and all of your screenshots don't match each other:

The error message talks about file 0 being 00009.m2ts. However, the first file (that's the one mkvmerge considers to be file 0) in the list is 00000.m2ts.
The track list doesn't show any appended track even though the file list shows appended files.

This makes is neigh impossible to help you. Please post a screenshot of the GUI's "input" tab (especially so that we can see which file each track belongs to) if you want a proper answer.

[hubblec4]

@LeMoi

I found some Blurays with multiple Playitems(more then one m2ts) and sometimes a m2ts has other stream settings like the other m2ts files.
MKVToolNix bring this error when you try to combine different streams.

Play file 00009 and 00001 and 00010 and see what is content.
In my chapterEditor (MultiEditionEditor) there is a possibillity to ignore the first and last m2ts file, maybe you could try this.

[Mosu]

I've just released v16.0.0 of MKVToolNix. This release is mostly a bug fix release.

Changes for package maintainers: libMatroska v1.4.8 is now required.

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

All binaries have been built and uploaded.

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

# Version 16.0.0 "Protest" 2017-09-30

## New features and enhancements

* mkvmerge: MP4 reader: added support for Vorbis. Implements #2093 (https://github.com/mbunkus/mkvtoolnix/issues/2093).

## Bug fixes

* configure: the checks for libEBML and libMatroska have been fixed to require libEBML 1.3.5 and libMatroska 1.4.7 as intended.
* mkvmerge: AAC reader: mkvmerge will now emit an error message for AAC files whose header fields imply a sampling frequency or number of channels of 0. See #2107 (https://github.com/mbunkus/mkvtoolnix/issues/2107).
* mkvmerge: AVC/h.264 ES parser: fixed the calculation of reference information for P and B frames. This also fixes some P frames being marked as B frames and vice versa.
* mkvmerge: AVC/h.264 ES parser: only non-key frames that have the NALU header field `nal_ref_idc` set to 0 will be marked as "discardable" in `SimpleBlock` elements. Other half of the fix for #2047 (https://github.com/mbunkus/mkvtoolnix/issues/2047).
* mkvmerge: HEVC/h.265: the generation of the HEVCC structure stored in `CodecPrivate` was wrong in two places: 1. the position of the number of sub-layers was swapped with reserved bits and 2. the VPS/SPS/PPS/SEI lists did not start with a reserved 1 bit.
* mkvmerge: output: the `doc type version` will be set at least to 2 if certain elements are written (`CodecState`, `CueCodecState`, `FlagInterlaced`).
* mkvmerge: output: the track header attributes `MinCache` and `MaxCache` will not be written anymore. Fixes #2079 (https://github.com/mbunkus/mkvtoolnix/issues/2079).
* mkvmerge: Matroska reader: the "key" and "discardable" flags of SimpleBlock elements will be kept as they are. Partial fix for #2047 (https://github.com/mbunkus/mkvtoolnix/issues/2047).
* mkvmerge: Matroska reader: if present in the file, the "white colour coordinate x" track header attribute was written to both "white colour coordinate x" and "white colour coordinate y" in the output file.
* mkvmerge: Opus output: mkvmerge will now put all frames with discard padding into their own block group. Fixes #2100 (https://github.com/mbunkus/mkvtoolnix/issues/2100).
* MKVToolNix GUI: header editor: removed the check for external modification when saving the file. Fixes #2097 (https://github.com/mbunkus/mkvtoolnix/issues/2097).
* MKVToolNix GUI: job queue: fixed calculation of total progress when automatic removal of completed is enabled. Fixes #2105 (https://github.com/mbunkus/mkvtoolnix/issues/2105).

## Build system changes

* libEBML v1.3.5 and libMatroska v1.4.8 are now required. In fact v15.0.0 already requires libEBML v1.3.5 and libMatroska v1.4.7 but did not include proper version checks for them (nor was there a NEWS.md entry for the new libMatroska requirement). New is the requirement for libMatroska v1.4.8 due to it fixing writing block groups for tracks with the track number 128 (see #2103 (https://github.com/mbunkus/mkvtoolnix/issues/2103)).

Have fun :)

[hubblec4]

Hi Mosu

First, thanks for the new version of MTX.

Second, I have a question about the order of the ID's which are used for the switches --video-tracks,--audio-tracks and --subtitle-tracks in an option-json file.
How important is the/your order (min to max).
Example: 1,2,4,7,13,18
Is it ok when I use 1,18,4,2,13,7 ?

After this 3 switches and their values follows a list with the ID's and some other options like --language and so on.
Can I change this order also or is it important to order the ID's (min to max)?

hubble

[sneaker_ger]

Order should be irrelevant. Did you run into problems?

[Mosu]

As long as the options remain in front of the file they apply to and as long as no ID occurs multiple times: the order isn't important, neither the IDs listed with a multi-ID option such as "--audio-tracks", nor multiple single-ID options such as "--language 1:fre". Meaning "--language 1:fre --language 2:ger input.mkv" and "--language 2:ger --language 1:fre input.mkv" are equivalent, as are "--audio-tracks 1,2" and "--audio-tracks 2,1".

If you have multiple options with the same ID, then the last one wins (e.g. in "--language 1:fre --language 1:ger…" the actual language would be "ger").

The order of the different options doesn't matter either: "--language 1:ger --audio-tracks 1" and "--audio-tracks 1 --language 1:ger" are equivalent.

That being said: there are certain options that correspond to other options and that are reset as soon as that other option is encountered. Sounds abstract? Here are two examples:

All options "--attachment-*", e.g. "--attachment-description", apply to the following "--attach-file" or "--attach-file-once" option. "--attachment-mime-type image/jpeg --attachment-description cover --attach-file 1.jpg" and "--attachment-description cover --attachment-mime-type image/jpeg --attach-file 1.jpg" are equivalent, but "--attachment-description cover --attach-file 1.jpg --attachment-mime-type image/jpeg" aren't as the very last "--attachment-mime-type" applies to the following "--attach-file" (which doesn't even exist in my example, meaning it would effectively be ignored).
"--chapter-charset" applies to the following "--chapters …" or the following input file, whichever comes first.

Basically there are two easy to remember rules:

Options apply to whatever comes next that uses that option (input file, chapter file, attachment…).
The order before each input file/chapter file/attachment doesn't really matter.

[hubblec4]

Order should be irrelevant. Did you run into problems?

I hope not, but I want to be sure before I start with coding.

@Mosu
Thanks for this explanation, it makes my task easier.

[LeMoi]

Your error message and all of your screenshots don't match each other:

The error message talks about file 0 being 00009.m2ts. However, the first file (that's the one mkvmerge considers to be file 0) in the list is 00000.m2ts.
The track list doesn't show any appended track even though the file list shows appended files.

This makes is neigh impossible to help you. Please post a screenshot of the GUI's "input" tab (especially so that we can see which file each track belongs to) if you want a proper answer.

I think you misunderstood the screens, or maybe they were not clear (1st screen is from mkvtoolnixgui, other ones from TSMuxerGUI).
First file is 00009.m2ts, not 00000.
Here's the screen from MKVToolnixGUI:
http://nsa39.casimages.com/img/2017/10/01/171001055913477928.jpg

As you can see, the GUI doesn't show any detail about the m2ts files included in the playlist.

I managed to solve the problem by creating my own 'playlist' while appending 00009.m2ts with 00000.m2ts, but I think there's a problem with the program and such playlists

[Ripman]

Thanks for v16 (and v15 too).

[LeMoi]

@LeMoi

I found some Blurays with multiple Playitems(more then one m2ts) and sometimes a m2ts has other stream settings like the other m2ts files.
MKVToolNix bring this error when you try to combine different streams.

Play file 00009 and 00001 and 00010 and see what is content.
In my chapterEditor (MultiEditionEditor) there is a possibillity to ignore the first and last m2ts file, maybe you could try this.

I think that's that is the problem, that's why I suggest that if the program finds many m2ts in the mpls file, and if all m2ts files don't contain the same tracks, it could offer the ability to choose the tracks to append to other ones

[Mosu]

I think that's that is the problem, that's why I suggest that if the program finds many m2ts in the mpls file, and if all m2ts files don't contain the same tracks, it could offer the ability to choose the tracks to append to other ones

Fine-grained track control for the files a single MPLS references won't happen. Would take way too much time rewriting stuff in both the GUI and in mkvmerge.

[hubblec4]

Maybe could Mosu do that, but I think this is a bit much work. Ask him :-)

On such a Bluray, the last m2ts file contains no audio or sub stream. So if you like to keep the last m2ts, you can't use any audio or sub.
I think it is better to ignore such "dummy" m2ts files.

[hubblec4]

As you can see, the GUI doesn't show any detail about the m2ts files included in the playlist.

A "normal" Bluray mpls looks like the same.
No m2ts files are listed.

[LeMoi]

Thanks for your answers, so the easiest way should be to use TSMuxerGUI to know what m2ts files to append, then MKVToolnixGUI to select the wanted tracks from these files. That's what I finally did and would do again if needed

[hubblec4]

Thanks for your answers, so the easiest way should be to use TSMuxerGUI to know what m2ts files to append, then MKVToolnixGUI to select the wanted tracks from these files.

For this simple case it would be ok, but believe me there are some Blurays with more then 40 m2ts files.
It is a huge task to append all this files.

The fastest way is to use chapterEditor(cE).
You get a mtxcfg file with all m2ts files and ordered streams (used or not).
Ok, for the moment is cE (BD2mkv) depent on eac3to.
The new cE (BD2mkv, comming soon) is only depent on MKVToolNix.

[LeMoi]

I rarely need it, usually TSMuxerGUI can provide me a playable file, but this time, for some reason, the video track was corrupted when I remuxed the mpls file with TSMuxer, and fine with MKVToolnixGUI...
Thanks for the tip, I'll try when I need to!

[AYColumbia]

Hi Mosu,
In the last couple versions I've started seeing more of this error:
[O] [2017-10-06] [18:41:37] Error: 'SomeAudioFile.ac3': Reading encrypted VOBs is not supported.
If I try to add the AC3 file to the UI it rejects it with an "Unrecognized file format" dialog that says "The file was not recognized as a supported format (exist code 2)." What's strange is it seems the issue is only on files encoded at 192kbps or 384kbps. This happens with files I reencode from dts for example or those I extract directly at original bit rate of 192 or 384. I'll upload an audio file with this issue shortly. Please let me know if you need any other info. Thank you.

[Mosu]

Thanks for the report. 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.

[AYColumbia]

Thanks for the report. 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.
I appreciate that. I'll put it in the bug tracker shortly. Thanks again.

[Mosu]

For those not following on Github: the AC-3 detection issue has been fixed. New pre-builds for Windows (https://mkvtoolnix.download/windows/pre/) are available.

[AYColumbia]

For those not following on Github: the AC-3 detection issue has been fixed. New pre-builds for Windows (https://mkvtoolnix.download/windows/pre/) are available.
Wow, that was quick. :) Thank you.

[Mosu]

Yeah… It was one of those issues where I knew in advance exactly what was happening and why; therefore it was easy to verify that assumption and change some things around in order to improve file type detection.

[Megalith]

I am trying to mux Blade Runner but MKVMerge is producing a file that can't be played. I can only assume that it has something to do with the video file being in VC-1 format...

[Mosu]

If it's VC-1, then see this issue (https://github.com/mbunkus/mkvtoolnix/issues/2113).

[Megalith]

Thanks, I had never bothered to look at the pre-builds before.

[burfadel]

I've been using prebuilds for a long while, and this is the first time in a very long time that I've come across an issue with them. For the last couple of prebuilds I get the following messge:
mkvmerge executable was not found. in the GUI when I add a source file, even though the mkvmerge.exe file is in the same folder. If I add audio (opus file) it shows the error, however it adds and it can be muxed. It does not allow additing of the video file though (and the message appears).

In Staxrip 1.7.0.0, which accesses mkvmerge directly, the following error occurs:
Muxing using mkvmerge 15.0.0 failed with exit code: -1073740940 (0xC0000374)

The exit code might be a system error code: A heap has been corrupted.

The version 15.0.0 is there because that's what Staxrip 1.7.0.0 comes with. The video file is h265 with .hevc extension.

The version 16.0.0 works fine.

[Mosu]

Can you please upload one such problematic file to my FTP server (https://github.com/mbunkus/mkvtoolnix/wiki/FTP-server)? Thanks.

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

[Mosu]

Welcome to release v18.0.0 of MKVToolNix. This is just a smallish bug fix release which also contains a couple of performance improvements.

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 18.0.0 "Apricity" 2017-11-18

## New features and enhancements

* build system: when building with clang v3.8.0 or newer, `configure` will no longer restrict optimization flags to `-O1` and use `-O3` again (older versions of clang suffered from excessive memory usage with higher optimization levels).
* build system: when building with mingw 7.2.0 or newer, `configure` will no longer restrict optimization flags to `-O2` and use `-O3` again (older versions of mingw suffered from bugs such as segmentation faults with higher optimization levels).
* build system: stack protection is enabled when building with clang 3.5.0 or newer on all platforms.
* mkvmerge: AVC & HEVC ES parsers: performance improvements by copying much less memory around.
* mkvmerge: tags: reintroduced a workaround for non-compliant files with tags that do not contain the mandatory `SimpleTag` element. This workaround was removed during code refactoring in release v15.0.0.
* GUI: multiplexer: the "AAC is SBR/HE-AAC/AAC+" checkbox in the "audio properties" section will be disabled if the functionality is not implemented for the selected track's codec & container.
* GUI: multiplexer: the "reduce to core" checkbox in the "audio properties" section will be disabled if the functionality is not implemented for the selected track's codec. See #2134 (https://github.com/mbunkus/mkvtoolnix/issues/2134).

## Bug fixes

* mkvmerge: AAC ADTS parser: fixed interpretation of the `channel_configuration` header element for ADTS files that do not contain a program configuration element: value 7 means 7.1 channels. Fixes #2151 (https://github.com/mbunkus/mkvtoolnix/issues/2151).
* mkvmerge: Matroska identification: the `date_local` and `date_utc` attributes will only be output if the identified Matroska file actually contains the "date" header field.
* mkvmerge: WebVTT: mkvmerge did not recognize timestamp lines if the hours components were absent. Fixes #2139 (https://github.com/mbunkus/mkvtoolnix/issues/2139).
* mkvpropedit, GUI's header editor: the `date` header field won't be added automatically anymore whenever the segment info section is edited and the `date` element is either deleted or not present in the first place. Fixes #2143 (https://github.com/mbunkus/mkvtoolnix/issues/2143).

Have fun :)

[raymondjpg]

Thank you for MKVToolNix. I have used it for many years.

Lately, muxing 25 fps AVC TS files into MKV containers I have observed strange frame rates reported by MediaInfo. Before muxing MediaInfo would be reporting one frame rate of 25 fps (PAL standard) for the TS files as follows:

Frame rate : 25.000 FPS

After muxing with MKVToolNix, MediaInfo reports video frame rates as follows:

Frame rate mode : Variable
Frame rate : 31.021 FPS
Original frame rate : 25.000 FPS

Even if I force 25 fps for the video stream in MKVToolNix I see the same result.

Can anyone explain to me why this is happening, and if there is some solution, can they point me to it?

TIA.

[Midzuki]

Somewhat off-topic but necessary, me thinks.

Internet Explorer 11 says about https://mkvtoolnix.download/windows/pre/ :

This page can’t be displayed

Turn on SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2 in Advanced settings and try connecting to https://mkvtoolnix.download again.

[Mosu]

Yes, I've deactivated inferior and partially-broken protocols such as anything below TLS 1.2. Do as it says and activate TLS 1.2. Or use a different browser.

[Midzuki]

Yes, I've deactivated inferior and partially-broken protocols such as anything below TLS 1.2. Do as it says and activate TLS 1.2. Or use a different browser.

The problem is, my IE11 IS configured to use TLS 1.2.
Also, other browsers, all up-to-date, return similar error messages.
Maybe your site has learned to ignore Windows 7 specifically? :confused:
Yes, I've already met certain sites which stopped working on all the browsers available on my machine. But this is the first time the problem has something to do with the use of the https protocol.

EDIT:

Seamonkey says: "The document contains no data".

Pale Moon says: "An error occurred during a connection to mkvtoolnix.download. Cannot communicate securely with peer: no common encryption algorithm(s). (Error code: ssl_error_no_cypher_overlap)"

K-Meleon says: "Connection Interrupted
The document contains no data.
The network link was interrupted while negotiating a connection. Please try again."

[sneaker_ger]

You can have TLS 1.2 and not brake too many browsers:
https://www.ssllabs.com/ssltest/analyze.html?d=forum.doom9.org
https://www.ssllabs.com/ssltest/analyze.html?d=mkvtoolnix.download&s=144.76.6.86

(Just saying ...)

[nevcairiel]

Thats probably because he also removed any AES 128 encrypted cipher suits (which for the record is not considered insecure)

[manolito]

It seems to follow the old pattern to shut out all users who do not use the latest and greatest (also very crappy) Win10 like it happened for XP users.

Thank God we have Baldrick and his invaluable VideoHelp site... :devil:
https://www.videohelp.com/software/MKVToolNix


Cheers
manolito

[Mosu]

Shutting out Windows 7 wasn't my intention, and judging from SSLLabs' report (which I did actually use) Windows 7 users should still be able to connect. As they aren't, I'll re-add the 128bit variants for AES.

I don't care about XP.

[Taurus]

Win7 64bit, Firefox 64bit latest, Internet Explorer 11 latest = no trouble reaching https://mkvtoolnix.download/windows/pre/
Standard Installations...

[hubblec4]

I use Waterfox with Win7(64) and have no issues.

[Midzuki]

Win7 64bit, Firefox 64bit latest, Internet Explorer 11 latest = no trouble reaching https://mkvtoolnix.download/windows/pre/
Standard Installations...

Perhaps your Windows 7 is full of "updates", whereas mine is not :confused:

No way I'm going to install Firefox or Chrome/Chromium because of a handful of sites — specially when there is no guarantee that these pesky browsers are going to work properly on my machine.

As a last resort, I can use wget 1.19.2.

</END OF COMPLAINT>

[Mosu]

The 128bit variants are now enabled again.

[Midzuki]

^ thanks!

[kuchikirukia]

Appending seems to be broken in the last couple releases. It used to work perfectly but now there's a hitch at every join if audio is present.

[sneaker_ger]

The way mkvmerge appends by default usually results in small timecode gaps. Read doc about append modes. If you are sure it's a regression please find out exact version and post sample.

[hdboy]

Is there a way to make an audio track the primary one without remuxing?

Say I have a m2ts file with

Audio 1: truehd English
Audio 2: ac3 English

I want to make audio 2 the default English track and Audio 1 the secondary, without making any other changes.

Is there a quick way to do this without remuxing? Thanks

[nevcairiel]

You can set the default flag on the second track, if a given player honors that is not something mkvmerge can influence.

[sneaker_ger]

Say I have a m2ts file with
[...]
Is there a quick way to do this without remuxing?
There is a reason it's called MKVToolNix, not M2TSToolNix. The only thing MKVToolNix can do with a m2ts file is to remux it to mkv (you can set default flags, deactivate tracks or change track order for that remux, of course).

[hdboy]

You can set the default flag on the second track, if a given player honors that is not something mkvmerge can influence.

But it still requires going through a remux, correct?

There is a reason it's called MKVToolNix, not M2TSToolNix. The only thing MKVToolNix can do with a m2ts file is to remux it to mkv (you can set default flags, deactivate tracks or change track order for that remux, of course).

Reason I'm asking is I'm trying to use my TV's internal player to play UHD files. It is a very capable player that handles many containers and codecs except it freaks out when there is a main lossless audio track, which there is for most movies. I think if I can edit the header and disable or renumber the lossless audio track that will do the trick. Is there any such tool?

[nevcairiel]

But it still requires going through a remux, correct?

Since its not MKV in the first place, then very much so (I missed that the first time since I didn't expect someone to write anything about other contains in a thread about MKV tools).

[hdboy]

Sorry, a another question. This time, it IS about mkvtoolnix, I hope.

I'm remuxing a UHD m2ts to mkv. I stripped out most audio tracks and subtitles. The file size went from 53GiB to 37GiB, which was surprising since the audio tracks and subs can't take that much space. So I looked at the files' mediainfo. Here's the original (video only)


Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
Codec ID : 36
Duration : 2 h 0 min
Bit rate : 57.9 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.291
Stream size : 48.7 GiB (91%)
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0050 cd/m2, max: 4000.0000 cd/m2
Maximum Content Light Level : 9918 cd/m2
Maximum Frame-Average Light Level : 3241 cd/m2



here's the remuxed



Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2 h 0 min
Bit rate : 44.1 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.222
Stream size : 37.1 GiB (99%)
Language : English
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0050 cd/m2, max: 4000.0000 cd/m2
Maximum Content Light Level : 9918 cd/m2
Maximum Frame-Average Light Level : 3241 cd/m2



The video stream size went from 48GiB to 37GiB. I was under the impression that mkvtoolnix is only copying the stream over. Where does the additional compression come from? Does it affect PQ?

thanks

[Selur]

Where does the additional compression come from?
Transport streams containers can have a lot or overhead, depending on the streams inside of them.

[sneaker_ger]

Is it from a Blu-ray with Dolby Vision?

[hdboy]

Is it from a Blu-ray with Dolby Vision?

No. HDR only. It's mad max fury road

[sneaker_ger]

While m2ts has a lot of overhead it seems a little too high for me. Please post the complete MediaInfo of the source. Maybe MediaInfo is underestimating audio track sizes. Video track size is probably just calculated by [total size] - [audio track sizes] - [overhead estimate] - [subtitles] etc. And/or extract the full audio tracks to get their exact sizes.

[hdboy]

I extracted all the audio and it's 12.3GiB. So it computes. I guess the 2 TrueHD atmos and multiple ac3 tracks do add up.

Mystery solved :)

[Midzuki]

"MKVToolNix moves to GitLab"

https://www.bunkus.org/blog/2017/12/mkvtoolnix-moves-to-gitlab/

[Mosu]

Hey people,

the year's almost over, so I'm just in time for the last release of the year: MKVToolNix v19.0.0 is out. It's not that big of release, but it still contains a couple of improvements all over the place — and two nice performance improvements on Windows that people will likely notice.


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 19.0.0 "Brave Captain" 2017-12-17

## Important notes

* The MKVToolNix project now contains a Code of Conduct (https://mkvtoolnix.download/doc/CODE_OF_CONDUCT.md).
* The MKVToolNix project's source code repository, bug tracker and wiki have been moved to GitLab (https://gitlab.com/mbunkus/mkvtoolnix/).

## New features and enhancements

* mkvmerge: splitting by duration, by timestamps or by timestamp-based parts: mkvmerge will now consider the first key frame within 1ms of the requested value to be eligible for splitting.
* MKVToolNix GUI: the GUI will now save and restore the widths of columns in tree and list views. Implements #2057 (https://github.com/mbunkus/mkvtoolnix/issues/2057).
* MKVToolNix GUI: header editor: when closing or reloading a modified file, the GUI will now focus the first element that's been modified before asking the user for confirmation regarding discarding unsaved changes.

## Bug fixes

* mkvmerge: fixed reading text files encoded in UTF-16 order UTF-32 that have different forms of line endings (new lines, carriage returns or a mix of both). Fixes #2160 (https://github.com/mbunkus/mkvtoolnix/issues/2160).
* mkvmerge: MP4 reader: fixed mkvmerge's interpretation of edit list entries with `segment_duration == 0` when there's more than one edit list entry. In that case mkvmerge was reading the whole content more than once. Fixes #2152 (https://github.com/mbunkus/mkvtoolnix/issues/2152).
* mkvmerge, GUI's multiplexer: MIME types: added the `font` top-level media types from RFC 8081. This means that the following new MIME types for fonts can be used: `font/ttf`, `font/otf`, `font/woff` and `font/woff2`.
* mkvmerge: MPEG transport stream reader: fixed slow speed on Windows due to lack of buffering.
* mkvextract: fixed slow track extraction speed on Windows due to lack of buffering. Fixes #2166 (https://github.com/mbunkus/mkvtoolnix/issues/2166).
* MKVToolNix GUI: multiplexer: changing the "subtitle/chapter character set" drop-down was ignored when the selected track was a chapter track. Fixes #2165 (https://github.com/mbunkus/mkvtoolnix/issues/2165).
* MKVToolNix GUI: multiplexer: once a "subtitle/chapter character set" was set for a track it couldn't be changed back to the empty entry (= auto-detection) anymore.
* MKVToolNix GUI: header editor: fixed re-translating several displayed strings when the GUI language is changed if the language the GUI was started with was not English. Fixes #2159 (https://github.com/mbunkus/mkvtoolnix/issues/2159).
* MKVToolNix GUI: header editor: whenever a file did not contain a "date" element in its segment information section, the GUI would erroneously ask the user to confirm discarding unsaved changes when closing or reloading the tab. Fixes #2167 (https://github.com/mbunkus/mkvtoolnix/issues/2167).
* MKVToolNix GUI: job queue: jobs are now saved when their status changes in addition to when the program exits. Fixes #2168 (https://github.com/mbunkus/mkvtoolnix/issues/2168).

Have fun :)

[sneaker_ger]

Thx.
Are new font MIME types a default in any way or just new, optional settings?

[Midzuki]

Thanks for the update :thanks:

[Mosu]

Due to my experience with players and font Mime types in the past, the new types are not the default and purely optional.

[sneaker_ger]

Good. Thx.

[Telion]

* The MKVToolNix project now contains a Code of Conduct.
I hope this means it's about time to become more inclusive towards Windows XP users community, isn't it? The painful harassment of this minority, the brunt on the problems and needs of those poor third worlders are so against this CoC that it literally moans to check your first world privilege. Recurrent derogatory remarks about Windows XP (i.e. its users) and the enforcement of those absolutely artificial, unnecessary, and discriminative constraints (MF instead of DX in Qt) which actively marginalize and push out of the community not only XP but also N/KN editions users are the exact opposite of creating an inclusive and more diverse environment. We feel humiliated when we encounter your hostile attitude towards us, we feel like we are steadily losing our human dignity in this toxic environment, we feel that we are so inferior and despicable we won't ever worth even a minuscule mercy from a meritocratic patriarch in a position of power. How can we believe in the sincerity of your pledge when you have just installed another suffocating axis of oppression, now based on Windows versions we are using? Only if you would abide by this part: "Project maintainers have the <...> responsibility to <...> edit <...> code <...> that are not aligned to this Code of Conduct", especially considering it's so easy to do so. Please quell the qualms and show us that CoC adoption isn't just for hypocritical virtue signalling, but social justice really matters for you. Actions speak louder than words.

[Mosu]

Not giving you something you very vociferously demand isn't harassment. What you're doing, on the other hand, is pretty much trolling. Please stop it.

[mariush]

There's a tiny bug i noticed a while ago. Well maybe it's not a bug, probably "unexpected behavior" would be better.

If you set a track name with spaces in it (edit: or you have files with spaces in them) and you then select Multiplexer > Show command line, the default escaped output (Windows cmd.exe is selected by default) is correct. But if I go in the drop down menu and select Don't escape, then the cmd escaping AND the " " for the text are removed.
For example, let's say I use "English 5.1" as track name, the default is shown like this:

mkvmerge.exe --ui-language en --output ^"D:\temp\output.mkv^" --language 0:und --language 1:und ^"^(^" ^"D:\temp\video.m2ts^" ^"^)^" --language 0:eng --track-name ^"0:English 5.1^" ^"^(^" ^"D:\temp\sound.opus^" ^"^)^" --track-order 0:0,0:1,1:0

Notice the --track-name ^"0:English 5.1^"

After selecting don't escape, it's converted to this:

mkvmerge.exe --ui-language en --output D:\temp\output.mkv --language 0:und --language 1:und ( D:\temp\video.m2ts ) --language 0:eng --track-name 0:English 5.1 ( D:\temp\sound.opus ) --track-order 0:0,0:1,1:0

so that's not correct because it takes track name as "English" and then it's confused by the standalone 5.1
mkvmerge v19.0.0 ('Brave Captain') 64-bit
Error: The file '5.1' could not be opened for reading: open file error.

(edit) Ah .. now I see the "Don't escape" also removes the "" around filenames if they have spaces in their name.

IMHO, the "don't escape" should not remove " characters which are required for values of parameters to function, for the command to actually work. I just want the ^ and cmd.exe escaping to go away.

In my particular case, I'm just trying from time to time to get the command and then replace filenames with %1, %2 etc and create a batch merge with a PHP script.

[Mosu]

IMHO, the "don't escape" should not remove " characters which are required for values of parameters to function, for the command to actually work. I just want the ^ and cmd.exe escaping to go away.

Uhm, no. Either you escape, or you don't. There is no middle ground, just "wrong/incomplete escaping that'll do the wrong thing in situations you don't expect".

[mariush]

I sort of see what you're saying but at the same time by your logic, since you're escaping the parenthesis in the first example, shouldn't those be missing in the 2nd form as well?

What's the difference between the ( ) characters and the " characters that the () get special treatment while " are silently removed? Your special way of parsing the parameters/arguments in command line seems to make using ( ) characters a requirement so to me it would seem your program should either add some intelligence during parsing to guess where file names end (and what's normally in text fields) , or you should treat " characters like those ( ) characters, as required to read arguments properly.

I think it's not a Windows thing to require " characters, you'd need them in Linux and other operating systems as well, or am I wrong...

[Mosu]

Parenthesis have nothing to do with escaping or the shell or cmd.exe. They're a function of mkvmerge and important to mkvmerge regarding appending files.

[Gser]

WHATTTTT? NO SUPPORT FOR WINDOWS 95? I am totally going to complain about this on my myspace page that has 3 visitors a year.

PS. You can send me your hearts and prays through AOL Instant Messenger, my email is backstreet_boys_superfan_*85*_<333@aol.com

[hello_hello]

I hope this means it's about time to become more inclusive towards Windows XP users community, isn't it?

You can always use another GUI that uses MKVToolNix for muxing, such as MeGUI, and while it's not as feature rich, MeGUI's muxer has one advantage over MKVToolNixGUI. The button to start muxing and the button to stop it are located together at the bottom of the same window. And if a language is written to a raw stream/file as any "Delay" often is, the world mysteriously keeps turning while MeGUI applies it automatically. ;)

I've only just switched to MKVToolNix 19, but so far version 10 of mkvtoolnix-gui.exe is playing nice with version 19 of mkvmerge.exe, so you can use that.

manolito's utility for automatically dismissing the warning could previously be found via this post (https://forum.doom9.org/showthread.php?p=1813131#post1813131) but the link seems to be dead so here's a new one if you want it.

(I've removed the link as I only had the exe's without instructions, plus it turns out I uploaded the first version and the SendTo method of opening files doesn't work. I didn't realise I'd kept it. See the next post for a new link from manolito).

PS. Thanks for the update Mosu.

[manolito]

Thanks hello_hello for uploading my little hack to VideoHelp...

ZippyShare deletes uploads after noone has downloaded them for more than 4 weeks, and this is very much OK with me. I just reuploded the complete hack (which contains instructions and the sources for the executable) here:
https://files.videohelp.com/u/172211/ToolNix_XP.zip

I do check new releases of MKVToolNix to make sure my workaround still works, so far I found no issues...


Cheers
manolito

[ccutrer]

Any more thoughts on Dolby Vision? UHD ripping has really taken off since it was first mentioned in October, and things are starting to get software updates to support Dolby Vision (I just got my AppleTV 4k -> Pioneer VSX-1131 -> LG OLED65C7P chain working today thanks to a Pioneer software update). I know it's a chicken-and-the-egg problem (why add DV to MKV if all current devices will choke on it), but until it's at least added to the spec, no device will ever be able to support it. Infuse on Apple TV 4k seems like a great first player for DV-in-MKV content.

[Mosu]

I currently have no plans for spending time on it. Busy with other things.

[ccutrer]

I currently have no plans for spending time on it. Busy with other things.

Ok. Thanks for the response, and all your hard work on MKVToolnix!

[hubblec4]

Hi Mosu,

I have started in the german forum (https://forum.gleitz.info/showthread.php?47806-Matroska-parsen&p=459923&viewfull=1#post459923) a topic about the Block structure.

Block Structure

Size = 1 + (1-8) + 4 + (4 + (4)) octets. So from 6 to 21 octets.

Could you explain a bit what the numbers mean?

[mkver]

The first 1 is for the 0xA1 denoting a block; 1-8 is not a substraction, but means that the size of the data to follow is coded with a variable length EBML integer. The next four bytes seem to be for the TrackID, the relative timestamp/timecode (soon to be depreceated verbiage) and the byte with the flags. I don't know what the last (4+(4)) means: You can possibly have lacing data next (depending on the flags), but even in this case (4+(4)) doesn't make any sense. Furthermore, the interpretation of the first four depends on the TrackID coded in 1 octet (Matroska allows up to 2^56-1 tracks at the moment and they are coded in EBML integer form like EBML sizes (but with the difference that there is no reserved value (EBML sizes have a reserved value denoting an unknown size; TrackID has not)).
So currently I'd say that this is a bug in the specs. If mose agrees, you should file a bug report on github (https://github.com/Matroska-Org/matroska-specification/issues).

[Mosu]

I'm pretty sure those numbers are completely wrong, both for the Block and the SimpleBlock elements. You've wondered that yourself in that German thread already, and it looks right to me.

For the Block structure, better numbers would be:

1 byte: element ID
1-8 bytes: element size (variable-sized integer)
1-8 bytes: track number (variable-sized integer)
2 bytes: block's timestamp relative to the cluster's timestamp (signed 16-bit integer)
1 byte: flags
1 byte: number of laced frames; only present if lacing is signaled in the flags
n bytes: lacing information; only present if lacing is signaled in the flags; total size depends on lacing method and number/size of laced frames; no upper limit (e.g. the Xiph method is rather wasteful for big frame sizes)
n bytes: content of laced frames

Edit: added missing "number of laced frames".

[Mosu]

The next four bytes seem to be for the TrackID, the relative timestamp/timecode (soon to be depreceated verbiage) and the byte with the flags.

More or less correct, but that is a) wrong if there's a track with a track number >= 128 and b) confusingly written on the web page (not your fault, obviously).

Furthermore, the interpretation of the first four depends on the TrackID coded in 1 octet (Matroska allows up to 2^56-1 tracks at the moment and they are coded in EBML integer form like EBML sizes (but with the difference that there is no reserved value (EBML sizes have a reserved value denoting an unknown size; TrackID has not)).

Nitpick: there's no such thing as the "TrackID" in Matroska, there's only the "TrackUID" and the "TrackNumber". The "TrackNumber" is what's stored in the Block. There's also no guarantee that the "TrackNumber" must always start at 1 and not have any gaps — you could have a file with a single track whose "TrackNumber" is 666, requiring two bytes in the Block/SimpleBlock structures.

"TrackID" (or rather: "track ID") is a concept used by mkvmerge & mkvextract, but there's no corresponding Matroska element.

Yeah, it's confusing, I get that ;)

So currently I'd say that this is a bug in the specs. If mose agrees, you should file a bug report on github (https://github.com/Matroska-Org/matroska-specification/issues).

That would be great as both calculations are still present there (https://github.com/Matroska-Org/matroska-specification/blob/master/index_matroska.md).

[hubblec4]

I'm pretty sure those numbers are completely wrong, both for the Block and the SimpleBlock elements. You've wondered that yourself in that German thread already, and it looks right to me.

For the Block structure, better numbers would be:

1 byte: element ID
1-8 bytes: element size (variable-sized integer)
1-8 bytes: track number (variable-sized integer)
2 bytes: block's timestamp relative to the cluster's timestamp (signed 16-bit integer)
1 byte: flags
1 byte: number of laced frames; only present if lacing is signaled in the flags
n bytes: lacing information; only present if lacing is signaled in the flags; total size depends on lacing method and number/size of laced frames; no upper limit (e.g. the Xiph method is rather wasteful for big frame sizes)
n bytes: content of laced frames

Edit: added missing "number of laced frames".

Many thanks for reading and this wonderful explanation. Now it is clear to me.

Nitpick: there's no such thing as the "TrackID" in Matroska, there's only the "TrackUID" and the "TrackNumber". The "TrackNumber" is what's stored in the Block. There's also no guarantee that the "TrackNumber" must always start at 1 and not have any gaps — you could have a file with a single track whose "TrackNumber" is 666, requiring two bytes in the Block/SimpleBlock structures.

"TrackID" (or rather: "track ID") is a concept used by mkvmerge & mkvextract, but there's no corresponding Matroska element.

Yeah, it's confusing, I get that ;)

Right! But the TrackNumber (like EBML variable-sized integer) can't be zero, because Tracknumbers start at 1, right?



That would be great as both calculations are still present there (https://github.com/Matroska-Org/matroska-specification/blob/master/index_matroska.md).

@mkver
Would you do this? I think your English is better.