View Full Version : MKVToolNix v99.0 released
Overdrive80
5th January 2019, 20:39
Hi Mosu, I uploaded video (at your FTP server) with issue in GUI when spanish language is set. With this problem is imposible to use the options of program. Regards.
Mosu
5th January 2019, 20:56
Well, your translations of some of the strings are too long. Try to make them shorter. Qt cannot wrap labels for checkboxes etc; therefore the minimum width of the right panel is however long the longest text shown in a single line.
Mosu
5th January 2019, 21:09
BTW, your screen resolution is extremely low. As I've stated in other places, I don't support extremely low resolutions simply because I don't have the time to support every possible hardware out there. With Spanish as the language and the default font size of 9 points, the preferences dialog fits nicely into 975x535 pixels (including the title bar), which I consider to be good enough.
As with anything Open Source, if someone who cares about really low resolution wants to take this type of problem on and improve it: sure, knock yourself out! I'd welcome patches.
Overdrive80
5th January 2019, 21:16
BTW, your screen resolution is extremely low. As I've stated in other places, I don't support extremely low resolutions simply because I don't have the time to support every possible hardware out there. With Spanish as the language and the default font size of 9 points, the preferences dialog fits nicely into 975x535 pixels (including the title bar), which I consider to be good enough.
As with anything Open Source, if someone who cares about really low resolution wants to take this type of problem on and improve it: sure, knock yourself out! I'd welcome patches.
My resolution screen is 1920x1080, and video is cropped to dont show my desktop.
EDIT: If I can not see it, is really difficult to shorten the captions because horizontal scroll bar dont work properly.
I uploaded other video in HD.
EDIT2: If the size of the preferences window is enlarged, could not it be compensated?
Mosu
5th January 2019, 21:36
Uhm, if your desktop is larger than the window you've shown in the video, then just make the whole preferences window bigger.
Overdrive80
5th January 2019, 21:41
Uhm, if your desktop is larger than the window you've shown in the video, then just make the whole preferences window bigger.
Ups, I dont notice that I could resize preferences window. :stupid:
Solved, although the resizing of that window could be automated according to the length of the content?
Thanks.
EDIT: The translations are what they are, it is not my fault that my language uses more characters to express something that is shorter in English.
mood
10th January 2019, 00:52
@Mosu
Review on videohelp (https://www.videohelp.com/software/MKVToolNix) site
MKVToolNix 30.1.0 is still truncating some of the files i try to remux.
A 88 MB file became a 6MB file, after remuxing.
Use version 30.1.0 with caution!
73ChargerFan
10th January 2019, 06:22
Resizing the GUI window seems weird. Minimum window size is 1152 x 715 - shorter than that and I lose the buttons and file entry box at the bottom.
Is there a minimum height for the mutliplexer/input/properties element? It won't shrink to less than 50% the height of the desktop.
Using 30.1.0 on Windows 10/1803 64bit, 1080p desktop, and dpi is set to 100%.
mkver
10th January 2019, 12:38
@Mosu
Review on videohelp (https://www.videohelp.com/software/MKVToolNix) site
Is there a way to contact TuNK and ask him about more details? Was he really remuxing or did he just use the chapter/header editor? Can he provide sample files together with a description of what he did?
And would it be possible for the description on videohelp to also include that bug reports should be posted on the project's issue tracker (https://gitlab.com/mbunkus/mkvtoolnix/issues) where they are actually taken care of?
sneaker_ger
10th January 2019, 12:48
Unfortunately, he has disabled PMs on Videohelp.
Mosu
10th January 2019, 13:26
Resizing the GUI window seems weird. Minimum window size is 1152 x 715 - shorter than that and I lose the buttons and file entry box at the bottom.
Is there a minimum height for the mutliplexer/input/properties element? It won't shrink to less than 50% the height of the desktop.
The minimum height is calculated automatically from the minimum height of all the control on all the panels in all the tools. As soon as you shrink it below that height, the controls will stay at their height and scroll bars will be shown. Meaning no, you do not lose the buttons, but you may have to scroll in order to find them.
Back in the day the GUI did not allow shrinking below the minimum size. Users requested that I do allow that, and the scrollable panes were the compromise that enabled the change.
LouieChuckyMerry
15th January 2019, 15:24
First, many thanks to Mosu for MKVToolNix :thanks: . After stalling as long as possible, I've finally gotten around to upgrading from version 8.3.0 (I know, I know) and, wow, the new GUI is really, really functional after getting the hang of it. I've one question, though: Is there any way to set the field "Output/File title:" to always populate as blank (no text)? I can't find a setting for this; perhaps there's a command line I could set? Thanks for any help.
Mosu
15th January 2019, 15:32
Thanks for the praise.
The title is affected by the following two options in the preferences: "Multiplexer" → "Default values" → "Automatically set the file title from source files" and "Automatically clear the file title when the last file is removed".
LouieChuckyMerry
15th January 2019, 16:13
Thanks for the praise.
You're welcome, it's very well deserved.
The title is affected by the following two options in the preferences: "Multiplexer" → "Default values" → "Automatically set the file title from source files" and "Automatically clear the file title when the last file is removed".
Ahhh, I was misinterpreting the above emphasized text. Thank you for the clarification; unticking that option is exactly what I needed :) .
LouieChuckyMerry
16th January 2019, 13:51
OK, seems I've a second question: Is there any way to set the field "Input/Properties:/Track name:" to always populate as blank (no text) for each track?
Mosu
16th January 2019, 13:59
No. The track name will be set if and only if the source file contains a track name. This is done so you can actually remove an existing track name by blanking the prefilled name.
LouieChuckyMerry
16th January 2019, 14:42
Damn, I though MKVToolNix could do everything ;-) . Thanks for the answer, Mosu, be well.
Mosu
16th January 2019, 14:55
If you don't like track names at all, you could set up a script to run after each job has completed (see preferences) that uses mkvmerge & mkvpropedit in order to remove any existing track names in the output file just created. MKVToolNix does provide all the mechanisms for automating nearly anything you would want to do, but you'll have to invest a bit of your time to tailor it to your specific needs.
LouieChuckyMerry
16th January 2019, 15:28
If you don't like track names at all, you could set up a script to run after each job has completed (see preferences) that uses mkvmerge & mkvpropedit in order to remove any existing track names in the output file just created.
OK, it's seems that is does do everything ;) . It's only sometimes that I want to clear the track names; is it possible to run the script manually? Ahhh, I'll check the Help file...
Mosu
16th January 2019, 15:45
You can define actions to run after job completion. Each action can be configured to be run automatically or on demand only. However, you'll have to activate the action to run while the job is running — currently there's no way to run an action on a job that has already completed (at least not from the GUI).
LouieChuckyMerry
16th January 2019, 16:15
You can define actions to run after job completion. Each action can be configured to be run automatically or on demand only. However, you'll have to activate the action to run while the job is running — currently there's no way to run an action on a job that has already completed (at least not from the GUI).
When I have a job queue that's a season (or several seasons) of a TV show, the only thing I (sometimes, not always) want to do is clear the video and-or audio track names ("Input/Track name:"). I don't quite understand what you meant by the above emphasized text. Sorry I'm a bit slow; I'm still in therapy from trying to learn AviSynth five years ago...
Mosu
16th January 2019, 16:23
In the "job output" tool there's a button called "When finished…" with which you can tell the GUI to execute a pre-configured action after the currently running job (or the whole queue) has finished. Using that button is what I meant.
What you cannot do, at the moment, is go to the "job queue" tool and execute a pre-configured action from there, e.g. for a completed job.
For your use case I'd simply write a script that iterates over all files in a certain folder, uses "mkvmerge --identification-format json --identify currentfile.mkv" in order to query track IDs and properties and then calls "mkvpropedit currentfile.mkv --edit track:… --delete name --edit track:… --delete name…" for all tracks that do have names set. That's assuming all of your files for a specific season (or show) end up in the same folder, but no other files are present in said folder.
LouieChuckyMerry
16th January 2019, 16:56
In the "job output" tool there's a button called "When finished…" with which you can tell the GUI to execute a pre-configured action after the currently running job (or the whole queue) has finished. Using that button is what I meant.
What you cannot do, at the moment, is go to the "job queue" tool and execute a pre-configured action from there, e.g. for a completed job.
Thanks for the clarification, now I understand.
For your use case I'd simply write a script that iterates over all files in a certain folder, uses "mkvmerge --identification-format json --identify currentfile.mkv" in order to query track IDs and properties and then calls "mkvpropedit currentfile.mkv --edit track:… --delete name --edit track:… --delete name…" for all tracks that do have names set. That's assuming all of your files for a specific season (or show) end up in the same folder, but no other files are present in said folder.
I've gone to "Preferences/Jobs & jobs queue/Executing actions/+ Add action", selected "Execute a program" and named it "ClearTrackName(s). My destination folder is "C:\Users\...\Desktop\MKVTempNix". I understand how a command line works, in its most basic sense, but not how to use it. That is, I can copy and paste your above text but don't understand how-where to place the folder path or how to call "mkvpropedit". I tried:
C:\Users\...\Desktop\MKVTempNix\mkvmerge --identification-format json --identify currentfile.mkv mkvpropedit currentfile.mkv --edit track:… --delete name --edit track:… --delete name…
but received a "Program execution failed" message.
Mosu
16th January 2019, 17:00
What you're trying to do cannot be expressed as a simple one-liner. You'll have to write a full script to do what I said. Here's (https://gitlab.com/mbunkus/mkvtoolnix/wikis/Batch-muxing-with-the-GUI#more-advanced-processing) an example of a Ruby script doing something else you can use as a basis to get started.
LouieChuckyMerry
16th January 2019, 17:04
Ooh boy, I'm going to have to double my therapy sessions (or up my Bitburger intake). I'll spend some time trying to figure this out, Mosu, thank you so much for your time :) .
Mosu
16th January 2019, 17:55
You're quite welcome.
Flash_Git
25th January 2019, 20:11
Since the release of 30.0.0 (including the latest) fonts have looked terrible on macOS (Mojave).
http://www.framecompare.com/image-compare/screenshotcomparison/YDDPNNNX
Mosu
25th January 2019, 20:23
Yeah, that's a known problem with Qt 5.12.0 on macOS. Qt 5.12 has other issues, too, but it does solve the very real issue of 5.11 not being usable at all on Mojave in dark mode. Meaning I'll stick with 5.12. I'll definitely update Qt as soon as new versions come out.
Your options are, obviously:
Stay with a version before v30.
Stay with a version after v30 and live with the bad font rendering.
Compile MKVToolNix v30.1.0 yourself against Qt 5.11.x (MKVToolNix is fully compatible with earlier Qt releases down to 5.3 or so).
hubblec4
25th January 2019, 20:59
On my Windows7 with font Segoe UI, many labels have spaces in the names, this come from QT5.12?
Mosu
25th January 2019, 21:46
No, the Windows builds are still using 5.11.x. It was another updated library that's causing this.
mariner
26th January 2019, 09:11
Here's (https://1drv.ms/u/s!Ag6hm31FMiVwjr8xOGQOZZARcUphkA) a 1 minute sample
Thank you, algorithm_colon.
leon
28th January 2019, 01:52
Is it possible to make mkvmerge completely abort muxing in case of a warning?
Mosu
28th January 2019, 18:39
Is it possible to make mkvmerge completely abort muxing in case of a warning?
No. At the moment there's no option for that. I might add one, though. Please file a feature request over on Gitlab (https://gitlab.com/mbunkus/mkvtoolnix/issues/). Otherwise chances are I might forget about it again. Thanks.
leon
31st January 2019, 11:26
No. At the moment there's no option for that. I might add one, though. Please file a feature request over on Gitlab (https://gitlab.com/mbunkus/mkvtoolnix/issues/). Otherwise chances are I might forget about it again. Thanks.
Somebody's already done it(Thanks): https://gitlab.com/mbunkus/mkvtoolnix/issues/2493
Thanks for considering this.
mkver
1st February 2019, 20:02
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
The kerning problem is gone since the first continuous build after 30.1 (https://gitlab.com/mbunkus/mkvtoolnix/commit/8cde39725e19267325ac7e0933fe214cf788786a). Incidentally, this commit is about qt, but updating the qt requirement alone can't fix this; there was an update of qt (or some other stuff that has something to do with font rendering) at the same time, wasn't there?
Mosu
1st February 2019, 20:31
Yep, I did update my MXE build environment on 2019-01-06, and the first continuous build after after 30.1.0 (not the one for 30.1.0, though) seems to have been done with the updated environment. MXE did update the HarfBuzz (https://www.freedesktop.org/wiki/Software/HarfBuzz/) library, among other things, within the timeframe.
Incidentally, this commit is about qt
That commit only updated the documentation & the check in "configure". The change that actually triggered higher Qt requirements went in before release 30.0.0 already. That commit is completely unrelated to the issue at hand.
tormento
3rd February 2019, 07:49
@Mosu I dunno if it's related to your suite or the specific app, anyway, could you please get a look at that (https://forum.doom9.org/showthread.php?p=1863191#post1863191)?
Mosu
3rd February 2019, 12:39
@Mosu I dunno if it's related to your suite or the specific app, anyway, could you please get a look at that (https://forum.doom9.org/showthread.php?p=1863191#post1863191)?
That's definitely due to what that application does. I cannot help you with it.
Mosu
9th February 2019, 12:31
Hey,
I've just released MKVToolNix v31.0.0 which fixes a couple of issues, especially drag & drop support in combination with Qt 5.12 and newer. Note that the addition of flushing cached data on closing files introduced in v30 has been reverted due to detrimental behavior; an additional command line option has been added to make mkvmerge flush its buffers for those who need it.
Nothing has changed for package managers since v30.1.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 31.0.0 "Dolores In A Shoestand" 2019-02-09
## New features and enhancements
* all programs: added a new option `--abort-on-warnings` that will cause the program to abort after it has emitted the first warning, similar to how it aborts after the first error. Implements #2493 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2493).
* mkvmerge, mkvextract: when closing files that were opened for writing, cached data will not be flushed to storage automatically anymore. This reverts the workaround implemented for #2469 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2469). A new option was added to both programs (`--flush-on-close`) that re-enables flushing for people who are affected by data loss such as described in #2469 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2469).
The reason is that automatic flushing causes long delays in processing queues when the output by mkvmerge/mkvextract isn't the final product but just an intermediate result to be processed further.
Implements #2480 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2480).
* MKVToolNix GUI: multiplexer: the dialog previewing different character sets for text subtitles will now keep the position of the displayed text when switching between character sets. Implements #2489 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2489).
## Bug fixes
* mkvmerge: AVI reader: using DV type 1 AVIs will now result in an unsupported file type being reported (as the underlying AVI library doesn't support them) instead of crashing mkvmerge. Fixes #2491 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2491).
* mkvmerge: HEVC: the height of interlaced streams will now be set correctly to the height of the full frame instead of the height of a single interlaced field. Fixes #2446 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2446).
* mkvmerge: MP4 reader: edit lists consisting solely of elements that mkvmerge doesn't support (such as dwells) are simply ignored. Before no data was read for such tracks at all. Fixes #2487 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2487).
* mkvmerge: text subtitles: entries with an explicit duration of 0ms will now be handled correctly: the 0ms duration will be stored in Matroska instead of the difference between the current and the following entry. Fixes #2490 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2490).
* MKVToolNix GUI: multiplexer, chapter editor: fixed drag & drop handling with Qt 5.12.0 and newer. Fixes #2472 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2472).
* MKVToolNix GUI: multiplexer: the GUI did not clean up temporary files created when running `mkvmerge`. Fixes #2499 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2499).
## Build system changes
* Qt 5.4.0 or newer has required (up from 5.3.0) since version 30.0.0; I just forgot to include this entry.
Have fun :)
mkver
9th February 2019, 21:20
Note that the addition of flushing cached data on closing files introduced in v30 has been reverted to do detrimental behavior;
Interesting. I didn't now you had such a destructive nature. :devil:
(You wanted to write "due to", didn't you?)
Mosu
9th February 2019, 21:27
LOOOOOOL I did indeed :D "due to" is obviously the intended wording :)
sneaker_ger
9th February 2019, 21:38
I've just released MKVToolNix v31.0.0
* MKVToolNix GUI: multiplexer: the dialog previewing different character sets for text subtitles will now keep the position of the displayed text when switching between character sets. Implements #2489.
Thank you.
mkver
9th February 2019, 21:58
LOOOOOOL I did indeed :D "due to" is obviously the intended wording :)
It happens to me all the time, too. See for example my recent PR for mkvalidator (https://github.com/Matroska-Org/foundation-source/pull/39): Despite rereading it repeatedly I let an unused variable slip through and had to reword the commit message.
Danette
10th February 2019, 16:47
I am merging various mkv files. Each file has a chapter name. When I add/append the files, the output does have the various chapter times correctly placed, but the chapter names disappear. Is there some way to merge these files and retain the chapter names within each file so I don’t have to manually re-enter the name for each one?
sneaker_ger
11th February 2019, 16:45
That is already the default behavior. Are you sure your source files actually have chapters as defined in the Matroska spec and not just e.g. Segment Titles?
Upload sample files and your complete command if necessary.
@Mosu:
Maybe it would make sense to add a <SEGMENT_TITLE> variable to --generate-chapters-name-template
Danette
11th February 2019, 19:06
That is already the default behavior. Are you sure your source files actually have chapters as defined in the Matroska spec and not just e.g. Segment Titles?
Upload sample files and your complete command if necessary.
@Mosu:
Maybe it would make sense to add a <SEGMENT_TITLE> variable to --generate-chapters-name-template
Thanks for the reply. I'll upload a sample as the next step, if you still think it necessary. However, here is what the XML file contains:
<?xml version="1.0"?>
<!-- <!DOCTYPE Chapters SYSTEM "matroskachapters.dtd"> -->
<Chapters>
<EditionEntry>
<EditionUID>17724414706209801463</EditionUID>
<ChapterAtom>
<ChapterTimeStart>00:00:00.000000000</ChapterTimeStart>
<ChapterUID>16958226351709810015</ChapterUID>
<ChapterDisplay>
<ChapterString>Chapter Name Test</ChapterString>
<ChapterLanguage>und</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>
</EditionEntry>
</Chapters>
Note that the chapter name is entitled: "Chapter Name Test".
Mosu
11th February 2019, 19:32
I am merging various mkv files. Each file has a chapter name. When I add/append the files, the output does have the various chapter times correctly placed, but the chapter names disappear. Is there some way to merge these files and retain the chapter names within each file so I don’t have to manually re-enter the name for each one?
Sounds a bit like all the chapters in the source files have the same chapter UIDs. Can you extract chapters from each of the file and upload them to my server, please?
Danette
11th February 2019, 22:34
Sounds a bit like all the chapters in the source files have the same chapter UIDs. Can you extract chapters from each of the file and upload them to my server, please?
You are right: many of the xml files have the same ChapterUID (all made with the MKVtoolnix chapter editor). The only difference is in the ChapterString, which contains the chapter name. I could upload them, but that is what you would see.
As I see it, being able to specify the ChapterString in the name template would fix it. I suppose that @sneaker_ger was suggesting.
leon
16th February 2019, 18:02
* all programs: added a new option `--abort-on-warnings` that will cause the program to abort after it has emitted the first warning, similar to how it aborts after the first error. Implements #2493.
That was fast. Thank you.
Megalith
23rd February 2019, 01:49
Is there an ETA on when the auto-sorting option (e.g., automatically move video files to the top of list) will be added to MKVToolNix?
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.