mkvtoolnix 4.1.1 released

[Mosu]

Yes, it breaks pretty much everything for anyone using any of my tools on the console. E.g. on a German Windows XP using "--output-charset CP1252" (1252 = GetACP()) in cmd.exe results in unreadable Umlaute.

My guess is that Windows 7 changes something fundamentally regarding which code page cmd.exe uses. So my tools will have to check the OS it is run on and use GetACP() even for console output on Windows 7, but again, that's just guesswork.

Consider Windows 7 the uncommon case, and that's why I will certainly not get rid of GetOEMCP() for the time being.

[stax76]

I don't think Win 7 changes something, if you like I can install a english XP to verify this.

[Mosu]

German Windows XP: CP 850, Umlaute work. Same on a German Vista. English Windows 2003 Server: CP 437. Umlaute work without changing the --output-charset (!).

So no, there's no real need for you to install an English XP. The only thing that would actually interest me is having a copy of Windows 7 myself. Until then -- topic closed for me.

[stax76]

Before I saw your post I've installed an english Windows 2000 with german locale settings within VirtualBox, no problem with Umlaute. You can get Windows 7 RC here:

http://www.microsoft.com/germany/windows/windows-7/download.aspx

I've skipped Vista using XP until 25 days ago so for me it's quite a improvement, it works and looks very well.

I don't know how long it will work legally, I think 3-4 months.

http://www.mydigitallife.info/2008/11/06/how-to-rearm-and-extend-free-usage-activation-grace-period-of-windows-7-to-120-days

[Mosu]

Until Windows 7 is final and released I will not spend any time on it. At least not regarding mkvtoolnix.

[tetsuo55]

Until Windows 7 is final and released I will not spend any time on it. At least not regarding mkvtoolnix. Any beta or RC1 build of Windows 7 is at least 1% (and at most 100's of %) faster and more stable than vista SP2/XP(where xp is faster it comes at the cost of either security or stability).

Also the final build has already been compiled and is available for OEM partners.

The whole point of MS releasing the OS in its pre-release form to software developers and end users it to make sure, that when it gets released in 2 months all software will work properly on it.

(I don't think there are any changes between RC1 and RTM that would make any difference for mkvtoolnix)

---------
Actually, and i'm not sure how it works, but you can sign up to the Microsoft software testing program, as a trused software vendor.
This will give you access to all the crash dumps generated by mkvtoolnix and performance data and other stuff handy for bugfixing.
Also this might cost money, but i don't think it does.
Being part of this group also gives you (100% legal and free) access to the latest test builds of all microsoft software (IIRC). And of you expose a bug in windows itself, they will supposedly fix it sooner than other bugs found.

[Mosu]

I don't care. I have more than enough to do with mkvtoolnix as it is in areas that are way more important that the issue at hand. I don't WANT to spend any time on beta versions of Windows. Simple as that. That the default charset for the console does not seem to work 100% on Windows 7 is a nuisance, but nothing more. I have no interest in being a beta tester. I've done that often enough in the past and I know how time consuming it can be.

[tetsuo55]

Yes, ofcourse you are free to chose what you do yourself.

I just wanted to make sure there are no misunderstandings about the "release candidate" label on Windows 7 which actually means something like XP SP8.

I bet that for english local, there will be no compatibility problems.

[khagaroth]

Encountering the same issue with localized command line output in Window 7, I played around a bit with mkvmerge and found out, that version 2.5.3 works correctly, anything after that shows garbled output.

[microchip8]

Hi Moritz,

I've noticed a small "problem" with mkvmerge v2.9.7 (on Linux). It seems that when you feed mkvmerge with a chapter file generated by dvdxchap, it creates an extra Menu chapter entry. I checked mkv files both in mediainfo and smplayer and, for example, if one has imported a chapters file with 25 chapter entries in it, the mkv will have 26 instead. The last chapter is somehow added by mkvmerge itself and sits in Menu #2 as reported by mediainfo on Linux. I have not had such behavior with past versions of mkvmerge. This is the report by mediainfo and the extra chapter entry is really there as I can also see it in smplayer

General

Format : Matroska

File size : 552 MiB

Duration : 1h 52mn

Overall bit rate : 689 Kbps

Movie name : The Bank Job

Encoded date : UTC 2009-07-06 20:11:17

Writing application : mkvmerge v2.9.7 ('Tenderness') built on Jul 2 2009 03:11:07

Writing library : libebml v0.7.8 + libmatroska v0.8.1

Cover : Yes



Video

ID : 1

Format : AVC

Format/Info : Advanced Video Codec

Format profile : High@L4.1

Format settings, CABAC : Yes

Format settings, ReFrames : 4 frames

Muxing mode : Container profile=Unknown@4.1

Codec ID : V_MPEG4/ISO/AVC

Duration : 1h 51mn

Width : 720 pixels

Height : 368 pixels

Display aspect ratio : 2.35

Frame rate : 23.976 fps

Resolution : 24 bits

Colorimetry : 4:2:0

Scan type : Progressive

Title : The Bank Job

Writing library : x264 core 67 r1173M f6d3166


Audio

ID : 2

Format : AAC

Format/Info : Advanced Audio Codec

Format version : Version 4

Format profile : LC

Format settings, SBR : Yes

Format settings, PS : No

Codec ID : A_AAC

Duration : 1h 52mn

Channel(s) : 2 channels

Channel positions : L R

Sampling rate : 48.0 KHz

Resolution : 16 bits

Title : HE-AACv1 Stereo

Language : English



Menu #1

00:00:00.000 : en:Chapter 01

00:07:20.800 : en:Chapter 02

00:11:15.800 : en:Chapter 03

00:13:46.333 : en:Chapter 04

00:18:58.499 : en:Chapter 05

00:21:25.333 : en:Chapter 06

00:24:45.666 : en:Chapter 07

00:28:54.699 : en:Chapter 08

00:36:29.699 : en:Chapter 09

00:40:25.666 : en:Chapter 10

00:45:53.666 : en:Chapter 11

00:50:12.333 : en:Chapter 12

00:54:07.200 : en:Chapter 13

00:56:59.366 : en:Chapter 14

00:59:48.200 : en:Chapter 15

01:02:25.300 : en:Chapter 16

01:05:46.700 : en:Chapter 17

01:09:50.000 : en:Chapter 18

01:15:37.500 : en:Chapter 19

01:22:34.533 : en:Chapter 20

01:30:42.666 : en:Chapter 21

01:38:21.166 : en:Chapter 22

01:41:49.833 : en:Chapter 23

01:45:45.633 : en:Chapter 24

01:51:53.333 : en:Chapter 25



Menu #2

00:00:00.097 : en:00:00:00.097

[Mosu]

I cannot reproduce this. I've created a chapter file with dvdxchap from ogmtools 1.5 which contains 36 entries. Then I've merged this file normally into a Matroska file (mkvmerge -o v.mkv v.avi --chapters chapters.txt). The resulting file also contains exactly 36 chapters:

[0 mosu@tionne /tmp] mkvinfo -v -v v.mkv | grep -i 'atom' | wc -l
36

Then I created a Matroska file without chapters (mkvmerge -o v.mkv v.avi) and used mmg's chapter editor's "save to Matroska file" function with the same chapters.txt file as before. The same result.

I don't know what MediaInfo thinks happens in that file or what exactly happens on your computer. How did you create that Matroska file?

Please re-check with mkvinfo. I don't trust other programs all that much in this regard.

What kind of a container format was your source file? If it was a MP4 file which in turn contained chapters (a single entry) then this might explain this behaviour. You can check this with "mkvmerge -i input.mp4".

[microchip8]

Hi Moritz,

I checked with mkvinfo and it's reported there as well. This is usually my mkvmerge command line

/usr/bin/mkvmerge --attachment-mime-type image/jpeg --attachment-name Cover --attach-file "/home/neutrino/cover.jpg" -A --title "The Bank Job" --track-name 0:"The Bank Job" "/home/neutrino/The Bank Job.avi" --track-name 1:"HE-AACv1 Stereo" --language 1:en --aac-is-sbr 1:1 /home/neutrino/audio.aac --chapters "/home/neutrino/The Bank Job.chaps" -o "/home/neutrino/The Bank Job.mkv"

I only take the video from the AVI and an external audio encoded by neroAacEnc which both get muxed into mkv.


neutrino@neutrino:~> mkvinfo -v -v "The Bank Job.mkv" | grep -i 'atom' | wc -l
26

[Mosu]

Upload the chapter file somewhere, please, or send me an email to moritz@bunkus.org

[microchip8]

Here it is http://www.mediafire.com/download.php?wemmjcmomdo

btw, could it have something to do that I use -o as last instead of as first parameter? eg, mkvmerge blablabla -o output.mkv VS mkvmerge -o output.mkv blablabla

[Mosu]

/usr/bin/mkvmerge --attachment-mime-type image/jpeg --attachment-name Cover --attach-file "/home/neutrino/cover.jpg" -A --title "The Bank Job" --track-name 0:"The Bank Job" "/home/neutrino/The Bank Job.avi" --track-name 1:"HE-AACv1 Stereo" --language 1:en --aac-is-sbr 1:1 /home/neutrino/audio.aac --chapters "/home/neutrino/The Bank Job.chaps" -o "/home/neutrino/The Bank Job.mkv"

1. The audio track in an AAC file has the ID 0, not 1. All the parameters e.g. "--track-name 1:..." will do nothing at all. mkvmerge outputs a warning for that.

2. I still cannot reproduce the problem here with the chapter file you've uploaded. AVI files do not contain chapters (or mkvmerge doesn't support reading chapters from them). So I really don't know what's wrong here. You may upload the AVI file in question to my FTP server if you want, but if not then I cannot really help you. BTW, please post the output of 'mkvmerge --identify-verbose "/home/neutrino/The Bank Job.avi"'.

btw, could it have something to do that I use -o as last instead of as first parameter? eg, mkvmerge blablabla -o output.mkv VS mkvmerge -o output.mkv blablabla

3. No.

The following command line uses dummy files in place of your original ones, obviously:

[0 mosu@tionne ~/dl] mkvmerge --attachment-mime-type image/jpeg --attachment-name Cover --attach-file ~/files/Pictures/Desktop/gilmorewall.jpg -A --title "The Bank Job" --track-name 0:"The Bank Job" ~/prog/video/mkvtoolnix/data/v.avi --track-name 0:"HE-AACv1 Stereo" --language 0:en --aac-is-sbr 0:1 /ftp/.rip/mkv/qtmp4/aac/sbr/sample_44-2-16_HE_AAC.aac --chapters "The Bank Job.txt" -o "The Bank Job.mkv"
...
[0 mosu@tionne ~/dl] mkvinfo -v -v The\ Bank\ Job.mkv| grep -i atom | wc -l
25

[microchip8]

Hi, Moritz

@1 - well, I tried both --track-name 0 and --track-name 1 on the audio.aac file and mkvmerge does not display a warning. All I see in both cases is this
'The Bank Job - chapter 1-1.avi' track 0: Using the MPEG-4 part 10 ES video output module.
'audio.aac' track 1: Using the AAC output module.

@2 I can't upload the whole AVI file since I don't have it anymore (deleted after remuxing). However, I did encode just now the first chapter of the DVD using very fast settings and very low resolution, just for testing purposes and exported the chapters with dvdxchap (I can upload that and the chapters file in a minute). Then manually muxed everything and still I get 26 chaps instead of 25

as for the identify thing...
mkvmerge --identify-verbose "/home/neutrino/The Bank Job - chapter 1-1.avi"
File '/home/neutrino/The Bank Job - chapter 1-1.avi': container: AVI
Track ID 0: video (h264) [packetizer:mpeg4_p10_es_video]
Track ID 1: audio (PCM)

[Mosu]

Hi, Moritz

@1 - well, I tried both --track-name 0 and --track-name 1 on the audio.aac file and mkvmerge does not display a warning. All I see in both cases is this

Then you only have a single AVI file as an input file and not a separate AAC audio file. In any case your command line does not match what you're seeing at the moment as mkvmerge's output.

@2 I can't upload the whole AVI file since I don't have it anymore (deleted after remuxing). However, I did encode just now the first chapter of the DVD using very fast settings and very low resolution, just for testing purposes and exported the chapters with dvdxchap (I can upload that and the chapters file in a minute). Then manually muxed everything and still I get 26 chaps instead of 25

A short AVI will be enough if it shows the same problem, but please upload all the files that are part of the remuxing process.

[microchip8]

Then you only have a single AVI file as an input file and not a separate AAC audio file. In any case your command line does not match what you're seeing at the moment as mkvmerge's output.

Now I did get a warning though, but only when using --track-name 0 and --language 0. Everything set to 1 for audio.aac does not produce a warning and shows the track name and language specified while when using 0 (and getting a warning) no track name and language are shown by mediainfo

With --track-name 0 --language 0

mkvmerge -A The\ Bank\ Job\ -\ chapter\ 1-1.avi --track-name 0:"foobar" --language 0:en audio.aac -o output.mkv
mkvmerge v2.9.7 ('Tenderness') built on Jul 2 2009 03:11:06
'The Bank Job - chapter 1-1.avi': Using the AVI demultiplexer. Opening file. This may take some time depending on the file's size.
'audio.aac': Using the Quicktime/MP4 demultiplexer.
'The Bank Job - chapter 1-1.avi' track 0: Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 313/176.
'The Bank Job - chapter 1-1.avi' track 0: Using the MPEG-4 part 10 ES video output module.
'audio.aac' track 1: Using the AAC output module.
Warning: 'audio.aac': A track with the ID 0 was requested but not found in the file. The corresponding option will be ignored.
The file 'output.mkv' has been opened for writing.
Progress: 100%
The cue entries (the index) are being written...
Muxing took 3 seconds.

With --track-name 1 --language 1
mkvmerge -A The\ Bank\ Job\ -\ chapter\ 1-1.avi --track-name 1:"foobar" --language 1:en audio.aac -o output.mkv
mkvmerge v2.9.7 ('Tenderness') built on Jul 2 2009 03:11:06
'The Bank Job - chapter 1-1.avi': Using the AVI demultiplexer. Opening file. This may take some time depending on the file's size.
'audio.aac': Using the Quicktime/MP4 demultiplexer.
'The Bank Job - chapter 1-1.avi' track 0: Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 313/176.
'The Bank Job - chapter 1-1.avi' track 0: Using the MPEG-4 part 10 ES video output module.
'audio.aac' track 1: Using the AAC output module.
The file 'output.mkv' has been opened for writing.
Progress: 100%
The cue entries (the index) are being written...
Muxing took 6 seconds.

Also, even if no chapters file is added, mkvmerge still creates that very same chapters entry and each time it has a value of 00:00:00.097



A short AVI will be enough if it shows the same problem, but please upload all the files that are part of the remuxing process.

Yes, doing it now. I'll upload the AVI, chapters file, audio.aac file and the muxed mkv file so you can see the chapters entries. Since you can't reproduce it on your side, I begin in thinking that it's on my machine somehow and not mkvmerge's fault

[Mosu]

'audio.aac': Using the Quicktime/MP4 demultiplexer.

You can stop the upload(s). The audio.aac file is actually a MP4 file and not a raw AAC file. That's why the track ID starts at 1 for you and not at 0, and that's probably where the lone chapter entry comes from. Reading chapters from MP4 files is a rather new feature, that's why you don't see the problem with older versions.

You can verify this with "mkvmerge -i audio.aac"; it should show chapters. You can turn off copying chapters from that file with the "--no-chapters" option, e.g. "mkvmerge -o ... --no-chapters audio.aac".

You'd better rename the file to audio.mp4, too ;)

[microchip8]

You can stop the upload(s). The audio.aac file is actually a MP4 file and not a raw AAC file. That's why the track ID starts at 1 for you and not at 0, and that's probably where the lone chapter entry comes from. Reading chapters from MP4 files is a rather new feature, that's why you don't see the problem with older versions.

You can verify this with "mkvmerge -i audio.aac"; it should show chapters. You can turn off copying chapters from that file with the "--no-chapters" option, e.g. "mkvmerge -o ... --no-chapters audio.aac".

You'd better rename the file to audio.mp4, too ;)

Ahhh, now it's so clear. Yes indeed, neroAacEnc wraps the audio in mp4 and I didn't think of that so it was user "error" on my part :D

I'll be using --no-chapters in the future then. Thanks for the great support ;)

[Mosu]

You're welcome.

[sneaker_ger]

I've probably found another small bug in the native mpeg4 part 2 muxing. I'd advise everyone to wait until Mosu has taken a look at it before remuxing your files.

[Chumbo]

I tried adding a PCM file but it keeps thinking it's an h.264/avc MPEG4 part 10 elementary stream. Here's the eac3to info for the file.eac3to v3.16
command line: eac3to audio.pcm -log=pcm.info.txt
------------------------------------------------------------------------------
This might be a RAW/PCM file. Trying to figure out the details.
This will probably take a while. Please be patient...
The RAW/PCM file seems to be big endian.
The RAW/PCM file seems to have a bitdepth of 16 bits.
The RAW/PCM file seems to have 6 channels.
RAW/PCM, 5.1 channels, 0:00:47, 16 bits, 4608kbps, 48khzI'm still using 2.9.5 right now.

[Mosu]

Raw PCM files are not supported and never will be.

[Tima]

I have two files:

1. a.mkv with one ASS track and 3 attaches fonts.
2. b.ass

Look at the following sequence:

1. add a and b into mmg
2. uncheck ASS track (from a.mkv)
3. remux the result into c.mks

After this sequence I get c.mks without attached fonts.
Don't think it's intended behaviour.


This workaround works ok:

1. add a and b into mmg
2. remux the result into t.mks
3. reset mmg; add t.mks
4. uncheck old ASS track
5. remux the result into c.mks


If this description isn't enough, I can provide all necessary test files :)

[sneaker_ger]

I have two files:

1. a.mkv with one ASS track and 3 attaches fonts.
2. b.ass

Look at the following sequence:

1. add a and b into mmg
2. uncheck ASS track (from a.mkv)
3. remux the result into c.mks

After this sequence I get c.mks without attached fonts.
Don't think it's intended behavior.


This workaround works ok:

1. add a and b into mmg
2. remux the result into t.mks
3. reset mmg; add t.mks
4. uncheck old ASS track
5. remux the result into c.mks


If this description isn't enough, I can provide all necessary test files :)

I can't reproduce it here so you may want to upload your samples.

[Mosu]

You might also make sure that you're testing this with mkvtoolnix 2.9.7 as I have changed the way that "track-less" files are handled in one of the latest releases due to the change how mmg presents attachments, chapters and tags present in source files.

[Tima]

You might also make sure that you're testing this with mkvtoolnix 2.9.7 as I have changed the way that "track-less" files are handled in one of the latest releases due to the change how mmg presents attachments, chapters and tags present in source files.

Yes, its, 2.9.7.

Samples:
http://nwfiles.gorodok.net/a.mkv
http://nwfiles.gorodok.net/b.ass

[sneaker_ger]

Yes, its, 2.9.7.

Samples:
http://nwfiles.gorodok.net/a.mkv
http://nwfiles.gorodok.net/b.ass

OK, now I get the same behavior. It always happens when trying to only copy the attachments, but no track.

[Chumbo]

Raw PCM files are not supported and never will be.
Thanks for the info. May I ask why if you don't mind? I'm curious.

[Mosu]

Thanks for the info. May I ask why if you don't mind? I'm curious.

Almost noe one uses raw PCM files with a container format that's designed for final storage. There are several lossless audio formats that are support, and the WAV container is among them.

TLDR: Way too much work for almost no gain.

[Chumbo]

Almost noe one uses raw PCM files with a container format that's designed for final storage. There are several lossless audio formats that are support, and the WAV container is among them.

TLDR: Way too much work for almost no gain.
That's what I figured. Thank you.

[SeeMoreDigital]

Hi Mosu,

I've just done some test muxes using MKVmerge v2.9.7 and it would appear an AVC streams "stream level" aspect ratio signalling is no longer removed by default.... What was the reason behind this change?


Cheers

[sneaker_ger]

Hi Mosu,

I've just done some test muxes using MKVmerge v2.9.7 and it would appear an AVC streams "stream level" aspect ratio signalling is no longer removed by default.... What was the reason behind this change?


Cheers

I'll try to translate Mosu's post as best as possible from the German forum:


Because many hardware players can't cope with files without the SAR set within the video bitstream mkvmerge 2.7.0 was changed in a way so that the SAR is no longer removed. Personally, I think it's complete nonsense because the container - as the outer layer - is much easier to modify as the contained bitstream if you want to change the SAR. But OK, reality has told us otherwise - everyone thinks SAR within the bitstream is the way to go.

[SeeMoreDigital]

Many thanks for the confirmation sneaker_ger...

I thought it might be for that reason. So bitstream AR signalling dominates, even in the .MKV world... Great, it's about time :D

[Mosu]

No, it's not "about time". It's ridiculous. How do you expect to fix broken streams in which the encoder (either due to software bugs or human error) has stored the wrong aspect ratio in the bitstream? That's right, you demux the stream, fix it somehow, and remux again, probably losing A/V sync on the way. But the easier, more logical way of only modifying the container is barred because a lot of cheap-ass hardware players did not spend the time to pass some of the essential information from the container level to the deocer level making life harder for almost everyone else.

It's a major hassle, it sucks, it is user-unfriendly. I will never, ever write a tool that can fix the aspect ratio of the bitstream contained in a Matroska file without remuxing because it is such an unbelievable amount of work.

The container is there for a reason. That reason is to provide a lot of information in addition to the information stored in the bitstream. Some pieces of information are absolutely neccessary for proper playback -- e.g. timecodes (no, the FPS stored at bitstream level will usually not cut it, think of variable FPS video tracks).

There are generally three layers of settings/information involved in playback: bitstream layer (furthest away from human control, a bitch to modify, only information that is absolutely essential for decoding); container level (middle ground between ease of access, how easy it is to change these settings, but still distributeable and kept intact if copied from one device to another); player level (easiest to modify but not permanent). The information at higher levels should always override the information at a lower level (e.g. choice of language, display size, aspect ratio (!)) unless it makes no sense (physical dimension of the encoded picture, sampling rate for audio).

Not everyone agrees. I don't really know why nor do I want to know. For me as a software developer this leads to interesting conflicts: one group of people complains that their crappy hardware devices do not handle "no aspect stored at bitstream level", another group complains that they now cannot change the aspect ratio properly anymore.

End of rant.

[hvda]

Question about MKVMerge command line interface (from newbie).

How can I with one single mkvmerge command line (in Windows environment) put 1 video track (= .m2v file) and 2 audio tracks (each audio = single .mp2 file) into a Matroska container and at the same time set the language codes for the audio tracks ?

I managed to do it in two steps (= 2 separate mkvmerge commands) : step 1= merge into .mkv, step 2= set language codes; example:

mkvmerge -o E:\DVR\name-of-movie_NoLangCode.mkv E:\DVR\name-of-movie.m2v E:\DVR\name-of-movie.fre.mp2 E:\DVR\name-of-movie.ger.mp2
mkvmerge -o E:\DVR\name-of-movie_WithLangCode.mkv --language 2:fre --language 3:ger E:\DVR\name-of-movie_NoLangCode.mkv

But I would like to do the muxing and the settting of the language codes in one single step; something like this:
mkvmerge -o E:\DVR\name-of-movie.mkv E:\DVR\name-of-movie.m2v E:\DVR\name-of-movie.fre.mp2 --language 2:fre E:\DVR\name-of-movie.ger.mp2 --language 3:ger
(however: this syntax does not seem to work: no language codes are set in the .mkv output).

Help would be much appreciated.

[Mosu]

Yes, that is possible. There are two things to remember:

1. You should always ask mkvmerge which track IDs it assigns to each input file because track IDs are local to each input file and the method for how they are numbered varies from file type to file type.
2. All command line options apply to the following input file.

1. is easy to do: use "mkvmerge -i movie.m2v", "mkvmerge -i movie.ger.mp2", "mkvmerge -i movie.fre.mp2". You'll probably get "1" for the track in the .m2v and "0" for each of the .mp2 files.
2. means that your order is wrong.

You should end up with a command line like

mkvmerge -o E:\DVR\name-of-movie.mkv E:\DVR\name-of-movie.m2v --language 0:fre E:\DVR\name-of-movie.fre.mp2 --language 0:ger E:\DVR\name-of-movie.ger.mp2

[hvda]

Yes, that is possible. There are two things to remember:

1. You should always ask mkvmerge which track IDs it assigns to each input file because track IDs are local to each input file and the method for how they are numbered varies from file type to file type.
2. All command line options apply to the following input file.

1. is easy to do: use "mkvmerge -i movie.m2v", "mkvmerge -i movie.ger.mp2", "mkvmerge -i movie.fre.mp2". You'll probably get "1" for the track in the .m2v and "0" for each of the .mp2 files.
2. means that your order is wrong.

You should end up with a command line like

mkvmerge -o E:\DVR\name-of-movie.mkv E:\DVR\name-of-movie.m2v --language 0:fre E:\DVR\name-of-movie.fre.mp2 --language 0:ger E:\DVR\name-of-movie.ger.mp2

Thank you so much, that works perfectly well.
(I should have better read the synopsis of mkvmerge:
mkvmerge [global options] −o out [options1] <file1> [[options2] <file2> ...] [@optionsfile])

[Tima]

Mosu, any update on my issue with attachments?

[Mosu]

I will post here when and if I have an update. So no.

[jmnk]

No, it's not "about time". It's ridiculous. How do you expect to fix broken streams in which the encoder (either due to software bugs or human error) has stored the wrong aspect ratio in the bitstream? That's right, you demux the stream, fix it somehow, and remux again, probably losing A/V sync on the way. But the easier, more logical way of only modifying the container is barred because a lot of cheap-ass hardware players did not spend the time to pass some of the essential information from the container level to the deocer level making life harder for almost everyone else.

It's a major hassle, it sucks, it is user-unfriendly. I will never, ever write a tool that can fix the aspect ratio of the bitstream contained in a Matroska file without remuxing because it is such an unbelievable amount of work.

The container is there for a reason. That reason is to provide a lot of information in addition to the information stored in the bitstream. Some pieces of information are absolutely neccessary for proper playback -- e.g. timecodes (no, the FPS stored at bitstream level will usually not cut it, think of variable FPS video tracks).

There are generally three layers of settings/information involved in playback: bitstream layer (furthest away from human control, a bitch to modify, only information that is absolutely essential for decoding); container level (middle ground between ease of access, how easy it is to change these settings, but still distributeable and kept intact if copied from one device to another); player level (easiest to modify but not permanent). The information at higher levels should always override the information at a lower level (e.g. choice of language, display size, aspect ratio (!)) unless it makes no sense (physical dimension of the encoded picture, sampling rate for audio).

Not everyone agrees. I don't really know why nor do I want to know. For me as a software developer this leads to interesting conflicts: one group of people complains that their crappy hardware devices do not handle "no aspect stored at bitstream level", another group complains that they now cannot change the aspect ratio properly anymore.

End of rant.
@Mosu - first, thanks for great piece of software. I have almost no issues ever with it, and the results are not only predictable but also logical.
Now, I almost agree with you completely, except one case. If I mux multiple video streams (let's assume two x264 streams) into mkv, and the streams happen to be flagged at different aspect ratio (like there are DVD extras that are often 4:3 while the main feature is 16:9), how would I deal with it if only container level signaling was to be used?

[Mosu]

I'm not proposing that bitstream AR information is to be ignored -- but that container AR information should override bitstream AR information if container AR information is available. If it isn't then bitstream AR information should be used. This is already implemented for most cases in the "player" layer: if you set MPC to a specific aspect ratio than that will be used regardless of what is stored in the bitstream.

The case of changing aspect ratio mid-stream is another problem, I agree. For this containers should provide a way of signaling such changes. For Matroska there is no such element available, so such cases are not covered by my ideal case outlined in the rant above.

[buzzqw]

maybe a stupid question

why the same file, muxed two time (with different name) have dirrect crc/md5 value ?

should be mkv 's md5 equal for the same input file every time is muxed ?

thanks

BHH

[Mosu]

Several fields in a Matroska file differ each time mkvmerge is run, even if you have identical input and settings. Among them are fields like unique IDs for tracks/attachments/chapters etc or the muxing timestamp.

mkvmerge knows an option that causes it to produce bit-identical files for identical inputs and settings. However, such files are not meant for playback, and that option is only used by myself for regression tests.

[buzzqw]

yep, using same input, muxed with same options, produced different crc

not a problem

thanks again

BHH

P.S. and you cannot share this hidden option ?

[sneaker_ger]

"--engage no_variable_data"

[buzzqw]

thanks!

BHH

[Mosu]

I have two files:

1. a.mkv with one ASS track and 3 attaches fonts.
2. b.ass

Look at the following sequence:

1. add a and b into mmg
2. uncheck ASS track (from a.mkv)
3. remux the result into c.mks

After this sequence I get c.mks without attached fonts.

The problem was only present in mmg, not in mkvmerge itself. It has been fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.9.7-build20090713-146-setup.exe

[Egh]

@Mosu:

neither 145 nor 146 build MMG works here. (Windows XP x64). Reverted back to 142 and all is OK.

BTW, I keep forgetting to tell you -- it seems your installer doesn't overwrite newer files. Is it per design?