mkvtoolnix 4.1.1 released

[SeeMoreDigital]

Hi Mosu,

Any chance of providing an "button option" to keep the "Video Stream Level Signalling" for MPEG-4 Part-2/Part-10 video streams. Instead of having to write-in the code?


Many thanks

[madshi]

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.
Thank you!

[buzzqw]

thanks Mosu!

BHH

[madshi]

@Mosu, don't know if you're still using my old code for parsing DTS-HD streams. I've found new information in the meanwhile. Here's the proper code to find out the size of the DTS-HD blocks:

if GetBits(bits, 32) = $64582025 then // DTS-HD sync dword
begin
GetBits(bits, 8);
GetBits(bits, 2);
blownUpHeader := GetBits(bits, 1) = 1;
if blownUpHeader then begin
GetBits(bits, 12);
sizeOfDtsHdBlockInBytes := GetBits(bits, 20) + 1;
end else begin
GetBits(bits, 8);
sizeOfDtsHdBlockInBytes := GetBits(bits, 16) + 1;
end;
end;
This is exactly the way "proper" DTS-HD decoders parse DTS-HD blocks. Finding out which stream is DTS-HD Hi-Res and which is DTS-HD Master Audio is not as easy as I originally thought. If you must know that I can tell you how. But I guess you don't really need to know, do you?

[Mosu]

@Mosu, don't know if you're still using my old code for parsing DTS-HD streams. I've found new information in the meanwhile. Here's the proper code to find out the size of the DTS-HD blocks:

Thanks, I've updated my code accordingly. Do you happen to have a sample with the blown-up-header bit set to 1? I only have samples with the bit set to 0.

Finding out which stream is DTS-HD Hi-Res and which is DTS-HD Master Audio is not as easy as I originally thought. If you must know that I can tell you how. But I guess you don't really need to know, do you?

Right, mkvmerge doesn't care as it has no effect on the way the track is muxed.

[Mosu]

In addition I would like to ask if there are plans to support VC.1 elementary streams as a source format ?

That's still only a "maybe". I'd like to, but it's mostly a question of lack of time.

[Mosu]

Any chance of providing an "button option" to keep the "Video Stream Level Signalling" for MPEG-4 Part-2/Part-10 video streams. Instead of having to write-in the code?

Maybe, maybe not. Sample files, please?

[madshi]

Thanks, I've updated my code accordingly. Do you happen to have a sample with the blown-up-header bit set to 1? I only have samples with the bit set to 0.
I don't have any such samples. I think it's a feature which is not used currently. It's probably for future use, I guess.

[Mosu]

I don't have any such samples. I think it's a feature which is not used currently. It's probably for future use, I guess.

Ah ok.

[ataraxia937]

I have built a package of mkvtoolnix 2.3.0 for Leopard. It is universal, but will not work on 10.4 or earlier. It is built with bzip2, lzo, and FLAC support, but does not include the GUI for mkvmerge as I haven't been able to make it work.

MKVToolNix for Leopard (http://www.andrew.cmu.edu/user/rjkohler/mkvtoolnix-2.3.0-universal.pkg)

(I also built a package of ogmtools if anyone wants that: OGMtools for Leopard (http://www.andrew.cmu.edu/user/rjkohler/ogmtools-1.5-universal.pkg))

I did send email to Mosu about these but I figured I'd post them here also.

[Ritsuka]

Oh well, I did one too but forgot about it.
edit: now available on http://www.bunkus.org/videotools/mkvtoolnix/downloads.html#macosx

It contains the gui too and works on 10.4.
Hopefully Mosu could put it his site like the 2.0 I compiled some years ago. :)

[SeeMoreDigital]

Maybe, maybe not. Sample files, please?Hi Mosu,

What I'm proposing is already possible. Currently however, in order to retain the "Video Stream Level Signalling" for MPEG-4 Part-2/Part-10 video streams, you have to go to the "User Defined Options" and write "--engage keep_bitstream_ar_info" in the box provided.

What I'm proposing is a "check-box" implementation. Something like this: -

http://i38.tinypic.com/1j6wqr.png


Cheers

[Mosu]

What I'm proposing is already possible. Currently however, in order to retain the "Video Stream Level Signalling" for MPEG-4 Part-2/Part-10 video streams, you have to go to the "User Defined Options" and write "--engage keep_bitstream_ar_info" in the box provided.

Ah, that's what you meant. Nope, sorry, I won't add an option for this. The reason is that in Matroska all information on every level should be the same. What I mean is: with AVC and other video formats there's the aspect ratio information on the bitstream level and the aspect ratio information on the container level. These two should always be the same -- otherwise how should a player decide which information to use? (The container information obivously, but it's ambiuous.)

The --engage option is there for users who know what they're doing, but I don't want to make it too easy for unexperienced users to shoot themselves in their feet.

[SeeMoreDigital]

Okay.... I understand what you mean. Keeping both CLS (Container Level Signalling) and SLS (Stream Level Signalling) would present confusion :(

Just a thought... Would it be possible to retain the Stream Level Signalling and not have any Container Level Signalling?

Personally, I've never really liked the idea of storing aspect ratio signalling at the container level ;)

[Mosu]

Just a thought... Would it be possible to retain the Stream Level Signalling and not have any Container Level Signalling?

Not with mkvmerge, no. And I won't add such an option, sorry.

[Mosu]

I have built a package of mkvtoolnix 2.3.0 for Leopard.

and

Oh well, I did one too but forgot about it.

Thanks a lot to the both of you. I'm hosting both of your pakages on my download page (http://www.bunkus.org/videotools/mkvtoolnix/downloads.html#macosx) now.

[Mosu]

I've spent the last couple of days implementing support for VC-1 video tracks. mkvmerge can now read VC1 tracks from EVOBs and from VC1 elementary streams like the ones that EVODemux produces. mkvmerge can still not read ASF/WMV files. You should not attempt to read VC1 from AVIs yet as the timecodes will probably be wrong (will be taken care of this weekend).

What I haven't been able to test:

Sample/pixel aspect ratio. The sample files that I have only have a 1:1 sample aspect ratio or no display information extension at all; therefore any other sample aspect ratio will cause mkvmerge to output a warning.
Audio/video synchronization. Unfortunately I don't have a single sample with which I can properly test A/V sync.
Timecodes for progressive material. The samples I have all seem to be interlaced.
The samples I have all use frame units (start code 0x00 00 01 0d). None use field or slice units (start codes 0x00 00 01 0c and 0x00 00 01 0b respectively). mkvmerge will abort if it encounters those. I don't even know whether or not VC1 allows field or slice units at all or if this is just allowed in WMV9.

As you can see I definitely need more sample files :) So if you'd like to upload a couple to my FTP server I'd be very grateful. Especially ones that cause any problem with mkvmerge. Please only upload EVOBs and VC1 raw elementary streams; I cannot handle WMVs at the moment. The samples should be "big enough"; unfortunately this often means a size of 50 MB or more. My FTP server can take it though, so don't be shy.

Here's the Windows build with VC1 support: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.3.0-build20080919-1.rar

Oh, a short question. How do I play back EAC3 without a hardware decoder on Windows? I "only" have the current CCCP installed, and MPC stalls on files with EAC3 sound tracks. AC3 playback is working, of course, ffdshow takes care of that.

[madshi]

I've spent the last couple of days implementing support for VC-1 video tracks. mkvmerge can now read VC1 tracks from EVOBs and from VC1 elementary streams like the ones that EVODemux produces. mkvmerge can still not read ASF/WMV files. You should not attempt to read VC1 from AVIs yet as the timecodes will probably be wrong (will be taken care of this weekend).

What I haven't been able to test:

Sample/pixel aspect ratio. The sample files that I have only have a 1:1 sample aspect ratio or no display information extension at all; therefore any other sample aspect ratio will cause mkvmerge to output a warning.
Audio/video synchronization. Unfortunately I don't have a single sample with which I can properly test A/V sync.
Timecodes for progressive material. The samples I have all seem to be interlaced.
The samples I have all use frame units (start code 0x00 00 01 0d). None use field or slice units (start codes 0x00 00 01 0c and 0x00 00 01 0b respectively). mkvmerge will abort if it encounters those. I don't even know whether or not VC1 allows field or slice units at all or if this is just allowed in WMV9.

As you can see I definitely need more sample files :) So if you'd like to upload a couple to my FTP server I'd be very grateful. Especially ones that cause any problem with mkvmerge. Please only upload EVOBs and VC1 raw elementary streams; I cannot handle WMVs at the moment. The samples should be "big enough"; unfortunately this often means a size of 50 MB or more. My FTP server can take it though, so don't be shy.

Here's the Windows build with VC1 support: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.3.0-build20080919-1.rar
Thanks! A few hints:

(1) For aspect ratio use DISPLAY_HORIZ/VERT_SIZE in relation to MAX_CODED_WIDTH/HEIGHT. You should totally ignore the ASPECT_RATIO bitstream elements. Only this way aspect ratio works correctly.

(2) For best muxing each frame should consist of:

[00 00 01 0f [...]] [00 00 01 0e [...]] 00 00 01 0d [...] [00 00 01 0c [...]] [00 00 01 (1b-1f) [...]]
In other words: You must not strip the sequence headers. Furthermore each MKV frame should contain exactly one "00 00 01 0d" part. Each MKV frame should begin with either "00 00 01 0f" or "00 00 01 0e" or "00 00 01 0d".

(3) AFAIK there's no "temporal_reference" field in the VC-1 bitstream nor anything similar. So I think you should just increase timestamps constantly with each frame. Which is different to MPEG2 and h264 where timestamps can jump back and forth, depending on "temporal_reference" respectively "pic_order_cnt".

(4) I've never seen "00 00 01 0b" used yet in any HD DVD or Blu-Ray streams. But "00 00 01 0c" is rather common in interlaced HD DVD and Blu-Ray streams. When there's "00 00 01 0c", there's a "00 00 01 0d" first. You need to mux them both into one MKV frame. If you separate them, the MS VC-1 decoder will show artifacts.

(5) You can double check whether your muxes are correct by comparing your MKVs with those created by eac3to ("mkvinfo -v"). eac3to's VC-1 muxing has been tested with hundreds of HD DVDs and Blu-Rays and I'm not aware of any problems. For eac3to to successfully mux VC-1 you need the latest Haali Media Splitter to be installed (download link see "eac3to -test").

I'll upload a few samples.

Oh, a short question. How do I play back EAC3 without a hardware decoder on Windows? I "only" have the current CCCP installed, and MPC stalls on files with EAC3 sound tracks. AC3 playback is working, of course, ffdshow takes care of that.
The latest ffdshow tryouts version can decode E-AC3, as long as it's part of an EVO or m2ts container, I think. You need the very latest ffdshow, since this was added just a couple of days ago...

[Mosu]

Thanks! A few hints:

(1) For aspect ratio use DISPLAY_HORIZ/VERT_SIZE in relation to MAX_CODED_WIDTH/HEIGHT. You should totally ignore the ASPECT_RATIO bitstream elements. Only this way aspect ratio works correctly.

At the moment I simply use DISPLAY_HORIZ/VERT_SIZE as the values for Matroska's "display width/display height" fields. Anyway, all samples I have have identical DISPLAY_HORIZ/VERT_SIZE and MAX_CODED_WIDTH/HEIGHT values, so I can't test that way either ;)

(2) For best muxing each frame should consist of:

[00 00 01 0f [...]] [00 00 01 0e [...]] 00 00 01 0d [...] [00 00 01 0c [...]] [00 00 01 (1b-1f) [...]]
In other words: You must not strip the sequence headers. Furthermore each MKV frame should contain exactly one "00 00 01 0d" part. Each MKV frame should begin with either "00 00 01 0f" or "00 00 01 0e" or "00 00 01 0d".

Ah. At the moment I've implemented muxing in V_MS/VFW/FOURCC mode that Haali's Matroska muxer also writes (dunno which version of Haali's muxer I've installed; I did the muxing with graphedit: EVO as the source, Haali's muxer connected directly to the EVO's video output pin). This one is quite different, though. It strips all sequence headers and entrypoints from the frames and puts one instance of each into CodecPrivate behing the BITMAPINFOHEADER.

I don't like it all that much myself, but I didn't know that eac3to can mux VC1 into Matroska. I'll take a look at how eac3to muxes VC1 and adopt mkvmerge's output accordingly.

So the basic warning is: Don't use the current mkvmerge for anything you want to keep! The way it muxes WILL change!

(3) AFAIK there's no "temporal_reference" field in the VC-1 bitstream nor anything similar. So I think you should just increase timestamps constantly with each frame. Which is different to MPEG2 and h264 where timestamps can jump back and forth, depending on "temporal_reference" respectively "pic_order_cnt".

True, but depending on the FRMCNT and RFF fields/flags in the frames (in combination with the sequence header's INTERLACE flag) the frame's duration may be longer than 1/FPS. That's what Haali's muxer did, anyay...

(4) I've never seen "00 00 01 0b" used yet in any HD DVD or Blu-Ray streams.

That's goot :)

But "00 00 01 0c" is rather common in interlaced HD DVD and Blu-Ray streams. When there's "00 00 01 0c", there's a "00 00 01 0d" first. You need to mux them both into one MKV frame. If you separate them, the MS VC-1 decoder will show artifacts.

Ok. That should not be such a big problem.

(5) You can double check whether your muxes are correct by comparing your MKVs with those created by eac3to ("mkvinfo -v"). eac3to's VC-1 muxing has been tested with hundreds of HD DVDs and Blu-Rays and I'm not aware of any problems. For eac3to to successfully mux VC-1 you need the latest Haali Media Splitter to be installed (download link see "eac3to -test").

Will do.

I'll upload a few samples.

Thanks a lot, both for the files and the info.

The latest ffdshow tryouts version can decode E-AC3, as long as it's part of an EVO or m2ts container, I think. You need the very latest ffdshow, since this was added just a couple of days ago...

Ah, good to know. I'll install it.

[madshi]

At the moment I simply use DISPLAY_HORIZ/VERT_SIZE as the values for Matroska's "display width/display height" fields.
That's exactly the right way. I'm already uploading 2 files with funny aspect ratios.

Ah. At the moment I've implemented muxing in V_MS/VFW/FOURCC mode that Haali's Matroska muxer also writes (dunno which version of Haali's muxer I've installed; I did the muxing with graphedit: EVO as the source, Haali's muxer connected directly to the EVO's video output pin). This one is quite different, though. It strips all sequence headers and entrypoints from the frames and puts one instance of each into CodecPrivate behing the BITMAPINFOHEADER.
Earlier versions of Haali's muxer did behave that way. But that resulted in artifacts with some HD DVD movies cause in some HD DVD movies the sequence headers change in the middle of the movie. I've reported that to Haali and he changed his way of VC-1 muxing in newer versions of his muxer to the same way eac3to is using. I guess you have an old Haali version installed on your PC.

True, but depending on the FRMCNT and RFF fields/flags in the frames (in combination with the sequence header's INTERLACE flag) the frame's duration may be longer than 1/FPS. That's what Haali's muxer did, anyay...
That's correct.

[nautilus7]

Ah, good to know. I'll install it.
ffdshow builds on sourceforge don't support E-AC3, so install this build posted by albain here (http://forum.doom9.org/showthread.php?p=1185130#post1185130). It's his last test build.

You can also play raw E-AC3 streams.

[Mosu]

Alrighty, thanks for your tips and the files that you guys have uploaded. Here's a new build that implements proper VC1 muxing:

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.3.0-build20080920-1.rar

Have fun testing :)

[STaRGaZeR]

VC1 tracks will be muxed in V_MS/VFW/FOURCC mode right Mosu?

[Mosu]

Yes, the same way they're muxed by Haali's muxer / by eac3to. You need a current version of Haali's splitter from http://haali.net/mkv/

[STaRGaZeR]

Nice. I can remember reading something about Haali's muxer using V_VC1, but it was removed later on because of some incompatibility with Microsoft's WMVideo Decoder DMO, IIRC. So I assume V_MS/VFW/FOURCC is the correct mode for the VC-1 codec family.

Will you add Windows Media Audio formats support in the future?

[Mosu]

Maybe, maybe not. They're pretty low on my TODO list.

[NanoBot]

Hi,

thanks for the support of raw VC.1 tracks, but it looks like you have forgotten to include the never versions of some dlls in the update archiv ?

"Die Anwendung kann nicht gestartet werden, weil wxbase28u_gcc_custom.dll nicht gefunden wurde"

C.U. NanoBot

[Eragon4ever]

Install 2.3.0 and unpack the archive on top of it. The dlls are in the installer.

[Mosu]

Eragon's correct. This is a newer build of v2.3.0 which includes the newer wxWidgets version.

[NanoBot]

Hi,

thanks for the fast answer. I accidentially extracted the archiv to an existing 2.2 installation or an older of 2.3 installation, and of course this could not work :stupid:

I reinstalled from the actual 2.3 installer and extracted the archiv, and now everything works fine. I am going to test the VC1 import function :thanks:

C.U. NanoBot

[shambles]

mkvmerge can't seem to handle ac3/e-ac3 files that are 2gb or larger. it just does this:

mkvmerge v2.3.0 ('Freak U') built on Sep 17 2008 09:50:38
'E:\1.eac3': Using the AC3 demultiplexer.
'E:\1.eac3' track 0: Using the EAC3 output module.
The file 'E:\1.mka' has been opened for writing.
Muxing took 1 second.

i tried cutting the file so it was just over 2gb and muxing failed. then i tried cutting it so it was just under 2gb and muxing worked fine.

[zeropc]

here is the os x version of mkvtoolnix 2.3.0.

special thanks to ritsuki for compiling it

http://www.mediafire.com/?nyxccrlz62t

[kurt]

remuxing of evobs (vc1) is not possible, is it?

mkvmerge v2.3.0 ('Freak U') built on Sep 20 2008 17:46:07

Error: 'I64d' is not a valid file ID in '--track-order 0:I64d'.



the audio tracks also don't seem to be recognized...

I'm uploading a sample, will edit the link here...

[Mosu]

mkvmerge can't seem to handle ac3/e-ac3 files that are 2gb or larger.

Thanks for noticing, fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.3.0-build20080921-2.rar

[Mosu]

remuxing of evobs (vc1) is not possible, is it?

Yes, it is.

Error: 'I64d' is not a valid file ID in '--track-order 0:I64d'.

!? I'm guessing you're using mmg. Which Windows version are you using?

[shambles]

Thanks for noticing, fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.3.0-build20080921-2.rar

thanks :D works fine in the new build

[yonta]

Loading these files in mmg fails with v2.3.0-build20080921-2.
It worked with v2.3.0-build20080920-1.

sample1 (http://www.sendspace.com/file/t34ojj)
sample2 (http://www.sendspace.com/file/bi6xn4)

[kurt]

Yes, it is.



!? I'm guessing you're using mmg. Which Windows version are you using?
sorry my fault, I made a mistake during installation. vc1 recognition it is working now :)

[Mosu]

Loading these files in mmg fails with v2.3.0-build20080921-2.
It worked with v2.3.0-build20080920-1.

Thanks, fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.3.0-build20080921-3.rar

[yonta]

Thanks, fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.3.0-build20080921-3.rar

WOW!
You are fast!

Now mmg doen't hang but reads all tracks except AVC video?

[Mosu]

Now mmg doen't hang but reads all tracks except AVC video?

Doh! Fixed in http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.3.0-build20080921-4.rar

[Tima]

Some timecode-related issues:

1) I demuxed an AC3 stream from some MKV file, then extracted timecodes for it. When I try to remux this AC3 to separate MKV with it's own (well, corrected) timecodes, after the process completion mkvmerge warns me that frame count in AC3 is greater then count of provided timecodes.

2) I demuxed two AC3 streams and two srt subtitles from the movie to separate MKA file. Now when I try to extract timecodes for any of these two AC3 streams, mkvextract returns a file with header only (no timecodes at all)! When extracting timecodes for these streams from the main movie, it works OK.

3)From mkvmerge documentation:

In this format each line contains a timecode for the next frame.

Shouldn't 'next' be 'current' here?

[Devilman1]

I try to download this last build (mkvtoolnix-unicode-2.3.0-build20080921-4.rar) but I always receive the message that the file is not found.

Bye

Carlo

[Mtz]

Maybe Mosu is working on a new build. Have some patience.

enjoy,
Mtz

[Mosu]

Some timecode-related issues:

1) I demuxed an AC3 stream from some MKV file, then extracted timecodes for it. When I try to remux this AC3 to separate MKV with it's own (well, corrected) timecodes, after the process completion mkvmerge warns me that frame count in AC3 is greater then count of provided timecodes.

I cannot reproduce this. I always get exactly as many timecodes in the extracted-timecodes-file as there are frames in the extracted AC3 file. Muxing the extracted AC3 files with the extracted timecodes does not result in a warning.

2) I demuxed two AC3 streams and two srt subtitles from the movie to separate MKA file. Now when I try to extract timecodes for any of these two AC3 streams, mkvextract returns a file with header only (no timecodes at all)! When extracting timecodes for these streams from the main movie, it works OK.

Are you perhaps using the wrong track IDs during extraction of the separate MKA files? They're definitely not the same as they're in the "big" original MKV file.

3)From mkvmerge documentation:

In this format each line contains a timecode for the next frame.

Shouldn't 'next' be 'current' here?

Depends on your point of view ;) I'm more of a "the next frame that will be read" person than a "I'm working with the current frame" thinking person. Anyway, each frame gets one timecode from the file.

[Mosu]

I try to download this last build (mkvtoolnix-unicode-2.3.0-build20080921-4.rar) but I always receive the message that the file is not found.

Doh, stupid me. That's because I built it, but I forgot to upload it. That's been fixed now :)

[Tima]

I cannot reproduce this. I always get exactly as many timecodes in the extracted-timecodes-file as there are frames in the extracted AC3 file. Muxing the extracted AC3 files with the extracted timecodes does not result in a warning.
I can cut the source file. If an issure will remain with the smaller sample, I can upload it to you -- if you need.



Are you perhaps using the wrong track IDs during extraction of the separate MKA files? They're definitely not the same as they're in the "big" original MKV file.
Yes, I'm aware of this, and used correct IDs for extraction.

I cut a small sample and uploaded it to your ftp -- the file is called 'no-timecode_sample.mka'. It contains only one AC3 stream, and there's no timecode extracted for track with ID 1 :)


Depends on your point of view ;) I'm more of a "the next frame that will be read" person than a "I'm working with the current frame" thinking person. Anyway, each frame gets one timecode from the file.
Maybe it'd be okay to change 'next' to 'correspondnig' then? It seems to be a person_type-independent solution ;)

[Mosu]

I cut a small sample and uploaded it to your ftp -- the file is called 'no-timecode_sample.mka'. It contains only one AC3 stream, and there's no timecode extracted for track with ID 1 :)

Thanks. I found the problem :) Fixed in http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.3.0-build20080922-1.rar

[KoD]

Hello Mosu, thank you for the new version of mkvtoolnix.

Here is a little interface bug in mkvmerge that's been present in 2.2.0 and probably before, and could be easily fixed. It's not critical, but hey ! :)

How to reproduce it:

a) 2 mkv files that have the segment title set (and not to the same value) are needed. So, for instance fileA.mkv which has only one segment, and the segment title is "Title A", and fileB.mkv which also has only one segment, and its segment title is "Title B".
b) take fileA.mkv and drop it in mkvmerge.
c) in the "Global" tab, "Title A" can be seen in the "File/segment title" input field.
c) in the "Input" tab, we press either the "remove" or "rem all" button
d) if we go to the "Global" tab again, we see the "File/segment title" input field still shows "Title A"
e) while in the "Input" tab, we drop fileB.mkv in mkvmerge
f) in the "Global" tab, "File/segment title" input field still shows "Title A" (hasn't been updated to "Title B")

So, that would be it. I'm using mkvmerge on Windows, but I guess this behavior is not platform dependent.

What should happen is:
1. on pressing "remove" or "rem all", the "File/segment title" input field should be cleared
2. after such a remove operation, mkvmerge should still set the "File/segment title" input field when adding mkv files that have it to the input box

[Mosu]

What should happen is:
1. on pressing "remove" or "rem all", the "File/segment title" input field should be cleared
2. after such a remove operation, mkvmerge should still set the "File/segment title" input field when adding mkv files that have it to the input box

No, I don't agree (and I've argued this point time and again). If you want to start over then you'll have to chose "File -> New". This will remove all tracks and clear all input fields. If you only use "Remove all" then mmg assumes you want to keep all the other settings as they are. There are people using mmg exactly that way, and I won't change this behaviour. Sorry :)