MKVToolNix 1.6.0 has been released

[ggab]

hi, i have a .mpg file with a video track and an audio track, i want to replace the audio track with a ogg vorbis file, but i cant:

img:
http://img453.imageshack.us/img453/922/capture2135eb.gif

log:
mkvmerge v1.6.0 ('Ist das so') built on Oct 14 2005 15:22:21

'C:\Happii Rakki ~Onegai Mirumo OP3.mpg': Using the MPEG PS demultiplexer.

'C:\Mirumo de Pon\Happy Lucky ~Please, Mirumo OP3.ogg': Using the OGG/OGM demultiplexer.

'C:\Happii Rakki ~Onegai Mirumo OP3.mpg' track 0: Using the MPEG-1/2 video output module.

'C:\Mirumo de Pon\Happy Lucky ~Please, Mirumo OP3.ogg' track 0: Using the Vorbis output module.



Error: The track number 0 from the file 'C:\Mirumo de Pon\Happy Lucky ~Please, Mirumo OP3.ogg' cannot be appended to the track number 0 from the file 'C:\Happii Rakki ~Onegai Mirumo OP3.mpg' because the formats do not match.


How can i append it? thanks!!!

[stephanV]

You dont want to append it, appending means putting the streams after one another, creating one continuous stream. Just add the two files normally, deselect the MP2 audio track and mux them together.

[echo]

Hi Mosu, I have a bug report for you. :) I'm using v1.6.0.

When I try to append a matroska file to another matroska file (both are XviD, AC3, srt) with mmg the resulting command line is this:

"mkvmerge" -o "new.mkv" --default-track 1 --display-dimensions 1:608x256 --language 2:eng --default-track 2 --language 3:gre --default-track 3 -a 2 -d 1 -s 3 "part1.mkv" -a 2 -d 1 -s 3 "+part2.mkv" --track-order 0:1,0:2,0:3 --append-to 1:1:0:0,1:2:0:0,1:3:0:0

All I get is an error code 2 and this message:
"Error: The file no. 0 ('part1.mkv') does not contain a track with the ID 0, or that track is not to be copied. Therefore no track can be appended to it. The argument for '--append-to' was invalid."

Playing around a bit I discovered that the proper command line would be:

"mkvmerge" -o "new.mkv" --default-track 1 --display-dimensions 1:608x256 --language 2:eng --default-track 2 --language 3:gre --default-track 3 -a 2 -d 1 -s 3 "part1.mkv" -a 2 -d 1 -s 3 "+part2.mkv" --track-order 0:1,0:2,0:3 --append-to 1:1:0:1,1:2:0:2,1:3:0:2

This also happens with avis, not just matroska files. I just managed to concatenate matroska files with the above command line. I couldn't find a way to concatenate the following files:
part1.avi
part1.srt
part2.avi
part2.srt

When I tried to do it I got a window telling me that "Appending a track from a file to another track from the same file is not allowed. This is the case for tracks number 4 and 5.". Now looking at the track order this was:
XviD
AC3
SRT
++>XviD
++>AC3
++>SRT


which was obviously wrong. When I changed the order to:
XviD
++>XviD
AC3
++>AC3
SRT
++>SRT

I got an error code 0 again with the same message that I got for the matroska files... And I could not find the proper track order for --append-to.

Also I created an mkv just over 2GB and it was not seekable in mplayer pre7. But I guess this is mplayer's fault since I can seek just fine with VLC or Zoom Player.

Cheers,

George

EDIT: Oh, I just saw that you already had a report for this in the previous page. Sorry... :(

[Mosu]

@Mosu:

So the little trouble I have is that I very often use VFR but I know *precisely* which frames to use as splitting points. Is there any possibility to have that functionality in mkvmerge? I.E. allow a list not of timecodes, but frame numbers?

Yeah, I could add that.

Also please clarify which method mkvmerge uses for splitting (to get full GOP). Whenever it expands the interval or goes forward/backwards from each timecode ?

mkvmerge splits right before the next key frame after the given condition has been met.

[Mosu]

yeah, i know. I only meant that there're still problems with append, though they are not releated to that mmg bug.

The two AVC files you want to append don't have matching codec private datas. So mkvmerge should simply refuse to append such tracks. That it doesn't refuse to is the actual bug. So in your case appending those files will simply not work. Sorry.

[Mosu]

hi, i have a .mpg file with a video track and an audio track, i want to replace the audio track with a ogg vorbis file, but i cant:

...


Stephan has given you the correct answer already.

[Mosu]

Hi Mosu, I have a bug report for you. :) I'm using v1.6.0.

When I try to append a matroska file to another matroska file (both are XviD, AC3, srt) with mmg the resulting command line is this:

...


EDIT: Oh, I just saw that you already had a report for this in the previous page. Sorry... :(

Correct. Does that build fix the problem for you?

[kurt]

Also I created an mkv just over 2GB and it was not seekable in mplayer pre7. But I guess this is mplayer's fault since I can seek just fine with VLC or Zoom Player.

same problem here - what's wrong with mplayer (using celtic_druid's latest)?

[foxyshadis]

same problem here - what's wrong with mplayer (using celtic_druid's latest)?
A seek/index to a signed 32-bit integer, just like every other 2G problem. Somewhere in the code it needs to be made unsigned or 64-bit.

[echo]

Correct. Does that build fix the problem for you?
Yes, thank you, it seems that I can append files with that build.

But the track rearrangement bug is still there. If I try to append part1.avi and part2.avi it works. But when I try to include part1.srt and part2.srt the resulting track order is:

XviD
AC3
SRT
++>XviD
++>AC3
++>SRT

instead of

XviD
++>XviD
AC3
++>AC3
SRT
++>SRT

as I said in my previous post.

[Egh]

The two AVC files you want to append don't have matching codec private datas. So mkvmerge should simply refuse to append such tracks. That it doesn't refuse to is the actual bug. So in your case appending those files will simply not work. Sorry.

Nah :) That's too late answer for that post. PRE version fixed that behaviour, thanks! ^^ In fact 1.6.0 1101-02 is the FIRST version since somewhat 1.5.6 sep 18 build which correctly appends two avc streams.

Note "TWO" in that phrase.
Cause though i haven't tested much, it seems it has difficulties for THREE parts join. Aka 1.MKV 2.MP4 3.MKV merge. All contain same avc stream.

And, amazingly, it was enough to convert mp4 in the mkv first, and then mkv+mkv+mkv worked! :)

But again, that's 1101-2 build, I haven't tested any after that, so might be that the bug is already fixed in more recent builds.

[Mosu]

Yes, thank you, it seems that I can append files with that build.

But the track rearrangement bug is still there. If I try to append part1.avi and part2.avi it works. But when I try to include part1.srt and part2.srt the resulting track order is:

XviD
AC3
SRT
++>XviD
++>AC3
++>SRT

instead of

XviD
++>XviD
AC3
++>AC3
SRT
++>SRT

as I said in my previous post.

Actually, this is not a bug but intended behaviour. Here's how mmg works:

If you have selected a file in the file selection box then mmg assumes that you want to append the new file to the selected one.
If you don't have a file selected then mmg assumes that you want to append the tracks to the last file in the file selection box.

In your case this means that mmg thinks that you want to append the tracks to the SRT file (because you've added the AVI first, then the SRT, then hit "append" for the AVI).

So you have two choices. You can either select the file you want to append to first before hitting the "append" button, or you can "add" the first AVI, "append" the second AVI, "add" the first SRT and then "append" the second SRT.

[echo]

Actually, this is not a bug but intended behaviour. Here's how mmg works:

If you have selected a file in the file selection box then mmg assumes that you want to append the new file to the selected one.
If you don't have a file selected then mmg assumes that you want to append the tracks to the last file in the file selection box.

In your case this means that mmg thinks that you want to append the tracks to the SRT file (because you've added the AVI first, then the SRT, then hit "append" for the AVI).

So you have two choices. You can either select the file you want to append to first before hitting the "append" button, or you can "add" the first AVI, "append" the second AVI, "add" the first SRT and then "append" the second SRT.

Ah, OK I understand now. But what I actually did was that I first dragged part1.avi and part1.srt in mmg and then appended part2.avi and part2.srt together (I hit the append button once and selected both). And I thought that it would work that way. Anyway thanks for everything! :)

[issa]

Latest cvs build of MKVToolNix, it's fix the mkvmerge crash when you de-select some track when importing.
This is a unicode build.
http://rapidshare.de/files/7552352/mkvtoolnix-1.6.0-20051113.7z.html

[pixolex]

Hy!

Is it possible to make a chapter.xml file when merging different avi/mkv files, where in the chapters goes the name of the input files?
And in the end we have just a global.mkv file with chapters!
And all this done AutoBlackMagicaly :P with just a tick in a checkbox? :P

Or a botton in the chapter editor to import the names & time stamps from the avi/mkv/.../movie files in the input box!


It's very annoying when i'm merging episodes in one big file, i have to make the chapters by my hand...

[Mosu]

Hy!

Is it possible to make a chapter.xml file when merging different avi/mkv files, where in the chapters goes the name of the input files?

Although I can understand why you would want that I will probably not do it. I will certainly not implement your second proposal, because for that I would have to write code to get the length of each input files, and that's simply waaaaaaay too much work for my very limited free time at the moment. Sorry.

[pixolex]

Although I can understand why you would want that I will probably not do it. I will certainly not implement your second proposal, because for that I would have to write code to get the length of each input files, and that's simply waaaaaaay too much work for my very limited free time at the moment. Sorry.

OK!
Thanks any way :(

Edit: There's any tool in linux to do that? I just know avimuxgui in windows.

[LeMoi]

With latest beta (2005/11/12), when i add more than one attachment, i always have a warning :
Warning: More than one name was given for a single attachment. 'Cover DVD.jpg' will be discarded and 'cover.jpg' used instead.
Warning: More than one name was given for a single attachment. 'cover.jpg' will be discarded and 'infos.txt' used instead.
This happens when i put 3 attchments : Cover DVD.jpg, cover.jpg and infos.txt. Even with 2 atttachments, i have the same warning. Files are muxed OK and attchments are OK.

[issa]

Here is the latest cvs unicode build of mkvtoolnix,
http://rapidshare.de/files/7881435/mkvtoolnix-1.6.0-20051120-unicode.7z.html

ChangLog:
2005-11-19 Moritz Bunkus <moritz@bunkus.org>

* mmg: bug fix: Fixed a problem with the selection of language
codes for chapters in the chapter editor.

2005-11-18 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: bug fix: If at least or more attachments were present
and the user used --attachment-name for each of them (as mmg does)
then mkvmerge was wrongly outputting a warning about multiple uses
of --attachment-name for a single attachment.

* mkvmerge: new feature: Added limited support for edit lists in
MP4/QuickTime files. Fixes Anthill bug #151.

* mkvmerge: bug fix: MP4/QuickTime files which contain another
atom before the 'avcC' atom in the video track headers weren't
correctly remuxed.

2005-11-16 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: bug fix: mkvmerge will now refuse to append AVC/h.264
video tracks whose codec initialization data blocks do not
match. Invalidates Anthill bug #163.

[kurt]

@Mosu: when will matroska v2 ("SimpleBlock") be added to mmg?

[jjseth]

@Mosu: when will matroska v2 ("SimpleBlock") be added to mmg?

From changelog in the mkvtoolnix-unicode-1.6.0-build20051112-1 pre-release

2005-10-21 Moritz Bunkus <moritz@bunkus.org>

* mkvinfo: new feature: The sub elements of the EBML head are
now shown.

* mkvinfo: new feature: Added support for the new SimpleBlock.

* mkvextract: new feature: Added support for the new SimpleBlock.

* mkvmerge, mmg: new feature: Added support for the new
SimpleBlock instead of BlockGroups (only available via "--engage
use_simpleblock" for now). Patch by Steve Lhomme (see AUTHORS)
with fixes by myself.

[kurt]

thx! must have overseen it :)
when will this feature be added to the GUI?

[Mosu]

thx! must have overseen it :)
when will this feature be added to the GUI?

"Muxing" menu -> "Add command line options" -> select "--engage use_simpleblock" & hit "Add"

[omion]

Mosu,

I just got to playing around with the SimpleBlock feature (20051120), and the 'discardable' flag is acting funny. My movie is x264 AVC with B-pyramid on. The beginning of the stats file looks like this:
in:0 out:0 type:I
in:5 out:1 type:P
in:3 out:2 type:B
in:1 out:3 type:b
in:2 out:4 type:b
in:4 out:5 type:b
in:10 out:6 type:P
in:8 out:7 type:B
in:6 out:8 type:b
in:7 out:9 type:b
in:9 out:10 type:b

The frames marked "b" are not needed for the decoding of any other frame, but the ones marked "B" are required for the following B-frames.

It looks like MMG decided the following for those frames:
SimpleBlock (key, timecode 0.000s [Frame 0, I])
SimpleBlock ( timecode 0.209s [Frame 5, P])
SimpleBlock (discardable, timecode 0.125s [Frame 3, B])
SimpleBlock (discardable, timecode 0.042s [Frame 1, b])
SimpleBlock ( timecode 0.083s [Frame 2, b])
SimpleBlock ( timecode 0.167s [Frame 4, b])
SimpleBlock ( timecode 0.417s [Frame 10, P])
SimpleBlock (discardable, timecode 0.334s [Frame 8, B])
SimpleBlock (discardable, timecode 0.250s [Frame 6, b])
SimpleBlock ( timecode 0.292s [Frame 7, b])
SimpleBlock ( timecode 0.375s [Frame 9, b])


It seems that MKVtoolNIX thinks the two B-frames after a P-frame are discardable, when the first one is actually not!
I'm pretty sure that the AVC standard has a "discardable" flag in each frame, but I'm not sure where...

Anyway, I know that the SimpleBlock is exceedingly new, but I'd just thought I'd give a quick bug report.

Thanks!

PS. Is the SimpleBlock the only addition of Matroska 2?

[LeMoi]

Here is the latest cvs unicode build of mkvtoolnix,
http://rapidshare.de/files/7881435/mkvtoolnix-1.6.0-20051120-unicode.7z.html
Doens't work by me, at all (does'nt even launch) :o

[robU*4]

PS. Is the SimpleBlock the only addition of Matroska 2?

So far, yes.

[kurt]

Doens't work by me, at all (does'nt even launch) :o
you have to click "Free" at the bottom of the site - then wait ~20sec and the downloadlink will appear (again at the bottom of the site) :)

[don't use a download accelerator like getright]

[LeMoi]

I know how to download, i downladed it, extracted in previous mkvtoolnix folder, overwrote older files, and launched mmg.exe, crashes immediately...

[Mosu]

The builds on rapidshare aren't done by myself, so I won't support them. You can also try my latest build http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.6.0-build20051119-1.rar which, as far as I know, works normally.

[Egh]

@Mosu:

just in case you wanted to have some more functionality in your mkvmerge, and which is practically very convinient to have, btw :P

So in short it's an attack on VFR AVI hack stupidity :) I'd like to have an option when muxing from avi source to have NULL frames STRIPPED AWAY. At the moment, at least with default options, mkvmerge muxes 119.88 avi into similar mkv.

Haali MKV muxer however, does strip null frames from such avis. Though at the moment (i have september version of his muxer) it does it wrongly (some frames get b0rked and stuff). The *ONLY* working tool now I know is little but precious japanese tool written specifically for that. It convertes avi to avi with null frames deleted. Naturally, those avi are being muxed into mkv afterwards for release.

It would be just great if mkvmerge itself could do that task upon muxing.

[Mosu]

So in short it's an attack on VFR AVI hack stupidity :) I'd like to have an option when muxing from avi source to have NULL frames STRIPPED AWAY. At the moment, at least with default options, mkvmerge muxes 119.88 avi into similar mkv.

Hmm, mkvmerge used to do this. But I've rewritten the AVI reading code recently, maybe I didn't add that functionality back in. Could you please upload a short sample file with 0 length frames? I don't think I have any.

Thanks.

[Egh]

Hmm, mkvmerge used to do this. But I've rewritten the AVI reading code recently, maybe I didn't add that functionality back in. Could you please upload a short sample file with 0 length frames? I don't think I have any.

Thanks.

I'm uploading to the ftp now. A cut from real source (those are VERY common for japanese raws). Filename short_sample_trauma_maiden@119.88fps.avi ^^^

I am not particulary strong in video terminology but are those zero-length frames same as null or "dropped" [as they are marked in vdub] frames? Since in fact those frames do have their own timestamps in the file, that's the point cause they are used as padding for VFR-in-avi hack.

[issa]

I know how to download, i downladed it, extracted in previous mkvtoolnix folder, overwrote older files, and launched mmg.exe, crashes immediately...

Sorry, I forgot to mention my build was compiled with SSE2 support turn on, maybe your CPU doen't support SSE2. Next time I will indicate it on my build.

[foxyshadis]

The *ONLY* working tool now I know is little but precious japanese tool written specifically for that.
yamb/mp4box will do this also, actually. (Though it won't read h264 avis.) The resulting mp4 can be fed to mmg.

[Egh]

yamb/mp4box will do this also, actually. (Though it won't read h264 avis.) The resulting mp4 can be fed to mmg.

Whenever I use yamb/mp4box i always get headache. usually it doesnt' work the way it needed :)

Whilest that japanese tool does it job flawlessly. And again, Haali Muxer is doing it, just that it has bugs so some frames get b0rked and stuff.

[Egh]

Heh,
sorry i seemed was wrong. Though you put those generated mkvs as 119.881fps (using default duration field) they are hardly 119.881 :P They seem to have null frames removed.

But, there's interesting thing.
If i use avidelnull, i can decrease the size of avi by 10-15 mb per each 250mb of source. But if I simply mux it into mkv (without deleting null frames first) then the size remains almost same. And i can mux avidelnull's generated avi into mkv, and size is naturally smaller than simply muxing into mkv.

So is there a way to correct this? i.e. put more sensible value into default duration matroska field and reduce size as allowed?

And, I though muxer by Haali is buggy. But seems not so hasty :) It could be bugged though, but I uploaded an mkv sample to ftp (smallsample.mkv) generated by Haali muxer. It is played (using Haali splitter :P) ok. But if i use it into mkvmerge for remuxing, it drops all after 26 seconds. (the sample is hardly over 30 seconds, but it's only to reduce filesize. even if i make complete episode, 24 min long, mkvmerge will still leave only first small fragment). The end code given by mkvmerge is "0" aka "everything went fine" :P

[Mosu]

Heh,
sorry i seemed was wrong. Though you put those generated mkvs as 119.881fps (using default duration field) they are hardly 119.881 :P They seem to have null frames removed.

Yeah I was pretty sure mkvmerge still did this correctly ;)

But, there's interesting thing.
If i use avidelnull, i can decrease the size of avi by 10-15 mb per each 250mb of source.

As each video frame in an AVI requires an entry in the index this can be easily explained. If you remove all those 0 length frames (aka "dropped" frames) then those don't need index entries anymore.

But if I simply mux it into mkv (without deleting null frames first) then the size remains almost same. And i can mux avidelnull's generated avi into mkv, and size is naturally smaller than simply muxing into mkv.

The size of the two mkvs should be roughly the same.

So is there a way to correct this? i.e. put more sensible value into default duration matroska field and reduce size as allowed?

Only by using external timecode files. I could probably make mkvmerge calculate the "best" new default duration by looking at each frame's length before muxing (this works for AVI without scanning the complete file because, as I've said earlier, AVI keeps track of all frames in an index). But I don't consider this high priority.

And, I though muxer by Haali is buggy. But seems not so hasty :) It could be bugged though, but I uploaded an mkv sample to ftp (smallsample.mkv) generated by Haali muxer. It is played (using Haali splitter :P) ok. But if i use it into mkvmerge for remuxing, it drops all after 26 seconds. (the sample is hardly over 30 seconds, but it's only to reduce filesize. even if i make complete episode, 24 min long, mkvmerge will still leave only first small fragment). The end code given by mkvmerge is "0" aka "everything went fine" :P

Ok, I'll take a look at this one.

[stephanV]

I believe Haali's muxer puts extra segmentinfo (thats what its called IIRC) at (random) points in the file. MKVmerge finishes the first time it encounters such an extra element.

[Mosu]

I believe Haali's muxer puts extra segmentinfo (thats what its called IIRC) at (random) points in the file. MKVmerge finishes the first time it encounters such an extra element.

Correct. Fixed in http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.6.0-build20051124-1.rar

[Egh]

As each video frame in an AVI requires an entry in the index this can be easily explained. If you remove all those 0 length frames (aka "dropped" frames) then those don't need index entries anymore.



The size of the two mkvs should be roughly the same.


That's exactly why I thought it doesn't remove those null frames in the first place. Size is not same :)

Real example:

Trauma Maiden 02.avi 457 132 032
Trauma Maiden 02.mkv 452 197 565

That's muxed with mkvmerge pre version from nov1 (haven't used the last yet :)

Then, using l33t tool avidellnul.exe (worshiping japanese puroguramer :))

trauma.02.delnull.avi 423 068 160
trauma.02.delnull.mkv 422 579 420

So there's 30MB difference (24:29 video) in those sizes. Why is that?

Video file is 1280*720 xvid+160kbpsMP3.


Only by using external timecode files. I could probably make mkvmerge calculate the "best" new default duration by looking at each frame's length before muxing (this works for AVI without scanning the complete file because, as I've said earlier, AVI keeps track of all frames in an index). But I don't consider this high priority.


That will be OK.

[Wilbert]

avidellnul.exe
Do you have a download link?

[Egh]

Do you have a download link?

yeah i know that's quite rare thing. Dont' even remember where i got that soft, and originally i most likely found about it in some older parts of doom9 forum.

the package is two files btw: avidelnull.exe and avi2timecode.exe, first exports avi file, second -- timecodes file, in both cases all null frames are deleted.

If needed to do comparison with mkvmerge in terms of null frames removal, i can upload to rapidshare, of course.


The decrease of filesize (about 10-15mb per 250mb of the source) should be on any 119.88fps raw, i guess.

[Liisachan]

here.
http://www.geocities.jp/aji_0/
afs_*.lzh
Use 7-zip if you don't know how to unzip .lzh
those tools are in ./converter with src

[Chez_Wimpy]

Sorry I haven't read the complete thread to this point, but I have noticed that since version 1.5.6 when you edit fields of files contained in "Tracks:" (language, track name, ect) switching from video tracks causes data input into the aspect ratio field to "self-erase" from the "Command Line:". If this has been brought up before, I apologize! As always, thanks for the awesome tool! ;)

[darkavatar1470]

Since inserting null frames in the process of making 120fps AVIs blow up the file size about 10M per 30min ... (some say due to the large overhead of AVI), I think the reverse should happen when you remove them when muxing to MKV. which is (I think) what Egh is suggesting .

should find more info on some old 120fps thread ....

[Egh]

Since inserting null frames in the process of making 120fps AVIs blow up the file size about 10M per 30min ... (some say due to the large overhead of AVI), I think the reverse should happen when you remove them when muxing to MKV. which is (I think) what Egh is suggesting .

should find more info on some old 120fps thread ....

Yes, and I don't see that happening on mkvmerge but on avidelnul the difference is quite clear.

Btw 10mb not for 30min, more like for 200mb. Original file is 500mb 720p 24min (träumend episode was used for test).

So in this case avidelnull removes 30mb, and w/o any visible artefacts or whatever. If it does it right (not removing needed frames as well :), so mkvmerge in theory can do that as well upon muxing.

[Mosu]

You "should" see the following behaviour:

with_null_frames.avi -> mkv: size reduction because mkvmerge drops null frames
with_null_frames.avi -> with_null_frames_removed.avi -> mkv: nearly the same size reduction because avidenull removes null frames
with_null_frames.mkv -> mkv: no size reduction because mkvmerge doesn't drop null frames when reading Matroska files

Maybe I'll look into this this weekend; but I have a couple of other issues I want to solve first.

[issa]

Latest CVS/SVN build,

http://rapidshare.de/files/8695841/mkvtoolnix-20051206-SSE2.7z.html

All the program compiled with SSE2 enable.

[Mosu]

http://forum.doom9.org/showthread.php?p=748011#post748011

This thread should be closed :)