mkvtoolnix 4.1.1 released

[madshi]

we want that ts/m2ts container support too by haali splitter, any chance?
You're asking this question in the wrong thread and to the wrong people. I don't think Haali is subscribed to this thread.

[nautilus7]

Confirmed... Haali spits out all dts-hd info from a mkv.

[Selur]

little request:

Would be nice if one could specify the 'assume framerate' for a video track via command line without the need to create a timecode file first.

Cu Selur

[Atak_Snajpera]

use this
--default-duration 0:xxfps

[Selur]

thanks :)

[Isochroma]

Suggested features for new builds:

1. Auto-set added tracks to selected language, if they have no language to begin with.

2. When warnings popup, please oh please make the dialogue have focus so I can just hit Enter rather than having to click to select the window first.

3. When adding both a video and audio track in one drag-and-drop operation, the app sets output type to MKS; why?

4. Option: set default framerate to user-defined value on tracks that would otherwise require it, rather than it always being auto-set to 25.

[~bT~]

this might be a stupid question considering that I have been using this tool for a long while now.

does it save to .mp4?

[buzzqw]

does it save to .mp4?

no... it's MKVtoolnix ;)

BHH

[~bT~]

^ thanks. i thought so. its just someone was telling me otherwise.

[buzzqw]

@~bT~
you can use YAMB, not full featured as mkvtoolnix but quite friendly

BHH

[stax76]

The docs use unicode minus (&minus == 0x2212) and the cmdl parser don't understand it. You can't copy/paste a switch from browser to shell and the browser search fails.

[Mosu]

The docs use unicode minus (&minus == 0x2212) and the cmdl parser don't understand it. You can't copy/paste a switch from browser to shell and the browser search fails.

True. Wasn't my decision, though... groff does it by itself (for those who don't know what groff is: it's a program for turning Unix manual pages into other data, e.g. HTML).

I've fixed the HTML docs by replacing − with a normal "-" instead:

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.2.0-build20080317-1.rar

No other changes in this build.

[stax76]

Thanks for fixing it mosu, I'll update StaxRip (http://forum.doom9.org/showthread.php?t=102652&page=86)to use this build (I host all apps myself now).

[stax76]

it would be handy if mkvextract would demux everything in case the only argument is a mkv file.

[plugh]

mkv noob here...

I was experimenting with mkvmerge and mkvextract gui's and have a couple questions.

1) When I mux Xvid (from avi file) into mkv, I can optionally choose a "FourCC". It seems as though whether I leave the option alone (blank) or explicitly choose 'XVID', mkvextractgui reports the resulting stream in the mkv file as "(V_MS/VFW/FOURCC,XVID)".

The little bit of reading I've done about mkv 'codec ids' would lead me to believe that this is what is referred to as 'avi compatibility mode'. I am ALSO under the impression that there is a NON-'avi compatible' way / format / id / ??? to include 'MPEG4-ASP' video (such as, for example, Xvid) into the file.

How?

2) When I originally muxed my audio and video into the mkv, I specified the audio delay. When I extract the streams back out to files, I can't seem to find the original delay value anywhere (which I would need for a later re-mux).

Is it lost in the process?

Thanks!

[chros]

2) When I originally muxed my audio and video into the mkv, I specified the audio delay. When I extract the streams back out to files, I can't seem to find the original delay value anywhere (which I would need for a later re-mux).

Is it lost in the process?
No, it's zeropadded or cutted when you mux it. So, when you demux it it's still in sync ...
Try it with a small sample ...

[stax76]

In case anybody is interested, StaxRip demuxes now all streams from mkv using mkvextract: http://forum.doom9.org/showthread.php?p=1121319#post1121319

[Brother John]

I am ALSO under the impression that there is a NON-'avi compatible' way / format / id / ??? to include 'MPEG4-ASP' video (such as, for example, Xvid) into the file.
Use Xvid_Encraw and don't output to AVI. This will produce a "native" MPEG-4 stream with a codec ID of iirc MPEG4/ISO/ASP.

[Eragon4ever]

The little bit of reading I've done about mkv 'codec ids' would lead me to believe that this is what is referred to as 'avi compatibility mode'. I am ALSO under the impression that there is a NON-'avi compatible' way / format / id / ??? to include 'MPEG4-ASP' video (such as, for example, Xvid) into the file.

How?

There is the --engage native_mpeg4 switch but I wouldn't recommend to use it. Last time I tested it the resulting files weren't playing correctly.

[plugh]

Thanks for the answers.
encraw isn't an option at the moment.
Is there a way to, uh, invoke the --engage via mmg?

fyi - I sort of found a way; avidemux will read avi and write mkv, with the xvid tagged as mpeg4/iso/asp. Unfortunately, I ran into a 'large file' issue with that approach.

For now I'm just leaving it as vfw/fourcc, as both xbox/xbmc and AppleTV/Perrian seem willing to accept the file this way.

[Eragon4ever]

Is there a way to, uh, invoke the --engage via mmg?
Muxing -> Add command line options
But you have been warned...

[plugh]

Muxing -> Add command line options
But you have been warned...

Acknowledged. And thanks...

(Oh no! the 'Laughing Man'! :eek: run away run away)

[plugh]

OK New question... I have processed a transport stream capture. I have video (xvid), audio (aac) and subs (srt).

The subs were created by extracting the closed caption data from the stream with 'ccextractor'. This utility will produce text lines in the srt file with leading blanks, in order to simulate the Closed Caption screen positioning.

I mux'd the srt into an mkv with mmg, but the horizontal positioning was not present on playback. I extracted them back out with mkvextractGUI, and sure enough, the leading blanks were gone. I'm guessing mkvmerge stripped them.

Is there a way to preserve the leading spaces?

[Mosu]

Is there a way to preserve the leading spaces?

The only way is to use this bugfixed version: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.2.0-build20080414-1.rar

[delacroixp]

Is there a way to preserve the leading spaces?
The only way is to use this bugfixed version: mkvtoolnix-unicode-2.2.0-build20080414-1 (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.2.0-build20080414-1.rar)
Nice one.


:):devil::D
Pascal

[plugh]

I'll give it a whirl.

Thanks!

[Tima]

I have a AVC + AAC + AAC Matroska file, which has been muxed by mkvmerge 1.0.2. The opening and especially seeking in player were extremely slow, so I decided to remux it with new mkvmerge. I tried versions 2.2.0-release, 2.2.0-latest_alpha and 1.4.0 -- all they fail to remux the file with following error:

Error: 'E:\The_Story_of_O.mkv' track 1: Could not extract the decoder specific config data (AVCC) from this AVC/h.264 track.

[NanoBot]

Hi there,

I think I found a bug in the h.264 import module of mkvtoolnix, but I am not sure about that. So I will describe the symptoms and perhabs somebody more familiar with h.264 streams and mkvtoolnix might be able to tell if it really is a bug:

Some time ago I recorded some DVB transport streams containing one h.264 video stream and one AC3 audio stream from a german tv station. I want to include additional audio streams, subtitle streams and chapter information ( ripped from SD DVDs of the same titles I own ). So I demultiplexed the ts to es using either "xport.exe" or "tsMuxeRGUI", and remultiplexed them to mkv using the latest version of mkvMerge GUI.

But with one of those recordings ( it is Episode6 in 1080i50 ) I ran into problems concerning the play length of the movie. The original ts plays fine with mpc and shows a playtime of 193813 video frames which equals 02:09:12.480 at 25fps. But after remultiplexing it to mkv, the playtime is shown as 2:09:30, which of course should not happen.

When I am using graphedit with haalis simple media splitter and haalis matroska muxxer, the resulting mkv file has the correct playtime, but when trying to navigate within the new file, mpc freezes. If I am remultiplexing the elementary streams to a transport stream using tsmuxeRGUI, the new ts also has a correct playtime of 2:09:12

In my attempt to find out the reason to this behavior, I analyzed the ts and the h.264 es with the trial version of elecards streamEye and found, that the encoding format is changing from frame based to field based at the beginning of a GOP at a playtime of 0:00:32:480 and goes back to frame based within a GOP at a playtime of 0:00:37:680. There may be more of those changes within the stream, but until now I did not search for more occurrences. Unfortunately I am not able to tell if they use PAFF oder MBAFF encoding since I do not know where to look in the h.264 header for this information.

Now back to mkvmergeGUI: What I suspect is, that mkvmerge accidentally counts the fields as frames and therefore produces a mkv file with a too long playtime.

If it would be helpful I am able to supply a small piece of the transport stream or the elementary stream containing such a "change" situation. But before doing that I would like to ask if this would comply to the rules of the forum, since it would be a ( rather small ) part of copyrighted material.

C.U. NanoBot

[hubereevez]

mkvmerge crash when adding an ogm file (see jpg)

Worked with 2.1.0 but without the chapters

Here is my ogm file :

Général
Complete name : H:\test.ogm
Format : OGG
File size : 702 Mio
Duration : 2h 42mn
Overal bit rate : 603 Kbps
Movie name : Me
Performer : Me

Vidéo
Format : MPEG-4 Visual
Codec ID : DX50
Codec ID/Hint : DivX 5
Width : 496 pixels
Height : 208 pixels
Display aspect ratio : 2.35
Frame rate : 25.000 Im/s

Audio
Format : Vorbis
Format settings, Floor : 1
Duration : 2h 42mn
Channel(s) : 2 canaux
Sampling rate : 48.0 KHz
Language : english

Texte
Language : french

Chapitres
01 : 00:00:00.000 Chapter 1
02 : 00:07:51.840 Chapter 2
...




Thanks

[delacroixp]

I'm pleased to hear that DivX 7 will be supporting the MKV container:

DigitAl56K - DARC (DivX Advanced Research Team) (http://forum.doom9.org/showthread.php?p=1152183#post1152183) : DivX 7 will use the MKV container format ! That's right, you heard it here first: our new format does not use AVI !

It's all good !


:):devil::D
Pascal


ps
I know that nothing is a done deal untill the fat lady sings but hopefully MKV will acquire that extra mile to sort the menu system.

[Mosu]

mkvmerge crash when adding an ogm file (see jpg)

Try http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.2.0-build20080515-1.rar

[hubereevez]

Works now ! Thks Mosu :)

[GasKid]

Hi,

I have an mkv file I muxed with mkvmerge earlier, but I forget the audio delay I set. I googled and found this thread (http://forum.doom9.org/showthread.php?t=111746). It tells me to "try mkvinfo -v and see when the timecode of the first audio packet".

I did so, and got something like this:
| + Block (track number 2, 8 frame(s), timecode 0.038s = 00:00:00.038000000)
But I remember that I set a negative value.

Then I did some tests, and found out that when setting a positive delay in mkvmerge, everything is OK, but when the value is negative, mkvinfo will report a positive timecode.

Haven't checked how's the output files like yet, so I don't know whether it's mkvmerge's problem or mkvinfo's, or just my problem. I'll check them asap.

Can someone please help me? Thanks.

btw, I'm using mkvtoolnix 2.2.0, the audio is in aac format.


====
Sorry for the late update.
I checked the file, the audio is properly adjusted. So it appears to be mkvinfo's problem?
I was using --delay to adjust audio delay.

[madshi]

@Mosu,

all the MKV muxers remove the AUDs (00 00 01 09 xx) when muxing h264 streams to MKV. That's alright, of course. But that means if we mux a raw h264 stream to MKV and then demux it again, we lose bit perfectness. Which is quite ugly.

So here comes my feature wish: Could you please readd AUDs into the stream when demuxing h264 streams with mkvextract? I think/hope it shouldn't be difficult to do.

Thank you... :)

[Mosu]

Do you have a small sample file with such elements? I don't seem to have any, so testing might be a bit difficult.

[Mosu]

I have an mkv file I muxed with mkvmerge earlier, but I forget the audio delay I set. I googled and found this thread (http://forum.doom9.org/showthread.php?t=111746). It tells me to "try mkvinfo -v and see when the timecode of the first audio packet".

I did so, and got something like this:
| + Block (track number 2, 8 frame(s), timecode 0.038s = 00:00:00.038000000)
But I remember that I set a negative value.

Then I did some tests, and found out that when setting a positive delay in mkvmerge, everything is OK, but when the value is negative, mkvinfo will report a positive timecode.

When you delay a track then the delay is added to all timecodes. If your delay is negative then some packets may end up with negative timecodes. These packets are dropped and not written to the output file (!). Therefore you should never see packets with negative timecodes in mkvinfo's output.

There's no way to retrieve the delay used during muxing reliably.

[madshi]

Do you have a small sample file with such elements? I don't seem to have any, so testing might be a bit difficult.
Don't you have any HD DVD and Blu-Ray h264 samples? I believe most of them (or all?) have AUDs. But I'll upload a few samples...

[sehgal.v7]

@Mosu
Reference to above question
hxxp://rapidshare.com/files/139273329/Original.h264

Original Raw Stream size - 10,485,888
Muxed with mkvMerge size - 8,478,255
Extracted raw stream with mkvExtract - 8,469,695

Original Stream to TS container (TSMuxer) > TS to MKV (eac3to) - 10,485,888 > 10,775,784 > 8,473,127

[madshi]

Here are 2 trailers with AUDs, one from a HD DVD, one from a Blu-Ray:

http://madshi.net/h264.evo
http://madshi.net/h264.m2ts

Thanks for looking into this... :)

P.S: Here's another thing (not as important, though): Some MKVs have the sequence headers stored in both the "codec private" data and in the frame data itself, too. Now as a result when demuxing a h264 stream with mkvextract, the sequence headers are stored twice in the beginning of the h264 stream. It would be great if mkvextract could check if the codec private data is identical to the beginning of the first frame. In that case the codec private data should not be prepended when demuxing the h264 stream.

P.P.S: The Blu-Ray trailer is still uploading. Should be ready for download in about 1 hour.

[Mosu]

Ok, I will not implement such a feature. There are several reasons. The first is that it isn't one of Matroska's design goals to have bit-identical streams after putting content into Matroska and extracting it from it again. Matroska has always been about being a comprehensive storage container for a multitude of content types, and efficiency has also been at least a secondary goal. If the AUDs are not neccessary for playback from containers other than MPEG-2 (E)VOB or whatever then there's no reason to keep them when you put a stream into a Matroska container.

A third reason is that it is technically impossible (or nearly so) to keep the stream bit-exact. For example, in the raw h.264 streams there are AUDs before the first SPS and PPS NALUs. However, the SPS and PPS NALUs are combined into the AVCC which is in turn stored in Matroska's CodecPrivate element (the same is done for storage of h.264 inside MP4 files). There's simply to space for AUDs in the AVCC.

However, it might be possible to modify mkvextract to create AUDs on its during extraction. There would be a separate option which turned this feature on, just like there's such an option in x264. The question is: how important is such a feature? I don't have much free time, and I'd rather not waste it on a feature that no one except one or two people might find useful.

[madshi]

A third reason is that it is technically impossible (or nearly so) to keep the stream bit-exact. For example, in the raw h.264 streams there are AUDs before the first SPS and PPS NALUs. However, the SPS and PPS NALUs are combined into the AVCC which is in turn stored in Matroska's CodecPrivate element (the same is done for storage of h.264 inside MP4 files). There's simply to space for AUDs in the AVCC.
I agree about AVCC.

But: IIRC earlier versions of mkvmerge stripped SPS and PPS NALUs from the frame data. At that time it made sense to prepend the codec private data when demuxing. But I think you changed mkvmerge to not strip SPS and PPS, anymore. Right? So I think prepending the codec private data in mkvmerge doesn't really make sense, anymore. What do you think?

However, it might be possible to modify mkvextract to create AUDs on its during extraction. There would be a separate option which turned this feature on, just like there's such an option in x264. The question is: how important is such a feature?
That is a good question and to be honest I'm not sure about the answer. What I can say is that my own tool (eac3to) depends on the AUDs as frame delimiters. So my tool cannot handle h264 bitstreams without AUDs in them. Now of course I could rewrite my tool to add support for h264 streams without AUDs in them, but to be honest having AUDs in the stream makes life so much easier. No need to write complicated algorithms to find out which slices belong together and which don't, when there are AUDs in the stream...

[Mosu]

I agree about AVCC.

But: IIRC earlier versions of mkvmerge stripped SPS and PPS NALUs from the frame data. At that time it made sense to prepend the codec private data when demuxing. But I think you changed mkvmerge to not strip SPS and PPS, anymore. Right? So I think prepending the codec private data in mkvmerge doesn't really make sense, anymore. What do you think?

True, but mkvextract has to scan the stream before it can decide whether or not the AVCC has to be prepended or not. As no program so far has had a problem with multiple SPS and PPS NALUs (as long as they are identical!) I haven't seen the need for more complicated NALU scanning code.

That is a good question and to be honest I'm not sure about the answer. What I can say is that my own tool (eac3to) depends on the AUDs as frame delimiters. So my tool cannot handle h264 bitstreams without AUDs in them. Now of course I could rewrite my tool to add support for h264 streams without AUDs in them, but to be honest having AUDs in the stream makes life so much easier. No need to write complicated algorithms to find out which slices belong together and which don't, when there are AUDs in the stream...

I see, but I'm afraid that the reasons I've stated (especially space efficiency) are more important to me ;) Most tools I know do not write AUDs by default (or cannot do it at all). So you cannot rely on AUDs being present in eac3to.

[madshi]

True, but mkvextract has to scan the stream before it can decide whether or not the AVCC has to be prepended or not. As no program so far has had a problem with multiple SPS and PPS NALUs (as long as they are identical!) I haven't seen the need for more complicated NALU scanning code.
Yes, that's why I said that it's not so important. I just find it cosmetically ugly to have duplicate SPS/PPS in the demuxed stream... :)

I see, but I'm afraid that the reasons I've stated (especially space efficiency) are more important to me ;) Most tools I know do not write AUDs by default (or cannot do it at all). So you cannot rely on AUDs being present in eac3to.
Most original streams I'm seeing (HD DVD, Blu-Ray, broadcasts) have AUDs in them. So relying on AUDs was not a problem so far. The only problem I'm having is that eac3to can not handle h264 streams demuxed by mkvextract. But I understand that space saving is important for you. And adding a new option is always a lot of work. I know that... :(

[Mosu]

Most original streams I'm seeing (HD DVD, Blu-Ray, broadcasts) have AUDs in them. So relying on AUDs was not a problem so far. The only problem I'm having is that eac3to can not handle h264 streams demuxed by mkvextract. But I understand that space saving is important for you. And adding a new option is always a lot of work. I know that... :(

Probably because all three use MPEG program or transport streams. I'd guess that most direct encodings into MP4 or raw streams do not contain AUDs though.

[madshi]

Probably because all three use MPEG program or transport streams. I'd guess that most direct encodings into MP4 or raw streams do not contain AUDs though.
Yes, that's probably right.

[Mosu]

Hey guys,

here's another release of mkvtoolnix, 2.3.0 this time. There are a couple of new features and a few important bug fixes along with the smaller improvements and changes. The change description from freshmeat.net reads as follows:

Newly supported features include DTS-HD tracks (both "high definition" and "master audio"), Ogg Kate text subtitles, skipping of ID3 tags in AAC and AC3 files, Vorbis-in-AVI, delaying any track type and floating point WAV files. Several bugs were fixed including timecode handling for various track types and use cases, A/V desynchronization in VOBs, wrong VobSub packets and more.

Please note that with 2.3.0 I stop providing binaries for a couple of distributions myself. These include: Ubuntu 6.06 and 6.10; OpenSuSE 10.0; Windows 95/98/ME/NT (meaning that there will be no more
non-Unicode binary for Windows). This does not mean that mkvtoolnix cannot be built on these platforms, just that you'll have to do it yourself.

A note for those who want to compile mkvtoolnix themselves: mkvtoolnix' library requirements have changed slightly. It now uses Boost's regex library instead of the PCRE library. mkvtoolnix can be linked against wxWidgets 2.6.x and 2.8.x as long as the 2.8 version has been built with 2.6 compatibility enabled (building definitely fails with 2.8 without 2.6 compatibility).

Here are the links:

...to the home page:

http://www.bunkus.org/videotools/mkvtoolnix/

...to the source code:

http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-2.3.0.tar.bz2

...to the Windows binary:

http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-2.3.0-setup.exe

As always, binaries for other Linux and Unix distributions are available from the home page.

Last but not least the full ChangeLog since the previous release 2.2.0:

------------------------------cut------------------------------
2008-09-08 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: all: On Unix/Linux rpath linker flags have been removed again (they were actually removed before the release of v2.3.0).

2008-09-07 Moritz Bunkus <moritz@bunkus.org>
* Released v2.3.0.

2008-09-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: improved the timecode calculation for MP3 tracks read from MP4 files. Another part of the fix for bug 165.

2008-09-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: mkvmerge honors the timecode offsets of all streams in a MPEG program stream (e.g. VOB file) fixing audio/video desynchronization. Fix for bug 295.

2008-08-30 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Switched from the PCRE regular expression library to Boost's RegEx library.

2008-08-23 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: DTS-in-WAV handling (14 to 16 bit expansion)was flawed. Fix for bug 288.
* mkvmerge: new feature: Added support for Vorbis in AVI (format tag 0x566f). Fix for bug 271.
* mkvmerge: new feature: Added support for PCM tracks withfloating point numbers (CodecID A_PCM/FLOAT/IEEE). Patch byAurelien Jacobs (see AUTHORS).

2008-08-21 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The fix to the timecode handling for AVC tracks in MP4 files from 2008-04-16 caused certain other MP4 filesto not be read correctly. The video tracks were found, but no frames were read. Fix for bug 294.
* mkvmerge: new feature: Added support for Ogg Kate subtitles. Patch by ogg.k.ogg.k@googlemail.com.

2008-08-20 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mmg: The option "--delay" was removed. The option "--sync" now only modifies the timecodes of a given track. mkvmerge does not pad audio tracks with silence. "--sync"works with all track types now, but using a stretch factor otherthan 1 with audio tracks might not work too well during playback. mmg's inputs for "Delay" and "Stretch by" can be usedwith all track types. Fix for bug 287.

2008-08-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: mmg outputs a more informative errormessage for known but unsupported input file types (e.g. ASF, FLV,MPEG TS) instead of the cryptic "file identification failed".
* mkvmerge: bug fix: The VobSub reader would sometimes read too many bytes for a single SPU packet. Part of a fix for bug 245.

2008-05-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Using BZIP2 compression resulted in broken streams. Patch by Aurelien Jacobs (see AUTHORS).

2008-05-15 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Improved support for WAV files biggerthan 4 GB which only contain a single DATA chunk and a wronglength field for this DATA chunk (e.g. eac3to creates such files).

2008-05-14 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Certain Matroska files with dis-continuous streams (e.g. subtitles) caused huge memory consumption. Fix for bug 281.

2008-04-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: mkvmerge will output a proper error message if it is called with ASF/WMV files instead of detecting other kinds of streams (e.g. AVC ES streams). Fix for bug 280.

2008-04-20 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed an assertion in the OGM reader occuringfor OGM files with embedded chapters. Fix for bug 279.
* mkvmerge: all: On Unix/Linux rpath linker flags are added for library paths given in LDFLAGS and configure's "--with-extra-libs" options.

2008-04-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed wrong timecodes for MP4 files thatcontain video tracks with B frames and edit lists. Fix for bug277. Patch by Damiano Galassi (see AUTHORS).

2008-04-14 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: mkvmerge will not strip leading spaces in SRT subtitles anymore.
* mkvmerge: bug fix: Tuned the file type detection for MPEG ESstreams. Fix for bug 265.

2008-04-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed writing to UNC paths on Windows. Fixfor bug 275.

2008-03-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for skipping ID3 tags in AAC and AC3 files. Fix for bug 204.
* mkvmerge: new feature: Added support for DTS-HD (both "master audio" and "high resolution").
------------------------------cut------------------------------

Have a nice day :)

Mosu

[nautilus7]

Thanks a lot for the update! :)Newly supported features include DTS-HD tracks (both "high definition" and "master audio")You mean High Resolution... :p

EDIT: I believe to forgot to update the program version number to 2.3.0. It displays 2.2.0 in titlebar.

[Mosu]

Thanks for noticing; I'll update the binaries.

[Mosu]

Binaries re-built and uploaded.

[NanoBot]

Hi Mosu,

first of all :thanks: for the new version.

In addition I would like to ask if there are plans to support VC.1 elementary streams as a source format ? ATM the only way to use raw VC.1 streams with mkvmerge is to create a mkv file containing only the video with eac3to/gsdmux first and to import this mkv into mkvtoolnix.

C.U. NanoBot