MKVToolNix v24.0.0 released

[Mosu]

Originally Posted by Nexin

Working with audio only with MKVmerge ATM.
No I frames unless audio also has I frames ?

Most audio formats are I frame only, but the old RealAudio do indeed have I and P frames – meaning you cannot start decoding at arbitrary frames but only from specific ones, same as for video in general. But for modern audio codecs it's true that all of their frames are decodable without any prior frame, and therefore mkvmerge can split before any of them.

Can MKVmerge split exact on cue sheet (chapter) Index marks or not ?

No. It can only split directly before a frame. For audio those frames are usually somewhere up to 40ms long (depending on the format and sampling parameters in question).

If not will the new GUI be able to do so ?

This has nothing to do with the GUIs. It's how mkvmerge works.

Will also the new GUI allow drag and drop for cue files. Current MKVmerge complains with 'File Identification Failed' when try to.

No, it won't. Again, this has nothing to do with the GUI but with mkvmerge. mkvmerge does not accept chapter files as input files; you have to pass them with "--chapters filename". Therefore the GUIs won't accept them when you drag such a file as an input file either.

[Nexin]

Thanks for your exact explanation Mosu, I will look elsewhere for what I need. Use your present and new GUI when need to contain some videos to use in other softwares'.



update:

It transpires that DVDV-A and DVD-A does not use cue sheet indexes but instead chapters. So splitting just before is ok as 40ms is small. Will try again and adjust where needed so correct.

Originally Posted by Mosu

It can only split directly before a frame. For audio those frames are usually somewhere up to 40ms long (depending on the format and sampling parameters in question).

Thankfully I can edit easily using cue sheets and have each audio track file name included. two files image and cue sheet a lot easier to store than many files.

Maybe also in time MKV itself updates so can parse chapters make life easier to use other options when needed.

[pepelugil]

Hi,

My standalone player doesn't correctly handle mkv generated with v5.9.0 and above: If I try to fast-forward, the mkv will stop playing. With v5.8.0 muxed mkv's there isn't this problem, and the only diference I've noticed is that while with v5.8.0 MediaInfo is this:

Format                                   : Matroska
Format version                           : Version 2

With newer versions is this one:

Format                                   : Matroska
Format version                           : Version 4 / Version 2

Is there any option or parameter in newer versions in order to force Version 2 only?

Thanks

[sneaker_ger]

See https://trac.bunkus.org/wiki/FAQ%3AI...ative_position, the part about --engage no_cue_duration and --engage no_cue_relative_position in particular.

[Chetwood]

What brand is that standalone?

[Mosu]

As sneakger_ger said; also read https://trac.bunkus.org/wiki/FAQ%3AP...eekMkvmerge590 which boils down to the same options but gives more explanation.

[pepelugil]

Originally Posted by sneaker_ger

See https://trac.bunkus.org/wiki/FAQ%3AI...ative_position, the part about --engage no_cue_duration and --engage no_cue_relative_position in particular.

Originally Posted by Mosu

As sneakger_ger said; also read https://trac.bunkus.org/wiki/FAQ%3AP...eekMkvmerge590 which boils down to the same options but gives more explanation.

Thanks that was it, adding --engage no_cue_duration and --engage no_cue_relative_position did the trick

Originally Posted by Chetwood

What brand is that standalone?

It's a Cambridge Audio azur 651BD with the lastest firmware available from May 2012.

[Chetwood]

I was afraid something like this might happen so I immediately added this parameters to my encodes to make sure they run on my WDTV. Never even tried it without

[hello_hello]

Originally Posted by Mosu

You may, but you won't change my mind, and I can live perfectly fine with your disappointment. I'm also pretty sure that the amount of time such a feature would have saved you doesn't even equal the time you've spent writing this post.

Oh well.... although I'm fairly sure I'll survive knowing how incorrect your assumption is.

I did play around with GDSMuxer and discovered it automatically defaults to English (or the default OS language, I assume) after adding individual streams without the world ending as a result, but it's not MKVMergeGUI.

A bit of messing around with command lines seemed to allow me to set the defaults I want for each track by adding the following to the "user defined options" for each one, allowing me to bypass the General Track Options tab most of the time (hopefully). Unless I need to change something, it's much faster than playing with drop down boxes to change each setting for each track individually.

--language <TID>:eng --track-name <TID>: --default-track <TID>:yes --forced-track <TID>:no

Currently I've added it to my clipboard manager for easy copying and pasting, but when I get a chance I'll have a play with the macro program. With any luck I might be able to automate the process a bit more.

Any way to coax MKVMergeGUI into opening with the "Extra options" tab selected rather than defaulting to the "General track options" tab?

[Mosu]

Originally Posted by hello_hello

Any way to coax MKVMergeGUI into opening with the "Extra options" tab selected rather than defaulting to the "General track options" tab?

No, there isn't. At least none that I know of. Maybe you could try to use something like AutoIt or other similar macro processing tools for emulating a click at the proper coordinates.

[Chetwood]

Using coordinates is a tedious approach due to people's varying screen resolutions and MMG window sizes. Far better is simulating keypresses which would however require keyboard shortcuts still missing from mmg like CTRL-A to Add to job queue. IMHO, AutoIt is a clumsy workaround for features that MKVToolnix should have. We've talked about this: having mmg play a sound when it's done or shutting down the machine (especially after working through a long job queue) should be standard these days. And if it's not feasible somehow due to MKVToolnix being multi OS, calling up an autoexec.bat in the MKVToolnix folder after each encode/finished queue would let people create their own actions.

[Mosu]

Originally Posted by Chetwood

keyboard shortcuts still missing from mmg like CTRL-A to Add to job queue.

There is such a shortcut, Alt+A. It works just fine on Linux and I haven't figured out why it refuses to work on Windows. That's only one of the reasons why I'm re-writing the GUI with a different toolkit…

We've talked about this: having mmg play a sound

Which I consider one of the worst features a program can have. I usually listen to music, my music player is at a volume I'm comfortable with, and then all of a sudden program XYZ blares out some arbitrary sound file at full volume? No thank you. The first thing after unpacking act3to, for example, is to delete all the .wav files in its directory in order to prevent this.

I realize different users have different needs, and that there are those like you that rather like such a feature. But I'm also not in the business of implementing each and every one of user's wishes. I wouldn't get anywhere if I were, and me doing this program must always be balanced around me having fun, too, because as soon as it drifts over into the realm of »it's all work that I don't like« then this will be detrimental to my long-term commitment to MKVToolNix.

However, as I've said above I'm currently re-writing the GUI with a different toolkit (Qt instead of wxWidgets). There's a multitude of reasons for that decision, and I will write a probably rather lengthy blog or wiki post about the why, how and when of that transition. The point is that on my TODO list (or at least on my »ideas for the new GUI« list) there is an item called »user-configurable job actions«. The long-term vision for this feature is to leverage Qt's own QtScript language (which is pretty much JavaScript) and allowing the user to write his/her own snippets in that language that will be executed on different events: before a job is started, after it has been completed, after all jobs have been completed etc. The short-term goal would be to simply allow this code to execute external applications. The long-term goal would be to have a tighter integration allowing the manipulation of the job files from within that script before the job is executed.

This kind of interface would definitely allow you to play sounds (via external programs), shut down the computer, send emails upon completion (again via external programs – I don't plan an implementing SMTP clients into the GUI) etc. Yes, it would be more work for you than simply ticking a checkbox in the preferences, but it would also be so much more flexible than such a checkbox would be. And it would save you from me saying »no I don't want that feature«

Yes, it's far off, but me re-writing the GUI is also the reason for my next sentence: I'm sorry, but there won't any more work on mmg safe for critical bug fixes. Definitely not new features, and highly unlikely bug fixes for cosmetic/unimportant/very hard to reproduce bugs.

And if it's not feasible somehow due to MKVToolnix being multi OS

My refusal for playing sounds is mostly based upon the reason stated above. Being multi OS with a crappy toolkit (wxWidgets) plays its part, too, but that wouldn't be a concern for Qt as Qt comes with a nice multi-platform multimedia framework (Phonon). Anyway, with the QtScript-based actions outlined above those concerns would be moot. This feature would be available on all platforms, and it would simply be up the user to select the external mechanisms suitable for him/her.

Ideas? Use dbus for desktop notifications on Linux. Use "shutdown /t now" on Windows. Send and email with "mail done | joe@user.org'' on Linux. Use Mac OS desktop notifications via growl.

[nautilus7]

Mosu, mkvmerge has some issues when reading mpls files.

I 've come across several Blu-ray discs (bbc's documentaries especially) that mkvmerge can't detect correctly all the tracks (video, audio, subs) because the playlist contains 2 or more m2ts files with different kinds of tracks. Look at the sample (bbc blu-ray.rar) which I have already uploaded to your ftp server.

LAV filters can playback such mpls files correctly, if that helps.

[Mosu]

MPLS referring to M2TS files with different tracks are not supported and most likely never will be. Those M2TS files have to be handled the same way as appending files has to be, which means that all track types and track parameters (codec, sampling frequency etc) will have to be the same.

Now for appending files normally mmg (and by extension mkvmerge) allow you to tell them which tracks should be appended to which other tracks – meaning you can fix that manually. I know that this is currently not possible for MPLS files. I've thought about this when I re-designed the MPLS support (changed from treating the M2TS as »additional parts« to »appended files«), but I figured that it would be a staggering amount of work to implement this properly both in mkvmerge and the GUI.

That's the reason it's currently simply unsupported and will most likely stay that way at least for a long time (if not forever).

[nautilus7]

I see. Thanks.

EDIT: so, I decided to load just the main m2ts file that is referenced in such mpls, but audio is not detected. Is that because it's pcm audio?

[hello_hello]

Originally Posted by Chetwood

Using coordinates is a tedious approach due to people's varying screen resolutions and MMG window sizes. Far better is simulating keypresses which would however require keyboard shortcuts still missing from mmg like CTRL-A to Add to job queue. IMHO, AutoIt is a clumsy workaround for features that MKVToolnix should have. We've talked about this: having mmg play a sound when it's done or shutting down the machine (especially after working through a long job queue) should be standard these days. And if it's not feasible somehow due to MKVToolnix being multi OS, calling up an autoexec.bat in the MKVToolnix folder after each encode/finished queue would let people create their own actions.

I must admit, I'm not a fan of software which goes "ding" myself, but if it can be enabled/disabled..... each to their own.
TSMuxer.... why can't it remember the "play sound" choice from the last time it ran?

I didn't bother with anything too clever in the end. I have AutoHotKey set to type a commandline for me. I only use two variations 99.999% of the time. English/Default Yes/Forced No, or the same with default=no instead.

Now it's a two handed operation.....
Click on a track, click on the user options area, tap a couple of keys with the other hand to activate adding the commandline line, select the next track.....

I could probably automate the process a little more, but I'll see how that goes first.

[Chetwood]

Originally Posted by Mosu

Which I consider one of the worst features a program can have. I usually listen to music, my music player is at a volume I'm comfortable with, and then all of a sudden program XYZ blares out some arbitrary sound file at full volume?

Wow?! Not everyone listens to music during work (or is sitting at the computer/in the same room the job queue is running on/in), the file selected isn't abitrary and as such could be recorded to lower volume but most importanty: it's an OPTION! And unlike header compression back then it would not be set to on by default.

Originally Posted by Mosu

I realize different users have different needs, and that there are those like you that rather like such a feature. But I'm also not in the business of implementing each and every one of user's wishes.

We know, you've made that abundantly clear on several occasions, just recently towards hello_hello.

Originally Posted by Mosu

»user-configurable job actions«. The long-term vision for this feature is to leverage Qt's own QtScript language (which is pretty much JavaScript) and allowing the user to write his/her own snippets in that language that will be executed on different events: before a job is started, after it has been completed, after all jobs have been completed etc.

While overkill for my needs (and probably everyone else's who's not too fond of getting into scripting) it sounds quite flexible and promising (but given your preferences unfortunately also way, way off in the future).

Originally Posted by Mosu

Use "shutdown /t now" on Windows.

Sure but how to do this right now? Currently I have to run AutoIt to periodically poll for MKVToolnix's "mkvmerge has finished" window in the background which does not work properly and is a crutch anyway. That's why I suggested for you to make the current version of mmg execute the file "autoexec.bat" (or whatever) from the MKVToolnix folder. Upon installation it's an empty file and nothing happens on execution (or missing file) but the user can put "shutdown /t now" (or somthing similar for Linux/Mac) or whatever into this.

I totally get that you don't want to lose your fun of working on MKVToolnix but I also think that adding this simple function to the current code would be worth the effort, if only to get people pestering you about the release date of the new GUI off your back

[Mosu]

Originally Posted by Chetwood

Wow?! Not everyone listens to music during work

And I did acknowledge other people's different uses and preferences, so what's your point?

We know, you've made that abundantly clear on several occasions, just recently towards hello_hello.

You know, it cuts both ways. As the sole developer of MKVToolNix I get receive a neverending stream of feature requests. On the other hand I rarely receive a patch by someone implementing a certain feature or fixing a bug. And users such as yourself come across as being somewhat entitled to feature XYZ and that I must be the one implementing it. I'm definitely not saying that's your intention or motivation! Just that I perceive your wording to inflect it. »It's just an option; not a lot of work; just do this and that and that will be enough«. To be honest, it's quite discouraging, because it makes me feel that how many features I ever implement, no matter how much time and effort I put into this piece of free software, it will never be enough, because there's always some feedback à la »this is not enough; I don't understand why you don't implement this and that; I need it NOW or not at all«.

Again, I'm not clairvoyant; I don't know your thoughts and I'm not making any judgement on your character. This is just how it comes across to me.

Several solutions you propose may be enough for you and your unique situation, but I have to think about all users whenever I implement a feature. I also have to keep in mind any previous feature request that might be affected by such a feature. Let's take your autoexec.bat example.

You proposed:

That's why I suggested for you to make the current version of mmg execute the file "autoexec.bat" (or whatever) from the MKVToolnix folder. Upon installation it's an empty file and nothing happens on execution (or missing file) but the user can put "shutdown /t now" (or somthing similar for Linux/Mac) or whatever into this.

Now when would I execute this file? For the shutdown case it would have to be either at the end of the job queue (when running the job queue) or at the end of the currently running muxing job (when not running the job queue). However, I've had feature requests for doing stuff at the end of the job queue but not when you're muxing the current settings. So we'd need two different files for that already.

Another feature request I've received in the past is being able to do stuff to the output file after it's been muxed, e.g. move it to a different drive/folder. This would require running such an autoexec.bat after each job has finished, no matter if its the current job or one from the job queue. However, that would make such a file unusable for the shutdown case because maybe you want the whole job queue processed and shutdown afterwards, not after the first file. And moving the file to a different output folder may depend on the exit status: if there were warnings then move to a folder requiring user intervention later; if there were no warnings then simply move it to the archive. So we'd need some kind of parameter passing. That would have to be flexible enough to be extensible in the future (because I may want to expand on the capabilities without braking compatibility). Even more stuff to think about and more time to spend.

but I also think that adding this simple function to the current code would be worth the effort, if only to get people pestering you about the release date of the new GUI off your back

You're quite wrong. It would get you off my back, but not the other users asking for features. There will never be a point where I can safely say »now all wishes have been fulfilled and I can go work on the new GUI«. It's simply unrealistic. As my time is limited I've elected to stop working on mmg completely; anything else is untenable for me. It wouldn't benefit you much either. For example, if I decided to implement features X, Y and Z from users A, B and C which aren't you then that would move the new GUI into the future even more delaying the features I've laid out in my previous post even more. So implementing your feature request delays work for everyone else.

It's simply not a clear case of »why don't you implement XYZ, nothing depends on it«.

[Chetwood]

Originally Posted by Mosu

And I did acknowledge other people's different uses and preferences, so what's your point?

That's what I was wondering. Why raise points (that could easily be countered) when you acknowledge other people's preferences which renders those points moot anyway? Moving on.

Originally Posted by Mosu

This is just how it comes across to me.

Well, then I have to say I'm sorry cause that wasn't my intention. I must admit though that your brisk way of dealing with requests and criticism (again, header compression) seems to provoke a different tone sometimes

Originally Posted by Mosu

Now when would I execute this file?

After the job queue is done is what I had in mind. This would keep it simple and therefore live up to my naive idea of being a "1-liner" job with no ramifications for your workload or other/requested features (I'm no coder though). Initially I thought about suggesting jobdone.bat and queuedone.bat (to be executed only after a return code of 0) but I realized that would probably strike you as a programmer less than elegant.

Originally Posted by Mosu

So we'd need some kind of parameter passing. That would have to be flexible enough to be extensible in the future (because I may want to expand on the capabilities without braking compatibility).

I get that. Implementing these feature requests requires careful planning (you don't have time for ATM) but I think you'll get this covered eventually with the scripting approach you mentioned. And of course, any negative side effects of people's inability to properly use that function would be their sole responsibility: "use at your own risk!". Still, while you're working on the new GUI, you might wanna add some extra space for future checkboxes ("shutdown after queue") next to "abort current job" in the mkvmerge is running queue window.

Originally Posted by Mosu

So implementing your feature request delays work for everyone else.

Obviously, and of course it's your decision what to implement next, whether it's the latest "tweak" to the MKV standard like no_cue_duration or the handling of new codecs. I, however, always found MKVToolnix to be lacking in the notification department (play sound or do whatever when done) we've come to expect from software over the years and I just thought that fixing this might benefit users more than an MKV feature that we've done fine without so far and that most likely will take standalone manufacturers forever to implement. But that's just me.

Still, I appreciate you taking time to explain this rather than shrugging it off. Thanks.

[Selur]

@Mosu: got an mp4 file here which was captured with VLC and where MediaInfo reports:

General
Complete name                            : f:\asynch after remux_vlcCapture.mp4
Format                                   : MPEG-4
Format profile                           : Base Media
Codec ID                                 : isom
File size                                : 105 MiB
Duration                                 : 13mn 30s
Overall bit rate mode                    : Variable
Overall bit rate                         : 1 092 Kbps
Encoded date                             : UTC 2012-12-18 20:00:04
Tagged date                              : UTC 2012-12-18 20:00:04
Writing application                      : vlc 2.0.4 stream output
Comment                                  : QuickTime 6.0 or greater

Video
ID                                       : 2
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L3.0
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 4 frames
Codec ID                                 : avc1
Codec ID/Info                            : Advanced Video Coding
Duration                                 : 13mn 28s
Source duration                          : 13mn 28s
Bit rate                                 : 1 024 Kbps
Width                                    : 720 pixels
Height                                   : 576 pixels
Display aspect ratio                     : 4:3
Frame rate mode                          : Variable
Frame rate                               : 25.000 fps
Minimum frame rate                       : 8.342 fps
Maximum frame rate                       : 25.025 fps
Standard                                 : PAL
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.099
Stream size                              : 98.7 MiB (94%)
Source stream size                       : 98.7 MiB (94%)
Language                                 : English
Encoded date                             : UTC 2012-12-18 20:00:04
Tagged date                              : UTC 2012-12-18 20:00:04
mdhd_Duration                            : 808599

Audio
ID                                       : 1
Format                                   : AAC
Format/Info                              : Advanced Audio Codec
Format profile                           : HE-AAC / LC
Codec ID                                 : 40
Duration                                 : 13mn 30s
Source duration                          : 13mn 30s
Bit rate mode                            : Variable
Bit rate                                 : 64.0 Kbps
Maximum bit rate                         : 99.7 Kbps
Channel(s)                               : 2 channels
Channel positions                        : Front: L R
Sampling rate                            : 44.1 KHz / 22.05 KHz
Compression mode                         : Lossy
Stream size                              : 6.18 MiB (6%)
Source stream size                       : 6.18 MiB (6%)
Language                                 : English
Encoded date                             : UTC 2012-12-18 20:00:04
Tagged date                              : UTC 2012-12-18 20:00:04
mdhd_Duration                            : 810422

Playback of the original file works fine, but if I remux it to mkv using mkvmerge the file is totally async.
Issue isn't that important to me, just thought you might want to know about potentially problematic mp4 files.
-> if you want I can upload the file to your ftp.

Cu Selur