View Full Version : MKVToolNix v24.0.0 released
Mosu
23rd April 2016, 16:00
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
24th April 2016, 14:22
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
24th April 2016, 14:41
@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
24th April 2016, 20:34
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
25th April 2016, 00:06
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
25th April 2016, 13:45
It can't cut mkv files. It just demuxes them.
stax76
25th April 2016, 13:55
I wasn't relating to your request. Create a feature request on the StaxRip issue tracker.
Selur
25th April 2016, 16:34
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
26th April 2016, 00:16
@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
26th April 2016, 13:45
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
26th April 2016, 13:51
Mkvmerge will always cut at I frames no matter whether time or frame count based syntax.
stax76
26th April 2016, 14:01
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
29th April 2016, 20:05
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
29th April 2016, 20:41
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
2nd May 2016, 09:34
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
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
2nd May 2016, 13:14
So understand well. The film I connected with five equal parts. Messages mergers NALU are only half the film.
bin_ch
2nd May 2016, 13:29
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.
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".
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
3rd May 2016, 02:08
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
3rd May 2016, 05:20
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
3rd May 2016, 10:15
And mkvmerge splitting isn't safe with OpenGOP.
tp4tissue
3rd May 2016, 18:46
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
3rd May 2016, 19:12
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
3rd May 2016, 21:08
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.
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.
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
4th May 2016, 00:49
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.
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
4th May 2016, 09:43
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
4th May 2016, 13:57
This should be fixed in pre-builds 01201 and higher (https://mkvtoolnix.download/windows/pre/).
Thanks. It works as intended in the pre build.
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.
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
7th May 2016, 00:43
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
7th May 2016, 01:05
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
11th May 2016, 21:48
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
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
11th May 2016, 23:41
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..."
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
12th May 2016, 16:47
"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.
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
12th May 2016, 19:49
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
12th May 2016, 22:18
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
12th May 2016, 22:40
... 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
13th May 2016, 06:32
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
13th May 2016, 06:58
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
13th May 2016, 14:46
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
13th May 2016, 15:54
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
13th May 2016, 22:49
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!
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.