MKVToolNix v24.0.0 released

[Simon88]

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

Your right, I rarely every use the GUI, only to grab the "command line". But, I just checked my system just now and mmg.exe uses very little cpu. He may need try using an SSD drive.

[Boulder]

Setting any priorities will help very little. The program will happily use whatever resources are available unless some other program requests for the same resource but has a higher priority. Sounds to me that some kind of I/O throttling is requested but I'd say it's very hard if not impossible to implement such a thing inside a program. Sounds more like a job for the OS.

[Mosu]

As others have pointed out you can set the process priority to "lowest" which will also set a lower I/O priority. The advantage is that other programs you use simultaneously will receive more I/O bandwidth which may alleviate your problem somewhat.

mkvmerge doesn't have a real throttling mechanism for adjusting the maximum I/O bandwidth.

Also : the mmg process itself should never use much CPU. It's just the frontend that controls mkvmerge. mkvmerge is the processdoing all rthe heavy lifting requiring CPU and I/O power.

[delacroixp]

Hi. How do I limit mmg.exe mux speed, it is killing my 5400RPM HDD. Impossible to use computer while muxing 10GB files. Cheers.
Also many motherboard chipsets are crippled in a way that consumes the cpu 90%+ when HDD is busy. Only way around it is buying a high performance RAID HDD controller which has its own memory and controller chips that offloads most tasks away from the cpu.
Muxing a 10GB file on an old PC is a major challenge.
Green 5400rpm HDD's (vs 7200rpm) are faced with a similar challenge.

That said ... installing a 2nd HDD (even an old 75GB model) will act like RAID if you mux over the 2 HDD's.
WRITE is more intense than READ ... so mux from C: to D:
A 3rd drive will marginally improve your situation still further since windows and other programs utilise the C: drive.
Once done, you can even move the 'paging file' to the new drive ... for a nice performance improvement overall.

Muxing, is a low CPU but a high HDD usage operation.
(It's little more than a copy operation in most cases)


It's all good
:):devil::D
Pascal

[Simon88]

Muxing a 10GB file on an old PC is a major challenge.
Green 5400rpm HDD's (vs 7200rpm) are faced with a similar challenge.

That said ... installing a 2nd HDD (even an old 75GB model) will act like RAID if you mux over the 2 HDD's.
WRITE is more intense than READ ... so mux from C: to D:
A 3rd drive will marginally improve your situation still further since windows and other programs utilise the C: drive.
Once done, you can even move the 'paging file' to the new drive ... for a nice performance improvement overall.

Muxing, is a low CPU but a high HDD usage operation.
(It's little more than a copy operation in most cases)


It's all good
:):devil::D
Pascal

I've noticed many low CPU, but HDD intensive operations can literally freeze some computer, but not others. Such as database manupulation or re-muxing. Sometimes an updated chipset+sata controller driver "may" fix it, but on other times it's just the way the controller/driver operates for that particular motherboard. Most newer well reviewed motherboards shouldn't do this. I've seen this behavior on some HP/Compaq or other pre-configured home computer systems. In the past HP and others almost always uses an OEM/crippled versions a budget ASUS motherboard. However buying a $100+ or so RAID controller will almost always fix this for me. Hence, it is often cheaper just to replace the motherboard. Of course, using two separate HDD will lessen the HDD bottleneck, as well.

[foxyshadis]

These days you can get 3TB for $100 (or 2 1TB for $100) or you can get a network-attached NAS for only a bit more, so it's hardly worth it. Each version of Windows also significantly improves default I/O priority, with 8.1 you can hardly tell anything's happening. I'll recommend everyone buy an SSD these days, too, they're becoming dirt cheap (though getting one into a laptop without sacrificing capacity is tricky, unless you settle for external storage).

[rhaz]

Lol, you guys still arguing about it. I got another question. How do you add an audio alert when muxing is complete? E.g. when eac2to command line finish the process it makes sound alert, really useful when away from keyboard.

[Mosu]

There's currently nothing in mmg for such a purpose. You could always run mkvmerge and some audio player from a batch file, of course.

[Chetwood]

How do you add an audio alert when muxing is complete?
We've been over this (http://forum.doom9.org/showthread.php?p=1668297#post1668297) and it doesn't look pretty :(

[Simon88]

Hi Mosu,

I was wondering if it would be possible to add another way of inputing aspect ratio in mkvtools? You currently have two ways in the GUI -- "Display width/height" and "DAR"...

Since (PAR) = (DAR)/(SAR), I'm wondering if it is possible to use PAR as an input method?

It is very easy to remember, and square pixels are always 1:1... It is especially useful and easy to calculate when dealing with subtitles that occupy its own area of the screen.

Thanks...

[Sparktank]

For playing simple WAV files from command-line (if media players cause a hassle), you can always use "sounder.exe" to play a WAV from the command line.
http://www.elifulkerson.com/projects/commandline-wav-player.php

[code]mmg ...batch commands...
sounder "C:\Bin\SFX\Star Trek\Romulan Hail Screen.wav"
[code]

It works great for batch processes.

MMG also has an option at the top of the menu bar where you can copy the command operation to clipboard, file, etc.
So there's plenty of options.

[MeridiusUK]

Hi all, just wanted to report a bug that I noticed with MKVToolNix 7.1.0 64bit on windows 7 intel chip.

It does not support multi monitors like older versions did what I mean is if I movie MKVToolNix to anything other than the primary monitor (centre) it does not stay there it tries to put itself back to the centre primary monitor. it will not save its position unless I use the centre monitor and it saves its positions all the time but soon as I move it to another monitor and reload it it goes back to the centre monitor. the older versions did not have this problem as I upgraded from 6.3.

just hope it can be fixed in the new versions

thanks

[Mosu]

I don't work on the old GUI anymore as I'm re-writing it with a different toolkit. I'm pretty sure that remembering the correct position in a multi-monitor setup won't work with that new version either at first, but once the most important things have been implemented I may get around to implementing multi-monitor positioning correctly. You'll have to live with for the time being, though.

[MeridiusUK]

no problem thanks for getting back to me

[Simon88]

I don't work on the old GUI anymore as I'm re-writing it with a different toolkit.

Where can we find betas/alphas of your new GUI version?

[Mosu]

There are no such builds yet. The next release should feature a first preview, but it'll really only be a preview, not an alpha, and most definitely not a beta.

[Carpo]

Mosu would it be possible in this new GUI to add the option to make and add tags to mkv files during muxing? I know at the moment we have to make the xml file ourselves and add it, just be nice to have it all in one so to speak :)

[Mosu]

A tag editor is something I might be working on one day, but that day is still far off in the future.

[Mosu]

Hey,

I've released mkvtoolnix v7.2.0. It fixes a couple of small bugs. Furthermore it fixes compilation with the just-released Boost v1.56.0 which is source-incompatible to earlier releases in certain ways.

Behind the scenes a lot of work has gone into the re-write of mmg called MKVToolNix GUI. This release is the first one to feature a preview of that new GUI, but only in the Windows binaries (users of other operating systems will have to compile the package themselves if they want to run the new GUI). More details are available at https://trac.bunkus.org/wiki/MkvToolNixGuiStatus

For packagers: note that the REAMDE file has been converted to Markdown format. Therefore it has been renamed to README.md.

Here are the usual links...

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

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

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

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

Here's the full ChangeLog since release 7.1.0:

2014-09-13 Moritz Bunkus <moritz@bunkus.org>
* Released v7.2.0.
* MKVToolNix GUI: included a first preview version in the Windows installer and portable releases.

2014-09-08 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed calculating AC3 delay from garbage data when reading AC3 from AVIs. This stopped working in release 5.4.0 due to commit 97cc2121.

2014-09-06 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: SSA/ASS files with sections after "[Events]" in their CodecPrivate are now handled correctly. Fixes #1057 (https://www.bunkus.org/trac/ticket/1057).

2014-09-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed handling certain edit list types in MP4 files that are used for positive track delays. Fixes #1059 (https://www.bunkus.org/trac/ticket/1059).

2014-08-09 Moritz Bunkus <moritz@bunkus.org>
* source: Fixed compilation with Boost 1.56.0 which changed the»indexed« range adaptor in an incompatible way.
* mkvpropedit, mmg's header editor: bug fix: when editing files with missing track UID elements such an element will be generated automatically instead of crashing and leaving the file in an unplayable state. Part of a fix for #1050 (https://www.bunkus.org/trac/ticket/1050).
* mkvmerge: bug fix: Reading Matroska files with missing track UID elements will no longer cause mkvmerge to abort with an error. A warning is printed and a new unique track ID generated instead. Part of a fix for #1050 (https://www.bunkus.org/trac/ticket/1050).

Have fun.

[sl1pkn07]

UO!!!!

thanks!!

show like this in my linux (build from sources)

http://wstaw.org/m/2014/09/13/plasma-desktopuf2662.png

is as expected?

greetings

EDIT: is a Qt5, fail build with Qt4 (configure say too old)

[wanezhiling]

The new desktop shortcut "MKVToolNix GUI preview" can not be automatically deleted after uninstalling the program.

[Mosu]

Only Qt5 is supported. Your screenshot looks a lot like it looks on my machine, albeit with a different theme (I'm not using Ubuntu, nor any of their UI stuff like Unity or those themes). So I'd say that yes, it should look this way. Anything in particular that you find strange about it?

[Mosu]

The new desktop shortcut "MKVToolNix GUI preview" can not be automatically deleted after uninstalling the program.

Will be fixed in the next released.

[sl1pkn07]

Anything in particular that you find strange about it?

at the moment, the white frame

greetings

[Mosu]

I've added an explicit frame around that panel because it was hard to distinguish on a traditional theme (meaning a lighter theme, e.g. Windows' default colors or something with light gray backgrounds). But that's just optics; I'm not really set on such things, just experimenting here and there.

[filler56789]

LOL, it seems some anti-viruses don't like the latest MKVtoolnix :)

http://www.videohelp.com/tools/MKVtoolnix#11697

[Mosu]

That happens regularly. It will happen again. I've even written a FAQ entry (https://trac.bunkus.org/wiki/FAQ%3AVirusInInstaller) about it.

It happens so often (especially with ridiculous files like eicar.mod – EICAR is not a virus, it's an anti-virus test file! (http://en.wikipedia.org/wiki/EICAR_test_file)) that I've given up reporting the false positives to anti-virus companies. It literally took hours for each release finding out where to send those reports to and then actually sending them.

[DragonQ]

I have a question about the new GUI preview. Why does it use the old Windows 2000 style Winforms elements? Why not use "visual styles"? I dunno about C++ but with .NET programs this literally is just ticking a box in Visual Studio.

[Carpo]

More than likely because it is just a preview and a rough example of what Mosu is thinking about, as more people see it and give feed back, then he can change things

[sl1pkn07]

Qt5 is relative new, need time to get look&feel like Qt4

[magsoud]

Please Add "--disable-track-statistics-tags" to New Version!

[Chetwood]

why not do it yourself and set it as default?

[Mosu]

I have a question about the new GUI preview. Why does it use the old Windows 2000 style Winforms elements? Why not use "visual styles"? I dunno about C++ but with .NET programs this literally is just ticking a box in Visual Studio.

I haven't fiddled with the platform-specific knobs yet at all. The goal, of course, is to have the application look as native as possible – which Qt5 can definitely do.

It's also quite possible that this has something to do with the fact that I'm linking statically and not dynamically at the moment; I seem to remember that having some influence at least on Linux regarding how an application looks in KDE and GNOME. Maybe it applies to Windows as well.

But like I said: this is a preview. I'd expect at least the beta to have this fixed, if not the alpha.

[Mosu]

Please Add "--disable-track-statistics-tags" to New Version!

If you're referring to the new GUI: I don't take feature requests yet. That being said, I've also stated (https://trac.bunkus.org/wiki/MkvToolNixGuiStatus) that achieving feature parity with the old GUI is definitely a goal. So the ability to set that option will come back in one form or another.

If you mean the old GUI: that's already possible: »Muxing« → »Add command line options« → select the desired option and press »Add«. If you want it set for all of your muxing jobs (which I suspect you do) then simply check »Set as default for new jobs«.

[DragonQ]

I haven't fiddled with the platform-specific knobs yet at all. The goal, of course, is to have the application look as native as possible – which Qt5 can definitely do.

It's also quite possible that this has something to do with the fact that I'm linking statically and not dynamically at the moment; I seem to remember that having some influence at least on Linux regarding how an application looks in KDE and GNOME. Maybe it applies to Windows as well.

But like I said: this is a preview. I'd expect at least the beta to have this fixed, if not the alpha.
Cool, I was just wondering if it was a deliberate choice or just something for a future build. Thanks.

[huhn]

should MXF with jpeg2000 work with mkvmerge?

[Mosu]

Neither MXF nor JPEG 2000 are supported, and there are no plans whatsoever for it either.

[huhn]

Neither MXF nor JPEG 2000 are supported, and there are no plans whatsoever for it either.

thx for the answer.

[Atak_Snajpera]

Any plans for MP4 (HEVC) support in mkvmerge?

[Mosu]

Sure, but not short-term (more like medium-term); same for MPEG TS. See #995 (https://trac.bunkus.org/ticket/995) and #996 (https://trac.bunkus.org/ticket/996).

[Atak_Snajpera]

Sure, but not short-term (more like medium-term); same for MPEG TS. See #995 (https://trac.bunkus.org/ticket/995) and #996 (https://trac.bunkus.org/ticket/996).

oki doki :)

[Mangix]

having issues with the latest version. using a command line like "mkvextract tracks 1.mkv 1:1.wv" results in:

Error: Track 1 with the CodecID 'A_WAVPACK4' is missing the "codec private" element and cannot be extracted.

[Mosu]

Matroska and therefore mkvextract requires certain data to be present in CodecPrivate for WavPack. If it isn't then mkvextract cannot re-create it from thin air. Hence the error message.

[73ChargerFan]

Feature request: Assume a file is PCM audio if the extension is .pcm

Not sure if that'll work; initially mmg said it was "MPEG-4p10/AVC/h.265" . Mediainfo was able to determine stream 2 in m2ts file was PCM audio from a blu-ray, though it took a while. Maybe it was analyzing it.

Audio
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : PCM
Format settings, Endianness : Big
Format settings, Sign : Signed
Muxing mode : Blu-ray
Codec ID : 128
Duration : 1h 26mn
Bit rate mode : Constant
Bit rate : 1 536 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Stream size : 950 MiB (6%)


As a work around I re-extracted using eac3to to a .wav file and mmg accepted that. The .wav file was 68 bytes larger than the .pcm file. Header info?

eac3to v3.27
command line: eac3to 1) 3: "00003 - 3 - PCM, Undetermined, 2.0 channels, 16 bits, 48kHz.wav"
------------------------------------------------------------------------------
M2TS, 1 video track, 1 audio track, 1:26:28, 24p /1.001
1: Chapters, 9 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: RAW/PCM, Undetermined, 2.0 channels, 16 bits, 48kHz
[a03] Extracting audio track number 3...
[a03] Reading RAW/PCM...
[a03] Swapping endian...
[a03] Writing WAV...
[a03] Creating file "00003 - 3 - PCM, Undetermined, 2.0 channels, 16 bits, 48kHz.wav"...
[a03] The original audio track has a constant bit depth of 16 bits.
Video track 2 contains 124388 frames.
eac3to processing took 2 minutes, 40 seconds.
Done.

[sneaker_ger]

You can't really auto-detect raw PCM files because infos like sampling rate are missing and can't be trivially detected. You need the wav header or other container.

Reading PCM from transport streams is not yet supported in the 7.2.0 stable build but you can get a preview build that has support for it:
https://www.bunkus.org/videotools/mkvtoolnix/win32/pre/ (64 bit only)

If it's still misdetected file a bug report on the tracker and supply a sample.

[Mosu]

Feature request: Assume a file is PCM audio if the extension is .pcm

Nope, sorry. Raw PCM doesn't come with headers that contain the information necessary for further processing (number of channels, sampling frequency, sample size in bits, byte order, quantization type lik linear/a-law/µ-law…). I'd have to add additional command line switches, too, and users would have to set those. There are tons of tools out there that can do just that and convert a raw PCM file to WAV files. There's simply not enough need for mkvmerge to be able to do that, too.

[Mosu]

Reading PCM from transport streams is not yet supported in the 7.2.0 stable build but you can get a preview build that has support for it:
https://www.bunkus.org/videotools/mkvtoolnix/win32/pre/ (64 bit only)

If it's still misdetected file a bug report on the tracker and supply a sample.

Exactly this. The next release will contain that feature, too, of course. If you have files for which even the new builds don't detect your PCM tracks then please provide a sample and post about it in the original LPCM-in-TS ticket (https://trac.bunkus.org/ticket/763). Thanks.

[yonta]

mmg detects a raw pcm file as a mpeg4 part10/avc stream and even muxes it into .mkv file, which of course is not playable.
sample (https://drive.google.com/file/d/0B1mCVSSmbT2LRTZaTl9HOWp6UTQ/edit?usp=sharing)

[Mosu]

And as others have said: detecting raw PCM is pretty much impossible because it has no recognizable structure at all. I know that the h.264 code often leads to false positives regarding its detection, but that's simply because raw h.264 (pretty much every MPEG elementary stream) has crappy structure, too.

No, I won't change anything regarding this, sorry.

Edit: What I meant about reporting mis-detection issues was PCM-in-MPEG-TS/MPEG-PS, not raw PCM files.

[Simon88]

It would be great if you add GUI-based splitting for mkv using "common codecs" in your revised GUI? I find using avidemux rather un-reliable, and going back and forth to MKVToolNix after I record split locations to do the splitting.