Log in

View Full Version : mkvtoolnix 4.1.1 released


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [21] 22 23 24 25 26 27 28 29 30 31 32 33

Mosu
29th May 2009, 21:51
Oh, I also downloaded both of your sample files and they play identically for me (using MPC Homecinema + DirectVobSub).

Snowknight26
29th May 2009, 21:52
The MP4 file, but don't expect a quick fix, please.

Here is the first 50,000,000 bytes of the file:
http://stfcc.org/misc/source.mp4

TheFluff
29th May 2009, 22:09
Demuxers and filters are not bug-free. Just sayin'.

I'm not saying it's your fault, in fact it's more likely to be a bug in the splitter (or even more likely a bug in vsfilter/dvobsub) just pointing out that it could have been wrong the entire time without anybody noticing (as per discussion on IRC it's pretty easy to miss it). The point of the original post was just to see if you happened to know anything about it.

Mosu
29th May 2009, 22:26
Just to sum up our IRC discussion: After being told what to look for (the first line has a different brightness than the second one in the 'unsorted' case) I can see it here, too. So yes, same problem.

LeMoi
30th May 2009, 14:36
Hey,

I've released mkvtoolnix v2.9.0.

Fixed bugs include several segfaults, crashes in the header editor and mmg always reporting that adding files has failed with a return code of 1 on certain Windows systems.

* mkvmerge: bug fix: Fixed support for Windows systems that use code pages that are not supported by the iconv library (e.g. code page 720). mkvmerge was exiting with warnings causing mmg to report that file identification had failed. Fix for bug 376.


Finally, works perfect, thansk a lot :)

Mosu
30th May 2009, 20:07
I recently remuxed an MP4 file to MKV but I noticed that whenever I played it, switching audio tracks would cause the video to stutter. As I was cutting a sample of that newly created MKV file, I noticed that mkvmerge gave me hundreds of these warnings:

The issue has been fixed in this build:

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.9.0-build20090530-135-setup.exe

However, you have to start muxing from the MP4 file again. The timecodes in the Matroska file are already bad, and there's no easy way to fix mkvmerge to correct those bad timecodes coming from such Matroska files.

tetsuo55
30th May 2009, 21:00
The issue has been fixed in this build:

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.9.0-build20090530-135-setup.exe

However, you have to start muxing from the MP4 file again. The timecodes in the Matroska file are already bad, and there's no easy way to fix mkvmerge to correct those bad timecodes coming from such Matroska files.Does that mean that muxing to MKV is not a completely lossless process

Mosu
30th May 2009, 21:13
That is a stupid question. Sorry for saying that. Remuxing from one container to another is ALWAYS a lossy process because no two containers offer the very same set of features.

Muxing to Matroska has never been a lossless process. It was never supposed to be that. The same is true for muxing to MP4 files. Or AVI. Or MPEG PS/TS.

It doesn't involve re-encoding the audio or the video though -- these bitstreams are mostly (!) kept 1:1 intact.

tetsuo55
30th May 2009, 21:34
That is a stupid question. Sorry for saying that. Remuxing from one container to another is ALWAYS a lossy process because no two containers offer the very same set of features.

Muxing to Matroska has never been a lossless process. It was never supposed to be that. The same is true for muxing to MP4 files. Or AVI. Or MPEG PS/TS.

It doesn't involve re-encoding the audio or the video though -- these bitstreams are mostly (!) kept 1:1 intact.Sorry, i should have been more clear.

I meant if the audio/video/subtitles are remuxed 100% losslessly. In which cases do the bitstreams get changed?

Mosu
30th May 2009, 21:41
Think of things like aspect ratio handling (the bitstream AR might be removed/added/changed to match the container AR); dummy frames in MPEG4 part2 that are removed completely.

ID3 tags are stripped from audio files.

For text subtitle formats some reformatting is done -- e.g. attachments like fonts and images are removed from SSA/ASS bitstreams and kept as attachments in the Matroska files. VobSub subtitle files are stripped of the surrounding MPEG program stream container, and even the SPU packets themselves are sometimes fixed because length fields are bad due to buggy authoring software.

You see, there are numerous cases in which the bitstreams get modified themselves, not just the meta information (timecodes etc).

However, all of those changes to not degrade the quality of the content. Like I said, audio/video is not re-encoded in the process.

tetsuo55
30th May 2009, 21:51
thanks for the reply, i guess a lot changes.

Imho MKV is the best container for PC archival use, so it doesn't really matter. (I have had to remux in the past though, and wanted to be sure that the movie would still work in that other container).

We also might have found a problem with a file mergeed with MKVmerge, a mkv containing a mpeg2 track and a simple audio track that does not have CodecPrivate field (causing it to either crash the player on only play audio).

Here is a sample: http://www.megaupload.com/?d=X4FA5TX3

Mosu
30th May 2009, 22:13
Not every codec needs a CodecPrivate element. Some audio codecs don't (MP2/3, AC3, old way of storing AAC ...), some do (new way of storing AAC, Vorbis...).

The file you've uploaded is not affected by the bug that I've fixed today. That bug was only happening for source containers that chose the very same timecode for a lot of samples -- MP4 in today's case. In that file contained the same timecode for over half a second of samples; this is not only bad for playback but also bad for storage in other containers.

Your MPEG2 file seems fine to me.

tetsuo55
30th May 2009, 22:15
Not every codec needs a CodecPrivate element. Some audio codecs don't (MP2/3, AC3, old way of storing AAC ...), some do (new way of storing AAC, Vorbis...).

The file you've uploaded is not affected by the bug that I've fixed today. That bug was only happening for source containers that chose the very same timecode for a lot of samples -- MP4 in today's case. In that file contained the same timecode for over half a second of samples; this is not only bad for playback but also bad for storage in other containers.

Your MPEG2 file seems fine to me.Yet it does not work with the MPC-HC built in splitter.
Note the file does work if it's remuxed through eac3to

Maybe the MPC-HC built in splitter expects the CodecPrivate element always

Mosu
30th May 2009, 22:26
I don't know, I don't care. MPC-HC is not my product. Haali's splitter works just fine. So this is a bug or missing feature (or whatever you want to call it) in MPC-HC.

tetsuo55
30th May 2009, 22:28
This post:http://forum.doom9.org/showthread.php?p=1291787#post1291787
It's a quote of the matroska specs that says for mpeg2 CodecPrivate appears required

Mosu
30th May 2009, 22:49
Ok, now I see what you mean. I misunderstood earlier -- I thought that the audio track was posing the problem and not the video track. I've replied to the thread you've linked to as you've probably seen already. This is indeed a bug in mkvmerge but also a bug in MPC-HD; I'm actually quite surprised -- the code is there to write CodecPrivate for MPEG-1/2 but is not called. I'm pretty sure that this was working a couple of versions ago, and fixing it is rather easy.

Mosu
31st May 2009, 00:18
Here's a build that creates a CodecPrivate element for MPEG-1/2 video tracks again. I also found out why I disabled this in the first place (see https://www.bunkus.org/bugzilla/show_bug.cgi?id=174 in case you're curious) but changing it back does not harm anything.

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.9.0-build20090531-136-setup.exe

allak
31st May 2009, 12:12
Mosu, I don't know if this may help you, but I can confirm that, at least under some circumstances, the code is there to write CodecPrivate for MPEG-1/2 was still working in mkvmerge v2.8.0.

I've got a mkv I did mux last month and it is working fine.




|+ Segment information
| + Timecode scale: 1000000
| + Muxing application: libebml v0.7.7 + libmatroska v0.8.1
| + Writing application: mkvmerge v2.8.0 ('The Tree') built on May 9 2009 18:02:06
| + Duration: 6492.200s (01:48:12.200)
| + Date: Wed May 20 19:22:13 2009 UTC
| + Segment UID: 0x99 0x19 0x4d 0xc7 0x0c 0x35 0x55 0xfb 0x9c 0xb0 0xc8 0x52 0x60 0x8c 0x2a 0x34
|+ Segment tracks
| + A track
| + Track number: 1
| + Track UID: 1
| + Track type: video
| + Enabled: 1
| + Default flag: 1
| + Forced flag: 0
| + Lacing flag: 0
| + MinCache: 1
| + Timecode scale: 1
| + Max BlockAddition ID: 0
| + Codec ID: V_MPEG2
| + Codec decode all: 1
| + CodecPrivate, length 152
| + Default duration: 40.000ms (25.000 fps for a video track)
| + Language: und
| + Video track
| + Pixel width: 720
| + Pixel height: 576
| + Interlaced: 0
| + Display width: 1024
| + Display height: 576

ibanez
2nd June 2009, 05:19
OK is sup support still on the table?

SUP support would be fantastic.

Thanks for a great application.

Isochroma
6th June 2009, 03:03
WMV support would be fantastic.

Many thanks for this great application.

Mosu
6th June 2009, 10:05
Sorry, but WMV support will not happen.

LeMoi
6th June 2009, 11:28
WMV support would be fantastic.

Many thanks for this great application.

http://forum.doom9.org/showthread.php?p=1283300#post1283300

Mosu
6th June 2009, 11:32
Just as an update: MPEG transport stream support is one of the next features I will implement; probably not THE next feature, but the next big one.

Mosu
7th June 2009, 18:32
Hey,

I've released mkvtoolnix v2.9.5. This release contains contains the usual mix of bug fixes, new features and smaller enhancements. Also some of the command line options have been renamed (check the ChangeLog for details). The old versions are still working for the time being, and users of mmg aren't affected by this change anyway.

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

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

The Linux binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 2.9.0:

------------------------------------------------------------
2009-06-07 Moritz Bunkus <moritz@bunkus.org>
* Released v2.9.5.

2009-06-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The handling of TrueHD/MLP audio in MPEG program streams was broken resulting in many dropped packets.
* all: bug fix: There was the possibility that invalid memory access occured and e.g. mkvmerge crashed on systems with the posix_fadvise() function (mainly Linux) if mkvmerge was opening several files from certain file systems (e.g. VFAT). Apart from obvious crashes the only other side effect was that the posix_fadvise() function would not be used resulting in slightly worse I/O performance.

2009-05-31 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Improved the control over which tags get copied from a source file to the output file. The old option "--no-tags" was replaced with the new options "--no-global-tags" which causes global tags not to be copied and "--no-track-tags" which causes track specific tags to not be copied. The new option "--track-tags" can be used to select tracks for which tags will be copied. The default is still to copy all existing tags.
* mkvmerge: new feature: Included chapters, global and track specific tracks in the output of mkvmerge's identification mode.
* mkvmerge: Renamed a couple of command line options to make the command line interface more consistent: "--no-audio", "--no-video", "--no-subtitles", "--no-buttons", "--audio-tracks", "--video-tracks", "--subtitle-tracks", "--button-tracks". The old versions of these options "--noaudio", "--novideo", "--nosubs", "--nobuttons", "--atracks", "--vtracks", "--stracks" and "--btracks" still work.
* mkvmerge: bug fix: The sequence header of MPEG-1/2 video tracks is put into the CodecPrivate again while still leaving sequence headers in the bitstream as well. This is more compatible with some existing parsers.

2009-05-30 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Removed the check if the user has added tracks and files before starting mkvmerge because mkvmerge itself is able to create track-less files (e.g. chapters only). Fix for bug 402.
* mkvmerge: bug fix: Improved the handling of consecutive AC3 packets with the same timecode (e.g. if AC3 is read from MP4 files). Fix for bug 403.

2009-05-27 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed an endless loop in the TrueHD code occuring when the TrueHD stream is damaged somewhere.

2009-05-26 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed the detection of MPEG transport streams with other packet sizes than 188 bytes (e.g. 192 and 204 bytes).

2009-05-24 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The detection of invalid padding packet lengths in the MPEG program stream reader was improved to not produce as many false positives. Patch by Todd Schmuland (see AUTHORS). Fix for bug 393.

2009-05-23 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for the FourCCs ".mp3" and "XVID" in QuickTime files.
* mmg: bug fix: Pressing 'return' in the job dialog will close the dialog on Windows, too. Fix for bug 392.

2009-05-22 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Fixed the behaviour of how mmg sets the output file name automatically if the option is enabled. If the user adds more than one file then the extension of the output file name is set each time a file is added and not only when the first one is. The full file name and path will only be set when the first file is added. Fix for bug 391.
------------------------------------------------------------

Have fun.

Isochroma
12th June 2009, 02:34
The program always adds a shortcut to itself to the All Users / Programs folder during setup. I don't want it there and every setup I delete it. The installer doesn't ask. It asks other things, but not that. It just goes ahead and bullies my folders. It is a master of preconception. I am a worker of post-deception.

Mosu
12th June 2009, 07:11
Then please provide a patch for my NSIS installer script. Thanks. Or you could skip the Windows installer altogether and use the .7z archive which doesn't do anything to the start menu or registry at all.

flebber
12th June 2009, 15:20
This may be a strange question but is there a way I could make mkvtoolnix remux an mkv to incorporate updated tag information.

vlc uses xspf xml format for their playlist. Due to a lot of previous encodes I have done in mkv without much tagging I want to go back and update the tags in the metadata.

If i create a script to read file names and update an xml format will mkvtoolnix be able to update the metadata without the need to remux all data to a new file?

Mosu
12th June 2009, 15:25
No, mkvmerge only does full remuxes. mmg can only update the header fields without a full remux, and that's not scriptable.

LeMoi
20th June 2009, 11:14
Would it be possible to add "mis" language to the top language list ? I often use it but i have to scroll the list to the 'm' letter and it's quite long ^^ thanks in advance

pdanpdan
20th June 2009, 20:12
Would it be possible to add "xxx" language to the top language list
I have a feature request also - to allow us to define the order of languages in the lists (I think that if someone's language is not in the top list he has to search for it very often). Maybe a text file with the languages list, one on each row, that can be reodered and saved and imported.
Thanks for the program.

Mosu
2nd July 2009, 10:21
Hey,

I've released mkvtoolnix v2.9.7. This release contains mostly bug fixes and two prominent changes to mmg.

1. Chapters and tags are now handled in the same way that tracks are: they can be checked individually, and properties like charset can be set for each entry.

2. The user can now change the list of "common" languages that appear at the top of language drop down boxes.

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

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

The Linux binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 2.9.5:

------------------------------------------------------------
2009-07-01 Moritz Bunkus <moritz@bunkus.org>
* Released v2.9.7.

2009-06-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The handling of NVOPs in native MPEG4 part 2 video storage has been improved. NVOPs are dropped again both from packed and non-packed bitstreams, and timecodes are adjusted to match the number of dropped frames.

2009-06-25 Moritz Bunkus <moritz@bunkus.org>
* mmg: The "preferences" dialog has been split up into several tabs. Some other preferences available in other dialogs have been merged into the "preferences" dialog.
* mkvmerge: bug fix: The I frame detection for AVC/h.264 video has been fixed. Sometimes a single I frame was recognized as two or more consecutive I frames resulting in garbled display and wrong timestamps. Fix for bug 415.

2009-06-23 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: The list of common languages can be configured by the user via the 'preferences' dialog.

2009-06-22 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: The programs do not try to close iconv handles -1 anymore which resulted in segfault during uninitialization on some platforms (e.g. FreeBSD, Mac OS X). Fix for bug 412.

2009-06-21 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Complete rewrite of the code for the native storage mode for MPEG4 part 2 video tracks. Fix for bug 298.

2009-06-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Made the detection rules for raw MP3, AC3 and AAC audio files more strict. This avoids a mis-detection of certain files, e.g. AVC/h.264 ES files being misdetected as MP3 files. Fix for bug 414.

2009-06-14 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Appending MP4 or OGM files with chapters will merge the chapters from all appended files and not just take the chapters from the first file and discard the chapters from the following files. Fix for bug 397.
* mkvmerge, mmg: new feature: The language for chapters read fromfiles such as OGM and MP4 files can be chosen with the --chapter-language command line option. Fix for bug 399.
* mkvmerge, mmg: new feature: Chapter and tag information contained in source files are now shown in the "track" selection box and can be toggled individually. The user can set the charset for chapters if the source file's chapters are not encoded in UTF-8 (e.g. in some OGM/MP4 files). The old file specific checkboxes "no tags" and "no chapters" have been removed. Fix for bug 400.

2009-06-13 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: The chapter editor was corrupting Matroska files if the chapters were saved to a file twice in a row without reloading them from the Matroska file.

2009-06-09 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: If the user selects the option "Verify" from the "Chapters" menu then a message will be shown even if the validation succeeded. Fix for bug 410.
* mmg/mkvmerge: bug fix: Adding MP4 files with chapter entries that are not encoded in UTF-8 will not result in mkvmerge aborting with a message about invalid UTF-8 sequences anymore. Fix for bug 408.
----------------------------------------------------

Have fun.

tetsuo55
2nd July 2009, 10:42
Thanks for the release.

I will make sure to remux my MPEG4 part 2 and MPEG4 part 10 files with the new version.

Liisachan
2nd July 2009, 12:18
2. The user can now change the list of "common" languages that appear at the top of language drop down boxes.

Hi, thank you.
I'm trying to test the above feature but getting this error message:


---------------------------
Invalid country selected
---------------------------
The country '' is not a valid ccTLD and cannot be selected.
---------------------------
OK
---------------------------

Any suggestion?


Edit:
Although this error message is annoying, the list is updated properly, with selected languages on top, next time you restart MMG.

Mosu
2nd July 2009, 12:47
That error message refers to the "chapters" page of that dialog. It will be fixed in a future release because you may indeed not select a country code.

Liisachan
2nd July 2009, 13:08
confirmed. no error message if you set a dummy, benign thing in the Chapters tab, such as eng->uk.
However, this means that when a user wants to change the Languages settings, he or she is forced to update the Chapters settings,
with no good reason. Even if they don't change anything in the Chapters tab, MMG insists it will update the Chapters settings.
Which is probably less than ideal.

Mosu
2nd July 2009, 13:40
Like I said, that problem will be fixed :) E.g. in http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.9.7-build20090702-142-setup.exe (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.9.7-build20090702-142.7z).

73ChargerFan
2nd July 2009, 16:18
Thanks for the update - I've had 3 bad 264 muxes in the last day, just tested them out and they are all garbled. I'll try the new one.

Request again - support of TS & M2TS files.
I had muxed by BDs with DTS-MA to TS when mmg couldn't, and am now trying to convert the TS files to MKV. I demux with tsMuxeR, which gives elementary .264 streams, then I use mmg - but the video is garbled in mpc-hc. The original TS file is fine. I don't care about subtitle support, just getting the video & audio out.

Mosu
2nd July 2009, 16:22
Request again - support of TS & M2TS files.

I hate to repeat myself but: Yes, supoprt for transport streams will be implemented in the near future, and no, I don't have an ETA.

73ChargerFan
2nd July 2009, 16:22
Another request - create chapters every 5 minutes

The last chapter should be minimum 5 minutes (credits), e.g. 122 minute film has chapters at 0:00, 0:05, ..., 1:50, 1:55

I've got txt files set up for this, but have to edit them each time to fit the movie. I think this is would be a very useful feature, because it would allow using the >> button to skip 5 minutes at a time.

Thank you.

Mosu
2nd July 2009, 16:26
No, sorry. I've refused to implement such features in the past due to them being either way too specialized to be of use for more than a handful of persons or the amount of work being way, way too much to make such a feature flexible enough to appeal to many people.

sneaker_ger
2nd July 2009, 16:43
Thanks for the release.

I will make sure to remux my MPEG4 part 2 and MPEG4 part 10 files with the new version.

Please note that native MPEG4 part 2 mkv files created from VfW material with versions prior to 2.9.7 are not fixed by remuxing them. Mosu says it's not possible.

Mosu
2nd July 2009, 16:49
Please note that native MPEG4 part 2 mkv files created from VfW material with versions prior to 2.9.7 are not fixed by remuxing them. Mosu says it's not possible.

That's correct.

1. Only merging files with "--engage native_mpeg4" has been affected by the changes in 2.9.7. Normal xvid/divx/MPEG4 part 2 merging without that --engage option has NOT changed.

2. Remuxing files with V_ISO/MPEG4/{SP,AP,ASP} codec IDs that have been written by mkvmerge versions before 2.9.7 cannot be fixed by a remux with 2.9.7 because too much valuable timecode and frame information has already been lost in the first step.

3. The native muxing will be made the default (and probably the only choice) in mkvmerge 3.0.0.

tetsuo55
2nd July 2009, 17:33
Too bad :(

stax76
4th July 2009, 15:53
Kann man mkvmerge so einstellen das die Konsole englisch ausgibt und deutsche Umlaute in den Pfaden korrekt dargestellt werden?

Mosu
4th July 2009, 16:15
Kann man mkvmerge so einstellen das die Konsole englisch ausgibt und deutsche Umlaute in den Pfaden korrekt dargestellt werden?

This is an English forum, so I'll reply in English.

The language mkvmerge uses and the charset it uses are two distinct things. The language and charset default to the system values. How those values are determined depends on the operating system you're running mkvmerge on.

Generally there are two options for changing these aspects: --ui-language and --output-charset. The former sets the language and the latter changes the charset that all tools use for outputting to the console.

On Windows you shouldn't have to change the output charset as mkvmerge detects the charset used by the console itself. Changing the output charset is only useful if you redirect the output, e.g. to a text file, and use an editor for looking through that text file. Changing the language on Windows is easy enough, just add "--ui-language en" to the command line.

On non-Windows systems mkvmerge usually gets its defaults from the locale environment variables (LC_ALL, LC_MESSAGES and LANG are examined in this order. The first one that is set is chosen.). You can still use --ui-language and --output-charset, or you could simply change the environment variable appropriately (e.g. "LC_MESSAGES=en_US.UTF-8 mkvmerge ..."). Unlike Windows the --ui-language parameter actually takes the same format as the LC_* and LANG variables meaning that for English you'll have to use "en_US" and not just "en" as on Windows.

Note for non-Windows systems: setting LC_MESSAGES to "en_US" (without an explicit charset) means that the charset defaults to "ASCII" and not to UTF-8. If you need German Umlaute then your Linux system is usually either set up for ISO-8859-15 or for UTF-8. Achieving the latter is easy: "en_US.UTF-8". However, the former is usually not supported out of the box by most Linux distributions. You'll have to use something like "en_US@euro" and use locale-gen to define en_US@euro as being ISO-8859-15, or you'll have to change en_US itself to map to ISO-8859-15. How that is done depends heavily on the distribution in question.

stax76
4th July 2009, 16:52
Thanks for the quick and detailed explanation, it didn't help with none of both issues.

mkvmerge.exe -h -ui-language en -> Gespr"chigkeit erh"hen
mkvmerge.exe -h -ui-language en --output-charset en -> Gesprächigkeit erhöhen

edit: I'm on Win 7 32bit english with german locale, if it helps you I can boot into XP german and check if it behaves different.

Mosu
4th July 2009, 17:10
There have to be two dashes with long options, not just one. --output-charset en won't work because "en" is not a valid charset. Just leave it out. It works nicely on Windows XP and Vista for me, and I don't have access to Windows 7 -- nor do I know which damn charset Windows 7 uses for its console. You could try "--output-charset CP850" or "--output-charset CP1252" or something like that.

Please read http://forum.doom9.org/showthread.php?p=1288702#post1288702 for an explanation of the issue of code pages on Windows (short version: Windows uses two different ones, one for the system and one for the cmd.exe thingy. Maybe they changed that in Windows 7 for cmd.exe).

stax76
4th July 2009, 18:47
I've entered chcp to find out the codepage, it's 850 on my english Win 7 system and Umlaute are NOT displayed correctly. On my german XP system codepage is also 850 but Umlaute are displayed correctly. Would it be possible that mkvmerge would output Umlaute on my system correctly without requiring me to use '--output-charset CP1252'?

Mosu
4th July 2009, 19:00
Not at the moment. And I won't spend any time on it until I have a Windows 7 installation myself which will most likely not be for the next couple of months.

stax76
4th July 2009, 19:11
I guess the problem occurs also on english XP and Vista, the thing is english people use english versions and german people use german versions which is the common case which don't cause the issue I guess. I'm german but use a english version and this is uncommon.

How about using GetACP instead of GetOEMCP for determining which CP to use for console output? Would this possibly break something?