View Full Version : MKVToolNix v99.0 released
manolito
16th December 2018, 11:51
I simply don't support such low resolutions.
I hope you don't mind if I call this attitiude "ARROGANT". Not everyone is in the situation to be able to afford a state of the art computer, graphics card and monitor like you.
kuchikirukia
16th December 2018, 13:01
Thanks for the suggestions. I won't implement any of them as they aren't going in a direction I want to take the GUI in. I simply don't support such low resolutions.
Resolution doesn't really do anything since nearly everybody scales their UI up to make it visible. My phone is 1080p and its screen is completely full from top to bottom with 20 icons. My desktop, on the other hand, can fit 50 icons on the taskbar and still have 1920x1050 area left over. It's screen size that gives real estate and most people aren't running something like this:
https://i.postimg.cc/13HydrnD/mjcqjfZ.jpg
The GUI would fit nicely in around 5% of that screen. But for the majority of us it takes up a third of our screens.
Perenista
16th December 2018, 17:09
What is going on?
First this https://forum.doom9.org/showpost.php?p=1860220&postcount=370
Now this, with the MKVExtractGUI2.exe:
https://i.imgur.com/YuIzBkB.png
Mosu
16th December 2018, 17:23
MKVExtractGUI2.exe is not part of MKVToolNix. It's a third-party application.
Mosu
16th December 2018, 19:08
I hope you don't mind if I call this attitiude "ARROGANT".
I very much mind. It isn't arrogant, it is necessary and normal. Every software developer out there places certain restrictions on what they support in their software, be it operating systems & their versions, the hardware (virtual or physical) its run on, or even the time of day it is run. It's simple logistics: every development team out there has a limited set of resources, both regarding money (in order to buy all the different equipment they have to support) and time (implementing stuff & hunting bugs takes a lot of time). Both of those resources are finite; hence decisions are made with respect to what a useful subset of all the requirements are that they can support with their current level of resources so that the most number of people benefit from it. It's always a trade-off.
MKVToolNix is basically a one-person project regarding coding — me. My time is very finite, and I have to chose carefully where to spend my time. And I've been spending my time on this fine piece of software that I offer you completely free of charge, free of any type of commitment, and I've been doing that for more than 15 years now. I've been gifting you countless hours of my time, no small amount of my wit, and you even get the whole source code to do with as you please.
And still you have the gall to call me arrogant when I decline to spend more of my free time on this piece of software, for which I'm not compensated, which I couldn't make a living off even if I wanted to, which solely benefits persons other than myself? Really? Statements such as yours are _the_ reason I and other open source software developers & maintainers often burn out.
All of this over an enhancement request? Really? It wasn't that the software didn't work form them; no, they simply didn't want to spend heir time scrolling in order to push buttons. But you expect me to spend my time improving your life. Don't get me wrong, it's 100% fine to ask about such a feature. That isn't arrogant. But not accepting me declining to do something for you for free? That is.
Apart from all of that: I wasn't kidding when I said that the suggestions lead in a direction I didn't want to take the GUI in. For example, I don't like using abbreviations all over the place. Abbreviations that may be obvious to you often aren't to other users. Placing buttons in the task bar is something I honestly haven't ever seen any program do — as a first-time user I would be very confused about them; even more so as those buttons only apply to the multiplexer tool whereas the whole status bar applies to all tools.
I simply don't consider those suggestions to be good, I don't consider them to be significantly helpful to a significant number of people, and I consider them to be detrimental or confusing to others. Not a good combination.
LeMoi
16th December 2018, 19:19
Thanks for the suggestions. I won't implement any of them as they aren't going in a direction I want to take the GUI in. I simply don't support such low resolutions.
Thanks :)
lvqcl
16th December 2018, 20:52
This reminds me of some discussions such as this (https://www.phoronix.com/forums/forum/software/distributions/974049-manjaro-linux-to-drop-32-bit-support) and this (https://www.reddit.com/r/linux/comments/4omfud/why_are_distros_starting_to_drop_x86_support/).
To quote a reddit user frome that thread:
Wow reading the comments there are a lot of people who feel entitled to someone else's time and work.
@Mosu: just disregard them.
Placing buttons in the task bar is something I honestly haven't ever seen any program do — as a first-time user I would be very confused about them; even more so as those buttons only apply to the multiplexer tool whereas the whole status bar applies to all tools.
+1.
manolito
16th December 2018, 21:05
I very much mind. It isn't arrogant, it is necessary and normal.
Sorry, I did not intend to insult you. All your points about providing free software are valid, and I am very grateful for software like MKVToolNix. And of course it is your baby, you are free to take it into any direction you want.
To make my view clear, I am a strong believer in sustainabilty, I believe that repairing hardware is better than throwing it into the trash bin. I believe that noone needs a new smartphone every year, and the same is true for computers and TVs and cars and whatever...
So remarks like "I simply will not support such low resolutions" or "I will not support such ancient OS like Win XP" do offend me. Apple was the company who introduced this attitude a long time ago, and this is the reason why I do not own any Apple products. Will your next move be to drop 32-bit support?
The problem with MKVToolNix is that over the years it has become a de-facto standard for dealing with MKV files. A lot of other software relies on it, and this "monopoly" is well earned (some MKV related things can be done with FFmpeg, but it is no match to MKVToolNix). But I believe that such a monopoly brings some obligations, even for free software.
So I do thank you very much for providing such a great tool like MKVToolNix, but I still wish that you would consider supporting users with older hardware or Operating Systems.
Cheers
manolito
kuchikirukia
16th December 2018, 21:12
Could we get an options page for changing keybinds? Resizing hiding the buttons wouldn't matter if I could just bind "mux" to mouse3 instead of CTRL-R.
Mosu
16th December 2018, 21:14
Could we get an options page for changing keybinds? Resizing hiding the buttons wouldn't matter if I could just bind "mux" to mouse3 instead of CTRL-R.
I have no intentions of implementing configurable key bindings. I would accept patches that implement this (= I'm not against such functionality, I just won't spend time on it myself).
Dulus_No
17th December 2018, 03:52
Something's wrong with kerning on v29.0.0: http://www.framecompare.com/image-compare/screenshotcomparison/W67WNNNX
OS is Windows 8 x64, font is Segoe UI.
System information: https://pastebin.com/h4e0RECr
mkver
17th December 2018, 05:12
Same here on Win 7 x64. I only noticed it after reading your post. Using the continuous builds (https://mkvtoolnix.download/windows/continuous/64-bit/28.2.0) it seems that the commits from November 4th are to be blamed (or maybe it is an update to the other components that happened at the same time): g4fc889a6f (https://mkvtoolnix.download/windows/continuous/64-bit/28.2.0/mkvtoolnix-64-bit-28.2.0-revision-009-g4fc889a6f.7z) works well, ge8342d4d9 (https://mkvtoolnix.download/windows/continuous/64-bit/28.2.0/mkvtoolnix-64-bit-28.2.0-revision-020-ge8342d4d9.7z) does not. Disabling High DPI scaling seems to not affect this.
Mosu
17th December 2018, 09:53
I regularly update all the libraries I use for building MKVToolNix at the start of the month. The result is probably due to a newer version of one of the libraries involved in font rendering (Qt, freetype, pango, harfbuzz…). It's something you'll have to live with for the time being.
Edit: MKVToolNix doesn't mess with font settings apart from the most basic information. All it does is set the font's family name and its point size. The rest is up to the aforementioned libraries.
varekai
17th December 2018, 09:57
@kuchikirukia
It's screen size that gives real estate and most people aren't running something like this:
That picture is so cool, it's a keeper! Thansk! :D
nautilus7
18th December 2018, 02:17
Kerning with windows 10 is ok.
Anakunda
18th December 2018, 12:27
The --no-chapters option is actually an input file option, not an output file option, i.e. it discards chapters already in your input file, but leaves chapters that you explicitly add during the muxing process (e.g. by using a chapters file) alone. In this case this means that any chapters in your w64 file (there aren't any and I don't believe that w64 is able to contain chapters anyway) would be discarded.
I'll open an issue for the real problem (that PCM is not split sample-accurately, but only block-accurately), but I don't think that he will fix this. After all, this just affects PCM.
I'm only curious if the issue was already fixed in latest version. No mention in change logs. Are the dev at least aware of the oddness?
Mosu
18th December 2018, 12:56
I am aware of it, but I'm not willing to spend time on it.
hello_hello
18th December 2018, 18:33
I have some UI suggestions that might improve the usability of the GUI.
The SendTo folder should be your best friend. If you use a program regularly, there should be a shortcut for it in the SendTo folder (especially if there's no other Explorer menus). Mostly, have have to create them yourself though. I'm on XP, but my SendTo folder is almost a mini start menu (it contains sub-folders for less up/down scrolling, so many of the shortcuts can't be seen in the screenshot below).
https://i.postimg.cc/jSnhsTPT/XP-Send-To.gif
And.... there's much better file management programs than Explorer, and some are free. The "Lite" version is free.:)
https://www.zabkat.com/alldown.htm
Selur
21st December 2018, 05:43
Hi!
Got a file created with VideoReDo which contains S_DVBSUB subtitles.
Trying to extract the subtitles using:
"I:\Hybrid\64bit\mkvextract.exe" tracks "C:\Users\Selur\Desktop\Beispiel_DVB_SUBS.mkv" 3:"E:\Output\Beispiel_id_3_lang_de"
I get:
Error: Extraction of track ID 3 with the CodecID 'S_DVBSUB' is not supported.
Is there a trick to extractin/handling those subtitles? Or is this a missing feature? (only saw support for S_DVBSUB in mkvmerge mentioned in the changelog)
Cu Selur
mkver
21st December 2018, 07:04
There is no defined "raw" format for DVB subtitles; only the packetization inside transport streams (as PES packets) and inside Matroska is defined. Therefore you can't really extract these subtitles, because there is no format to extract them to. (One could of course create such a format. One could e.g. declare the stream of PES packets to be the raw format, similar to vobsubs. But the difference to vobsubs is that the latter is an established format, whereas the former would be a new creation by MKVToolNix. And why create such a format? It makes no sense. If you want to keep only the DVB subtitles inside a Matroska file, simply remux the file with only the DVB subtitles selected.)
Selur
21st December 2018, 15:49
Didn't know there is no defined raw format for those subtitles.
-> I will convert them to dvd subs (idx/sub). Thanks!
kuchikirukia
25th December 2018, 16:36
I've been running into an issue:
If you split a mkv at say 1:00, but there's an .ASS subtitle line running from 0:59 to 1:10, MKVToolNix will keep the entire length of the subtitle line, which makes the length of the first part 1:10 even though your audio and video were cut at 1:00. If you try to append the split segments together again the video will not append seamlessly. There'll be a gap and the time on players will jump ahead when they hit the gap.
Is there a way to hard cut the subtitle line at 1:00 or just ignore it so this doesn't happen?
sneaker_ger
25th December 2018, 17:00
No. Only way is to disable subtitles (and cut them externally with a different tool).
JackBauer
27th December 2018, 22:29
I just discovered this tool and I'm in love :)
Unfortunately though I can't figure out how to make the tool, by default, not select non-english audio and subs for when I multiplex.
Under Preferences: Multiplexer: Encoding items, I've selected the "only enable copying of tracks..." but when I load a mkv, all the other languages are still checked in the "copy item" column.
So I'm guessing I'm misunderstanding that configuration setting.
Some mkv's have a ton of subtitles, so I'm just trying to make it easier to strip some of them out rather than clicking on 20 lines. I figure there has to be a way, I'm just not getting it?
TIA :)
Mosu
27th December 2018, 22:42
In the preferences, select the "Multiplexer" → "Enabling items" pane. There:
Under "Enable copying of items by their type", make sure "audio", "video" and "subtitles" are actually selected (as this setting takes precedence over the language-specific setting insofar as deselecting e.g. "audio" here means audio tracks will never by selected, no matter their language and the enable-by-language settings).
Under "Enable copying of items by their language":
enable "only enable copying…"
for "always enable copying…" select "video" but neither "audio" nor "subtitles" and
select "English (eng)" in the language list.
JackBauer
27th December 2018, 23:15
In the preferences...
That did it.... Thank you very much!
Mosu
27th December 2018, 23:29
You're quite welcome.
algorithm_colon
30th December 2018, 13:03
There's been some noise recently about this (https://github.com/DolbyLaboratories/dlb_mp4base) tool from Dolby which can create Dolby Vision mp4 files. I was able to create a profile 7 file from a UHD disc backup which played succesfully with DV on an LG TV.
I was wondering if there's anything in the code that might provide some clues for getting Dolby Vision into mkv - after remuxing the mp4 with mkvtoolnix all of the dolby vision information is lost.
SeeMoreDigital
30th December 2018, 13:20
... I was able to create a profile 7 file from a UHD disc backup which played succesfully with DV on an LG TV.
..Are you able to upload a sample .mp4?
algorithm_colon
30th December 2018, 14:24
Here's (https://1drv.ms/u/s!Ag6hm31FMiVwjr8xOGQOZZARcUphkA) a 1 minute sample
SeeMoreDigital
30th December 2018, 17:15
Here's (https://1drv.ms/u/s!Ag6hm31FMiVwjr8xOGQOZZARcUphkA) a 1 minute sampleNice one,
I can confirm that your Dolby Vision .mp4 contained sample does indeed work with my LG television and my OPPO UDP-203 :)
MediaInfo detects the dedicated 'DVHE' meta-data as a separate video stream, which MKVmerge currently doesn't know what to do with. But this is a good start.
Perhaps you should also make jdobbs, the author of BD Rebuilder aware of information as he's intending to create an .m2ts muxer. Here's a link to his most recent post in his 'BD Rebuilder Beta' topic: https://forum.doom9.org/showthread.php?p=1861438#post1861438
UPDATE: I've just managed to add an LC-AAC audio track to your .mp4 sample using 'My MP4Box GUI' (with a new build of MP4Box)...
Cheers
gonca
30th December 2018, 23:05
Here is a link to a small discussion on this
https://www.makemkv.com/forum/viewtopic.php?f=12&t=18602
J-Wo
31st December 2018, 17:55
Running v29 x64 on an i5-8400 with 16Gb ram and Windows 10 Pro. When multiplexing a 30Gb 4K movie, I noticed in the task manager that my memory seems to max out at 50% (e.g. 8Gb/16Gb). Just wondering if this is the expected behavior and/or limitation of MKVMerge?
Thanks!
mkver
1st January 2019, 10:58
Normally, mkvmerge takes way less memory; there are basically two possibilities why this could happen:
a) Your file might contain only few frames that are detected as keyframes by mkvmerge so that mkvmerge has to buffer a lot of material before it can write it again. If so, then your source material might simply not contain a lot of keyframes; or they aren't detected by mkvmerge. The latter case would be a bug.
b) There is a memory leak going on. This would also be a bug.
If you want to help, you should upload the source file (not the remuxed file) to the server described here (https://gitlab.com/mbunkus/mkvtoolnix/wikis/FTP-server) and open an issue here (https://gitlab.com/mbunkus/mkvtoolnix/issues).
algorithm_colon
2nd January 2019, 08:18
Nice one,
I can confirm that your Dolby Vision .mp4 contained sample does indeed work with my LG television and my OPPO UDP-203 :)
MediaInfo detects the dedicated 'DVHE' meta-data as a separate video stream, which MKVmerge currently doesn't know what to do with. But this is a good start.
Perhaps you should also make jdobbs, the author of BD Rebuilder aware of information as he's intending to create an .m2ts muxer. Here's a link to his most recent post in his 'BD Rebuilder Beta' topic: https://forum.doom9.org/showthread.php?p=1861438#post1861438
UPDATE: I've just managed to add an LC-AAC audio track to your .mp4 sample using 'My MP4Box GUI' (with a new build of MP4Box)...
Cheers
The dolby tool can do audio as well, but of course mp4 won't hold truehd, hence my interest to see if this could work with mkv
Wakaku
3rd January 2019, 14:50
Happy New Year everyone, and thank you for such a superb Matroska software, MKVToolNix. I just want to ask if there's a way, without loading any file, to immediately start MKVToolNix GUI to a desired main tab instead of the default Multiplexer tab. Like if I want it to start at Header Editor tab immediately. Perhaps a command line option which could be put into a shortcut or batch file. For example if I could create different shortcuts (or shorcuts to batch files) yet pointing to the same mkvtoolnix-gui.exe.
Mosu
3rd January 2019, 15:17
Not without opening a file in the wanted too, no. The existing options can be found here (https://mkvtoolnix.download/doc/mkvtoolnix-gui.html), but they only have an effect if a file name is given after them, too.
Wakaku
4th January 2019, 09:46
Not without opening a file in the wanted too, no. The existing options can be found here (https://mkvtoolnix.download/doc/mkvtoolnix-gui.html), but they only have an effect if a file name is given after them, too.
OK thanks. Also thank you and everyone for considering Matroska rotation during playback. A really convenient and powerful container ability. :)
Mosu
4th January 2019, 14:31
Hey,
2019 is here along with the first release of MKVToolNix for the year, v30.0.0. It's on the smaller side wrt. the number of user-visible changes. It does contain a couple of usability enhancements for the GUI, though, that folks will hopefully appreciate.
Nothing has changed for package managers since v29.0.0.
Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the Windows installer/portable version & macOS DMG & Linux AppImage (https://www.fosshub.com/MKVToolNix.html) and the source code (https://mkvtoolnix.download/source.html).
The Windows and macOS binaries as well as the Linux AppImage are available already. The other Linux binaries are still being built and will be available over the course of the next couple of hours.
Here are the NEWS (https://mkvtoolnix.download/doc/NEWS.md) since the previous release:
# Version 30.0.0 "Interstellar" 2019-01-04
## New features and enhancements
* mkvextract: WAV extractor: mkvextract will now write W64 files instead of WAV files if the file name extension is `.w64` or if the final file size is bigger than 4 GB, the file size limit for WAV files. Implements #2458 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2458).
* MKVToolNix GUI: multiplexer: a new button was added next to the "destination file" controls. Clicking it shows a menu with the ten most recently used output directories. Selecting one of them will change the destination file to the selected directory keeping the file name. Implements #2468 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2468).
* MKVToolNix GUI: multiplexer (preferences): the ten most recently used values for the "relative output directory" and "fixed output directory" settings are now saved. The corresponding settings have been changed into combo boxes allowing quick access to those recent values.
* MKVToolNix GUI: multiplexer (preferences): the predefined split sizes and durations can now be customized in the preferences.
* MKVToolNix GUI: chapter editor: added an option in the "Chapter editor" menu for appending chapters from an existing file to the currently open editor tab. Part of the implementation of #2439 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2439).
* MKVToolNix GUI: chapter editor: added an action in the context menu for copying the selected entry and all of its children to another open editor tab. Part of the implementation of #2439 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2439).
## Bug fixes
* mkvmerge: all files opened for writing will now be flushed once before they're closed. This ensures the operating system actually writes all cached data to disk preventing data loss in certain situations such as power outages or buggy drivers in combination with suspending the computer. Fixes #2469 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2469).
* mkvmerge: AAC: under certain conditions 8 channel audio files were taken for 7 channel ones.
* MKVToolNix GUI: multiplexer: removing a file added as an "additional part" will no longer cause a crash. Fixes #2461 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2461).
* source code: fixed compilation with Boost 1.69.0 after API-breaking change to the `boost::tribool` class. Fixes #2460 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2460).
Have fun :)
manolito
4th January 2019, 16:34
Starting with this version 30.0.0 the old hack from this post:
https://forum.doom9.org/showthread.php?p=1813131#post1813131
to make the software work under Win XP is now history. The very latest version which works under XP after replacing the GUI with the old v. 10 GUI is v29.0.0. You can still download it here:
https://files.videohelp.com/u/172211/ToolNix_XP.zip
Cheers
manolito
/EDIT/
The archive was updated to also include the last Win7 compatible version (32-bit only)
filler56789
4th January 2019, 21:22
## New features and enhancements
* mkvextract: WAV extractor: mkvextract will now write W64 files instead of WAV files if the file name extension is `.w64` or if the final file size is bigger than 4 GB, the file size limit for WAV files. Implements #2458.
.
.
.
## Bug fixes
* mkvmerge: all files opened for writing will now be flushed once before they're closed. This ensures the operating system actually writes all cached data to disk preventing data loss in certain situations such as power outages or buggy drivers in combination with suspending the computer. Fixes #2469.
:goodpost: && :thanks:
mood
5th January 2019, 00:32
@Mosu
version 30 has a serious bug
Version 30 has a major bug that will delete your files! Unbelievable! If you use the chapter editor function and add New Edition Before or New Edition After and then add a subchapter, click save and watch your file size shrink to around 1-7 kb! Excellent(!)
I see this comment on videohelp (https://www.videohelp.com/software/MKVToolNix) site, I tested and it's true, reduced a file from 700 MB to 561 bytes
Mosu
5th January 2019, 00:36
Thanks for bringing it to my attention. I'll look into it tomorrow.
hubblec4
5th January 2019, 02:09
I have used a 7,5mb file only and there is no issue. (Win7-64 MTX-64bit)
hubblec4
5th January 2019, 03:40
Nice gif :-)
I believe you, but maybe it helps Mosu to identify to issue faster when he knows with small files seems to work.
I had added editions before and after and insert a chapter to this edition. Then I used the save item from the main menu and also try the "save in...." item but the files size don't changed.
Mosu
5th January 2019, 15:01
I can reproduce the problem if the file was created by Handbrake. I cannot reproduce such a problem with files created by MakeMKV, ffmpeg or mkvmerge. I haven't investigated yet what the difference is with Handbrake's files. If you want to be kept up to date, follow the issue I've opened (https://gitlab.com/mbunkus/mkvtoolnix/issues/2476).
As a workaround you can remux with mkvmerge before editing chapters.
Mosu
5th January 2019, 15:56
I've just committed a fix for the regression (v29 was ok; the problem was introduced during the implementation of appending chapters to open tabs for v30). I'll likely release v30.1.0 later today or tomorrow.
Mosu
5th January 2019, 17:30
Like I've stated above, the problem's already been fixed. The determining factor wasn't Handbrake vs. mkvmerge, but whether the source file contained chapters or not.
Mosu
5th January 2019, 17:39
Hey,
due to an unfortunate bug in v30.0.0 that caused the GUI's chapter editor to truncate Matroska/WebM files to a few KB, I have to release v30.1.0 today. This release also implements a workaround for dragging & dropping not working on macOS with Qt 5.12 (due to a bug in Qt).
Nothing has changed for package managers since v29.0.0.
Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the Windows installer/portable version & macOS DMG & Linux AppImage (https://www.fosshub.com/MKVToolNix.html) and the source code (https://mkvtoolnix.download/source.html).
The Windows and macOS binaries as well as the Linux AppImage are available already. The other Linux binaries are still being built and will be available over the course of the next couple of hours.
Here are the NEWS (https://mkvtoolnix.download/doc/NEWS.md) since the previous release:
# Version 30.1.0 "Forever And More" 2019-01-05
## Bug fixes
* build system: fixed building on non-UTF-8 locales. Fixes #2474 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2474).
* MKVToolNix GUI: multiplexer: implemented a workaround for drag & drop not working on macOS with Qt 5.12 due to a bug in Qt 5.12. Fixes #2472 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2472).
* MKVToolNix GUI: chapter editor: when opening a Matroska/WebM file that doesn't contain chapters and later saving chapters back to them, the editor was truncating the file down to a couple of KB in size. This was a regression introduced with the implementation of #2439 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2439) in v30.0.0 Fixes #2476 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2476).
Have fun :)
mood
5th January 2019, 17:40
Like I've stated above, the problem's already been fixed. The determining factor wasn't Handbrake vs. mkvmerge, but whether the source file contained chapters or not.
oki...
I tested with 30 rev 006 and work now without the bug
:thanks::thanks:
Edit....
You were faster to post than I was :)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.