MKVToolNix v24.0.0 released

[nautilus7]

Yes, it should be "Dolby E" (it says so at the bottom of the video stream). What is Dolby E?

[filler56789]

It's something to bring more complication to our lives :)

http://wiki.multimedia.cx/index.php?title=Dolby_E

[nautilus7]

I see thanks.

[Chetwood]

Could a 'check box' be added to more quickly enable/disable these new meta-data lines?
I always add it to the command-line options and save as default for new jobs. Currently I'm using

--engage no_cue_duration --engage no_cue_relative_position --disable-track-statistics-tags

to be on the safe side when it comes to hardware players.

[SeeMoreDigital]

Currently I'm using

--engage no_cue_duration --engage no_cue_relative_position --disable-track-statistics-tags

to be on the safe side when it comes to hardware players.

Good idea, many thanks Chetwood :)

[Mosu]

Dolby E is currently not supported by mkvmerge. At the moment I have no plans for adding support, though I most certainly don't rule it out.

[SeeMoreDigital]

Dolby E is currently not supported by mkvmerge. At the moment I have no plans for adding support, though I most certainly don't rule it out.As far as I'm aware, Dolby E has been designed for commercial distribution purposes. So even if you did include support for it someone would need to design a suitable splitter and decoder for it too... Unless one already exists!

[nautilus7]

ffmpeg/lav doesn't support it?

[Simon88]

Hi Mosu,

I was playing with some ATSC TS files the other day, and after muxing them into a MKV file, the user data area is no longer available for VLC to decode/display the closed captioning. Perhaps it is the job of the media player to detect the closed captioning, I thought. So,I also tried verifying this by mkvextracting the mpg from the mkv file and the file also no longer have the closed captioning information. Has mkvtoolsnix inadvertently stripped the user data away or was it labeled incorrectly during extraction that they no longer are understood by media players which supports closed captioning?

[Mosu]

Closed captions are currently not supported by mkvmerge, and as they're separate streams inside the TS they won't be copied into the Matroska file.

[Korgnex]

Since version 7.0.0 something strange is happening when you mux a file:

When you remove an audio or subtitle track (eg removing any additional audio or subtitle language that you don't want to keep), after the file has been (re-)muxed successfully and you put it again into mkvmerge GUI to take a look at it, it will show ADDITIONAL tag tracks for EVERY remaining track - which you can't get rid of (because if you mux it again, they will just pop up AGAIN).

Eg if your file now consists of 1 video and 1 audio track, the mkvmerge GUI will show TWO additional tag tracks:
tags for track-ID 01
tags for track-ID 02

BUT there are no actual tags anywhere in the video or audio tracks, so why are these showing up since version 7.0.0??

[Mosu]

Pro tip: always read the ChangeLog (https://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog). Additionally it's helpful to read some of the recent posts (http://forum.doom9.org/showthread.php?p=1685722#post1685722) in this very thread.

If those don't answer your question then I also recommend reading the fine FAQ entry I've written about this very topic (https://trac.bunkus.org/wiki/FAQ%3AAutomaticTagGeneration). If all else fails you could still search for it (http://bit.ly/1raAXay).

Of course you're also free to register in this forum and ask this question without doing any of the above. Don't be surprised if the answers might be somewhat snarky, though.

[sneaker_ger]

mkvmerge 7.0.0 writes some tags even for webm output:
DURATION : 00:01:00.080000000
NUMBER_OF_FRAMES : 3004
NUMBER_OF_BYTES : 698325
_STATISTICS_WRITING_APP : mkvmerge v7.0.0 ('Where We Going') 32bit built on Jun 9 2014 15:08:34
_STATISTICS_WRITING_DATE_UTC : 2014-07-10 14:27:08
_STATISTICS_TAGS : BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES

I cannot play those files in Chrome (or Chromium based Opera) and suspect this might be the cause.
From mkvmerge doc:
-w, --webm
Create a WebM compliant file. This is also turned on if the output file name's extension is "webm". This mode enforces several restrictions. The only allowed codecs are VP8 video and Vorbis audio tracks. Neither chapters nor tags are allowed. The DocType header item is changed to "webm".
(Doc should also be updated for VP9 and Opus?)

[Mosu]

Meh, that is indeed a bug. Thanks for reporting it; I will fix it for the next release.

[sneaker_ger]

After checking out 6.9.1 again: It's not the cause of Chrome's/Opera's failure to open such files. Any ideas?

About the tags:
It seems people are getting confused as these tags appear like tracks in mmg. UI clearness suffers as I see it. Instead of people turning them off (and losing debug info in turn) maybe mmg should simply not list them by default?

[Mosu]

I have to admit that I haven't thought of how mmg presents those tags. I will have to think about how to handle this. I will probably change mkvmerge to not list statistics tags as being track tags at all.

[sneaker_ger]

I only looked at the mkvmerge doc at first but looking at the WebM page tagging seems to be supported now after all. I'm not sure if only "official" WebM tags or all tags. The specs are kinda vague. Enabling them in their current form (with TrackUID != 0) would at least be against their recommendation, though, so turning them off looks like a good decision for the time being.

http://www.webmproject.org/docs/container/#tagging
http://wiki.webmproject.org/webm-metadata/global-metadata#TOC-Official-Tags

[vid.user]

I noticed a slight language parsing output anomaly I hope you can take a look at. Using mkvmerge GUI v7.0.0 (x64) on Windows 8.1 (x64), if I leave (or set) any of the track (video|audio|subtitle) languages to English (eng) then that language information is not displayed within the output of MKVINFO. If I set it to any other language then yes, I get the language when displaying the file information using MKVINFO.

I looked at the 'Muxing|Show the command line' option which seemed to be correct, displaying:
"--language" "1:eng" if I set to English or
"--language" "1:rus" if I set to Russian.

MKVINFO output would show:
| + Language: rus
but would never display:
| + Language: eng

Thanks for your time.

[bobp]

I noticed a slight language parsing output anomaly I hope you can take a look at. Using mkvmerge GUI v7.0.0 (x64) on Windows 8.1 (x64), if I leave (or set) any of the track (video|audio|subtitle) languages to English (eng) then that language information is not displayed within the output of MKVINFO. If I set it to any other language then yes, I get the language when displaying the file information using MKVINFO.

I looked at the 'Muxing|Show the command line' option which seemed to be correct, displaying:
"--language" "1:eng" if I set to English or
"--language" "1:rus" if I set to Russian.

MKVINFO output would show:
| + Language: rus
but would never display:
| + Language: eng

Thanks for your time.

I believe the answer is available here: https://trac.bunkus.org/wiki/FAQ%3AElementsNotShowingUpInOutputFile

Basically since 'eng' is the default track language, mkvmerge won't write it to the file.

[vid.user]

@bobp:
Interesting.... and a big thanks.

[Mosu]

Hey,

I've released mkvtoolnix v7.1.0. It fixes a few minor issues. Probably the most important fix is that the new statistics tags introduced with v7.0.0 aren't written to WebM files anymore as the WebM specs currently don't allow tags.

For packagers: nothing has changed since v7.0.0.

Here are the usual links...

...to the home page:
http://www.bunkus.org/videotools/mkvtoolnix/

...to the source code:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-7.1.0.tar.bz2

...to the Windows installer and 7zip archive:
http://www.fosshub.com/MKVToolNix.html

All of the Linux binaries that I provide have already been built and
are available.

Here's the full ChangeLog since release 7.0.0:

2014-07-27 Moritz Bunkus <moritz@bunkus.org>
* Released v7.1.0.
* all: bug fix: Fixed file seeking code for »seek relative to end of file« case. Fixes #1035 (https://www.bunkus.org/trac/ticket/1035).
* mmg: bug fix: Selecting the root of the chapter editor tree will disable the language/country inputs properly as changing those fields doesn't make sense for the root.

2014-07-26 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: if MKVToolNix on Windows is residing in a directory containing non-ASCII characters then translations weren't found. This has only been fixed for cases where those non-ASCII characters are part of the system's active code page.

2014-07-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: track statistics tags are not written for WebM files anymore as the WebM specification doesn't allow tags.

2014-07-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed wrong default duration for PCM audio tracks if the source file provides timecodes for that track. Fixes #1001 (https://www.bunkus.org/trac/ticket/1001) and #1033 (https://www.bunkus.org/trac/ticket/1033).

2014-06-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: SSA/ASS: in addition to semicolons comments can now start with exclamation marks, too.

2014-06-11 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: Fixed a crash when opening damaged/invalid Matroska files in all extraction modes. Fixes #1027 (https://www.bunkus.org/trac/ticket/1027).

Have fun.

[filler56789]

Thanks a lot :thanks:

[Gravitator]

Привет!
Why mkvmerge does not accept prores.mov files?
> sample (http://files.videohelp.com/u/227452/prores%20(sample).mov)

[SeeMoreDigital]

Привет!
Why mkvmerge does not accept prores.mov files?
> sample (http://files.videohelp.com/u/227452/prores%20(sample).mov)
Yes... I've been meaning to mention this too...

As a work-around I've been re-muxing ProRes.mov to ProRes.avi (using MPEG StreamClip 1.2). Then ProRes.avi to ProRes.mkv using MKVmerge GUI.

[Simon88]

Привет!
Why mkvmerge does not accept prores.mov files?
> sample (http://files.videohelp.com/u/227452/prores%20(sample).mov)
Proprietary & lossy for post-production use:
http://en.wikipedia.org/wiki/Apple_ProRes

[Simon88]

I was looking at some files w/ MediaInfo and what happens bitstream AR is removed, etc...

I was wondering if there is a corresponding command-line option for "--engage remove_bitstream_ar_info"

for example.. "--engage insert_bitstream_ar_info"

[sneaker_ger]

H.264 bitstream AR is not removed by default so there is no need for such an option. Maybe you're misinterpreting MedieInfo's output. Or are you looking for a feature to actually write/change the H.264 stream to match the AR option chosen in mkvmerge? That does not exist indeed.

[Simon88]

H.264 bitstream AR is not removed by default so there is no need for such an option. Maybe you're misinterpreting MedieInfo's output. Or are you looking for a feature to actually write/change the H.264 stream to match the AR option chosen in mkvmerge? That does not exist indeed.

When I did the "--engage remove_bitstream_ar_info", it causes the Original AR to be calculated from "square" pixels. eg. 352x288p = ~1.222:1 rather than the original intended non-square AR of 4:3 or even the really stretched pixel AR of 16:9. These probably should've been encoded to 640x360p

These were definitely "improper" encodes, but I just wished I could re-insert the proper AR into BOTH the bitstream & the mkv container on many of my older encodes w/o the need for re-encoding. Apps that use such info wouldn't be confused.

A command that can mirror the mkv container AR into the bitstream AR would fix this issue which I sometimes run into.

[Boulder]

I'm not sure if I follow what you are looking for, but I've sometimes had to use H.264 Aspect Ratio Modifier to correct some streams if I've made a mistake while encoding.

[Simon88]

I'm not sure if I follow what you are looking for, but I've sometimes had to use H.264 Aspect Ratio Modifier to correct some streams if I've made a mistake while encoding.

Thanks for the info Boulder... I did a search and it appears to work with AVI files mostly... but the other day I did some tests using Ffmpeg and it appears to offer this capability... Having it within MKVTools's "Add command line options" would make it a whole lot easier and I could just set it in my batch file and forget about it, without the need to peek into the file first when re-muxing. I still MUCH prefer the MKVTools MKV creater to that of FFmpeg's.

[Boulder]

It needs an elementary h.264 stream so if you happen to use it, you need to extract that from the container.

You could create a batch file to mux with ffmpeg and remux with mkvmerge if you like ;)

[Simon88]

It needs an elementary h.264 stream so if you happen to use it, you need to extract that from the container.

You could create a batch file to mux with ffmpeg and remux with mkvmerge if you like ;)

Yeah, that was my thinking as well... I just didn't want to double the time and double the wear & tear on my HDD if a single command in MKVTools can re-write the AR for BOTH bitstream & container at the same time while muxing, whether needed or not, without the need for Ffmpeg :(...

[AYColumbia]

Yes... I've been meaning to mention this too...

As a work-around I've been re-muxing ProRes.mov to ProRes.avi (using MPEG StreamClip 1.2). Then ProRes.avi to ProRes.mkv using MKVmerge GUI.
Another option; my camera creates MOV files and I use tsmuxer to demux and then remux to MKV. But yeah, it would be sweet if mkvmerge supported the MOV container. So +1 for that feature. :)

[Mosu]

MOV in general is supported, though not all of the codecs that can be stored in there. I have no plans for adding ProRes support at the moment.

[SeeMoreDigital]

Another option; my camera creates MOV files and I use tsmuxer to demux and then remux to MKV. As far as I'm aware... TSmuxer is capable of accepting MPEG-1, MPEG-2 and MPEG-4 Part-10 video placed within the .MOV container, but not ProRes video placed within the .MOV container.

[AYColumbia]

As far as I'm aware... TSmuxer is capable of accepting MPEG-1, MPEG-2 and MPEG-4 Part-10 video placed within the .MOV container, but not ProRes video placed within the .MOV container.
Yeah, that was my bad as I glazed over ProRes. Sorry about that.

[hello_hello]

I believe the answer is available here: https://trac.bunkus.org/wiki/FAQ%3AElementsNotShowingUpInOutputFile

Basically since 'eng' is the default track language, mkvmerge won't write it to the file.

I'd kind of forgotten about that myself, but.....

If you set the language for a track to "English" when muxing, and MKVMerge doesn't write the language element, how does MediaInfo distinguish between a track which was muxed using "English" and a track which was muxed with the language element as "undefined"? Or is MKVMerge removing an existing "undefined" language element when you set the language to "English"?

[sneaker_ger]

Or is MKVMerge removing an existing "undefined" language element when you set the language to "English"?
Yes.
Basically you can have the following possibilies:
no language element -> means "English"
"eng" language element -> means "English"
"und" language element -> means "undefined"

[cyberbeing]

Mosu, is there a reason why mkvtoolnix must refuse to accept and process sources missing a TrackUID? Having a warning is fine, but this seems like one of those things which would be trivial to just ignore by default, assign a temporary TrackUID when parsing/demuxing, and just repair automatically when muxing. The current workaround is just to manually add a TrackUI with mkvpropedit/header-editor, but that seems like an unnecessary extra step.

The muxer in question which generates these single-track Video-only files missing a TrackUID, is that Whammy Javascript-based WebM encoder. A quick google search seems to suggest this issue has existed for a couple years now, and was never fixed upstream. Not a big issue to me personally, but still a bit of an annoyance from an end-user perspective when I run across websites or userscripts making use of this Whammy muxer.

[Mosu]

I think the reason is simply that I haven't run across such a file before. Back in the days of implementing Matroska for the first time I was using the track number element for track selection in the command line options (you know, the »123« in »--language 123:eng«). However, it turned out that too many programs were writing broken files and were assigned track numbers multiple times within the same file, hence making them impossible to use for track identification.

Can you please open a ticket in my bug tracker (https://trac.bunkus.org)? This is definitely something I will want to fix, but I will be going on vacation soon and might forget about it otherwise.

[cyberbeing]

Can you please open a ticket in my bug tracker (https://trac.bunkus.org)? This is definitely something I will want to fix, but I will be going on vacation soon and might forget about it otherwise.
You seem to have a permission problem with newly created Trac accounts which prevents creation of tickets. Upon registering and verifying email for a new account, there is no visible link for ticket creation, and going directly to https://trac.bunkus.org/newticket result in a forbidden error while logged in: TICKET_CREATE privileges are required to perform this operation. You don't have the required permissions.

[hello_hello]

Yes.
Basically you can have the following possibilies:
no language element -> means "English"
"eng" language element -> means "English"
"und" language element -> means "undefined"

If you add a single elementary stream to MKVMergeGUI (raw avc for example) and simply mux it, there's nothing I can see in respect to the language in the command line ("Muxing/Show the commandline" menu), but if you click on the drop down list and select "undefined", which is the default anyway, the following is added:
"--language" "0:und"
With or without it though, an undefined language element is written.

Does the above mean MKVMergeGUI doesn't follow the Matroska specification exactly? Logically, if I open an MKV containing a bunch of tracks without a language element, MKVMergeGUI should default to displaying English for each. The Header Editor does just that, but MKVMergeGUI defaults to "undetermined" and forces you to manually specify English. Maybe if it didn't, it appear to be defaulting to English so it's a kind of workaround for the Matroska spec. For people who'd generally use another language I could see that being inconvenient, so instead MKVMergeGUI defaults to "undetermined", making it equally inconvenient for everyone. ;)

I still think letting the user select a language for MKVMergeGUI to default to if there's no language element present would be a better idea, and/or maybe a default language for when the element is "undetermined", although I know Mosu disagrees.

[Mosu]

You seem to have a permission problem with newly created Trac accounts which prevents creation of tickets. Upon registering and verifying email for a new account, there is no visible link for ticket creation, and going directly to https://trac.bunkus.org/newticket result in a forbidden error while logged in: TICKET_CREATE privileges are required to perform this operation. You don't have the required permissions.

Yeah, I'm having intermittent problems with spammers. I therefore turn on the need for manual administrator approval of each newly registered account. Unfortunately I had forgotten I did that and in turn didn't authorize accounts… I've approved your account just now and turned manual authorization off for the time being.

[Mosu]

If you add a single elementary stream to MKVMergeGUI (raw avc for example) and simply mux it, there's nothing I can see in respect to the language in the command line ("Muxing/Show the commandline" menu), but if you click on the drop down list and select "undefined", which is the default anyway, the following is added:
"--language" "0:und"
With or without it though, an undefined language element is written.

Not exactly true. If you don't specify a language then mkvmerge will try to keep the source's language intact if there is one (e.g. if you read the track from another Matroska file or from a VobSub file).

If the source doesn't provide a language then mkvmerge defaults to »undefined«.

Does the above mean MKVMergeGUI doesn't follow the Matroska specification exactly? Logically, if I open an MKV containing a bunch of tracks without a language element, MKVMergeGUI should default to displaying English for each. The Header Editor does just that, but MKVMergeGUI defaults to "undetermined" and forces you to manually specify English.

This is not true. If a source Matroska file doesn't contain a »language« element then both mkvmerge and mmg assume it is set to »English«. You can try to re-create this easily:

Create a Matroska file with a single track from something and set the language manually to »English«
Restart mmg
Add the file you've just created and observe how mmg sets the language selection for that track

In step 1 you've created a Matroska file whose single track doesn't contain a language element. But mmg will still set that track to »English« when you add the file because that's what the track's language is logically set to according to the specs.

However, if the source file does not provide a language (e.g. if you add an SRT or AC3 file) then mmg defaults to »undefined«. This has nothing to do with the Matroska specs as the specs do NOT say that all tracks must default to »English«! They only say that the language element defaults to »English« if it is missing from the file. That's all.

[hello_hello]

If the source doesn't provide a language then mkvmerge defaults to »undefined«.

That's what I said, I think. :)

This is not true. If a source Matroska file doesn't contain a »language« element then both mkvmerge and mmg assume it is set to »English«. You can try to re-create this easily:

You're correct and I was 100%, totally and completely wrong. I don't know what I was thinking......
Maybe I opened the wrong MKV with MKVMergeGUI and it was the one containing the undefined elements instead of no elements at all. Sorry.

[Thunderbolt8]

I want to transfer jobs I created for the job queue with mkvmerge from one computer to another. how can I do that?

I tried copying the .mmg files from the user/appdata/roaming/mkvtoolnix folder from the first PC into the same folder on the 2nd. But those files werent added to the manage jobs window in mkvmerge on the other PC.

[Mosu]

mmg also stores information about the jobs in the registry (for the installed version; for portable it's in the .ini file). It's the »jobs« sub-tree of HKCU\Software\mkvmergeGUI. That sub-tree (respectively all the sections from the .ini whose names start with »jobs« for the portable version) has to be copied as well.

[rhaz]

Hi. How do I limit mmg.exe mux speed, it is killing my 5400RPM HDD. Impossible to use computer while muxing 10GB files. Cheers.

[Simon88]

Hi. How do I limit mmg.exe mux speed, it is killing my 5400RPM HDD. Impossible to use computer while muxing 10GB files. Cheers.

Some Win apps such as archivers & gui-encoders, when minimized will lower priority into a low priority background app. or use fewer cpu cores. For mmg.exe, you'll have to set the priority in the OS task manager.

Also many motherboard chipsets are crippled in a way that consumes the cpu 90%+ when HDD is busy. Only way around it is buying a high performance RAID HDD controller which has its own memory and controller chips that offloads most tasks away from the cpu.

[cyberbeing]

For mmg.exe, you'll have to set the priority in the OS task manager.

mmg.exe actually has a 'Process priority' setting for mkvmerge under File>Options>mkvmerge for controlling this. According to the tool-tip if you set that option to 'Lowest', mmg to also set low I/O priority, which is what rhaz likely requires to reduce HDD impact.