mkvtoolnix 4.1.1 released

[Mosu]

@Mosu:

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

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.9.7-build20090713-149-setup.exe should work.

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

I know.

Is it per design?

I have no strong feelings one way or the other. But I won't spend any time on it either; so unless someone provides a patch for the NSIS script I won't change it.

[fingershop]

Two possible bugs:

For subtitle tracks, the Default track flag, if set to "default", is being set to Yes instead, as seen when I open the muxed file in MMG. If I set the flag to No, mux, open the file, its now set to Default.

For chapter tracks, the language value is not being saved to the muxed file.

[Mosu]

Two possible bugs:

For subtitle tracks, the Default track flag, if set to "default", is being set to Yes instead, as seen when I open the muxed file in MMG. If I set the flag to No, mux, open the file, its now set to Default.

The value "default" refers to mkvmerge's default settings, not to the actual value of the flag in the resulting file. Setting it to default means "let mkvmerge decide". mkvmerge does indeed set the DefaultTrack flag for the first subtitle track.

Setting the drop down box to "No" results in the DefaultTrack flag being set to "0" for that track for me, so I cannot reproduce this. Anyway, I doubt that there's really a bug.

For chapter tracks, the language value is not being saved to the muxed file.

The language value only applies to chapters read from files which do not contain language tags for the chapters themselves. These include MP4 and Ogg/OGM files, but not Matroska files, as chapters in Matroska files have their own language tags. If you want to force a different language for chapters in a Matroska file you have to use the chapter editor's "adjust values" function.

[fingershop]

The value "default" refers to mkvmerge's default settings, not to the actual value of the flag in the resulting file. Setting it to default means "let mkvmerge decide". mkvmerge does indeed set the DefaultTrack flag for the first subtitle track.


Oh, that explains it then. I'd been thinking that mkvmerge/mmg were muxing transparently, but its applying a default of Yes to the first sub track. For me this behavior is only useful for non-dubbed foreign language movies and shows, which make up at most a tenth of my files.

Could you provide a global setting that would by default copy all track attributes as they are? This would help a lot, especially when re-muxing. When I load a file that contains subs, I'd rather it show "No" if that is what the sub track was originally set to.

The language value only applies to chapters read from files which do not contain language tags for the chapters themselves. These include MP4 and Ogg/OGM files, but not Matroska files, as chapters in Matroska files have their own language tags. If you want to force a different language for chapters in a Matroska file you have to use the chapter editor's "adjust values" function.

I learn more all the time! Thanks. I do think it would be more consistent if mmg treated chapter tracks the same as it does all the other track types that support the language attribute. Setting the chapter language from the track list would also be much easier too.

[nurbs]

Does that really matter? The only player (both hardware or software) I know that displays the default subtitle track without user intervention is VLC.

[Mosu]

Oh, that explains it then. I'd been thinking that mkvmerge/mmg were muxing transparently, but its applying a default of Yes to the first sub track. For me this behavior is only useful for non-dubbed foreign language movies and shows, which make up at most a tenth of my files.

Yeah I noticed this myself yesterday. This is a bug. Normally when left on "default" mkvmerge should honor the source container's setting for the flags. So if you add a Matroska file with a subtitle track and its "default track" flag was set to "no" ("0" in mkvinfo's output), leave the drop down box in mmg on "default" then the subtitle track should have its "default track" flag turned OFF in the output file as well. I'll get it fixed in the next couple of days.

I do think it would be more consistent if mmg treated chapter tracks the same as it does all the other track types that support the language attribute. Setting the chapter language from the track list would also be much easier too.

I will not change that, sorry.

[Mosu]

For subtitle tracks, the Default track flag, if set to "default", is being set to Yes instead, as seen when I open the muxed file in MMG. If I set the flag to No, mux, open the file, its now set to Default.

This problem should be fixed in the following build:

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.9.7-build20090716-158-setup.exe

[fingershop]

This problem should be fixed in the following build:

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.9.7-build20090716-158-setup.exe

Cool! Now it acts like I was thinking it did. Thanks for the quick update.

[fingershop]

Does that really matter? The only player (both hardware or software) I know that displays the default subtitle track without user intervention is VLC.

Zoom Player does as well, and I suppose standards are there for a reason :-)

[fingershop]

I do think it would be more consistent if mmg treated chapter tracks the same as it does all the other track types that support the language attribute. Setting the chapter language from the track list would also be much easier too.

I will not change that, sorry.



I understand. And since we're on the subject... here are two related wishes of mine for your consideration:

1) The ability to add chapter text files to the track list in the same way as other track types. Most chapters I work with are unique to each muxed file and are not global, and I'm constantly forgetting to remove or update the chapters file on the global tab.

2) For chapters in the track list, I'd like to open them in the Chapter Editor to edit them, and then use this edited version when I mux (maybe a "save track changes" command on the Chapter Editor menu?). An alternate version of this wish would be: to allow setting a Delay for chapter tracks, the same as other track types.

A large part of my reason for these requests is that I'm converting my dvd collections to mkv, and I like keeping the original chapters from the dvds. The ripper I use saves the chapters in a file with the same name as the individual vobs and/or individual streams, and I can quickly add these files to mmg by using a wildcard file extension in the Add window -- except for the chapter files that are currently entered separately on the Global tab. After the initial mux, I need to briefly play each file and test the chapters to make sure they line up correctly, and if they don't then I need to adjust their timing. This would be much quicker and easier if adjusting (or editing) chapter timings were possible from the track list.

[Mosu]

I understand. And since we're on the subject... here are two related wishes of mine for your consideration:

1) The ability to add chapter text files to the track list in the same way as other track types. Most chapters I work with are unique to each muxed file and are not global, and I'm constantly forgetting to remove or update the chapters file on the global tab.

No, sorry.

2) For chapters in the track list, I'd like to open them in the Chapter Editor to edit them, and then use this edited version when I mux (maybe a "save track changes" command on the Chapter Editor menu?). An alternate version of this wish would be: to allow setting a Delay for chapter tracks, the same as other track types.

Neither this, again, sorry.

The time I save you is very short compared to the time it would require me to implement such features. And free time is the one thing that I do not have in abundance. I'm not against implementing those features per se. If someone contributed a patch that implemented them I'd happily accept it. That someone just won't be me.

[Mosu]

In case anyone wonders. What I am working on is fixing bugs (always time consuming) and dealing with support requests (even more time consuming). The next two new big features will be support for MPEG transport streams (will take huge amounts of time to do it right -- especially with all those abominations of spec violations out there) and support for specifying cut points ("only copy from timecodes A to B and from K to L", again a lot of work) -- probably in that order.

[Egh]

The next two new big features will be support for MPEG transport streams (will take huge amounts of time to do it right -- especially with all those abominations of spec violations out there)

Good luck with that, that would be a very cool feature. I completely agree regarding all the possible abominations. I don't know any .ts related software which would be able to process properly all the kinds of different .ts files I have. Amongst them, DGIndex is probably most stable, though not for all files. Proper implementation may indeed take a great deal of time...

[Chumbo]

...The next two new big features will be support for MPEG transport streams (will take huge amounts of time to do it right -- especially with all those abominations of spec violations out there) and support for specifying cut points ("only copy from timecodes A to B and from K to L", again a lot of work) -- probably in that order.
These are great features. Thank you for your continued efforts. This tool is invaluable.

[fingershop]

The time I save you is very short compared to the time it would require me to implement such features. And free time is the one thing that I do not have in abundance.

Especially with what you're currently working on.


I'm not against implementing those features per se. If someone contributed a patch that implemented them I'd happily accept it. That someone just won't be me.

Glad to know...

Cheers!

[Mosu]

Especially with what you're currently working on.

In fact I haven't really started working on TS support yet (apart from two, three hours of reading ffmpeg's/mplayer's source code). But what little free time I do have I don't want to spend on other features.

[Snowknight26]

Croatian (scr) seems to be missing from valid language choices in the newest builds. Every time I try to mux an mkv I made with scr set as one of the languages (done with v2.4.1), 2.9.7 says
Error: 'scr' is neither a valid ISO639-2 nor a valid ISO639-1 code. See 'mkvmerge --list-languages' for a list of all languages and their respective ISO639-2 codes.


Granted, I can't find scr in neither list of languages (not surprising as its really hvr), though it's strange that it once worked before. Heck, even eac3to it shows the track as Croatian (confirmed with the -logmkv switch).


Edit: And that solves that..
http://www.bunkus.org/cgi-bin/gitweb.cgi?p=mkvtoolnix.git;a=commitdiff;h=12d4a2f59f2985d89bc735503fdf55390505aa71

[Mosu]

Correct. 'scr' was an obsolete code that has been removed because it has been removed from the official ISO639-2 lists as well.

[mbcd]

I often read (and had) some mkv have errors in EBML-Structure.

Now I´m asking if it is possible to repair such errors. There is no known methode or program for repairing such errors, but fact is:

- These files often play (with errors on scrubbing or jumping on timeline) with some players.
- You can not demux/extract them or do any other things with them until to this specific error-position.

Is it possible to repair those files ?
Recovering Data is of course maybe impossible, but maybe its possible to scan the whole stream an rewrite/reorder/skip some Header, or skip faulty Bytes who are damaged.

I mean: Its better to get a repaired file with "one frame missing" (due wrong EMBL-Entry) as loosing the whole file.

Or maybe: Implementing a check after muxing. These EBML-Errors must have its fault somewhere. Maybe a check after muxing should be fine.

Regards

[Mosu]

My answer will be a bit longer. Get some coffee.

You're talking about two different aspects: error prevention and error recovery.

Error prevention:

I can almost guarantee that the muxing process produces 100% correct EBML structures. The libraries I use have been basically unchanged for five years, and there's not a single confirmed report that one of my tools create corrupt EBML structures. Also having a check after muxing imposes a false sense of security due to several reasons:

1. The library used for validation would be the same library used for creation. If one is serious about validation then this is a no go.
2. Caching. The file just created will always be partially cached by the operating system, and how big this part is depends on various factors like overall memory size, operating system type and version and current memory usage. Therefore the validation process would not be able to test if the file is stored correctly on the hardware ( = hard disc, flash drive etc) reliably.

Which leads me to the two obvious reasons and another not so obvious one why files get corrupted.

The first is bad hardware. This is actually more common than one might think or hope. Having unrecoverable hard disc read errors does occur, it's no myth. While this is usually not a fatal error in the sense that the hard disc cannot be used anymore (due to techniques like sector reallocation) it does mean that data read from that sector is corrupt and that the application has to deal with it. This is even more common for flash drives. Most flash drives use cheap memory, and those chips (cheap or not) are very susceptible to things like environmental conditions etc. Those things are not suited for long-term data storage. I even go so far as to create checksums of all important files that I transfer with flash drives due to past experience with corrupted files.

The second cause is bad transmission. Downloading files from the Internet (no matter if it's legal or not) always poses a risk of data transmission errors. If checksum files are available together with the download then you should always use them to verify data integrity.

The not so obvious reason applies to illegal downloads. There are companies working for the major movie and music studios that create faulty files or files that are 100% garbage, name them after certain popular movies and offer them for download.

Like I already said: use checksum tools for error detection even if you store your files locally. They're freely available and only require a little bit more work.

Now on to error recovery.

The library mkvmerge uses is not good in dealing with faulty files. Sometimes it can recover and continue from the next valid cluster, but often it cannot. There's nothing I can do about it, or at least nothing I'm willing to do due to the huge amount of time involved in creating my own set of libraries and changing about 60% of all of mkvmerge's code that depends on this library either directly or indirectly.

If you need error recovery and restoration of original files then there are external techniques like PAR files that can offer increased security at the cost of a certain percentage of the file's size.

[Kurtnoise]

Hey Mosu,

I've a question regarding the EditionUID value : does the length of this is defined somewhere ? or does any random value is acceptable ?

[Mosu]

EditionUIDs are unsigned integers != 0. Integers in Matroska files can be up to eight bytes long; however, due to the way they're stored in a Matroska file (variable length encoding) only seven bytes can actually be used.

[sneaker_ger]

A small request:

When muxing raw AVC content mkvmerge GUI displays a warning when not setting the FPS field even when feeded with a timecode file. It could lead to irritation as the FPS value is neither required nor used in that case and shouldn't be displayed.

[sneaker_ger]

In the MPC-HC thread there was a small discussion about UTF-8 subtitles. Maybe you could expand the documentation a little and explicitly state that UTF-8 subtitles with BOM are automatically detected as UTF-8 and not with the system charset.

[Mosu]

Maybe, maybe not. Patches are always welcome. mkvmerge handles all text files the same way: if there's a BOM present then the BOM dictates the file's charset. Otherwise an --xyz-option will be used if one is present, and if it isn't then the system's locale is used.

[Gew]

Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 60 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 121 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 147 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 317 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 113 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 146 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 256 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.


Each part is not a lot of data... 100-300 bytes here and there isnt a problem... But when this happens 50 times in a single video, by the end the sound is out of sync. Is there any way to get mkvmerge to ignore these errors and keep these bytes intact? Or possibly replace these bytes with delays equivalent to the timing?

I know I'm bumping a ~2 year old post, but I believe that the question is still relevant. I had the very same issue earlier this day, when trying to MKVmerge an .avi w/ the same "garbage padded" mp3 audio, causing the end-product .mkv to lose it's sync at the end of the video.

I was looking for a solution, so I figured I would try some alternative muxers. I started labbing..


1st tryout: ffmpeg (-vcodec copy -acodec copy -f matroska).

Resulted in a a mkv without sync issues, but with b-frame malfunction, causing picture to become all messy (for a longer time, aswell) after seek.

2nd tryout: AVI-mux

Resulted in an mkv with audio just "cut off" about 10 minutes into the clip, presumably after the first occurrence of audio chop spot. Gah!

3rd tryout: VirtualDubMod

This is where I reached success. The .MKV file was playing fine, seeking was fine, without any sync errors.


MediaInfo reported a slightly outdated libmatroska (go figure :)) though, so just for compatibility I ran "mkvmerge -o finalproduct.mkv vdubmodmuxres.mkv".

Now, it worked fine.

I'm still a bit left out in the cold in regards to what happened under the hood of this machinery, but I assume that VDubM could have made a few assumptions and/or automatized silent mp3 padding when muxing.

Anyways. Worked! :)

[Liisachan]

Interesting. It is not unusual to see AVI that has a broken MP3 frame at the very first or at the very end. Cut-and-pasting AVI segments can easily cause the problem.
One typical situation is the one where the video must have a length of 1001/24000*integer seconds (i.e. 1 frame = about 42ms), and when AVI is edited the last MP3 frame gets broken, cut at the wrong place in the middle, unless the length is exactly 24ms*integer, which is unlikely because of the first condition.
If VDM just does zero padding and reconstructs one complete MP3 frame whenever it finds a broken MP3 frame, then I think the audio will be delayed little by little and getting out of sync anyway. At least in the above situation. If AVI has a lot of broken MP3 frames and the result by VDM is still ok, VDM might be doing both padding and discarding--if the bad MP3 frame is big, zero-pad (or discard it and make up a new one by just repeating the previous MP3 frame), and if the bad frame is smaller discard it. Then the result would be acceptable on average. Who knows?

Anyway, I heard that MKV created by VDM is broken, because like you said, the app is quite old and not maintained. Doing mkvmerge again is a good idea. Hope that will fix the problem. I mean, VDM may fix your problem, but it may create other (not-so-noticeable) problems :)

[Mosu]

Hey,

I've released mkvtoolnix v2.9.8. This release contains contains the usual mix of bug fixes and smaller enhancements. The most prominent enhancement is probably the big speed-up in mmg's header editor for parsing existing files.

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

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

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 2.9.7:

------------------------------------------------------------
2009-08-13 Moritz Bunkus <moritz@bunkus.org>
* Released v2.9.8.
* mmg: bug fix: The inputs for timecode files and the language are deactivated if the user has selected a track that will be appended to another track. Fix for bug 432.

2009-08-06 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: mmg will handle multiple consecutive spaces in the options given with "add command line options" properly and not cause mkvmerge to exit with misleading error messages anymore. The "add command line options" dialog has been reordered, and the drop down box in it is now read-only. Fixes for bug 429.
* doc, mmg: bug fix: The tooltip and documentation for the 'delay' option was misleading. Fix for bug 420.

2009-07-31 Moritz Bunkus <moritz@bunkus.org>
* mmg/header editor: enhancement: Implemented a considerable speedup in the processing of large files.

2009-07-30 Moritz Bunkus <moritz@bunkus.org>
* mmg/header editor: bug fix: The header editor copes better with files that do not contain all mandatory header fields. The missing ones are added or assumed to be default values.

2009-07-23 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: Selecting the translations with the "--ui-language" option did not work on Mac OS X.

2009-07-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed an invalid memory access in the VobSub reader module. Fix for bug 426.
* mmg: bug fix: Tracks added from Matroska files did not get their 'default track' drop down box set correctly if the flag was 'off' in the source file and no other track of its kind hat its 'default track' flag set.
* mkvmerge: bug fix: mkvmerge was wrongly turning the 'default track' flag back on for the first subtitle track muxed from a Matroska file if none of the subtitle tracks muxed had their 'default track' flag set in their source files and if the user didn't use the '--default-track' option for setting that flag explicitely.

2009-07-15 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Running mkvmerge on Windows from an installation directory with two spaces in the path (e.g. "C:\Program Files\Video tools\mkvtolnix") crashed mmg when the user started muxing. Fix for bug 419.

2009-07-13 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Files for which all tracks were disabled were left out from mkvmerge's command line so that tags, chapters and attachments were not copied from such files either.
* mkvmerge: bug fix: Appending MPEG4 part 2 video tracks from Matroska files which contain aspect ratio information will not result in an error message "connected_to > 0" anymore. Fix for bug 427.

2009-07-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed the audio sync for tracks read from AVI files containing garbage at the beginning. Fix for bug 421.
* mmg: bug fix: Trying to save chapters that contain editions without a single chapter entry does no longer result in a crash but a descriptive error message instead. Saving empty chapters to a Matroska file will remove all chapters contained in the file instead of not doing anything. Fixes for bug 422.

2009-07-05 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: enhancement: Implemented speed-ups of up to 50% for middle to larger files.

2009-07-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed reading AVC/h.264 video tracks from OGM files. Fix for bug 418.
* mmg: bug fix: The chapter language for chapters copied from source files (e.g. Matroska, MP4 or OGM files) is only changed if the user has selected any language other than "und". Fix for bug 420.
* mmg: bug fix: mmg will no longer show an error message if the user has not selected a country in the "chapters" tab of the preferences dialog.
------------------------------------------------------------

Have fun.

[Mosu]

In the MPC-HC thread there was a small discussion about UTF-8 subtitles. Maybe you could expand the documentation a little and explicitly state that UTF-8 subtitles with BOM are automatically detected as UTF-8 and not with the system charset.

The man page now contains such a paragraph ("Text files and character set conversions").

[roozhou]

Hi Mosu,

Recently I have noticed a problem concerning delay in aac audio. Maybe I should start a new thread because this problem does not only occur with matroska.

I cut an audio sample of 10.031s and encoded it to he-aac using neroAacEnc. The resulting mp4 show 10.136s in MediaInfo. If I decode the mp4 through foobar2000 or neroAacDec, the decoded wav has an exact length of 10.031s. But if I decode the mp4 through mplayer or directshow it gave me 10.090s and a delay of ~59ms. When I mux it into mka through mmg and decode it again through foobar2000 it gave me the same 10.090s and the delay.

The delay also occurs when I extract the aac to adts or remux it to mp4. Apparently there was information, which cannot be shown from MediaInfo, indicating the decoding delay of the aac stream in mp4. Such information gets lost when you remux it to another container. I also tried adding a negative delay in mmg but it just strip one or two frames at the beginning of aac stream, which is not what i want.

My question:
Will there be an A/V async if I mux aac with video into matroska and play it in mplayer or through directshow? Although 59ms delay could be too difficult for me to notice, there can larger delay (e.g. CT AAC with SBR+PS gives me ~112ms delay on 44100Hz source).

[Mosu]

Probably not.

[LeXXuz]

Hi Mosu,

I backed up my whole DVD Collection a couple of month ago to AVC with AC3/DTS or AAC audio. Now I want to add some extra audio tracks with heavy DRC.

So far so good, but every 4th or 5th movie is out of sync (when playing it with the new audio tracks). I remember that a lot of discs had some audio delay which I let mmg/mkvmerge take care of when creating my backups.

From what I found on the last 57 pages of this thread, since version 2.4.0 mkvmerge no longer tampers with the files. It modifies the timecodes instead.

Is there no way to find out this delay? It would save me a huge ammount of time, since I have to manually check and correct every movie for a/v-sync.

[Mosu]

No, sorry.

[LeXXuz]

No, sorry.

I had a feeling I would get an answer like that. :D

Just out of curiosity, can you explain a bit more in detail why this is not possible? :)

[VEGITA]

Hello, I'm having trouble merging 4 mkv files, all encoded with the same settings using x264. Two of the files are under 200MB and the other are a little over 200. The smaller files join without a problem but when I try to join the bigger files to the smaller ones the output file is smaller than it should be, I'm talking 25% smaller.
Anyone else had this problem, because I've had this problem 2 months ago on an older build of mmg and gave up on it but I spent like 4 days encoding these and it would be a pain to encode it again.

[buzzqw]

but it is ok ?

don't look at file size, is your muxed file perfectly watchable or is ruined ?

BHH

[VEGITA]

it always cuts a few minutes from the resulting file, the last 4-5 minutes, other than that it looks like the input files.

[Mosu]

I had a feeling I would get an answer like that. :D

Just out of curiosity, can you explain a bit more in detail why this is not possible? :)

Because there's no such thing as 'the delay of this track'. There are only timecodes. Packets are not muxed into the resulting file if their effective timecode is < 0. However, that doesn't mean that the first packet's timecode is automatically 'the delay'. An example:

In the original file the first video frame starts at 0ms, the first audio track's packet at 15ms with a duration of 40ms. Now you delay the audio track by let's say -40ms. The resulting file's first audio packet will be at 35ms then. But does this mean that you can use +35ms as the delay for muxing other tracks? Obviously not.

[sneaker_ger]

1.) shouldn't the first packet also start at 15 ms in your case as you're delaying by the length of exactly one frame? What am I missing?
2.) If the delay is longer than the audio frame duration it should probably be sufficient to look at the timecodes, right?

[Mosu]

The 40ms delay was a bad example, yes. Take any other value, e.g. -5ms. Then the first audio packet would start at +10ms, but those +10ms are not the delay you'd need for adding yet another track.

[sneaker_ger]

Despite obviously being a bad example I wanted to state that your calculation was wrong.
And your new example's also bad, since you're not cutting away any frames in it, so "+10ms" is the delay you'd need for adding another track. Or am I mistaken?
And what about my second question?

[Mosu]

If both of the audio tracks come from the same source then both need the same delay of -5ms obviously, even though that isn't obvious from the first packet's timecode. There are several cases in which simply taking the first packet's timecode as the delay will not work. There are cases where it will work. Just try it, watch the resulting file, if A/V sync is off then re-mux with adjusted delay and repeat.

2.) If the delay is longer than the audio frame duration it should probably be sufficient to look at the timecodes, right?

No. For the same reason as stated above.

Anyway, end of topic for me. Sorry. Just try muxing with different values; if the first timecode works for you then fine, if not then adjust and retry.

[zn]

Is it possible to select/skip some parts in --split mode?
When I need to extract only 1 part of video it is doing full processing.

[Mosu]

No. Yes, it has been requested multiple times. Yes, I will probably implement something like that. No, this will not be in the near future.

[LeXXuz]

I've noticed that mkvmerge and mkvextract produce heavily fragmented output files (Windows).

I was wondering if this is a problem of mkvmerge's writing routine, as other muxers (tsmuxer, avimuxgui,...) do not produce such fragmented files.

I've demuxed a 9GB Matroska file to an almost empty partition. OO Defrag show's that the files are spread all over the volume.

[Mosu]

Both tools write files in small chunks, does not use any preallocation or similar and have pretty much no optimizations in this regard. This will stay that way until someone provides a good patch for me.

[Inspector.Gadget]

Is there a way I can append Matroska files - each containing streams that I encoded with the same parameters - to generate one big file with automatic chapter markers at join points?

[sneaker_ger]

Are there any plans on supporting Blu-Ray Subtitles?

[Mosu]

Plans yes, but no timetable.

[Eraser_stp]

Any chances for Windows x64 build?