MKVToolNix v24.0.0 released

[SledgeHammer_999]

I guess that mmg will chose "application/x-font-ttf" as well when I upgrade the libmagic for the Windows port.

This will brake MPC at least.(It is a splitter's issue, right?)
In Linux, gstreamer picks up correctly emdedded fonts with "application/x-font-ttf" as MIME type. (haven't tested mplayer/vlc/xine)

[Mosu]

It's up to the splitter, yes. As MPC is an actively maintained OpenSource project I'm sure that asking the devs to update will fix it.

[TheFluff]

it doesnt seem possible to add lpcm tracks created with eac3to. whys that?
eac3to 00000.m2ts 2: mka_with_pcm.mka
should work. It is (as far as I know) impossible to automatically detect a random PCM file's bitdepth, channel layout and sampling rate in a reliable way, so it's not surprising at all that mkvmerge doesn't support it.

[Anakunda]

Greetings, does mkvmerge reconstruct once splitteed movie into exactly the same streams as were before splitting ?
It deals all kinds of streams, audio, video, text, chapters..

[Incast]

Hopefully a simple query here: If I have three files demuxed from eac3to, for example:
1. 1.mkv -1.ac3 - uncorrectable audio delay: 8ms
2. 2.mkv -2.ac3 - uncorrectable audio delay: 15ms
3. 3.mkv - 3.ac3 - uncorrectable audio delay: 9ms

And I use mkvmerge append function to combine them into a single mkv file, will MKVMerge correctly handle each audio delay I insert for the individual files 1.ac3 (8ms), 2.ac3 (15ms) and 3.ac3 (9ms) and retain overall sync in my final single mkv?

[Thunderbolt8]

has this warning

Warning: 'video' track 1: The AVC video track is missing the 'CTTS' atom
for frame timecode offsets. However, AVC/h.264 allows frames to have more than
the traditional one (for P frames) or two (for B frames) references to other frames.
The timecodes for such frames will be out-of-order, and the 'CTTS' atom is needed
for getting the timecodes right. As it is missing the timecodes for this track might be wrong.
You should watch the resulting file and make sure that it looks like you expected it to.

any relevant meaning? (Im trying to encode a normal BD @23.976fps with GOP size = 1)

[Mosu]

GOP size = 1 means only key frames, doesn't it? Then the warning isn't relevant.

[Thunderbolt8]

ok what what if I set GOP size back to 33 (so I will also have B- and P-frames), what could I do then to avoid timecode problems so that my video and audio wont go out of sync?

[Mosu]

Well, normally you don't have to do anything -- the software encoding the video should write the CTTS atom in such a case automatically.

[Thunderbolt8]

so does this warning also appear if the atom has been written correctly? because the encoding software doesnt seem to have done it.

[Mosu]

It only appears if the atom is not found ( = if it hasn't been written). I don't know if B frame timecodes are always out of order. If they aren't then the CTTS atom is not needed, and the warning can be disregarded.

[pdanpdan]

I just found out: v4.8 (oficial and all test builds) can not identify (-i and identify for mmg) .avi files (any type of avi file). v4.7 works as it should. Win7x64.
The program just does not return anything, and keeps one CPU in 100%.
It I can provide any other info please tell me.
Thank you

[Abradoks]

I just found out: v4.8 (oficial and all test builds) can not identify (-i and identify for mmg) .avi files (any type of avi file). v4.7 works as it should. Win7x64.
Works for me on WinXP. Try that (http://www.mediafire.com/?fgfsp67vw70r1pg) build.

[pdanpdan]

this build works

[ynamojn]

I have problem extracting audio from one particular mkv. The extracted audio is shorter in duration and smaller in size compare to the audio stream in the original mkv. The audio is 5.1 dts cbr 1510 kbps. Duration in original mkv is 1 hour 36 minute. The extracted one is 1 hour 32 minute. I use mkvextract. What would possibly cause it?

[Mosu]

The audio inside the Matroska files has timecodes. The "duration" of the audio inside the Matroska files is therefore the maximum timecode.

Outside of a Matroska file DTS audio tracks do not have timecodes. Therefore it's possible that the track inside the Matroska files has some gaps in it -- jumps in the timecodes with no audio samples to fill them.

This is perfectly normal, e.g. if someone uses mkvmerge's --sync option with a stretch factor > 1 on an audio track (though I don't advice doing that; better results are usually achieved by stretching video and subtitle tracks in the other direction due to players using audio as the synchronization source).

[ynamojn]

The audio inside the Matroska files has timecodes. The "duration" of the audio inside the Matroska files is therefore the maximum timecode.

Outside of a Matroska file DTS audio tracks do not have timecodes. Therefore it's possible that the track inside the Matroska files has some gaps in it -- jumps in the timecodes with no audio samples to fill them.

This is perfectly normal, e.g. if someone uses mkvmerge's --sync option with a stretch factor > 1 on an audio track (though I don't advice doing that; better results are usually achieved by stretching video and subtitle tracks in the other direction due to players using audio as the synchronization source).

Thank you for your reply and explanation. Currently I am able to solve my problem by:
1. demux the video (24 fps x264) and the audio (5.1 dts)
2. encode the 5.1 dts to 5.1 ac3 with stretching (25 fps to 24 fps)
3. remux the video (24 fps x264) and the audio (5.1 ac3)
4. and the av are perfectly in sync

I already suspected the problem has something to do with frame rate since the out-of-sync getting worst and worst, not constant. So yesterday I check the mkv element header using the mkvmerge. The timecode scaling for both the audio and video track is 1 so I think the stretching was not done in the mkv.

My guess is that the audio stream (5.1 dts) of the original mkv was taken from another source with 25 fps rate. Then the audio stream just remuxed to the mkv with 24 fps video. Is such scenario possible? Is there other possibility?

[Mosu]

The timecode strecth factor in the headers is only one way of stretching timecodes. mkvmerge's --sync option does NOT use it. Instead it directly scales the timecodes. If you have e.g. a video at 25fps (therefore 40ms per frame) and you'd specify a strecth factor of 1.5 then mkvmerge would produce timecodes at 0ms, 60ms, 120ms etc instead of 0ms, 40ms, 80ms etc.

Like I said before I'd advice against stretching audio. Just leave audio be. Modify the video FPS instead, the results are more predictable across devices, players and platforms.

[Kurtnoise]

Hi Mosu,

Does the last mkvmerge is able to create TrackOperation (http://www.matroska.org/technical/specs/index.html#TrackOperation) entries ? If yes, how to do that exactly ?

[Mosu]

No, not yet.

[ynamojn]

The timecode strecth factor in the headers is only one way of stretching timecodes. mkvmerge's --sync option does NOT use it. Instead it directly scales the timecodes. If you have e.g. a video at 25fps (therefore 40ms per frame) and you'd specify a strecth factor of 1.5 then mkvmerge would produce timecodes at 0ms, 60ms, 120ms etc instead of 0ms, 40ms, 80ms etc.

Like I said before I'd advice against stretching audio. Just leave audio be. Modify the video FPS instead, the results are more predictable across devices, players and platforms.

Thanks Mosu. So I can conclude that using the --sync option a 25 fps video will play longer. I am just curious, suppose I have such mkv produce using this --sync option, if I extract the video, will I get a longer playing time or the original one?

The mkv I got it from somewhere else. I just want to convert it to DVD. And the audio portion is making me a headache because it was created probably using the --sync option.

[Mosu]

As the sync option modifies both the timecodes and the default duration you could get a longer-playing video after extraction if the extraction is done into a container (MP4, AVI) and not into a raw bitstream.

However, mkvmerge does not modify certain fields inside the video bitstream. h264 videos can contain an FPS field inside their bitstream as far as I remember, and that one is not touched.

[bin_ch]

Hi,
Is there any easy way to disable header removal compression in mkvmerge without setting each and every track?
There is an option to do this in the GUI, but that option doesn't seem to apply to the CLI version.

Thanks.

[Mosu]

No, there isn't.

[Abradoks]

Hi,
Is there any easy way to disable header removal compression in mkvmerge without setting each and every track?
There is an option to do this in the GUI, but that option doesn't seem to apply to the CLI version.
You can try patched build from that post (http://forum.doom9.org/showthread.php?p=1503876#post1503876).

[bin_ch]

Thanks Mosu for the reply, and Abradoks for the patched build. Looks like a good solution for now.

[robpdotcom]

I received this warning when muxing a video today:

"A block group was found at position 13766262488, but no block element was found inside it. This might make mkvmerge crash."

As far as I can tell, everything went fine. What does this mean?

[Mosu]

I received this warning when muxing a video today:

"A block group was found at position 13766262488, but no block element was found inside it. This might make mkvmerge crash."

As far as I can tell, everything went fine. What does this mean?

A block group usually contains several Matroska elements: reference information (used for frame type distinction: I/P/B frame?), timecode, duration and the actual frame's content. If no frame content is found then that is very curious -- maybe the file is damaged at that part or it was created by a muxer with a bug. As I've never encountered such a file myself I haven't been able to test whether or not mkvmerge works correctly in that case by simply skipping that block group -- hence the warning. If muxing has gone fine for you and the result has been OK then you can simply ignore the warning.

[Mosu]

I just found out: v4.8 (oficial and all test builds) can not identify (-i and identify for mmg) .avi files (any type of avi file). v4.7 works as it should. Win7x64.
The program just does not return anything, and keeps one CPU in 100%.
It I can provide any other info please tell me.
Thank you

One other user reported the same issue, but I haven't been able to reproduce it. In order to get to the bottom of this I've compiled each and every revision between 4.7.0 and 4.8.0. They're all available from http://www.bunkus.org/videotools/mkvtoolnix/win32/debug/ ordered by commit date. If would be great if you could pinpoint which release was the first that started locking up. Thanks.

[pdanpdan]

It would be great if you could pinpoint which release was the first that started locking up.
None of them are working. But http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.7.0.7z is working.
Also, the statically built version from here http://forum.doom9.org/showthread.php?p=1510733#post1510733 worked.
So maybe it's not something in the code but something in the compiling environment.

[Mosu]

Looks that way, indeed. I have upgraded some of the libraries in the meantime, but I don't remember exactly what I updated. Bummer. Thanks for testing, though.

[Mosu]

Hey,

I've released mkvtoolnix v4.9.0. It's mostly a bug fix release with few new features.

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

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

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 4.8.0:

2011-07-10 Moritz Bunkus <moritz@bunkus.org>
* Release v4.9.0.

2011-07-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: DV files are recognized as an unsupported container type. Fix for bug 630 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=630).
* mkvmerge: bug fix: Fixed handling block groups in Matroska files with a duration of 0.

2011-07-08 Moritz Bunkus <moritz@bunkus.org>
* mmg: Various compatibility fixes for use with wxWidgets 2.9.x.

2011-06-23 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Fixed building with Sun Studio's C compiler.

2011-06-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: ISO 639-2 terminology language codes are converted to the corresponding bibliography code upon file identification (e.g. 'deu' is converted to 'ger').

2011-06-02 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: bug fix: The timecode scale is retrieved first before applying it to the segment duration.
* all: Added an Italian translation by Roberto Boriotti and Matteo Angelino (see AUTHORS).

2011-05-28 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Fixed populating the 'compression' drop down box according to what mkvmerge was compiled with.

2011-05-26 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: When a DTS track is read from a source file that provides timecodes (e.g. Matroska files) then those timecodes will be preserved.

2011-05-25 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Fixed remuxing certain VC1 video tracks from Matroska files. Fix for bug 636 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=636).

Have fun.

[sneaker_ger]

Thx, but updater says that there is 5.0.0 already available?

[Snowknight26]

H.264 in MKV detection seems to be taking far longer with this new version.

Sample: http://stfcc.org/misc/mkvmerge490.mkv

[GuilhermeAraujo]

Thx, but updater says that there is 5.0.0 already available?

Indeed. An "update window" poped up on the 1st run saying there's a version 5.0.0.

[Chumbo]

H.264 in MKV detection seems to be taking far longer with this new version.

Sample: http://stfcc.org/misc/mkvmerge490.mkv
I've confirmed that this is true. I have a 7MB XviD clip that loads immediately in 4.8.0 and took just over 50 seconds to load in 4.9.0. Let me know if you want that clip. Here's the MediaInfo info:General
Unique ID : 210574927490640108572371383594975910910 (0x9E6B417EAC8112629966D9BDB4E25BFE)
Complete name : clip.mkv
Format : Matroska
Format version : Version 2
File size : 7.70 MiB
Duration : 55s 656ms
Overall bit rate : 1 160 Kbps
Encoded date : UTC 2011-06-15 02:51:24
Writing application : mkvmerge v4.6.0 ('Still Crazy After All These Years') built on Mar 13 2011 18:33:29
Writing library : libebml v1.2.0 + libmatroska v1.1.0

Video
ID : 1
Format : MPEG-4 Visual
Format profile : Advanced Simple@L5
Format settings, BVOP : Yes
Format settings, QPel : No
Format settings, GMC : No warppoints
Format settings, Matrix : Default (H.263)
Codec ID : XVID
Codec ID/Hint : XviD
Duration : 55s 639ms
Bit rate : 1 009 Kbps
Width : 624 pixels
Height : 352 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.192
Stream size : 6.69 MiB (87%)
Writing library : XviD 1.0.3 (UTC 2004-12-20)

Audio
ID : 2
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Mode : Joint stereo
Codec ID : A_MPEG/L3
Codec ID/Hint : MP3
Duration : 22mn 11s
Bit rate mode : Variable
Bit rate : 128 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 20.3 MiB
Writing library : LAME3.90.
Encoding settings : -m j -V 4 -q 2 -lowpass 17.6 --abr 128
Language : English

[Mosu]

Thx, but updater says that there is 5.0.0 already available?

No, that was an error in the release file on the update server.

[Mosu]

H.264 in MKV detection seems to be taking far longer with this new version.

Should be fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.9.0-build20110711-353-setup.exe

[Carpo]

Should be fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.9.0-build20110711-353-setup.exe

bad little moo cow!!!! :devil:

[Chumbo]

Should be fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.9.0-build20110711-353-setup.exe
Thanks Mosu.

[Mosu]

None of them are working. But http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.7.0.7z is working.
Also, the statically built version from here http://forum.doom9.org/showthread.php?p=1510733#post1510733 worked.
So maybe it's not something in the code but something in the compiling environment.

Alright, I finally figured it out. The following build should be OK again: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.9.0-build20110711-354-setup.exe

[LeMoi]

Should be fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.9.0-build20110711-353-setup.exe

Thanks, i was afraid it was not working any more !!

[pdanpdan]

:D It's working - thank you.

[Mosu]

Hey,

I've released mkvtoolnix v4.9.1. It fixes two servere bugs that were introduced with v4.9.0.

Here are the usual links:

...to the homepage: http://www.bunkus.org/videotools/mkvtoolnix/

...to the source code: http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-4.9.1.tar.bz2
...to the Windows installer: http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.9.1-setup.exe
...to the 7zip archive for Windows: http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.9.1.7z

Most of the binaries (http://www.bunkus.org/videotools/mkvtoolnix/downloads.html) that I provide myself are still being built and will be available later.

Here's the full ChangeLog since release 4.9.0:

2011-07-11 Moritz Bunkus <moritz@bunkus.org>
* Released v4.9.1.
* mkvmerge: bug fix: Fixed endless loop when reading AVI files on Windows if MKVToolNix was compiled with a gcc mingw cross compiler v4.4.x. Fix for bug 642 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=642).
* mkvmerge: bug fix: Fixed long file identification time caused by DV detection. Fix for bug 641 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=641).

Have fun.

[SamuriHL]

Windows installer not found?

[Mosu]

It was still being built. The upload should be done in a few minutes.

[SamuriHL]

Ok, thanks!

[Motenai Yoda]

The Italian translators have missed something.
http://img7.imagebanana.com/img/d798ro5y/thumb/miss1.png (http://www.imagebanana.com/view/d798ro5y/miss1.png) http://img7.imagebanana.com/img/mwjes0hc/thumb/miss2.png (http://www.imagebanana.com/view/mwjes0hc/miss2.png)

[b66pak]

@Mosu thanks a lot...it looks like your site is down...
_

[Mosu]

The Italian translators have missed something.

The Italian translation is still work in progress, yes.