MKVToolNix v24.0.0 released

[DragonQ]

@DragonQ: You might try VLC 2.1.2 or K-Lite Mega those two has worked great for me on problematic streams. For cutting of *.ts stream, Avidemux 2.6.7 works great for me as the MKV produced by it is fine, BUT I re-mux again using latest MKVTools, "just in case"..
Thanks for the suggestions but VLC does not play the MKV files correctly either (same issue: timestamps incorrect in places). TS-Doctor is surely not the problem as the issue happens with uncut files too. In any case, AVIDemux insta-crashes when I install it on Windows 8.1 x64.

[Simon88]

Thanks for the suggestions but VLC does not play the MKV files correctly either (same issue: timestamps incorrect in places). TS-Doctor is surely not the problem as the issue happens with uncut files too. In any case, AVIDemux insta-crashes when I install it on Windows 8.1 x64.

I'm using Win7 x64 and tested it on your file and it worked fine. Did you update to latest Avidemux v2.67?...

You can also process the files via commandline using latest ffmpeg or libav...

[DragonQ]

I'm using Win7 x64 and tested it on your file and it worked fine. Did you update to latest Avidemux v2.67?...

You can also process the files via commandline using latest ffmpeg or libav...
Never used AVIDemux before so yes I installed the latest v2.67. What do you mean "process the files"? All I want to do is mux them to MKV.

EDIT: If I use the following command on the sample TS file:

ffmpeg -i test.ts -c copy -map 0 test.mkv

I get these errors:

http://www.aotplaza.com/Files/HTPC/Samples/MKV%20Dodgy%20Timestamps%20ffmpeg.png

[Simon88]

@DragonQ: I usually just use Avidemux and snip the ends and then sometimes simply extract the main video and audio streams using ffmpeg, the reason is *.ts files can contain alot of "junk/filler" streams that just waste space. When all else fails I use VideoRedo TV Suite which has an excellent stream fixer and GOP slicer that I used in the old MPEG-1/2 days... but it is a commercial program and can fix many uncooperative files, including newer H.264/AAC/AC-3 files. You may give it a try, they have a trial version, but I recommend testing all new software in a virtual machine, as I use to always have to restore my system from an image backup when I start testing ALOT of trialware and some will screw everything up... I usually use/love ffmpeg as I can batch process a hundred files in a few hours without user intervention....

[73ChargerFan]

I've finally gotten around to archiving some TV recordings (1080i/25 AVC) from the past couple of months after being lax about it.
Had you done this months ago with an older version of mkvtoolnix? Do you think your problems because you updated it? Or is this the first time you've tried this?

If you think it might be the muxing, you might try the mkv muxer by Haali. I prefer mmg, but when I run into weird streams I try another muxer to see if it's the software or the video.

[73ChargerFan]

My C drive has only 20gb free. I just installed mkvtoolnix 6.7.0 64bit and it now muxes to my system drive instead of the target drive.

How can I disable this? v6.6.0 didn't do that. Took my half an hour to fix my computer after it completely filled my drive. I don't see anything in Options. It stored the file in:
C:\Program Files (x86)\MKVToolNix\j

[Mosu]

mkvmerge writes to where you tell it to write; in mmg you set this via the output file name. That output file name is suggested automatically by mmg based on the settings of the default output directory in the preferences.

I've just re-tested with 6.7.0 64bit and it writes exactly where I tell it to, be it a second hard drive, a USB flash drive or a connected network share.

[DragonQ]

Had you done this months ago with an older version of mkvtoolnix? Do you think your problems because you updated it? Or is this the first time you've tried this?
I updated when it said there was an update. As I said above this happens with v6.0.0 too so if a change broke things it must've happened a while back.

If you think it might be the muxing, you might try the mkv muxer by Haali. I prefer mmg, but when I run into weird streams I try another muxer to see if it's the software or the video.
Thanks for the tip, I just tried muxing it with Haali's MKV Muxer (dsmux.x64.exe) and the resulting MKV plays perfectly! It must be a bug with how MKVToolnix handles these TS files then. Can you look into this please Mosu using the sample I provided above?

[Mosu]

Not in the next two or three weeks; I currently have other priorities, sorry.

[73ChargerFan]

My bad. I tried to target the j:\ drive but missed the colon, so instead it targeted a subdirectory j in the program directory. The cascade of computer errors and the fact that I had just installed the new version led me to think it was a temporary location. Sorry.

[shinchiro]

How could I make mkvmerge show attachment's name in japanese or chinese when using -i option?

[Mosu]

My guess is that you're referring to the fact that the output of Unicode characters on Windows' cmd.exe is buggy. That's handled (and fixed) in ticket 971 (https://trac.bunkus.org/ticket/971). You have two options:

Download and use the new build mentioned in that ticket.
Redirect mkvmerge's output to a text file with the following two options: --redirect-output output.txt --output-charset UTF-8

Option 2 has the advantage of working with versions going back years.

[cihub]

I'm not sure whether this question have been asked previously, but how do you leave info about "Bits/(Pixel*Frame)" in Matroska after remuxing (MKVToolNix 6.5.0, 6.7.0)? When I mux H.264 from x264 and add AAC-HE, it gets stripped, but when I mux only video, or AC3, it stays there.

[Mosu]

You cannot. There's no header information for this.

What you see is MediaInfo estimating the bitrate based on the track size. However, MediaInfo can only do that if there's only a single track inside that file because in Matroska there's no header info about the track size either.

Therefore: Only one track -> MediaInfo uses the file size as an approximation for the track size -> MediaInfo calculates estimated bitrate based on the file's duration and the file's size.

[cihub]

Thank you for explanation, Mosu.

[shinchiro]

My guess is that you're referring to the fact that the output of Unicode characters on Windows' cmd.exe is buggy. That's handled (and fixed) in ticket 971 (https://trac.bunkus.org/ticket/971). You have two options:

Download and use the new build mentioned in that ticket.
Redirect mkvmerge's output to a text file with the following two options: --redirect-output output.txt --output-charset UTF-8

Option 2 has the advantage of working with versions going back years.

Thanks, Mosu. That's great. Tried with option 1 but it look like the japanese character turn to '???' so I used option 2 and it worked :p

[Sakura-chan]

Hi

Is there some sort of compression in Matroska for MPEG2 streams?

I've seen this happen with certain discs. The story goes like this. I have a DVD, 6.37 GB in size. I use MakeMKV on the main feature, the resulting MKV is 5.18 GB. It has an MPEG2 and an AC3 track. Then, because I want to add English subs, I remux that MKV and the subs with mkvtoolnix v6.6.0. But now the resulting MKV is only 3.93 GB.

What is going on? The bitrate of the movie is decreased, but everything is there. mkvmerge doesn't re-encode anything. I guess there must be some compression going on. But how can it be so strong to cut 1.25 GB of the MPEG2 track? Is there some kind of "garbage" or useless data in the frames of the MPEG2 stream?

Why MakeMKV's resulting file has a "logical" filesize given the source and mkvmerge remux is a lot smaller?

Extracting the MPEG2 tracks from both big and small MKVs results in .mpg files with sizes according to the original MKVs. So the stream doesn't go back to the original size. mkvmerge simple discards something in the mux.


This doesn't happen always. Or probably I haven't noticed before because I didn't stop to check the sizes of the MKVs. For now I've seen this with 3 PAL DVDs (French editions of Hideo Gosha's films). I made MKVs of other DVDs and didn't observe this drastic size reduction, just a little as always when making MKVs from DVDs.

Here's the info of the video tracks of both MKVs.

Original:

Video #1
ID : 1
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings, BVOP : No
Format settings, Matrix : Custom
Codec ID : V_MPEG2
Codec ID/Info : MPEG 1 or 2 Video
Duration : 1h 32mn
Bit rate mode : Variable
Bit rate : 7 703 Kbps
Maximum bit rate : 8 500 Kbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.743
Time code of first frame : 10:00:00:00
Time code source : Group of pictures header
Stream size : 4.96 GiB (96%)
Language : English
Default : No
Forced : No


Remuxed:

Video #1
ID : 1
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings, BVOP : No
Format settings, Matrix : Custom
Codec ID : V_MPEG2
Codec ID/Info : MPEG 1 or 2 Video
Duration : 1h 32mn
Bit rate mode : Variable
Bit rate : 5 808 Kbps
Maximum bit rate : 8 500 Kbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.560
Time code of first frame : 10:00:00:00
Time code source : Group of pictures header
Stream size : 3.74 GiB (95%)
Default : Yes
Forced : No


All in all, another great reason to store/backup movies in MKV, that's a nice (and lossless) file size cut :P

[Mangix]

I believe avi files are broken with mmg 64-bit under windows. I switched to the 32-bit version and could remux an avi file without running into error code 3.

[Mosu]

Thanks, Mosu. That's great. Tried with option 1 but it look like the japanese character turn to '???' so I used option 2 and it worked :p

Then your Windows version lacks support for Asian languages, or your cmd.exe uses a font that lacks those characters.

[Mosu]

I believe avi files are broken with mmg 64-bit under windows. I switched to the 32-bit version and could remux an avi file without running into error code 3.

Known and fixed. See https://trac.bunkus.org/wiki/Troubleshooting.

[Mosu]

Hi

Is there some sort of compression in Matroska for MPEG2 streams?

No. What you're most likely seeing is mkvmerge removing filler data. Various MPEG-based formats require certain storage (on a DVD) to have a minimum bitrate. Filler data is therefore inserted in order to achieve that minimum. This filler data is not required for decoding, it is complete garbage from the point of view of the decoding process. A decoder skips that data.

mkvmerge simply removes it. A Matroska file does not have a minimum bitrate.

Note that the actual video bitrate is unaffected by this removal. The video bitrate is the number of bits the actual encoded pictures use. That filler data only affects the whole stream's bitrate, which is highly misleading. If you have a video stream at 2Mbit/s then the quality will not be improved one iota by packaging it as a stream with a stream bitrate of 4Mbit/s.

[hello_hello]

I'm not sure when it happened.... I think I skipped a version or two and went from 6.4 to 6.7..... but I just wanted to say thanks. MKVMergeGUI no longer opens at a snail's pace running on my quad core PC. It used to take at least twice as long to open as it did running on my dual core. Now it opens nice and quickly regardless of the CPU. Sometimes, it's the little things.....

Thanks! (32 bit version, XP)

[Nexin]

Mosu using MKVmerge recently for splitting and audio image with added cue sheet.

MKVmerge
drop audio file - Mux to mka file - Remove audio file
Drop new muxed mka file - add cue file to it - close MKVmerge (To remove all cue file info, as there is no remove all here. Would be nice to have the option to do this with need to restart MKVmerge.)
Open MKVmerge - drop newer mka file and select Global then Splitting Mode

This is where I become stuck what to add for Split Parts By Timecodes which I guess will be the most exact way to split perfectly on INDEX 00:03:54 (now chapters). I have tried many ways yet unable to get it to split.

I have a suggestion wouldit be possible for MKVmerge to parse an mka file on load so automatically knows each chapter (from the now embedded cue file in mka). So when using Splitting and other MKVmerge features we see instead a list and able to select what chapters we like to be split and output.

I did get MKVmerge to work but it fails for what I needed as I though it would from the splitting name. I used the following..
Split Before Chapters
All
# [# of tracks to split]

As can guess the track splits weren't perfectly correct and erased those split files.

If you can see a way to make MKVmerge better to automatically parse each file or highlighted file on Input screen (after you implement this do tell if we need to highlight file in the upper or lower panel on Input for file to auto chapter parse)


Also the MKVmerge gui doesn't keep its screen position on restart. This is even with GUI maximise window set. With each new MKVmerge start the GUI has moved nearly all off the monitor screen
(1 gfx screen and 1 hardware monitor setup using xp3)

[hello_hello]

MKVmerge
drop audio file - Mux to mka file - Remove audio file
Drop new muxed mka file - add cue file to it - close MKVmerge (To remove all cue file info, as there is no remove all here. Would be nice to have the option to do this with need to restart MKVmerge.)
Open MKVmerge - drop newer mka file and select Global then Splitting Mode

The File/New menu doesn't open a new file or a new instance of MKVMergeGUI as I'd originally assumed it would. It clears everything.
At one stage I requested a "New" button be added to the bottom of the window. Maybe replacing the "copy to clipboard" button, which I suspect would be a likely winner if ever entered into a "least often used GUI button" competition. ;) Or maybe that's just me. A "manage jobs" button next to "add jobs" button might be handy too.


I did get MKVmerge to work but it fails for what I needed as I though it would from the splitting name. I used the following..
Split Before Chapters
All
# [# of tracks to split]

As can guess the track splits weren't perfectly correct and erased those split files.

I've not split files by chapters before so after reading your post I gave it a spin after muxing a multitrack flac file into an MKA, then again using multitrack MP3. Each time I included the corresponding cue file.
After muxing, opening the muxed file and splitting before chapter (all), the output files all contained a single chapter with a timecode of 00:00:00.000, so for me MKVMergeGUI split exactly at each chapter.
I'm using version 6.7.0 and XP.

[hello_hello]

MKVMergeGUI has an option to automatically use any audio delay included in the file's name if the delay amount follows the word "delay". For those who aren't aware it can do so, an example file name would be (as extracted by DGIndex):
"Audio T81 2_0ch 224Kbps DELAY 32ms"

Feature request:
When audio is extracted from an MKV using MKVCleaver, it looks something like this (it doesn't write the delay value):
Audio_Track01(EN).mp3
MKVExtractGUI does it like this (no audio delay written either)
Audio_track2_eng.mp3
MeGUI extracts the audio this way:
audio - [0] English 16ms
Although after requesting it be changed, Zather informed me the next MeGUI version would write the file names in a more MKVMergeGUI friendly manner.
audio - [0] English Delay 16ms

Given most programs write the language name (or two letter code) to the extracted audio, would it be possible for a future version of MKVMergeGUI to automatically apply the specified language when adding tracks? The same way it automatically applies the correct delay? MeGUI's muxers understand the format MeGUI uses for languages in file names and automatically applies them, so I'd assume it's not impossible. MKVMergeGUI already does so when opening MKVs if the streams within have a specified language and/or delay.

If the developers of the above software (and MKVMergeGUI) would care to get together one day, have a few drinks, tell a few jokes at the expense of other software developers, then settle down to the task of deciding on a common naming format each program will use when extracting, I'll buy the first couple of rounds. ;)

[Mosu]

Mosu using MKVmerge recently for splitting and audio image with added cue sheet.

This works as intended, just like hello_hello has written. Keep in mind that mkvmerge can only split before I frames, not at arbitrary positions (even though you can enter arbitrary timestamps). See the documentation (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.description.split).

To remove all cue file info, as there is no remove all here. Would be nice to have the option to do this with need to restart MKVmerge.

Use »File« -> »New«, that's what the function is there for: to start over as if you had re-started mmg. The »Remove all« button is intentionally different and keeps the content of a lot of controls in order to facilitate muxing several sets of files, e.g. several episodes of a series where you keep certain central things, one after each other.

I have a suggestion…

I'm in the middle of re-writing the GUI with a different toolkit (Qt instead of wxWidgets). Therefore the old GUI has reached its end of life; I won't spend any more time on it. I also don't accept feature requests for the new GUI yet.

[Mosu]

Given most programs write the language name (or two letter code) to the extracted audio…

No, and not for the reason that I'm currently re-writing the GUI. Read this FAQ entry (https://trac.bunkus.org/wiki/FAQ%3ADetectingTrackLanguageFromFilename) I've written about this very topic.

[hello_hello]

No, and not for the reason that I'm currently re-writing the GUI. Read this FAQ entry (https://trac.bunkus.org/wiki/FAQ%3ADetectingTrackLanguageFromFilename) I've written about this very topic.

That's disappointing..... and to be honest I'm not sure any of the reasons listed would necessarily be show stoppers. If I may....

If I wanted to detect full language names (e.g. "English") then how should Johnny English.srt or, even worse, The French Connection.srt be handled?
If I wanted to detect full language names it would be restricted to their English representations. But what if the file name contains a localized language name? In the following example the language would be "English" again, but the whole file name is in French: Le fabuleux destin d'Amélie Poulain (Anglais).srt
So we're back to short ISO-689 codes. Even if I only try to detect them at word boundaries there's a huge problem as some of those three-letter codes are actual words in certain languages. Let's take Le juge est une femme.srt Here est is the language code for Estonian.

MeGUI's muxers have used the language written to extracted streams for as long as I can remember. I tested it by changing the file name to a language like this:

Audio - [0] English 16ms
French - [0] English 16ms

Disappointingly it used English the first time and French the second, so it's not particularly clever. I'd be willing to bet the number of complaints regarding this behaviour in the MeGUI threads would be somewhere in the vicinity of none. Having said that.....

The word "Delay" preceding the delay value in the file name has been the secret handshake for applying a delay for as long as I can remember, yet file names can also contain numbers. Surely a similar secret handshake could be used for applying language names? A two/three letter code following, or surrounded by, characters which aren't likely to be otherwise combined in the same way?

Audio -[[En]]- Delay 16ms

I'd imagine you'd need set the standard.... be the one who decides on on the appropriate secret handshakes for MKVMerge, while the developers of encoder GUIs and extraction utilities etc would need to make their programs MKVMergeGUI friendly. If there's ever going to be a standard for this sort of thing, it's got to start somewhere. :)

Another problem occurs with files that can contain multiple tracks. Let's take Life of Brian (FRE).mkv as an example. What if there's one audio track and one subtitle track in that file? Which of those would FRE refer to?

Neither. Mostly, it's after extracting streams from their original containers it'd be handy to have languages and audio delays written to file names and automatically applied. Doing the same at the container level doesn't seem as important to me.
While I hadn't envisaged it, if a container contains more than one track, any language written to the file name would probably be best ignored. It's ignored currently so nothing would change there. If a container contains more than one stream, I'd expect the language specified for the streams to be applied as it currently is.
Maybe if a container only contains a single stream the language in the file name could be applied, but if the stream itself has a set language I'd probably expect it to take precedence. Or maybe in such a situation they could both be ignored... Whatever happens, the user would get used to the way it works.


The next problem is that detecting the language code is one thing. Making the user aware that mmg has tried to detect such a code is another matter entirely. If the language drop-down box is simply set accordingly then the user will only realize this if he clicks on all added tracks in turn. But he has to do that because it's such a frail mechanism that he has to verify the results.

When streams or files are opened by MKVMergeGUI for muxing, each stream is listed in the tracks section. Changing the text color of a stream which has been subjected to an automatic application of settings.... as long as the user is given some sort of "hey, something happened and you might want to check it warning".....
Mind you when currently opening an existing MKV I'd imagine most people know the individual tracks need to be checked unless they're confident they were set correctly in the first place.... sometimes you just need to check.
Even if the "general track options" area contained a single "default" button which for the selected track would automatically apply a particular language, default and forced track setting according to the users preference, it would probably reduce the need for clicking, scrolling and selecting by a considerable amount.

Anyway.... thanks for all the hard work on MKVToolNix. It's appreciated!

[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.

[Nexin]

Mosu using MKVmerge recently for splitting and audio image with added cue sheet.
This works as intended, just like hello_hello has written. Keep in mind that mkvmerge can only split before I frames, not at arbitrary positions (even though you can enter arbitrary timestamps). See the documentation (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.description.split).
Working with audio only with MKVmerge ATM.
No I frames unless audio also has I frames ?

Can MKVmerge split exact on cue sheet (chapter) Index marks or not ? If not will the new GUI be able to do so ?

Currently MKVmerge GUI Splitting feature has many options. I thought the 'Split by parts based on Timecodes' would be an exact precise split of the cue file Index points (chapters). Use of MKVmerge is for demux only with no audio file conversion. To demux and split precisely only at exact Index points using the embedded cue index (chapters).

To remove all cue file info, as there is no remove all here. Would be nice to have the option to do this with need to restart MKVmerge.
Use »File« -> »New«, that's what the function is there for: to start over as if you had re-started mmg. The »Remove all« button is intentionally different and keeps the content of a lot of controls in order to facilitate muxing several sets of files, e.g. several episodes of a series where you keep certain central things, one after each other.
Thanks the File-New option works as needed, I was looking for a GUI button to do the same.

I have a suggestion…
I'm in the middle of re-writing the GUI with a different toolkit (Qt instead of wxWidgets). Therefore the old GUI has reached its end of life; I won't spend any more time on it. I also don't accept feature requests for the new GUI yet.
Good news I didn't know you were working on a new GUI.

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

Looking forward to the new MKVmerge GUI features and options :)

[Mosu]

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.
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%3AImprovingPlaybackCompatibilityWithPlayers#Notusingcertainnewelementsinthecueswith--engageno_cue_durationand--engageno_cue_relative_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%3APlaybackDoesNotWorkVLCCannotSeekMkvmerge590 which boils down to the same options but gives more explanation.

[pepelugil]

See https://trac.bunkus.org/wiki/FAQ%3AImprovingPlaybackCompatibilityWithPlayers#Notusingcertainnewelementsinthecueswith--engageno_cue_durationand--engageno_cue_relative_position, the part about --engage no_cue_duration and --engage no_cue_relative_position in particular.

As sneakger_ger said; also read https://trac.bunkus.org/wiki/FAQ%3APlaybackDoesNotWorkVLCCannotSeekMkvmerge590 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 :):):)

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]

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]

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]

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]

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]

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.

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.

»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).

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]

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]

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.

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 :sly:

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.

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.

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