MKVToolNix v24.0.0 released

[Mosu]

Originally Posted by mariner

Greetings Mosu.
Appreciate if you could kindly assist with a problem of wav audio (LPCM) in mkv not recognised by tsmuxer.
Many thanks and best regards.

Sorry, but I cannot help you with that. That's tsmuxer's problem.

[Mosu]

Originally Posted by markanini

How can I get MKVToolNix GUI to generate a chapter mark between appended files?

You cannot as there is no such feature at the moment, and I currently don't have any plans on implementing one – mostly because mkvmerge's flexibility makes it very hard to say where such a mark would have to be put exactly.

[Mosu]

Hey,

I've released MKVToolNix v8.5.0. It contains the usual mix of bug fixes and enhancements, most of them for the GUI but some for mkvmerge, too. Most of these correspond directly to entries in the issue tracker.

There's one small change for package maintainers: there's a new translation of the man pages into Catalan.

Here are the usual links: the MKVToolNix home page, the Windows installer and portable version and the source code.

All binaries that I provide have been uploaded already.

Here's the full ChangeLog since the previous release:

2015-10-17 Moritz Bunkus <moritz@bunkus.org>
* Released v8.5.0.

2015-10-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: the cropping parameters contained the "cropping:" prefix twice in the verbose identification output.
* MKVToolNix GUI: merge tool enhancement: when dropping files onto the GUI the last file's directory is remembered as the last directory a file was opened from causing the next open file dialog to start in that directory. Implements #1477.
* all: new feature: added a Catalan translation of the man pages by Antoni Bella Pérez (see AUTHORS).

2015-10-15 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: chapter editor enhancement: the start and end timestamps in the tree are displayed with nanosecond precision. Implements #1474.
* MKVToolNix GUI: merge tool enhancement: added a column to the track list containing the state of the "forced track" flag. Implements #1472.

2015-10-14 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: pressing the delete key in the attachments list removes the selected entries. Implements #1473.

2015-10-13 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: enhancement: if the last directory opened doesn't exist anymore then default to one that does in order to prevent an error message from older Windows versions about a location not being available. Fixes #1438.

2015-10-10 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: enhancement: the context menu for the status bar job status counters is now shown when the user clicks with any mouse button, not just the right one. This should make the feature easier to discover. Implements #1396.
* MKVToolNix GUI: new job queue feature: added an option in the preferences for resetting the warning and error counters of all jobs and the global counters in the status bar to 0 when exiting the program. Implements #1437.
* MKVToolNix GUI: current job output enhancement: the separator lines for warnings and errors ("--- Warnings emitted by Job … started on … ---") are only shown when warnings/errors actually occur and not for each job that's run.

2015-10-09 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: the menus that are currently not shown are disabled properly so that they don't react to keyboard shortcuts anymore. This affected e.g. Alt+J with the English localization as there were three shortcuts active: the "add to job queue" button (if the merge tool is active), the "job queue" menu and the "job output" menu.

2015-10-08 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix (Windows): changed some options for Qt's file dialogs in order to speed up access to network shares in certain situations. Fixes #1459.

2015-10-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: improved identification output for DTS 96/24. Implements #1431.

2015-10-04 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: PCM tracks: if the number of samples per packet varies then no default duration will be written. Fixes #1426.
* MKVToolNix GUI: merge tool enhancement: added buttons for previewing the character sets for text subtitles read from SRT and SSA/ASS files as well as for chapter files. They're located next to the drop down boxes for the character sets on the input and output tabs.
* MKVToolNix GUI: merge tool enhancement: added buttons next to the 'segment UID', 'previous segment UID' and 'next segment UID' controls that enable the user to select a Matroska file. The GUI reads that file's segment UID and enters its value into the corresponding control. Part of the implementation of #1363.
* mkvmerge: new feature: The three options that use segment UIDs (--segment-uid, --link-to-previous and --link-to-next) can now read the segment UID of an existing Matroska file. For this the file's name must be given as an argument prefixed with = (e.g. '--segment-uid =some_file.mkv'). Implements #1363.
* MKVToolNix GUI: chapter editor enhancement: Added another variable to the chapter name templates called <START> which is replaced by the chapter's start timestamp. An optional format can be specified, e.g. <START:%H:%M:%S.%3n> resulting in something like 01:35:27.734. This can be used in the 'generate sub-chapters' or the 'renumber sub-chapters' functionality. Implements #1445.

2015-10-03 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool bug fix: If there's currently no source file present when the user drags & drops files onto the merge tool then the GUI will no longer leave an empty, superfluous tab for certain drop modes. Fixes #1446.
* MKVToolNix GUI: merge tool enhancement: implemented the optional warning before overwriting existing files when starting to mux or adding a job to the queue. The pending jobs in the queue are checked for the same destination file name as well. Implements #1390.
* MKVToolNix GUI: enhancement: pressing the delete key in the chapter editor and the job queue removes the selected entries. Implements #1454.
* MKVToolNix GUI: merge tool enhancement: dropping chapter, tag and segment info files from external applications will cause those file names to be added to the appropriate controls on the 'output' tab. Implements #1332 and 1345.
* MKVToolNix GUI: merge tool enhancement: the feature "default track language" has been split into track languages by type. There are now three separate settings for audio, video and subtitle tracks. Implements #1338.

2015-09-29 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: the verbose identification for MP4 files will now derive basic audio parameters of MP3 and AC3 tracks from the bitstream instead of relying on the values in the track headers.

2015-09-27 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new merge tool feature: implemented an optional vertical layout mode for the "input" tab in which the track properties are shown below the track list. Implements #1304.

2015-09-26 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool bug fix: the "default track flag in output" column wasn't updated properly directly after loading settings.

2015-09-25 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: when browsing for chapter files on the "output" tab the initial directory is the first input file's directory instead of the directory accessed last.
* MKVToolNix GUI: merge tool bug fix: the cropping parameters were not converted into parameters for mkvmerge at all.

2015-09-22 Moritz Bunkus <moritz@bunkus.org>
* all: several ISO 639-2 codes of languages that are very old and not spoken anymore have been removed (e.g. "English, Middle (1100-1500)").
* MKVToolNix GUI: enhancement: on Windows the drop down boxes were elliding overlong text. This has been changed to making the open combo boxes' scroll areas wide enough to contain the whole entries. This matches the behavior of Qt on other operating systems.
* all: fixed the spelling of the AC-3, E-AC-3 and VC-1 codec names.

2015-09-21 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new merge tool feature: added context menu entries for opening the selected files/the source files of selected tracks in MediaInfo. Implements #1423.

2015-09-20 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: the interface language selection has been improved not to select wrong entries resulting in error messages from mkvmerge about unknown translations. Fixes #1434.
* MKVToolNix GUI: bug fix: if the Windows version of the GUI was started from a symbolically linked folder then it would crash when the user added a file. Fixes #1315.

Have fun.

[Music Fan]

Hi,
I installed version 8.5.0 and I don't find the GUI for MKVmerge, is it abandoned ?
I prefer the ususal GUI than the new one (mkvtoolnix-gui), is there a way to continue with the usual GUI using the new mkvmerge.exe ?

[Mosu]

Yes. No, at least not a supported one.

What I suggest you do instead is to start using the new GUI and telling me what you don't like about it. Maybe you're missing functions from the old GUI that you didn't know exist already in the new GUI? Or maybe trying to do things one way while not being aware that the new GUI offers you other ways, often more effective, to achieve the same result? But please be specific; I cannot do anything with a generic "I don't like it". Thanks.

[ndjamena]

I don't like the layout of the header editor, it was the one thing I wanted changed from MMG but you kept it the same.

Look at the way the "merge" header elements are managed and compare it to the "edit headers" method.

Is there some reason you prefer that particular layout?

[Mosu]

ndjamena: I'm sorry but I don't quite get what you mean. Can you describe in more detail what kind of a layout you'd prefer to see?

What I cannot really do is list all of the properties beneath each other as in the track properties in the merge tool, if that's what you mean. There's way too much text to be displayed for such a layout not to look confusing, I'm afraid.

[Music Fan]

Originally Posted by Mosu

What I suggest you do instead is to start using the new GUI and telling me what you don't like about it.

That's confusing, too different from MKVmergGUI with too many things written and more little windows.
I don't understand why you changed the interface that was clear and to which we were used.

[ndjamena]

Could you put editable track Name, Language, UID, Default and Forced elements in the track root node properties at least, to make them more accessible?

[Mosu]

Because users were requesting several things that weren't possible with the old layout. A really quite common complaint was that the (old) GUI was too high, especially on notebooks with rather low resolution where the GUI wouldn't even fit. Monitors have been getting wider and less high (I had been using 1600x1200 for a long time, but try to get something > 1024 pixels high without going up to 2500x… nowadays), and the old GUI was designed exactly the wrong way around.

However: If you prefer the vertical layout used in the old GUI then with 8.5.0 you can switch the new GUI to a vertical layout, too.

And "too man things written"…? Uhm, excuse me, but what?

I also don't get what you mean by "little windows". Like I said, please be specific.

[Mosu]

Originally Posted by ndjamena

Could you put editable track Name, Language, UID, Default and Forced elements in the track root node properties at least, to make them more accessible?

No, sorry, that would make the whole point of a tree-ish layout moot and somewhat confusing. Especially as the fact whether or not the default track flag is present in the file is actually important regarding the interpretation of the value (not present means its effective value is "yes/on" due to the element's default value).

[markanini]

Originally Posted by Mosu

You cannot as there is no such feature at the moment, and I currently don't have any plans on implementing one – mostly because mkvmerge's flexibility makes it very hard to say where such a mark would have to be put exactly.

I was offered a solution here which I'll use for the time being: http://forum.videohelp.com/threads/3...=1#post2414720

[73ChargerFan]

Yep, that technique works fine with the current release. Thanks markanini!

It'll be very useful to convert extras from blu-ray disks into a single mkv. I've tried manually creating chapter files for this, but they're always off by half a second here, half a second there.

[ndjamena]

To use your own argument against you, if I'm processing movie subtitles and copying "names" from one file to the next, I don't have enough vertical real estate to have more than two subtitles tracks expanded at a time without maximising the entire window. Not to mention the fact that it's difficult to blindly search and select the correct one given the current layout. There's no indication from the outside which subtitle has any particular name and after expanding the tracks the name nodes are so far apart that fitting them on the screen and finding them is a pain.

At the same time there's a whole lot of real estate in the bottom right that's just been wasted on emptiness.

Checking the UIDs of each track is difficult too, you have to expand each and every one and hunt down the UID nodes.

The layout is just difficult, I don't pretend to know what you're trying to accomplish or what a better solution would be but...

[Mosu]

If the problem is finding the right track to modify then I can probably make that easier without a lot of work (which re-working the whole layout would require).

In the tree I already include the CodecID. In the same spirit I can incorporate more information, probably in the form of real columns and not just as text in the first column. Track name, UID, codec ID, default track flag, video resolution/audio sampling frequency & number of channels come to mind.

[ndjamena]

As long as I can copy from there that would be an improvement.

How difficult would providing a dropdown box with a list of custom entries to choose from in the name section be? Too hard?

I won't be too pedantic about it, it's just that I accidently deleted my batch script that renamed the tracks and now I'm stuck using the Header Editor until I can pull something together to replace it. Not that I was happy about it before then or even before the new GUI.

[Mosu]

You won't be able to copy from those columns, no, but I think I'll do something in addition to those columns: I'll add some more information on the track's page and enable mouse selection for those entries. So your workflow could look like this: determine the track to click on by looking at the various columns in the tree view, click on that track's entry in the tree, select the name on the right, copy.

You can already customize which columns are shown in other views by right-clicking on the column headers; the same mechanism will apply to the tree view in the header editor, too.

The header editor wasn't built for mass-modification. That's the domain of mkvpropedit, much like mass-muxing is the domain of mkvmerge and not of the GUI. Instead the header editor's current design is to be precise in how it represents the file's content and to allow the user to do exactly what (s)he wants to – e.g. remove element XYZ.

I may implement a whole different editing mode in the future that's more along the lines of a tabular view of editable fields for everything, but that's not that easy to implement. Other things in the GUI will have higher priority for me, though.

[ndjamena]

I've already created simpler batch scripts for TV shows with hard coded values, the problem is every cinematic movie is unique and needs more complicated routines to help fill them in, hence the manual copy/pasting at the moment.

[Fullmetal Encoder]

Originally Posted by Mosu

...and I currently don't have any plans on implementing one – mostly because mkvmerge's flexibility makes it very hard to say where such a mark would have to be put exactly.

How so? Assuming they aren't corrupt don't video files begin with an I-frame? So couldn't a blank chapter be attached at the beginning of each file segment that's being appended just prior to the appending process? That way each chapter would begin precisely on an I-frame and when multiple files with blank chapters are appended MKVToolNix GUI automatically adjusts the starting and ending times of each chapter in the resulting combined MKV. So it seems that the program can already do the bulk of the work, only the way it is now, to achieve the same result, we would have to manually create and attach a blank chapter file to each and every video segment separately before appending. And if a user wanted more fine grained control over where each chapter mark actually begins they wouldn't be using such a feature anyway since it would actually create more work for them by having to edit the starting times in the chapter file of the combined MKV.

This is useful in the case where different video processing may need to be done on separate chapters within say, a DVD, for example. We separate the chapters (or VOBs) perform our processing on the segments then rejoin them back into a single large MKV.

[Mosu]

Like I said, mkvmerge is flexible. There are cases for which such a functionality would be more or less easy to implement: a typical file with a single video track, one or more audio tracks. In such a case the start of the next file would probably be the first video track's timestamp. Oh wait, video tracks actually don't have to start with an I frame (think open GOP), so first I frame's timestamp.

Yeah ok. But what about files with multiple video tracks? Which video track do I use in that case? The first? What if the second one has its "default track flag" set instead of the first one? Which one is actullay the "first" if the user re-orders the tracks so that the second from the source file will be the first in the input file?

Next case: two video tracks in different files (meaning you have four files in total, mux two of them in parallel and append one to each of the other so that the output file will contain two video tracks). Now it's quite possible (likel, even) that one of the video tracks' first file is shorter than the other. So how to I handle that situation? Create two chapter entries? Only one? If only one then the same as the question above applies.

What if you're appending different number of files? Yes, I have had reports from users doing just that: they had three video segments and two audio segments, all of which would end up with the same total length. Imagine a situation with two video tracks and different number of segments. Same question as above: where should it create chapter markings?

mkvmerge appends on a track-by-track basis, not on a file-by-file basis. That's what makes it incredibly flexible. But it also means that such new functionality requires a lot of thought in order to get it right, and a lot of effort to implement and test properly. I'm not willing to invest that time. I would love for someone to step up and offer code for this, but my experience from the past is that apart from minor bug fixes people only contribute to MKVToolNix in the form of translations, not code. That's quite OK, but that also means that I'm the only person to implement new features, and my time is limited. So please respect that I sometimes simply don't _want_ to tackle an issue, even if it would fit into its scope and design. Thanks.