MKVToolNix v24.0.0 released

[Mosu]

Remuxing was preferred in the past because there were known problems with the header editor (and mkvpropedit as both use the same code for modifying the files) that could lead to file corruption. However, those bugs have long been ironed out, and I haven't received a single report about problems in that area for quite some time yet. Therefore I'd say "go for it and use the header editor".

[sneaker_ger]

Good to know, thought it had something to do with fragmentation or similar.
Any comment on my question (and b66pak's report) about audio timecodes?

[Mosu]

Fragmentation? I don't remember such an argument. The resulting files are 100% spec compliant, and as all header info is always referred to frame a seekhead entry at the start of the file playback should not suffer at all (the only exception is if you want to stream the resulting file over a non-seekable channel).

[Mosu]

About the timecodes: You're partially right. mkvmerge recalculates timecodes for some audio codecs but not for others. The ultimate goal is to re-use existing source container timecodes though.

[sneaker_ger]

Fragmentation? I don't remember such an argument. The resulting files are 100% spec compliant, and as all header info is always referred to frame a seekhead entry at the start of the file playback should not suffer at all (the only exception is if you want to stream the resulting file over a non-seekable channel).

I see.

About the timecodes: You're partially right. mkvmerge recalculates timecodes for some audio codecs but not for others. The ultimate goal is to re-use existing source container timecodes though.

I asked after some tests I made to help out in this thread (http://forum.doom9.org/showthread.php?t=160596). (no need to read everything)

He had sync issues after re-encoding video, but copying audio straight from mkv->mkv with mkvmerge, so I at first thought it was the video timecodes not being copied correctly, but the problem still persisted. You can download the timecodes in the last post by the thread starter. It has gaps in the timecodes (some timecodes being very large) and those gaps didn't make it through mkvmerge.
Also mkvmerge screws up, if you manually edited the first timecode to say 10ms, which really put me off. I tested AC3 IIRC.

[Mosu]

I know that re-calculating timecodes poses problems. Like I said, it's on my TODO list.

[sneaker_ger]

Ok, just making sure we're talking about the same thing. When you find the time to implement it, it would be nice to have an option in mmg to force recalculation (like it can be done with video tracks by specifying fps).

[Mosu]

You'll have to use a timecode file for that. Or extract before and merge the extracted version. Such a feature would be interesting to a very few users and uses cases only, therefore most likely no extra option.

[Thunderbolt8]

Remuxing was preferred in the past because there were known problems with the header editor (and mkvpropedit as both use the same code for modifying the files) that could lead to file corruption. However, those bugs have long been ironed out, and I haven't received a single report about problems in that area for quite some time yet. Therefore I'd say "go for it and use the header editor".
is the only important criteria here the age of the mkvtoolnix version I use to edit the header? or does the mkvtoolnix version with which the according .mkv file has been created also play a role?

[robpdotcom]

I've used the header editor to rename tracks, titles, change default/forced flags, etc on at least 100 DVD and Bluray rips - never had a single problem.

If you have any doubts, just copy the file before using the editor.

[Mosu]

is the only important criteria here the age of the mkvtoolnix version I use to edit the header? or does the mkvtoolnix version with which the according .mkv file has been created also play a role?

Only the version you are editing with is relevant.

[Lighto]

Is it just me or is the mmg.exe in the mkvtoolnix 4.7.0 package meant for 4.6.0?

Edit: seems like some left over registry/temp file messed it up. it's working now.

[Mosu]

So far you're the only one reporting such a problem (even though I don't even know what your problem actually is).

[Superb]

A friend sent me a patch to fix negative delay parsing for idx/sub:
http://www.sendspace.com/file/5xk2at
Could you take a look at it and possibly integrate it to the next official version?

[Mosu]

Can you provide a sample file, please? The modifications are not that straight-forward that I want to simply apply it as it is.

[b66pak]

So far you're the only one reporting such a problem (even though I don't even know what your problem actually is).

hi,


i use the windows portable versions of mkvtoolnix...after running 4.7.0 for the first time some registry entries are done (mkvmerge_executable)...this will mark the path to mkvmerge in 4.7.0 folder...when run an old mkvtoolnix a warnig will pop up...this ruin the portability...
_

[sneaker_ger]

i use the windows portable versions of mkvtoolnix...after running 4.7.0 for the first time some registry entries are done (mkvmerge_executable)...this will mark the path to mkvmerge in 4.7.0 folder...when run an old mkvtoolnix a warnig will pop up...this ruin the portability...
_

The toolkit I use (wxWidgets) uses the registry automatically on Windows and INI files on other systems. Patches are welcome to change that (you can request the toolkit to use an INI file instead even on Windows), but those patches would have to provide a migration path as well.

5chars

[allouh]

Never mind

[Mosu]

Even though allouh figured it out before I could answer I think the answer may be interesting to more than one user. Therefore this was was his question:

Is there a way to use MKVtoolnix under linux without installation?
I mean i only have access to linux console without root privilege, so is there a compiled version that i can use?

You have two options:

1. Use the "--prefix" option of configure to redirect the installation into a sub directory of your home directory:

./configure --prefix=$HOME/opt/mkvtoolnix
drake
drake install

2. Don't install at all and execute directly from the source code directory. As a matter of fact mkvmerge doesn't need anything on Linux to be installed in the location figured out by the configure script. The only drawback you get is that it won't find its translation files resulting in English-only programs.

[Mosu]

A friend sent me a patch to fix negative delay parsing for idx/sub:
http://www.sendspace.com/file/5xk2at
Could you take a look at it and possibly integrate it to the next official version?

I've applied the patch with some minor adjustments.

[Mosu]

i use the windows portable versions of mkvtoolnix...after running 4.7.0 for the first time some registry entries are done (mkvmerge_executable)...this will mark the path to mkvmerge in 4.7.0 folder...when run an old mkvtoolnix a warnig will pop up...this ruin the portability...
_

I've fixed this for the next release. As long as you don't select a specific mkvmerge.exe via "Preferences -> mkvmerge -> browse..." mmg will not replace "mkvmerge" with its full path when it saves the registry settings.

[Mosu]

Hey,

I’ve released mkvtoolnix v4.8.0. It’s mostly a bug fix release with few new features.

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-4.8.0.tar.bz2

...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.8.0-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.8.0.7z

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 4.7.0:

2011-05-23 Moritz Bunkus <moritz@bunkus.org>
* Released v4.8.0.
* mmg: bug fix (Windows): mmg will no longer convert the "mkvmerge executable" from just "mkvmerge" into a full path name when writing its preferences to the registry upon existing.
* mkvmerge: enhancement: Added support for VobSub IDX files with negative "delay" fields.

2011-05-11 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The 'doc type read version' EBML header field is only set to 2 even if a stereo mode other than 'none' is used for at least one video track. Fix for bug 625 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=625).

2011-05-06 Moritz Bunkus <moritz@bunkus.org>
* mkvpropedit: new feature: Added support for adding, replacing and removing chapters.

2011-05-03 Moritz Bunkus <moritz@bunkus.org>
* All: Avoided a segmentation fault in gcc by not including a pre-compiled header if FLAC or CURL support is disabled.
* mkvmerge: bug fix: Reading DTS files stored in 14-to-16 mode were read partially.

2011-04-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: mkvmerge will rederive frame types for VC1 video tracks stored in Matroska files instead of relying on the container information. This fixes files created by e.g. MakeMKV that mark all frames as key frames even if they aren't.

2011-04-26 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed detection of AAC files with ADIF headers. Fix for bug 626 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=626).

2011-04-25 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The 'doc type version' and 'doc type read version' EBML header fields are only set to 3 if a stereo mode other than 'none' is used for at least one video track. Fix for bug 625 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=625).
* mkvmerge: enhancement: File identification for tracks read from Matroska files with a codec ID of "A_MS/ACM" will show the track's format tag field if it is unknown to mkvmerge. Implements bug 624 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=624).

2011-04-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Track, tag and attachment selection via --audio-tracks, --video-tracks etc. can have their meaning reversed by prefixing the list of IDs with "!". If it is then mkvmerge will copy all tracks/tags/attachments but the ones with the IDs given to the option (e.g. "--attachments !3,6").
* mkvmerge: bug fix: Fixed handling AVIs with AAC audio format tag 0x706d and bogus private data size. Fix for bug 623 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=623).

Have fun.

[SamuriHL]

Thanks, Mosu. It keeps getting better and better with every version.

[b66pak]

thanks a lot...
_

[allouh]

You have two options:

1. Use the "--prefix" option of configure to redirect the installation into a sub directory of your home directory:

./configure --prefix=$HOME/opt/mkvtoolnix
drake
drake install

2. Don't install at all and execute directly from the source code directory. As a matter of fact mkvmerge doesn't need anything on Linux to be installed in the location figured out by the configure script. The only drawback you get is that it won't find its translation files resulting in English-only programs.

It's not that i figured it out this way, i just looked for a compiled copy to use.
For once, i just extracted the files from the binary file(deb) and tried to run them, but unfortunately i got the error message
-bash: line 55: ./mkvextract: cannot execute binary file
Also i tried a compiled copy that is prepared to run on WDTV, but i got the same error message above.
So i think i don't have the privilege to execute such files!
After this i gave up hope.

Return to your suggestion:
I tried configure the way you suggested but it got interrupted by missing ogg library.
Tried to install this library the same way, it succeeded but configure for MKVtoolnix still got interrupted by missing the very same library.

Do you think there is a way for me to run MKVtoolnex (specially MKVextract)?

[Mosu]

It's not that i figured it out this way, i just looked for a compiled copy to use.
For once, i just extracted the files from the binary file(deb) and tried to run them, but unfortunately i got the error message
-bash: line 55: ./mkvextract: cannot execute binary file

This means you're probably trying to execute a 32bit binary on a 64bit system without having installed support for 32bit libraries & executables, or you're executing a 64bit binary on a 32bit system (which will never work).

I tried configure the way you suggested but it got interrupted by missing ogg library.
Tried to install this library the same way, it succeeded but configure for MKVtoolnix still got interrupted by missing the very same library.

Do you think there is a way for me to run MKVtoolnex (specially MKVextract)?

Sure, but you'll have to be prepared to compile more than just libogg as well. Basically you should install everything into a prefix, e.g. $HOME/opt. Then you'll have to tell the various configure scripts of the libraries and mkvtoolnix where to find the libraries you've just compiled. This is often done via environment variables:

export CFLAGS=-I$HOME/opt/include
export CXXFLAGS=-I$HOME/opt/include
export LDFLAGS=-L$HOME/opt/lib
./configure --prefix=$HOME/opt


For boost this is a bit different.

You can get some hints from the section "2.3 Manual installation" from the file README.Windows.txt. Even though it explains how to compile all the libs for Windows with a mingw cross compiler it also deals with having all the libs in such a prefix directory and telling the configure scripts where to find them.

[Mosu]

remuxing mkv with h264+dts (for adding new tracks or subs) results in a +11ms delay for the dts track:

I've verified and fixed this in the following pre build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.8.0-build20110526-339-setup.exe

I've also checked whether or not the audio packetizers preserve source timecodes. The DTS packetizer obviously had some problems. The AAC and AC3 packetizers already did preserve timecodes.

If you find that some packetizers don't preserve timecodes and always recalculate then please let me know.

[allouh]

Thank you Mosu
This worked for everything except boost.
With Boost there's been a new problem arose; I'm only limited to 27k files on the server space i have, which is less than the files in the Boost 1.46 archive.
So I've been trying for a day with boost 1.36 (which contains less files), but i didn't succeed.
Also i tried the 64bit binary files from deb file, and they run but they asked for the dependencies.
So i think my other option is to have a compiled 64bit version like the one i got for WDTV from here (http://forum.wdlxtv.com/viewtopic.php?f=40&t=568&start=20#p11162)!
Do you think this is possible Muse?
I know my problem is becoming more of a linux problem and this is not the place for it, so i appreciate any help here before i go into the hard way.

[Mosu]

Which Linux distro, version and architecture is your server using?

[allouh]

Which Linux distro, version and architecture is your server using?
I wasn't informed of these, but by running some script (http://moustix.dyndns.org/fred/index.php/2006/06/17/5-script-to-return-the-linux-distribution-version-and-architecture) i found i get:
Debian release 5.0.8 on x86_64 (2.6.34.6-xxxx-grs-ipv6-64)
And by running "cat /proc/version" command i get
Linux version 2.6.34.6-xxxx-grs-ipv6-64 (root@kernel-64.ovh.net) (gcc version 4.3.2 (Debian 4.3.2-1.1) ) #3 SMP Fri Sep 17 16:06:38 UTC 2010

[Mosu]

Debian 5.0 is Lenny. I'm sorry, but I don't provide binaries for Lenny anymore as the Boost version contained in Lenny is too old.

[allouh]

Debian 5.0 is Lenny. I'm sorry, but I don't provide binaries for Lenny anymore as the Boost version contained in Lenny is too old.
Does this mean i can't run mkvextract(because this is the only executable i need) unless i move to new distribution?
Or is there a workaround for this.
Even with an old version of mkvtooldnix, can't this be possible?

[Mosu]

Old versions of mkvtoolnix are still available, both in source code and in binary form. For Debian Lenny the last package I provided was for version 4.5.0. It is still available for download: http://www.bunkus.org/debian/lenny/binary/amd64/mkvtoolnix_4.5.0_amd64.deb

You can try to extract its content without installing it (if you don't have root access) with dpkg-deb.

[Abradoks]

Hi, Mosu!
I've finally managed to build mkvtoolnix with MinGW, but here are some questions.
1) Have you tried to compile gui with wxWidgets 2.9?
When I tried I've ended up with errors on startup and menu bar disapeared.
2) Why are you using threading=single when building boost? Could there be any issues with mt version?
3) Have you intentionally commented out "m4_include(ac/ebml.m4)" and "m4_include(ac/matroska.m4)" in configure.in?
4) What do I need to run scripts from ./tests?
5) Is it possible to update avilib?
Currently I have to add _Pragma ("GCC optimize \"0\"") into avilib.c to get mkvmerge work with avi files. I've tested it with gcc 4.5.2 -O3/-O2 and 4.5.0 -O3 and every time mkvmerge hanged with 100% CPU usage. Also it needs needs -D__USE_MINGW_ANSI_STDIO=1 on MinGW.
6) Actually, there are more issues with 4.5.2. Without --disable-precompiled-headers it miscompiles mkvmerge so it crashes when trying to mux from mkv. Here is backtrace, in case it helps:
#0 0x006ff8ac in __cxa_throw ()
#1 0x004b4df0 in mm_io_c::read_uint32_be (this=0x3eadd8)
at src/common/mm_io.cpp:541
#2 0x004ce5de in kax_file_c::resync_to_level1_element_internal (
this=0x3eae68, wanted_id=524531317) at src/common/kax_file.cpp:162
#3 0x004ce4f2 in kax_file_c::resync_to_level1_element (this=0x3eae68,
wanted_id=524531317) at src/common/kax_file.cpp:149
#4 0x004cddf7 in kax_file_c::read_next_level1_element_internal (
this=0x3eae68, wanted_id=524531317) at src/common/kax_file.cpp:64
#5 0x004cdbb6 in kax_file_c::read_next_level1_element (this=0x3eae68,
wanted_id=524531317) at src/common/kax_file.cpp:38
#6 0x004ce13e in kax_file_c::read_next_level1_element_internal (
this=0x3eae68, wanted_id=524531317) at src/common/kax_file.cpp:96
#7 0x004cdbb6 in kax_file_c::read_next_level1_element (this=0x3eae68,
wanted_id=524531317) at src/common/kax_file.cpp:38
#8 0x004ceee5 in kax_file_c::read_next_cluster (this=0x3eae68)
at src/common/kax_file.cpp:247
#9 0x0043fa5c in kax_reader_c::read (this=0x3ea888, requested_ptzr=
0x3f44e80, force=false) at src/input/r_matroska.cpp:1966
#10 0x005ef0d3 in generic_packetizer_c::read (this=0x3f44e80)
at src/merge/pr_generic.h:462
#11 0x0041d584 in main_loop () at src/merge/output_control.cpp:1870
#12 0x004142e0 in main (argc=4, argv=0x3e3fd0) at src/merge/mkvmerge.cpp:2210
7) BTW, it would be nice to have --disable-precompiled-headers mentioned in compilation instructions.
8) Also mentioning which versions of gcc and libs are known to work properly with mkvtoolnix would save a lot of time.
9) And it would be nice to see --debug, --capabilities and --compression parameters listed in mkvmerge's --help.
10) LZO and other compression options are missing in mmg.
11) src/info/resources.rc seems to fail building with --disable-gui.

Oh, and here is build itself: MKVToolnix-4.8.0-static-cfa64aa.7z (http://www.mediafire.com/?fgfsp67vw70r1pg). It's statically linked and stripped.
Patches used:
1) mkvtoolnix-static.diff (http://pastie.org/1981544) to get static build compiled
2) mkvtoolnix-extlibs.diff (http://pastie.org/1981547) to link with external libebml and libmatroska.
3) mkvtoolnix-avilib.diff (http://pastie.org/1981546) to avoid breaking avilib
4) mkvtoolnix-defaults.diff (http://pastie.org/1981549) to change default behavior of mmg and mkvmerge. Now header removal compression is disabled by default in mkvmerge. Relative option in mmg is enabled by default, but changing it does nothing.
Also this patch adds language "nul (None)" which implies not writing language tag at all. For playback application it should be equivalent to eng. But now, when you select "eng", it always gets written. Remuxing file which didn't contain language tag also writes "eng".

I would appreciate if someone can help me testing it.

[Mosu]

Hi, Mosu!
I've finally managed to build mkvtoolnix with MinGW, but here are some questions.
1) Have you tried to compile gui with wxWidgets 2.9?
When I tried I've ended up with errors on startup and menu bar disapeared.

I refuse to test with 2.9.1 as they still label it a "development release" -- even though they claim that it is stable enough for new production projects. I simply lack the time to support non-production releases.

2) Why are you using threading=single when building boost? Could there be any issues with mt version?

No idea, never tried.

3) Have you intentionally commented out "m4_include(ac/ebml.m4)" and "m4_include(ac/matroska.m4)" in configure.in?

Yes. For the time being the included versions of libebml and libmatroska are preferred.

4) What do I need to run scripts from ./tests?

Ruby and my test files, and most likely Linux.

5) Is it possible to update avilib?

My version contains fixes and patches; therefore in general: "no".

6) Actually, there are more issues with 4.5.2. Without --disable-precompiled-headers it miscompiles mkvmerge so it crashes when trying to mux from mkv. Here is backtrace, in case it helps:

Please report such errors to the gcc devs.

7) BTW, it would be nice to have --disable-precompiled-headers mentioned in compilation instructions.
8) Also mentioning which versions of gcc and libs are known to work properly with mkvtoolnix would save a lot of time.
9) And it would be nice to see --debug, --capabilities and --compression parameters listed in mkvmerge's --help.

Patches are welcome. I don't have a list of compatible gcc and library versions that are known good. I only have the versions I use at the time, but making that list public would only lead to questions like "but I'm using ver XYZ and it works, too!" or "why don't you upgrade to ver ABC?" etc etc.

10) LZO and other compression options are missing in mmg.

On startup mmg queries mkvmerge about its capabilities. If mkvmerge has been built without support for LZO and BZ2, then mmg won't list them. If mmg doesn't list those even though mkvmerge has been built with them then that could be a bug.

11) src/info/resources.rc seems to fail building with --disable-gui.

Interesting, but fixing that has no priority for me.

1) mkvtoolnix-static.diff (http://pastie.org/1981544) to get static build compiled
2) mkvtoolnix-extlibs.diff (http://pastie.org/1981547) to link with external libebml and libmatroska.
3) mkvtoolnix-avilib.diff (http://pastie.org/1981546) to avoid breaking avilib
4) mkvtoolnix-defaults.diff (http://pastie.org/1981549) to change default behavior of mmg and mkvmerge. Now header removal compression is disabled by default in mkvmerge. Relative option in mmg is enabled by default, but changing it does nothing.

I'll take a lookt at 1 and 3. Thanks.

Also this patch adds language "nul (None)" which implies not writing language tag at all. For playback application it should be equivalent to eng. But now, when you select "eng", it always gets written. Remuxing file which didn't contain language tag also writes "eng".

mkvmerge does not write default values at the moment, and "eng" is the default value. So what you're observing is... strange and should not happen.

[Mosu]

Both patches are not portable, and I don't know the proper #ifdefs to check for "mingw but not a cross-compiler".

[b66pak]

I've verified and fixed this in the following pre build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.8.0-build20110526-339-setup.exe

I've also checked whether or not the audio packetizers preserve source timecodes. The DTS packetizer obviously had some problems. The AAC and AC3 packetizers already did preserve timecodes.

If you find that some packetizers don't preserve timecodes and always recalculate then please let me know.

thank you...
_

[Abradoks]

Ruby and my test files, and most likely Linux.
Can you please share those test files?

My version contains fixes and patches; therefore in general: "no".
Is it working for you on Linux with GCC 4.5? Because it seems more like a bug in avilib, than in GCC.

Patches are welcome.
Well, I knew you'll give such answer. Obviously it isn't critical, but updating documentation is generally expected from those who change code.

I only have the versions I use at the time, but making that list public would only lead to questions like "but I'm using ver XYZ and it works, too!" or "why don't you upgrade to ver ABC?" etc etc.
And not making it public creates superfluous obstacles for those who try to build on there own.

On startup mmg queries mkvmerge about its capabilities. If mkvmerge has been built without support for LZO and BZ2, then mmg won't list them. If mmg doesn't list those even though mkvmerge has been built with them then that could be a bug.
Yeah, I meant that "mkvmerge --capabilities" reports both BZ2 and LZO, but they are absent in mmg. Same with your build.

mkvmerge does not write default values at the moment, and "eng" is the default value.
Yes, that's why I had to hack libmatroska to actually write "eng".
So what you're observing is... strange and should not happen.
That was description of patched behavior, with clean mkvmerge everything works as expected.

Both patches are not portable, and I don't know the proper #ifdefs to check for "mingw but not a cross-compiler".
Those are just quick fixes to get mkvtoolnix compiled. I've posted them for information, not for commiting.

[Mosu]

Is it working for you on Linux with GCC 4.5? Because it seems more like a bug in avilib, than in GCC.

Yes, it works just fine here on ubuntu 11.04 64bit with gcc 4.5.2 and -O2 or -O3 (I don't remember).

Well, I knew you'll give such answer. Obviously it isn't critical, but updating documentation is generally expected from those who change code.

True but:

--debug is intentionally not documented (just like --engage).

--capabilities is only useful for people writing frontends. This one could use documentation.

--compression is already listed in --help.

And not making it public creates superfluous obstacles for those who try to build on there own.

README.Windows.txt already lists libraries and version numbers that used to work for me at the time of writing. The number of people trying to build on a non-Linux platform is rather low, and catering to such a low number is really time consuming; time I just don't have. It's not a matter of principal; I just have to chose wisely where to spend time and where not to.

Yeah, I meant that "mkvmerge --capabilities" reports both BZ2 and LZO, but they are absent in mmg. Same with your build.

Alright, that's a bug then. I'll look into it.

Yes, that's why I had to hack libmatroska to actually write "eng".

That was description of patched behavior, with clean mkvmerge everything works as expected.

Ah, I misunderstood you.

Those are just quick fixes to get mkvtoolnix compiled. I've posted them for information, not for commiting.

But if we could get them to be portable then you wouldn't have to maintain the ones I'm willing to apply.

[Abradoks]

--debug is intentionally not documented (just like --engage).

--capabilities is only useful for people writing frontends. This one could use documentation.

--compression is already listed in --help.
Ok, you are right about --debug and --capabilities. But in help --compression is in the wrong section and lacks options, while man pages are ok.

README.Windows.txt already lists libraries and version numbers that used to work for me at the time of writing.
Nothing about GCC version and wx < 2.9 there. Or am I the first one who encountered miscompilation of mkvmerge?

But if we could get them to be portable then you wouldn't have to maintain the ones I'm willing to apply.
Maybe I'll look into avilib issue later. At least we should understand why it fails, not just workaround it wih -O0.

[Mosu]

Ok, you are right about --debug and --capabilities. But in help --compression is in the wrong section and lacks options, while man pages are ok.

Ah, you're correct. I'll move --compression. I've also added --debug, --capabilities and --engage for completeness.

Nothing about GCC version and wx < 2.9 there. Or am I the first one who encountered miscompilation of mkvmerge?

No, you're not the only one. But I usually don't update documentation for libs that are still in development stage. Like I said, it's a matter of time and priorities. mkvtoolnix is pretty much a one-person job (apart from the translations), so I cannot simply hand such things over to someone else either.

[Mosu]

I've fixed the compilation errors with 2.9.1, but not the errors upon execution. It looks like I'm using IDs for menu items that are too low/too high/that collide with internal IDs. If so then it should be easy enough to fix.

However, I've also added code to configure that will disable the wxWidgets based GUIs if 2.9.0 or newer is detected. This has also found its way into README and README.Windows.txt.

The bug with mmg not including lzo and bz2 in the compression drop down box has been fixed. It was trivial to fix as the reason was that the drop down box was populated before mkvmerge was queried for its capabilities.

[Thunderbolt8]

it doesnt seem possible to add lpcm tracks created with eac3to. whys that?

[Mosu]

Because mkvmerge doesn't LPCM at all.

[Thunderbolt8]

hm any special reason for that?

[Mosu]

Lack of time and interest.

[SledgeHammer_999]

I am not sure if I should post this in this thread.

I am a little confused on how to mux ASS subs which use custom fonts. I thought that if I muxed the ass script and attached the font file it would be enough. But no, ffdshow-tryouts(+mpc) doesn't seem to pick up the emdedded font file and thus uses a generic font. What am I missing? (yes I have attached the correct font file).

EDIT: Arghhh, I feel stupid. The problem was in the mime type. I muxed through the commandline not the GUI. As MIME I used whatever GNOME showed me which is "application/x-font-ttf" but then I tried the mkvmerge gui and I noticed that it detected it as "application/x-truetype-font".

Does mkvmerge(or other mkv tool) provide a function that can tell me the MIME type of a file? Or is there any way to let mkvmerge decide itself the MIME? (the docs say that I have to specify the MIME)

EDIT2: And yes the docs are misleading. If you ommit the "--attachment-mime-type" mkvmerge autorecognizes the MIME type. Sorry for the noise people.

[Mosu]

mkvmerge and mmg both use the "libfile" library for MIME detection. This is the same library used by the Linux/Unix command line utility "file" for file type recognition. Both programs can be built without that library present in which case they'll fall back to detection by file name extension -- which might sometimes produce the correct result.

I'll take a look at the documentation.

[SledgeHammer_999]

In Debian Unstable file -i bla.ttf gives bla.ttf: application/x-font-ttf; charset=binary

From the online docs:
--attachment-mime-type MIME type

MIME type of the following attachment. Applies to the next --attach-file or --attach-file-once option. A list of officially recognized MIME types can be found e.g. at the IANA homepage. The MIME type is mandatory for an attachment.

I guess the bold part can be read many ways.

[Mosu]

It's quite possible that newer versions of the libmagic library (I was wrong before: the tool is called "file", yes, but the library it and mkvtoolnix use is called "libmagic") report different MIME types for TrueType fonts than older ones. mkvtoolnix' Windows version comes with a not so up to date version of libmagic.

Note that there seems to be no official MIME type registration for TrueType fonts (see http://www.iana.org/assignments/media-types/application/index.html ); each type starting with "x-" is an unofficial extension. I've seen numerous variants for TrueType fonts including but most likely not limited to: font/ttf (this one is especially bad as there's no official "font/" prefix registration), application/font-ttf, application/ttf, application/octet-stream (well... this is just the generic "binary data!" type), application/x-font-ttf, application/x-font-truetype, application/x-truetype-font, application/x-ttf-font. I'm not saying any one of them is more correct than any other, mind you, just that reading applications should be extended to recognize several versions.

I guess that mmg will chose "application/x-font-ttf" as well when I upgrade the libmagic for the Windows port.