MKVToolNix v24.0.0 released

[Mosu]

I'm 200% sure that my eyes are completely OK and that I'm not imagining things here. Yes, it plays smoothly on both players in Linux. I don't have a Windows workstation here, nor do I have a powerful PC running Windows anyway, and I don't use madshi or EVR. So... yes. It works for me.

[DragonQ]

Just tested MediaPortal, it plays the MKV smoothly at 50 fps. The audio and video are out of sync but I'm sure that's just an issue with making the cut sample using TSMuxer - the original file was in sync.

[madshi]

@DragonQ, try using "eac3to broken.ts broken.mkv" and then using mkvtoolnix afterwards to mux the video+ac3 together. That fixes the FPS problem on my PC. You could argue, though, that eac3to writes a wrong DefaultDuration to the file, though. In any case, I plan to add a detection & correction for twice as high "FPS" information coming from the splitter to the next madVR build. This might already fix the problem when using madVR.

[DragonQ]

@DragonQ, try using "eac3to broken.ts broken.mkv" and then using mkvtoolnix afterwards to mux the video+ac3 together. That fixes the FPS problem on my PC. You could argue, though, that eac3to writes a wrong DefaultDuration to the file, though. In any case, I plan to add a detection & correction for twice as high "FPS" information coming from the splitter to the next madVR build. This might already fix the problem when using madVR.

You're right, that does seem to fix the issues in both EVR and MadVR. Surely if both EVR and MadVR work correctly when the DefaultDuration is 40 ms, it makes sense for MKVMerge to set it to this when muxing? I know it might not be technically correct and a new fps field would be better, but if it works...

There's still the mystery of what possesses MKVMerge to make the DefaultDuration 20 ms rather than 40 ms for these newer files and not older ones...maybe there's some really subtle change in the TS stream that doesn't show up in MediaInfo?

[nevcairiel]

You can't just change the DefaultDuration like that, its also used to avoid having to write a duration for every single block. If every block has the same duration, you can just skip writing it, and use the DefaultDuration for that.
Since your file does indeed seem to have one field per block, a DefaultDuration of 20ms makes sense (50 fields per second), two blocks/fields make one frame and give you 40ms/25 frames per second.

So the real problem still is that you can't use the DefaultDuration as a plain FPS value.
madVR will fix it, so that deinterlacing is still performed, and i'll do also some fix in LAV to try to detect a more accurate FPS value.

[madshi]

@DragonQ, truth be told mkvtoolnix does the "right" thing and eac3to does it "wrong", if you follow the MKV spec to the letter. I don't see any negative consequence of doing it "wrong", but I understand that Mosu wants to follow the spec perfectly. I've already modified madVR now to auto-detect this situation and to auto-correct wrong FPS information coming from the splitter/decoder. And I think nevcairiel is planning to implement a similar patch in LAV Splitter. So the problem should be gone soon. Personally, I'm always using eac3to first to mux the video to MKV, then I'm using mkvtoolnix in a 2nd step to add the audio tracks. This has always worked very well for me. But as I said, what eac3to does is technically not really correct, according to the MKV spec. I don't plan to change this, though, unless MKV gets a new dedicated FPS field, then I'll adjust eac3to accordingly.

[DragonQ]

So the real problem still is that you can't use the DefaultDuration as a plain FPS value.
madVR will fix it, so that deinterlacing is still performed, and i'll do also some fix in LAV to try to detect a more accurate FPS value.
So would a change in LAV fix the issue for EVR then? I can't use MadVR on my laptop (although I use it on my desktop).

@DragonQ, truth be told mkvtoolnix does the "right" thing and eac3to does it "wrong", if you follow the MKV spec to the letter. I don't see any negative consequence of doing it "wrong", but I understand that Mosu wants to follow the spec perfectly.
Yeah, I understand.

Thanks to all three of you for your help with this matter, it'll be great to see this issue fixed in the future! :)

[nevcairiel]

So would a change in LAV fix the issue for EVR then? I can't use MadVR on my laptop (although I use it on my desktop).

Yes, it will. As long as you use LAV Splitter. ;)

[DragonQ]

Yes, it will. As long as you use LAV Splitter. ;)
Cool. It seems MediaPortal's splitter already works fine anyway (rightly or wrongly) and that's the only time I don't use LAV Splitter. :p

[DragonQ]

@DragonQ, try using "eac3to broken.ts broken.mkv" and then using mkvtoolnix afterwards to mux the video+ac3 together. That fixes the FPS problem on my PC. You could argue, though, that eac3to writes a wrong DefaultDuration to the file, though. In any case, I plan to add a detection & correction for twice as high "FPS" information coming from the splitter to the next madVR build. This might already fix the problem when using madVR.
FYI, whilst this trick fixes MadVR and EVR compatibility for files with AC3 audio, it doesn't work for files with HE-AAC audio - MadVR still doesn't deinterlace these.

[Mosu]

Hey,

I've released v5.9.0.

I've released MKVToolNix v5.9.0. It fixes several bugs: 793 (appending empty subtitle tracks); 795 (file names containing '%' read from .mmg files); reading linked seek heads in mkvmerge (fixes mkvmerge not finding attachments after usage of mkvpropedit); 801 & 802 (discarding EBML void elements when writing and reading XML chapter files); 804 (mkvmerge will keep timecodes of PCM tracks read from containers that provide timecodes); 805 (reading seek position elements bigger than 2 GB).

Enhancements include writing the newly introduced elements "cue duration" and "cue relative position" which provide more detailed information for seeking. Due to this compilation requires new versions of libEBML (1.3.0) and libMatroska (1.4.0), neither of which has been released yet: they're only available from the Subversion repository so far. However, MKVToolNix comes bundled with internal copies of both libraries which will be used.

Here are the usual links: the home page (http://www.bunkus.org/videotools/mkvtoolnix/), the source code (http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-5.9.0.tar.bz2) and the Windows installer (http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.9.0-setup.exe) and 7zip archive (http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.9.0.7z).

All of the binaries (http://www.bunkus.org/videotools/mkvtoolnix/downloads.html) that I provide myself are already available.

Here's the full ChangeLog (http://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog) since release 5.8.0:

2012-12-09 Moritz Bunkus <moritz@bunkus.org>
* Released v5.9.0.
* mkvmerge: bug fix: Fixed reading seek position values bigger than 2 GB. Fixes #805 (https://www.bunkus.org/trac/ticket/805).

2012-12-08 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed appending non-empty tracks to empty tracks. Fixes #793 (https://www.bunkus.org/trac/ticket/793).
* mkvmerge: bug fix: mkvmerge will now keep timecodes of PCM tracks from source files if they're available. Fixes #804 (https://www.bunkus.org/trac/ticket/804).

2012-12-05 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: EBML void elements will be skipped when reading structures from XML (e.g. chapters). Fixes #802 (https://www.bunkus.org/trac/ticket/802).

2012-12-02 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: EBML void elements will be skipped when saving structures to XML (e.g. chapters). Fixes #801 (https://www.bunkus.org/trac/ticket/801).
* mkvmerge: bug fix: Fixed reading linked seek heads in Matroska files.

2012-11-13 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Fixed reading file names containing a '%' from a .mmg settings file (both normally saved files and the job queue files). Fixes #795 (https://www.bunkus.org/trac/ticket/795).

2012-10-08 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Dirac video code: Added four more pre-defined video types from Dirac spec v2.2.2 and two from Dirac Pro.

2012-09-27 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mmg: enhancement: Added options for turning off writing "CueDuration" elements ("--engage no_cue_duration") and "CueRelativePosition" elements ("--engage no_cue_relative_positions").
* mkvmerge: new feature: The element "CueRelativePosition" is written for all cue entries.
* mkvmerge: new feature: The element "CueDuration" will be written for all cue entries referring to subtitle tracks.
* mkvmerge: new feature: mkvmerge will write cues for subtitle tracks by default now.
* mkvinfo: new feature: added support for the new elements CueDuration, CueRelativePosition and TimecodeScaleDenimonator. The denominator's value is only shown so far but not taken into account when calculating any timecode.
* mkvpropedit, mmg, mkvmerge: removal: removed support for the deprecated element TrackTimecodeScale.

Have fun.

[Selur]

Thanks for the new release.
Are their expected problems the cue-elements are added? (like when the header removal compression was added?)

[Mosu]

No. They're additional elements. So any player that properly handles elements it doesn't know (meaning simply skipping and disregarding them) will not have any problem. Won't be able to take advantage of the additional information, of course, but won't be off any worse either.

[nevcairiel]

Thanks for the new release.
Are their expected problems the cue-elements are added? (like when the header removal compression was added?)

Only if you have a broken parser which doesn't simply ignore unknown tags.

[Mosu]

Additional information I forgot. As those elements belong to version 4 of the Matroska specs mkvmerge will write "DocTypeVersion = 4" instead of "DocTypeVersion = 3". This may pose problems for players, yes, if they're shittily implemented.

But: the element more important for players, "DocTypeReadVersion", stays at 2 because any player not supporting those elements should still be able to use the file 100% fine.

[nevcairiel]

I just noticed a small inconsistency, in your mail to matroska-devel you assigned the id 0x53 b3 to CueDuration, but in the spec sheet on matroska.org it got the id 0xb2 .. i assume the spec sheet is correct?

[Mosu]

The specs are indeed correct. Both new elements, CueDuration and CueRelativePosition, only use one-byte long IDs (0xb2 and 0xf0, respectively). Thanks for catching this; I'll send a mail to matroska-devel.

[Keiyakusha]

The specs are indeed correct. Both new elements, CueDuration and CueRelativePosition, only use one-byte long IDs (0xb2 and 0xf0, respectively). Thanks for catching this; I'll send a mail to matroska-devel.

So do we need to wait for new build before using mkvtoolnix? or current v5.9.0 is safe after all?

BTW are these new elements supposed to solve issues with OPUS?

[Mosu]

The specs and libMatroska are both generated automatically from the same file. So mkvmerge is fine. Only the email sent to the mailing list was wrong.

The elements are not supposed to "fix Opus" because it is still unclear whether or not changes are required at all. Steve disagrees strongly with the Opus people on how timecodes should be stored in a container. Please read he discussion on the mailing list if you want the details,

[Mosu]

Well well well... VLC does have its problems with those new elements. Would not have thought so. The reason is simple. VLC does not skip elements it does not know about. It can be turned on, but it isn't on by default. You can find that option here: Tools -> Preferences -> “Show settings: all” at the bottom left; In the tree on the left side: Input/Codecs -> Matroska; make sure “Dummy elements” is turned on. See this screenshot (http://www.bunkus.org/pics/vlc-preferences-matroska-dummy-elements.png).

The tooltip for the option says something about being bad for damaged files. So I can understand the reasoning behind it. However, it also violates the Matroska specs (or at least its spirit). Note that I'm talking about skipping unknown elements, which should be supported by the application. Not knowing an element and not supporting it are two different things: it's perfectly OK to say "we don't support elements X, Y and Z", but to say "we found an element we don't know, so let's abort reading the whole tree from here on" is bad. Very bad.

I'll file a bug report. They'll add support for those elements. Everyone will update their players.

[sneaker_ger]

I have VLC 2.0.4 with standard settings ("Dummy Elements" not checked) and it seemed to work fine in a short test. What's broken exactly?

[Mosu]

Seeking, but that's broken bad. See the two bug reports I've submitted for VLC: 7884 (https://trac.videolan.org/vlc/ticket/7884) and [https://trac.videolan.org/vlc/ticket/7887]7887[/url].

[sneaker_ger]

I've looked at your reports, but I don't know in what way seeking is broken. I quickly remuxed a .mov trailer to mkv with mkvmerge 5.9.0 and seeked a bit around with VLC 2.0.4. It seems to just work at expected.
Is the playback supposed to stop? Your report says it will "abort"? Are the elements only created under specific conditions?

[Mosu]

Use any not trivially small file that doesn't fit easily into your machine's cache/memory (e.g. one over 4 GB) that has been muxed with v5.9.0. Make sure "dummy elements" is off. Start playback and seek far into the file. VLC locks up until it has reached that point by manually skipping over clusters because it wasn't able to read the cues properly.

What happens (technically) is that VLC aborts reading the rest of the file/section as soon as it finds an element that it doesn't know about. As each cue entry contains such an element now VLC does not read a single cue element successfully, resulting in VLC not having an index helping it seek.

Your trailer is most likely way too short to notice the slow method of skipping over content instead of using the index.

[sneaker_ger]

Thx for the explanation. I could indeed reproduce the problem with a file that was bigger. I hope the VLC devs know about this.

[Mosu]

TypX, the guy responsible for the two bugs, told me on IRC that he has seen them and that he'd respond over the weekend. His schedule is as full as mine though; and the holidays are coming up, so... Well. I made a couple of proposals how they can improve the situation while still keeping good user experience for heavily damaged files.

[Snowknight26]

The Windows installer doesn't show the image on the first installation screen; the label "MKVToolNix 5.9.0 by Moritz Bunkus" has a black background.

[Mosu]

I know, but I don't consider this to be of any significance. If you want to spend some time investigating why this happens then by all means, be my guest. I'd welcome the results. I'm running on Arch Linux using nsis compiled from the AUR; the NSI script and auxiliary files are publicly available on github (https://github.com/mbunkus/mkvtoolnix/tree/master/installer).

[Mosu]

The Windows installer doesn't show the image on the first installation screen; the label "MKVToolNix 5.9.0 by Moritz Bunkus" has a black background.

BTW, I've had too much free time on my hands today and fixed the problem. The issue is that the NSIS package in Arch Linux does not contain some of the patches that the package in the Ubuntu/Debian repositories contains. I've ported those packages and am using a modified NSIS on my Arch now which shows both the picture and the text properly.

[Mosu]

Here's a little Christmas present. I've implemented support for the Macromedia Flash Video file format over the last couple of days. As I don't have that many test files I'd appreciate some testing from you.

Support is implemented for:

MP3
AAC audio tracks (only tested with 2 channels, non-SBR)
h.264 video tracks (only tested with B-frame-less files; also: even if the timecodes were right B frames wouldn't be marked as such; in Matroska terms: only one reference and not two for BlockGroups and the 'Discardable' flag is not set for SimpleBlocks)
FLV1 (Flash's own variation of the h.263 codec)
FLV4 (untested)

What does not work: any other audio or video codec.

And here's the build (480 and newer) (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/).

Happy holidays!

[Superb]

Adobe* :P Nice feature. gj!

[Mosu]

Hmm. It has been Macromedia once upon a time. But you're right. I've renamed that stuff to "Flash Video" without a company name.

[Taurus]

Thanks for sharing.:thanks:
Really appreciated.
A Merry Christmas and a Happy New Year to you.

[Overdrive80]

Hi, I have various videos a 23.976 and audios with samplerate accord to their, synchronized.

However, I want reproduce video's parts to different framerate. I use this timecodes file for video.

# timecode format v1
assume 23.976
0,2615,25
2616,32423,24
3242,34727,25
34728,34916,24

I tried to assign the same timecodes to audio, but never in sync

My question is: How could I do for that audio is sync in?

Thanks in advance.

[Mosu]

Timecodes are assigned one to each Matroska block. Each Matroska block contains one... "unit". For video this is either a full progressive frame or one interlaced field. For audio, however, it's one audio frame (the smallest indivisible unit that audio codec can handle). How long such an audio frame is depends on how many samples there are in that block. Most audio formats have a fixed number of samples per frame (e.g. always 1024 for AAC). However, there are several problems that make playing around with those timecodes rather hard:

Different audio codecs use different number of samples per frame (e.g. AAC 1024, AC3 1536).
Even within the same audio codec it may depend on the frame headers (e.g. MP3: several possible numbers of samples: 384, 576 or 1152)
For some audio codecs it is only possible to estimate the number of samples in a frame without fully decoding it (Vorbis)
Even if you do manage to calculate the number of samples in each frame a lot of players will have real problems with playback speed and/or audio/video synchronization if the duration between two audio frames deviates too much from what it should normally be.

If you do have the number of samples in a unit you have its duration by calculating samples/sample_rate (this would be in seconds, then). The frame's timecode is the sum of all durations of all the preceding frames.

[Overdrive80]

Ohhh, maybe I must forget this idea... I dont understand the way to do it. Thanks

[Simon88]

FLV to MKV Conversion of a variable framerate FLV seems OK. I just opened the FLV without ANY changes to any settings... Just hit "add", then "start muxing".. Both Audio & Video were inside the MKV & were in sync. Also, the video is 640x480, where did the "640/485" come from, (the video stream had a wrong dimension descriptor??).. But I also received the following warning:

mkvmerge v5.9.0 ('On The Loose') built on Dec 31 2012 17:36:59


'C:\Downloads\mkvtoolnix-unicode-5.9.0-build20121231-488\video.flv' track 0: Using the output module for the format 'AVC/h.264'.


'C:\Downloads\mkvtoolnix-unicode-5.9.0-build20121231-488\video.flv' track 1: Using the output module for the format 'AAC'.


Warning: 'C:\Downloads\mkvtoolnix-unicode-5.9.0-build20121231-488\video.flv': A track with the ID 1 was requested but not found in the file. The corresponding option will be ignored.


The file 'C:\Downloads\mkvtoolnix-unicode-5.9.0-build20121231-488\video.mkv' has been opened for writing.


'C:\Downloads\mkvtoolnix-unicode-5.9.0-build20121231-488\video.flv' track 0: Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 640/485.


Progress: 0%
Progress: 10%
Progress: 25%
Progress: 36%
Progress: 48%
Progress: 60%
Progress: 74%
Progress: 81%
Progress: 92%
Progress: 100%
Progress: 100%



The cue entries (the index) are being written...


Muxing took 4 seconds.

---------

I use to use "FLVExtractCL.exe", then import it into "mkvmerge", but variable framerate FLVs had issues, obviously. I had to use ffmpeg to convert to an intermediate format before importing into mkvmerge in order to get proper A/V sync...

Anyhow, thanks for this new feature... and happy new year!!

edit: thanks for remaindering me, sneaker_ger: I meant variable frame-rate FLVs, as opposed to variable bitrate ... I got those two terms switched :-(

[sneaker_ger]

Variable bitrate does not pose any problems, only variable framerate if you don't use the timecodes when using FLVExtract + mkvmerge.

If you think mkvmerge does not handle your file correctly you should upload a sample, but if the information inside the flv is wrong, likely nothing will be done about it.

[Simon88]

"mkvtoolnix-unicode-5.9.0-build20130106-489", released only a few hours ago, seems to have fixed the issue I mentioned!

Thanx Mosu...

[Mosu]

Uhm... yeah, I meant to answer here that I've fixed the issue yesterday, but luckily you've found out by yourself already ;)

For reference, the issue Simon88 & I mean is this warning when reading FLV files:

Warning: 'C:\Downloads\mkvtoolnix-unicode-5.9.0-build20121231-488\video.flv': A track with the ID 1 was requested but not found in the file. The corresponding option will be ignored.

[[ReX]]

Are there any more supported formats for mkvextract that haven't been added to the documentation (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvextract.html#mkvextract.output_file_formats) like Theora and VP8?

[Mosu]

Likely. Are you offering to look at mkvextract's source code (https://github.com/mbunkus/mkvtoolnix/tree/master/src/extract) and to provide a patch for the documentation (https://github.com/mbunkus/mkvtoolnix/blob/master/doc/man/mkvextract.xml)? 'Cause that would be great.

[[ReX]]

Likely. Are you offering to look at mkvextract's source code (https://github.com/mbunkus/mkvtoolnix/tree/master/src/extract) and to provide a patch for the documentation (https://github.com/mbunkus/mkvtoolnix/blob/master/doc/man/mkvextract.xml)? 'Cause that would be great.

I was hoping you had a list, I can do that though. ;)

Edit: 0.4.2 had this change:
* Removed the '--sub-type' switch as all text subtitles will be
stored in UTF-8 format. Made iconv mandatory in the configure
checks for this very reason.

Does that mean S_TEXT/ASCII doesn't need to be documented along with S_TEXT/UTF8?

Another edit:
Is S_VOBSUB/ZLIB still applicable?
I tried muxing an IDX file with an equivalent ZIP file with the SUB file inside it, but mmg wouldn't accept it; I also tried setting the track compression to zlib, the resulting codec id was just S_VOBSUB.

Also it seems that setting the compression to lzo makes the track invisible to mkvmerge, and by extension, to mmg; mkvinfo can see it though.

[Sparktank]

I'm wondering if there's any work-around or solution to using mmg to do a complicated split.
I tried to search but couldn't find anything, or couldn't find the right words.

What I want to do is extract a Blu-Ray movie to MKV with splits (chapters or custom time codes).
Also with no "segment linking".

But to make things complicated, I want mmg to write only the segments I want to keep and not write unwanted segments/chapters.
As if it were to write a "null file" or "empty file" for the unwanted segments (even if it has to read through the unwanted segments to get to the wanted segments) so that no HDD space is taken and no manual deleting (to avoid any accidental deleting).

Only files written with data are the ones wanted.

Right now, I just remux to MKV with split time codes for the whole movie and manually delete the unwanted segments (sometimes deleting wanted segments).

It's not segment linked mostly for editing (like extracting Blu-Ray audio of the end credits; or experimenting with other AviSynth scripts (2Dto3D anaglyph; Interframe for Pseudo 60fps; etc)). Or sometimes just to have a favorite part of the movie to watch whenever I feel inclined (intense action scenes or graphically entertaining).

Example:
Movie.m2ts/Movie.mpls (from Blu-Ray) to Movie.mkv (split)
time codes in red are unwanted: split=00:00:00 to 00:05:00,00:05:00 to 00:15:00,00:15:00 to 00:45:00,00:45:00 to 00:47:00,00:47:00 to 01:00:00,01:00:00 to 01:10:00,01:10:00 to End Of File,

Keep/Write: [00:05:00 to 00:15:00], [00:45:00 to 00:47:00], [01:00:00 to 01:10:00]
Lose/Delete/Null Write: [00:00:00 to 00:05:00], [00:15:00 to 00:45:00], [00:47:00 to 01:00:00], [01:10:00 to End Of File]

I hope that seemed clear. It took awhile to think how to word it. :o :confused:
(Time for some more coffee.)

Is any of that possible with mmg? Perhaps in combination with a batch script or perl script?
Any ideas or help would be greatly appreciated.

[sneaker_ger]

Yes, that is possible. See doc (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html) 2.5 subchapter "4. Keeping specific parts by specifying timecode ranges while discarding others.".

[Pomegranate]

@ sneaker_ger
Thank you for that tip! I never managed to do this with MKVMergeGui and didn't even think to try the command line.

[Sparktank]

Yes, that is possible. See doc (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html) 2.5 subchapter "4. Keeping specific parts by specifying timecode ranges while discarding others.".

That's perfect! Thank you so much!
I feel so noobish for not seeing that part before. ; ;

[Mosu]

;1610542']I was hoping you had a list, I can do that though. ;)

The man page's list is the only list I have. Other than the source code, of course ;)

Does that mean S_TEXT/ASCII doesn't need to be documented along with S_TEXT/UTF8?

I don't know of a single program that can produce or read S_TEXT/ASCII subtitles (mkvmerge cannot create them). I think we even deprecated that CodecID.

Is S_VOBSUB/ZLIB still applicable?

No. That was from back in the day (roughly ten years ago) when we thought of using the CodecID for providing addition information like the compression scheme used. I've never seen a file with that CodecID in the wild.

There's something similar for A_AAC (e.g. A_AAC/LTP etc.) before we decided to store AAC's data in CodecPrivate and simply use the shorter CodecID A_AAC, and as mkvmerge had been writing such files for some time there are actually files out there with the longer CodecIDs.

I tried muxing an IDX file with an equivalent ZIP file with the SUB file inside it

mkvmerge has never supported that, and that isn't what the /ZLIB postfix was about (btw, zlib = gzip != zip).

I also tried setting the track compression to zlib, the resulting codec id was just S_VOBSUB.

Correct. The compression scheme used is stored in a separate element hierarchy ("ContentEncodings") in the track headers.

Also it seems that setting the compression to lzo makes the track invisible to mkvmerge, and by extension, to mmg; mkvinfo can see it though.

Hmmm sounds like a bug. Although I somehow doubt there are five people on this planet who've ever used lzo in mkvmerge ;) It's faster than zlib but has worse compression. bzip2 is the other way around. However, most devices only support zlib, and that's what should be used.

[Mosu]

@ sneaker_ger
Thank you for that tip! I never managed to do this with MKVMergeGui and didn't even think to try the command line.

No need to use the command line for this. In mmg this is called "splitting by parts".

[Mosu]

That's perfect! Thank you so much!
I feel so noobish for not seeing that part before. ; ;

In was implemented with release v5.5.0 on 2012-04-06. So it's only been available for a little while.