mkvtoolnix 4.1.1 released

[Mosu]

Yes. The header editor allows the user to edit the "segment info" and "track" headers. With it you can change existing values, add values for fields that are not currently present, and remove existing fields as long as they're not mandatory according to the specs.

When the header editor saves its changes to the file it will intelligently pick the best place to store the elements, overwrite any other existing element of the same kind (e.g. Haali's muxer can write the track headers at more than one place) in order to avoid ambiguity, and update the index (meta seek elements) to reflect all changes.

The part that takes quite some time is the initial file scanning phase when you open a file in the header editor. The editor will scan all level 1 elements (those are segment info, track headers, meta seek elements, but also all clusters) for their size and position. While this does not require reading the whole file it still takes a lot of time. This cannot be avoided.

At the moment the header editor also re-scans the file after having saved its changes. This is mainly a safety measure and not strictly neccessary. It will be removed in a future release so that saving the file only takes a second or two.

I should also issue a warning here: Even though I've spent many hours (at least ten) making sure my "save to existing file" algorithm doesn't screw up your files there may still be bugs left in it. So it might be wise to make a backup of important files before editing them, or at least try it on a couple of not so important files first.

[Liisachan]

Thanks for 2.6.0! I'm going to play with the header editor.
I'm not sure if this is exactly a great idea: The "simple" chapter extraction mode (OGM style chapter output) outputs strings converted to the system's
current charset by default now instead of always converting to UTF-8.
But if that makes other people happy...
And I can use explicit --output-charset anyway.

[Mosu]

You could also just NOT use the simple chapter format ;) Use the XML chapter format, that's always UTF-8 anyway. Aaaand it offers more features.

[madshi]

Yes. The header editor allows the user to edit the "segment info" and "track" headers. With it you can change existing values, add values for fields that are not currently present, and remove existing fields as long as they're not mandatory according to the specs.

When the header editor saves its changes to the file it will intelligently pick the best place to store the elements, overwrite any other existing element of the same kind (e.g. Haali's muxer can write the track headers at more than one place) in order to avoid ambiguity, and update the index (meta seek elements) to reflect all changes.

The part that takes quite some time is the initial file scanning phase when you open a file in the header editor. The editor will scan all level 1 elements (those are segment info, track headers, meta seek elements, but also all clusters) for their size and position. While this does not require reading the whole file it still takes a lot of time. This cannot be avoided.

At the moment the header editor also re-scans the file after having saved its changes. This is mainly a safety measure and not strictly neccessary. It will be removed in a future release so that saving the file only takes a second or two.
Thanks, sounds very good! I think this new functionality is really a worthwhile addition.

I'm wondering: Why do you have to read in all the clusters? Is that needed for meta seek updating or what?

[Mosu]

As I said the scan process locates all level 1 elements. This is a pretty easy process: read the EBML ID, read the element size, seek to the end of the element. But most files use rather small clusters of 2 MB. So mmg reads eight bytes, skips 2 MB, reads eight bytes, skips 2 MB etc. This is not that fast, but not catastrophically slow either. Due to its nature it will be pretty slow when accessing files over a network, I guess.

On my PC this takes roughly a minute for a 1.4 GB file.

I'm wondering: Why do you have to read in all the clusters? Is that needed for meta seek updating or what?

Yes. Matroska's flexible structure allows most header fields to not be present. So when you add a couple of fields mmg might not be able to fit the new headers into the space the old ones occupied. So it looks for the proper place to store them. This can be anywhere in the file with enough "free space".

Another reason is that there's the possibility that there is more than one occurence of the track headers, e.g. Haali's muxer can write multiple instances. Those have to be overwritten in order to not cause ambiguity between updated and not updated headers. As the level 1 elements are not always indexed by meta seek elements mmg has to scan the whole file.

I have an idea or two of how to make this process a bit faster by making certain assumptions as long as there are proper meta seek elements -- but I wanted to get it right first and fast later.

[Snowknight26]

The installer still likes to take its time when adding/removing the path to the system variables on Vista. Appears (but doesn't) to hang while its doing so.

[Mosu]

Ok, cannot do anything about that though.

[nurbs]

I noticed a small bug in mkvmergeGUI. When you use the job queue the "current job" progress bar doesn't show any progress. The bar that shows the finished jobs works fine.

[Mosu]

Interesting bug. Which OS? Which language do you run mmg with?

[turbojet]

Is sup support a possibility in the not so distant future?

[Mosu]

Maybe, don't know yet. Are there specs available? Or source code for demuxers/decoders that can read those files?

[turbojet]

Unfortunately I don't think there's any specs available and the best information I can get about them is that they contain compressed pictures by RLE (http://en.wikipedia.org/wiki/Run-length_encoding)

DVD sups are used by many authoring applications and can be demuxed by tools like pgcedit and ifoedit. Also just about every text sub/vobsub editor inputs dvd sups. When placed in a vob they can be decoded by many players without the use of an external decoder but I believe DirectVobSub can also decode these.

BD/HDDVD sups are gaining more and more software support. TSMuxer and eac3to demux subtitles to sup only. SupRip, BDSup2Sub, SupRead are sup editors/converters. TSMuxer/TSRemuX/TS4NP use them as input to mux to (m2)ts files. Only players I know of that can decode these are commercial BD players (PowerDVD, Showtime, WinDVD, Arcsoft, etc.) and MPC-HC which I believe uses an updated vsfilter.dll (http://www.xvidvideo.ru/component/option,com_docman/task,doc_download/gid,1423/).

The reason I ask for the sup is so original subtitles can be used without relying on OCR.

[Mosu]

So no specs, no open source apps? Then I won't be spending time on them soon, sorry.

[turbojet]

Oh source code you were looking for didn't notice that. Here's some:
PGCDemux (http://download.videohelp.com/jsoto/tools/PgcDemux_1205_src.zip) a dvd sup demuxer
MPC_HC SVN (http://sourceforge.net/scm/?type=svn&group_id=170561) (hd)dvd\bd player\decoder
SubtitleCreator (http://sourceforge.net/project/showfiles.php?group_id=120228&package_id=251117) (hd)dvd sup editor\converter
DVDSubEdit (http://download.videohelp.com/DVDSubEdit/Downloads/DVDSubEditSource1.5.zip) dvd sup editor\converter
TSRemux (http://www.megaupload.com/?d=6G5LPRI4) remuxes BD with sup's

Also info on BD\HDDVD sup (http://exar.ch/suprip/hddvd.php) and some info on dvd sup here (http://dvd.sourceforge.net/spu_notes) and here (http://www.mpeg.org/MPEG/DVD/Book_B/Subpic.html) and here (http://dvd.sourceforge.net/dvdinfo/spu.html)

[Mosu]

Ah thanks a lot for the links. Now all I'd need would be some sample files. Preferably as TS or EVOs :)

[Mosu]

Hmm, aren't those the same as vobsubs except that they haven't been extracted from the program streams?

[nurbs]

Interesting bug. Which OS? Which language do you run mmg with?

Windows XP SP3, german.

[Mosu]

I'll take a look. Please try changing mmg's language to English and see if the progress works normally then.

[turbojet]

Your welcome.

BD sup (http://www.sendspace.com/file/e8ohwr)

DVD sup (http://www.sendspace.com/file/9u3dlo)

I don't have any HDDVD sup files here.

If you need the subs inside of a ts container I can upload it in about an hour when blankclip x264 encode finishes.

They may be like vobsub but sup supports things vobsub doesn't like adding a line to a current line without redrawing, different font/color in the same line, fades. VobSub isn't supported by any authoring programs as far as I know, sup is supported by all that I know of except scenarist which uses it's own proprietary scn format or plain bitmaps.

[Mosu]

Thanks for the samples.

What I'm wondering is if there's a need for the information that VobSub stores in the .idx files -- like palette information etc. Those are gathered from the IFO files if I'm not mistaken. Or is a sup substream enough for proper display?

[turbojet]

Oh, from what I can tell, dvd vob needs ifo to get it's color palette and stream language. Without the ifo file it relies on the player's color palette and stream languages are unknown.

With BD a standalone (m2)ts file displays subs fine, it also contains stream language (tsmuxer detects) but MPC-HC sets the stream languages as unknown.

[Mosu]

I noticed a small bug in mkvmergeGUI. When you use the job queue the "current job" progress bar doesn't show any progress. The bar that shows the finished jobs works fine.

Found the problem. The next release will have it fixed.

[nurbs]

Thank you!

[turbojet]

Here's a 1080p sup muxed with 1080p blank video in an m2ts (http://www.sendspace.com/file/ki7zsg) if you still needed it.

Sorry it took so long, forgot about it, and thanks for looking at supporting it.

[Mosu]

Thanks again for providing the files.

[HymnToLife]

Not sure if this has been reported already, but when I import a MKV file that has a colon in its File/segment title, the colon gets replaced with a "c" in the box under the "Global" tab.

[yonta]

2009-03-29 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge, mkvetract: new feature: Added support for TrueHD audio
(read from raw streams with or without embedded AC3 frames, MPEG
program streams).


Thank you for adding support for TrueHD streams.

Direct muxing from a evo file fails with Error: common.cpp/safemalloc() called from file src/common/mpeg4_common.cpp, line 1039: malloc() returned NULL for a size of 229756 bytes.
Demuxed streams work fine.

evo sample (http://www.sendspace.com/file/fobcdg)

[Mosu]

Not sure if this has been reported already, but when I import a MKV file that has a colon in its File/segment title, the colon gets replaced with a "c" in the box under the "Global" tab.

Thanks, should be fixed in http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.6.0-build20090330-101-setup.exe

[Kurtnoise]

@Mosu: the sample "God Save The Queen" from here (http://samples.mplayerhq.hu/A-codecs/lossless/mlp/) doesn't seem to be recognized as trueHD stream by mkvmerge...

[Mosu]

MLP is not TrueHD, even though it is almost identical. I've purposefully not added support for MLP.

[madshi]

Of course you could store MLP content as A_MLP (all else similar to TrueHD muxing)... ;) The purpose of this would be to make demuxed MLP audio tracks (coming from DVD-Audio) seekable. Demuxed MLP audio tracks are not properly seekable in demuxed form due to being VBR.

Not sure how important this is, though. I think TrueHD support is *much* more important!

However, I've heard, the libav guys will very soon have a fully functional MLP encoder. That might increase need for MKV MLP muxing?

[Mosu]

True. Here's a build with MLP support on top of the TrueHD support and a fix for the loss of the last TrueHD/MLP frame during muxing: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.6.0-build20090330-102-setup.exe

[madshi]

Thanks! :) Now if only Haali added splitting support for that... :(

[Mosu]

Please use http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.6.0-build20090330-103-setup.exe for TrueHD/MLP tests -- earlier builds had the sample rate and number of channels swapped for TrueHD/MLP tracks read from EVOs.

[canuckerfan]

good stuff! any chance for DTS-HD MA?

[yonta]

good stuff! any chance for DTS-HD MA?

2008-03-09 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: new feature: Added support for DTS-HD (both "master audio" and "high resolution").

[Mosu]

The only type of DTS audio that's not supported yet that I am aware of is DTS Express. I don't have plans to implement support for it in the near future.

[canuckerfan]

2008-03-09 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: new feature: Added support for DTS-HD (both "master audio" and "high resolution").
wow, that's wicked! do MKV splitters need to also support this, too or will they already work?

[Egh]

wow, that's wicked! do MKV splitters need to also support this, too or will they already work?

MPCHC internal does. Not sure about haali yet ;)

[yonta]

Both MPC-HC internal and Haali's splitters output DTS-HD streams.
But, there's no free DTS-HD decoder yet.

[The_Keymaker]

Please use http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.6.0-build20090330-103-setup.exe for TrueHD/MLP tests -- earlier builds had the sample rate and number of channels swapped for TrueHD/MLP tracks read from EVOs.

I loaded this version of MKVtoolnix (MKVmerge) and muxed the Iron man TrueHD+AC3 audio and Video.

However, when I attempted to play back the file using Zoom Player, only the VIDEO showed up in Zoom Player. An audio stream was not found.

I'm assuming this is an MKVmerge issue and not an eac3to issue since I was able to play the TrueHD+AC3 file fine as a standalone file (i.e., not in a MKV container).

Has anyone had success muxing a TrueHD+AC3 audio file?

NOTE: I have been told that the Haali Media Splitter does not recognize TrueHD tracks. I must use the MPC HC Mpeg splitter!

[Maccara]

Thank you very much for the new version.

Now, I suggest you fix the Windows installer. If you can't set PATH properly, DO NOT set it at all! Especially since you overwrite the system PATH, not the USER! (wreaks all kinds of interesting havoc)

At least this application informed me properly it screwed up, so I could restore it. :)

(HINT: installer probably parses strings containing "(x64)" etc incorrectly - not the first time I've seen this and probably won't be the last; proper string handling seems next to impossible for installer authors - or they do not realize PATH variable is case insensitive, so it can be Path PATH pATH)

[Mosu]

NOTE: I have been told that the Haali Media Splitter does not recognize TrueHD tracks.

That's correct so far. Therefore what you're experiencing is most likely not a bug in mkvtoolnix.

[Mosu]

Now, I suggest you fix the Windows installer. If you can't set PATH properly, DO NOT set it at all!

Please open a bug in my Bugzilla (https://www.bunkus.org/bugzilla/) for this problem.

[Maccara]

Please open a bug in my Bugzilla (https://www.bunkus.org/bugzilla/) for this problem.

Sorry, public email required for reporting which will be seen by all.

Will have to wait until I have a trash account I can use.

Just remove the damn path settings altogether as 1. they're BROKEN 2. would not work on Vista /w UAC anyway (or so I would gather - can't test atm)

As it is now, it does more harm than good.

Edit: I will report the bug properly when I have the time, but for the meanwhile at least remove it until it can be fixed as the potential to screw up users' system is great at the moment.

[Mosu]

You'll be happy to know that you're one of two users having reported anything like this at all and that therefore the potential to cause great harm hasn't struck as often as you fear.

[Maccara]

You'll be happy to know that you're one of two users having reported anything like this at all and that therefore the potential to cause great harm hasn't struck as often as you fear.

That's good to know.

It maybe some specific string/combination I have in the path that triggers this behavior (although, there shouldn't be anything "special" there).

Also, as the specific message from installer was "path was empty", maybe it simply was because my "PATH" was spelled "Path" and some installers are not case insensitive (should be, as they are case insensitive strings) and simply can't find the variable with different casing.

I'll see at some point if I can replicate this issue again and what the conditions seem to be to cause that and open a bug report about it.

[Mosu]

The installer modifies the registry key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\PATH", so it'd be nice if you could dump that one and send me the resulting .reg file if you can reproduce the problem.

[LeMoi]

I tried to install 2.6.0 over a 2.2.0 installation. installation worked fine but not mmg, every time I loaded a fil, i had a code 0 error, file not recoginzed, mkvmerge not found... I checked the path in the options, removed and reinstalled mkvtoolnix, cleaned registry, no way : i can't make version 2.6.0 work, i had to go back du 2.2.0 :s

[Mosu]

Uninstall v2.2.0, remove the installation folder. Remove the HKEY_LOCAL_MACHINE\Software\mkvmergeGUI and HKEY_CURRENT_USER\Software\mkvmergeGUI registry entries and their children. Install v2.6.0.

The only cases that I know of of mkvmerge always failing is when old DLLs haven't been removed properly.