mkvtoolnix 4.1.1 released

[KoD]

Ah, I was not aware there was a File->New menu option ! :D

In this case there's no need indeed for clearing those fields when remove is pressed. :)

[Mosu]

Here's a new build with a couple of bug fixes in the VC1 code. Especially EVOBs with multiple VC1 video tracks are read correctly now.

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

[STaRGaZeR]

A request Mosu, can you add a 60000/1001 option?

[yonta]

Mosu, can you take a look at this sample (http://www.sendspace.com/file/yxqa5g)?
It's from a HDTV cap and 1080i@60 MPEG2 ES.
I try to load it in mmg and mmg gives that message I get when I load a AVC ES?

You're adding an AVC/h.264 elementary stream.......

I'm using 20080925-1 build.

[Mosu]

Please download this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.3.0-build20081004-2.rar It fixes file type detection for your file.

[madshi]

@Mosu, would it be easy for you to add a version resource to the win32 mkvmerge.exe and mmg.exe files? Or at least to the mmg.exe file? The reason I'm asking is that my "eac3to" tool contains an "is there a new mkvtoolnix beta build available?" online check. Currently I'm using "mkvmerge --version" to do this check. But it seems that sometimes mmg.exe has a later date in a new beta build compared to mkvmerge.exe (e.g. in latest beta build mkvmerge reports Oct 4, while mmg.exe seems to be Oct 5), and since I can't programatically read out the mmg.exe version number and compile date, my version check sometimes fails to work properly.

[Mosu]

Starting with http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.3.0-build20081006-12.rar all EXEs have VERSIONINFO resources. Here's such a resource for mkvmerge for a release version:

1 VERSIONINFO
FILEVERSION 2, 3, 0, 0
PRODUCTVERSION 2, 3, 0, 0
FILEFLAGSMASK 0x3f
FILEOS 0x4
BEGIN
BLOCK "StringFileInfo"
BEGIN
BLOCK "040904B0"
BEGIN
VALUE "CompanyName", "Moritz Bunkus"
VALUE "FileDescription", "mkvmerge"
VALUE "FileVersion", "2.3.0"
VALUE "InternalName", "mkvmerge"
VALUE "LegalCopyright", "Released under the GNU Pulic License http://www.gnu.org/licenses/gpl-2.0.html"
VALUE "OriginalFilename", "mkvmerge"
VALUE "ProductName", "MKVToolNix"
VALUE "ProductVersion", "2.3.0"
END
END
END

Builds between releases have their build date and number coded into "File Version" and "Product Version", e.g.
...
VALUE "FileVersion", "2.3.0-build20081006-12"
...

[madshi]

That's *very* nice - thank you! :)

Just a quick question: Is there a specific exe you're always updating in a new beta build? Or should I simply loop through all exes to make sure I find the newest one to be able to show the proper version information?

[Mosu]

I've modified my build and upload scripts to always put the same version information into all EXEs and to re-build all EXEs for a beta build. Each build has its own unique version/build number. Therefore you should not have to loop through all EXEs anymore.

PS: The information shown in mmg's "About" window and in "mkvmerge --version" might not correspond to the version information in the resource. Use the data from the resource. That's more reliable for the Windows port. (The reason is simple: time. Building mkvmerge so that its --version output is up to date takes about 5 minutes with my crappy build computer while simply relinking with newer resources is done in 15 seconds or so.)

[madshi]

Great, will update my version check accordingly. Thanks again!

[madshi]

P.S: You could change the "mkvmerge --version" code in such a way that it reads its own EXE version resource and then outputs that. As a result you'd never have to waste those 5 minutes, anymore. At least that's how eac3to's version display works... ;)

[Mosu]

True, but that's no cure because there's no such thing as resources on non-Windows operating systems :)

[swaaye]

I've noticed that mkvmerge is very slow when muxing to a network drive. On my gigabit LAN, it can only pull about 5 MB/s even when it is only writing to the network (reading sources from local system drive.) I can dump DVDs to network drives at 20-30 MB/s, on the other hand.

Is this due to small-sized write accesses causing tons of overhead perhaps? It's a curious thing.

[Mosu]

Yes, most likely. mkvmerge is not multi-threaded and does not use advanced read-ahead or caching mechanisms. Sorry, I don't have time to do everything.

[swaaye]

Yes, most likely. mkvmerge is not multi-threaded and does not use advanced read-ahead or caching mechanisms. Sorry, I don't have time to do everything.

No no. I'm not asking for anything, just mentioning what I've run into. Your app is great! I'm not exactly using it in a typical way and it's not a critical thing at all .

[zeropc]

mosu, is it possible to add full support of .m2ts container import?

this would save some big time demuxing ;)

[Mosu]

Maybe, maybe not.

[madshi]

There are 2 big problems with adding m2ts support to mkvtoolnix:

(1) Some audio tracks might need transcoding to make sense. E.g. there's no current standard to store TrueHD in MKV. So TrueHD would have to be transcoded to something else. Or alternatively the Matroska "official forces" would have to be asked to add an official method to mux TrueHD into MKV. But even if that happens, mkvtoolnix would still have to be able to strip the AC3 frames from the TrueHD stream. That's possible to do, but can't be developed in 5 minutes.

(2) Some Blu-Ray movies consist of multiple m2ts parts. Simply demuxing video/audio and remuxing them into MKV would result in audio slowly drifting out of sync throughout the whole movie because audio overlaps in these m2ts parts while video (usually) does not.

As a result I'm not sure if it's worth it for Mosu to add m2ts support. However, @Mosu, if you want to add ts/m2ts support, when you have any technical questions, feel free to contact me.

[Mosu]

(2) Some Blu-Ray movies consist of multiple m2ts parts. Simply demuxing video/audio and remuxing them into MKV would result in audio slowly drifting out of sync throughout the whole movie because audio overlaps in these m2ts parts while video (usually) does not.

Oh my frellin' god. Which idiot came up with that scheme!?

Anyway, adding MPEG TS support is one of the bigger projects left. I might tackle this one day, but that's more an "if I find the time and motivation" than a "when I find the time and motivation".

[madshi]

Oh my frellin' god. Which idiot came up with that scheme!?
Well, if you think about it, it does make some sense. Each of the m2ts parts must play on its own (this logic is mainly used for seamless branching titles). So at the beginning of each m2ts part video and audio are perfectly in sync. But since e.g. an AC3 audio frame is 32ms long and video frames are usually 41.7ms long there's a runtime mismatch between audio and video. So it's clear that either audio or video have to overlap a bit. That's ok for a Blu-Ray player, but of course a bit problematic for a demuxing/transcoding tool.

[Mosu]

Ah yes, I was thinking about repeated audio packets. That would have been stupid. Overlapping timecodes are fine, though.

[Mosu]

Hey Matroska users,

here's another release of mkvtoolnix, 2.4.0. New features include support for VC1 video read from elementary streams and MPEG program streams, Dirac video elementary streams, support for 7.1 channel EAC3 tracks and the extraction of Theora video tracks into Ogg files. Bug that were fixed include the handling of unknown tracks in Ogg files, the automatic garbage detection for AC3/MP3 tracks, the handling of DTS in MPEG program streams, (E)AC3 files bigger than 2 GB and many more.

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

...to the Windows installer:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-2.4.0-setup.exe

The Linux binaries that I provide myself (Debian, Ubuntu, OpenSuSE and Fedora Core) have already been uploaded and are available from the home page.

Here's the full ChangeLog since release 2.3.0:

------------------------------------------------------------
2008-10-11 Moritz Bunkus <moritz@bunkus.org>

* Released v2.4.0.

* mmg: bug fix: The chapter editor's function "save to Matroska file" was corrupting the target file in some cases. Fix for bug 307.

2008-10-06 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: bug fix: mkvmerge was only writing one reference block for real B frames. Patch by Daniel Glckner. Fix for bug 306.

* all: bug fix: The Windows uninstaller was not removing all start menu entries during uninstallation on Windows Vista. The installer now creates the start menu entries for all users instead of the current user only. Fix for bug 305.

2008-10-05 Moritz Bunkus <moritz@bunkus.org>

* mmg: bug fix: The "language" drop down box contained some entries twice or more. Fix for bug 304.

2008-10-04 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: bug fix: Incorrect usage of the iconv library caused some conversions to omit the last character of each converted entry (e.g. for the conversion from Hebrew to UTF-8). Fix for bug 302.

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

* mkvmerge: enhancement: mkvmerge will use the timecodes provided by the MPEG program stream source file for VC1 video tracks.

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

* mkvmerge: bug fix: Reading EVOBs with multiple VC1 video tracks was broken (all packets where put into a single video track).

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

* mkvextract: new feature: Added support for handling SimpleBlocks for timecode extraction.

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

* mkvmerge: bug fix: Reading raw (E)AC3 files bigger than 2 GB was broken.

* mkvmerge: new feature: Added support for Dirac video tracks.

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

* mkvmerge: bug fix: Improved the detection of MPEG-1/-2 and AVC/h.264 video tracks in MPEG program streams (VOBs/EVOBs).

* mkvmerge: bug fix: Fixed reading DTS audio tracks from MPEG program streams (VOBs/EVOBs).

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

* mmg: enhancement: Added the extensions "evo", "evob" and "vob" to mmg's "add file" dialog.

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

* mkvmerge: new feature: Added support for muxing VC1 video tracks read from MPEG program streams (EVOBs) or raw VC1 elementary streams (e.g. as produced by EVODemux).

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

* mkvmerge: new feature: Added support for 7.1 channel EAC3 files. Fix for bug 301.

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

* mkvmerge: bug fix: Revision 3831 (the change to the "--delay" and "--sync" options) caused mkvmerge to no longer respect the delay caused by garbage at the beginning of MP3 and AC3 audio tracks in AVI files. The timecodes of such tracks are now delayed appropriately again. Fix for bug 300.

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

* mkvmerge: bug fix: Unknown stream types in Ogg files (e.g. skeleton tracks) don't cause mkvmerge to abort anymore. They're simply ignored. Fix for bug 299.

* mkvextract: new feature: Added support for extracting Theora video tracks into Ogg files. Fix for bug 298.

* mkvmerge: bug fix: Fixed the frame type (key or non-key frame) detection for Theora tracks.
------------------------------------------------------------

Have fun :)

Regards,
Mosu

[shon3i]

Thanks :)

PS. can you update title of this topic and first post?

[Mosu]

Done.

[excentro]

Thank you.

[video_magic]

Hello Mosu and thankyou very much!

[delacroixp]

:thanks: much !


It's all good !
:):devil::D
Pascal

[KoD]

I noticed that mkvextract extracts chapters to utf-8 files with a signature, which is great.

However, when extracting chapters with mkvextract, the contents of a <ChapterSegmentUID format="hex"> element is made of illegal UTF8 characters. Is that the expected behavior ? I think the file is not a legal xml file in this case. And it can't be opened in a text editor either, it has to be opened in a Hex editor who doesn't care about the contents of the file. Even mkvmerge crashes when trying to load that xml chapters file.

<ChapterAtom>
<ChapterTimeStart>00:00:00.000000000</ChapterTimeStart>
<ChapterTimeEnd>00:01:00.000000000</ChapterTimeEnd>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterSegmentUID format="hex">_illegal_utf8_characters_happen_here</ChapterSegmentUID>
<ChapterUID>2647081373</ChapterUID>
<ChapterDisplay>
<ChapterString>Chapter Title Goes Here</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>

Btw, MKVExtractGUI was a collateral victim of the latest mkvtoolnix. Seems to not like the output of the cli utilities/libraries' calls anymore. Is the original author around ? If not, I'll have a look at the source code as there was another issue I did not like, it was replacing the utf-8 bom of extracted chapter files with a "?".

[Mosu]

I noticed that mkvextract extracts chapters to utf-8 files with a signature, which is great.

However, when extracting chapters with mkvextract, the contents of a <ChapterSegmentUID format="hex"> element is made of illegal UTF8 characters. Is that the expected behavior ? I think the file is not a legal xml file in this case. And it can't be opened in a text editor either, it has to be opened in a Hex editor who doesn't care about the contents of the file.

You're mixing things here. The XML file itself is encoded in UTF-8, that's correct. From the point of view of the XML layer the content of the ChapterSegmentUID element contains only 17 different characters: 0-9, A-F and spaces. All those are perfectly valid UTF-8 characters.

The fact that mkvmerge translates this into binary data is entirely another matter. This happens after the data has been removed from the XML container, and therefore XML doesn't care anymore what happens to it.

[KoD]

I see what you're saying. I'm not an expert in xml, so I'll take your word on that.

I've made an edit later on to that post. In this case, I'd only like to report that mkvmerge crashes when loading said chapters xml file that it has itself exported previously.

[Mosu]

Can you upload that chapter file somewhere, please?

[KoD]

I've sent you a PM with lots of details. Let me know if there's anything else needed. :)

[Mosu]

Thanks. Fixed the bug in mkvextract. Here's a new build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.4.0-build20081013-24.rar

[KoD]

Thank you. I confirm it works here too. And now MKVMergeGUI works again, as well. :D

[NanoBot]

Hi Mosu, hi everybody,

yesterday I began to create some mka files ( only audio ), which should contain one ore more DTS tracks. This worked fine in most cases, but some dts files where rejected by mkvmerge with the following error messages:


mkvmerge v2.4.0 ('Fumbling Towards Ecstasy') built on Oct 13 2008 21:05:53
'G:\DTS\test.dts': Using the DTS demultiplexer.
'G:\DTS\test.dts' track 0: Using the DTS output module.
The file 'H:\test.mka' has been opened for writing.
Warning: 'G:\DTS\test.dts' track 0: Skipping 3583 bytes (no valid DTS header found). This might cause audio/video desynchronisation.
Progress: 0%Warning: 'G:\DTS\test.dts' track 0: Skipping 3583 bytes (no valid DTS header found). This might cause audio/video desynchronisation.
Warning: 'G:\DTS\test.dts' track 0: Skipping 3583 bytes (no valid DTS header found). This might cause audio/video desynchronisation.


and lots more of that.

eac3to also complains that is it not able to identify the source file format. I am able to playback those DTS files with MPC_HC together with AC3Filter, both through spdif or analog, but the internal DTS dekoder of MPC_HC is playing them back with wrong speed and pitch ( same as a mka muxxed with Haali, see below ). Mediainfo reports about those files:

Audio
Format : DTS-HD
Format/Info : Digital Theater Systems
Bitraten-Modus : Variable
Kanäle : 6 Kanäle
Channel positions : Front: L C R, Surround: L R, LFE
Samplingrate : 44,1 KHz
Auflösung : 20 bits

As a comparision, those DTS files which don't make problems look like that:

Format : DTS
Format/Info : Digital Theater Systems
Bitraten-Modus : Constant
Bitrate : 1 411,2 Kbps
Kanäle : 6 Kanäle
Channel positions : Front: L C R, Surround: L R, LFE
Samplingrate : 44,1 KHz
Auflösung : 24 bits


I also tried to mux such a file to mka using Haalis gsdmux, this works, but when the resulting mka file has a total wrong playtime, and the playback is strange, e.g. the pitch of the audio is absolute incorrect. Then I tried to "repair" those files with DTSParser, but this doesn't help at all.

So my question is what is wrong about those files ? Is it the 20bit depth, or is it the bitrate flagged as variable ?

If it is helpful I am able to provide a sample of such a DTS file.

C.U. NanoBot

[nautilus7]

These are DTS-HD tracks, but if eac3to can't handle them, then they may be damaged. Can you post the eac3to log file?

[NanoBot]

The only answer from eac3to is

"The format of the source file could not be detected."

[nautilus7]

That among with the error log from mkvmerge tell me that your file is corrupted. Does it play as it is? Where did you find the dts track and how did you demux it? If it came from a disc, re-rip the disc and try again.

[NanoBot]

Yeah, I think reripping is the only solution. What makes me wondering is that ac3filter is able to play those files without problems.

Anyway, thanks for your attempted help.

[NanoBot]

Hi again,

as an exception, I will answer my own posting because I found the reason for my problems. If one of the moderators would be so kind, he might move all postings related to this subject to a new thread, perhaps in the audio encoding forum.

First of all, reripping the DTS audio CDs was not the solution, because the ripped dtswav files were okay. The problem was caused by the programs which are used to convert dtswav files to dts files. I tried three different programs, that's wav2dts, besplit and DTSParser, and for some reason, all of them set the frame size in newly produced dts files to 3585 byte instead of 3584 byte by mistake. I found that by comparing the DTS headers of one of the defective files to another DTS file, which are working fine. The informations on that website were helpful for me to point out the error:

http://wiki.multimedia.cx/index.php?title=DTS

Correct DTS file headers:

Frame Type 1 normal
NumOfSamples - 1 11111 31
CRCPresent 0 no
NumOfBlocks 0011111 31
FrameSize - 1 00110111111111 3583
ChannelConfig 001001 L,C,R,SL,SR,LFE
SampleRate 1000 44100Hz
BitRate 10110 1411,2 kBit/s
DownMix 0
DynamicRange 0
TimeStamp 0
AuxData 0
HDCD 0
External Descr 000
External coding 0
ASPF 1
LFE 10
Predictor history 1
Header CRC not present
Multirate inter 0
Version 0111
Copy history 01
Source PCM resolution 000 16 bit
Front sum 0
Surround sum 0
Dialog normalization 0000 none


Defective DTS file header:

Frame Type 1 normal
NumOfSamples - 1 11111 31
CRCPresent 0 no
NumOfBlocks 0011111 31
FrameSize - 1 00111000000000 3584
ChannelConfig 001001 L,C,R,SL,SR,LFE
SampleRate 1000 44100Hz
BitRate 10110 1411,2 kBit/s
DownMix 0
DynamicRange 0
TimeStamp 0
AuxData 0
HDCD 0
External Descr 000
External Coding 0
ASPF 1
LFE 10
Predictor History 1
Header CRC not present
Multirate inter 0
Version 0111
Copy history 01
Source PCM resolution 010 20 bit
Front sum 0
Surround sum 0
Dialog normalization 0000 none


Is it possible that the authors of all three programs did not notice that the relevant header field must contain the frame size - 1 ?

C.U. NanoBot

[nautilus7]

All you had to do was to use eac3to to convert your dtswavs to dts (you didn't tell you are dealing with such). :p eac3to works fine with them.;)

[NanoBot]

Hi nautilus7,

If it would have been so easy...

One of the problematic cds was this title:

http://www.cduniverse.com/productinfo.asp?pid=1280942&cart=785928301

When I feed the ripped dtswav to eac3to it is not able to identify the wav file as dtswav, it sees it as a normal two channel PCM wav:

D:\MPEG\EAC3TO>eac3to.exe f:\moody.wav g:\test.dts
WAV, 2.0 channels, 0:43:34, 16 bits, 1411kbps, 44.1khz
Reading WAV...
Writing WAVs...
Creating file "g:\test.L.wav"...
Creating file "g:\test.R.wav"...
This audio track has a constant bit depth of 16 bits.
...

D:\MPEG\EAC3TO>eac3to.exe f:\moody.wav
WAV, 2.0 channels, 0:43:34, 16 bits, 1411kbps, 44.1khz

D:\MPEG\EAC3TO>


C.U. NanoBot

[nautilus7]

Yes, 're right. Send a sample to madshi to add support for this type of dtswav if you want to.

[NanoBot]

I will ask him if he is interested, since there might be only a few of those problematic DTS CDs.

[madshi]

My best guess would be that the DTS track is faulty in itself. Normally if you extract the DTS track of a DTSWAV file you don't do any changes to the DTS bitstream. So if all those 3 programs you tried output a wrong framesize than this wrong framesize is most likely already wrong in the original source. And that's probably also the reason why eac3to doesn't even detect the track as being DTSWAV at all - because it's simply not a valid DTS(WAV) track.

[NanoBot]

ATM I could neither confirm nor deny if the problematic source DTSWAV files are faulty. Because of the 14 bit words and the little endianess used in DTSWAV, it is a little bit difficult for me to identify the relevant header bits in the DTSWAV files. Nevertheless I will try to check the source DTSWAV for the frame size indicated there. Do do that, I will try to define winhex templates for the headers of standard DTS and DTSWAV. This should make it much easier to analyze the header.

[Adub]

Okay, I am trying to split some mkv files of mine, using the "Enable Splitting...after timecodes:" option.

However, I continue to receive an error if I use the format "00:43:32.220000000,01:26:58.320000000". But when I remove the decimal digits, everything works fine. Is this a bug in the GUI? Because I am using the correct time codes format.


Oh, and also, if I do NOT link the files, and use the format "00:43:32,00:43:45,00:43:42,00:43:24", which is supposed to result in chunks (episodes) that are 43min 32 seconds long and so on an so forth, instead results in 5 files which are 43:40, 12 seconds, 1 second, 22 seconds, and then the rest of an hour and a half or so. NOTE: these are not the exact times that I used, but they are essentially the same, and it shows that the resulting behavior is faulty and does not follow as the guide to MKVMerge GUI explained the process.

Since I did NOT linked the files, I expected the timecode to start from 0 after every split. I don't know if this happened, but the output was faulty anyways.

[zeropc]

anyone willing to make a os x version of the latest release???

thanks :)

[lchiu7]

This is a strange one. Using the 2.2.0 GUI I

This is the situation. Our local broadcaster transmits HD as H.264 with AC-3 audio over DVB-T. Files end up quite large 4G/hr so I want to compress them and remove the ads.

I can remove ads okay with tspacket editor but the resulting file has AC-3 packet errors which are not apparent when played but play havoc with programs like tsremuxer etc. It seems that the packet errors occur at cut points.

So I thought I would do the following.

1. Break up the file into each segment between ad breaks.
2. Compress each segment into h.264 using x264
3. demux the AC-3 audio from each segment using dgavcindex
4. Merge the compressed video with the original audio into a MKV container using mkvmerge.

This seems to work fine. dgavcindex outputs the AC-3 file with a name containing text like DELAY -234ms and mkvmerge reads that delay value and inserts it into the parameter for delays.

However I end up with 4-5 separate mkv files for the one show. What I want to do of course is have just one file.

Thought I could do that with mkvmerge and just merge the 5 MKV files together. While that works, the resultant file loses audio/video sync - in fact the sync is fine for the part of the video that comes from the first file, it loses sync after that. That is strange since each individual file is in sync - it's just the merged file that isn't.

Tried something else - that is, rather than create 5 files, create one file by using the append option for each MP4 file but taking note for each different audio file, marking the appropriate delay for it.

That also doesn't work. Audio/video goes out of sync after the first segment.

Finally tried just a DOS copy /b option to concatenate the 5 files together but the resultant file just plays up to the end of the first segment.

Any thoughts or ideas appreciated on what I could do now.

Thanks

Larry

[Adub]

One thing you could do is to do all of your editing in Avisynth using the trim() command. That way you will result in one video and audio file. If you want more information on how to do this, use search on this forum, or visit the Avisynth wiki. Right now it just sounds like you are doing it the hard way.