mkvtoolnix: new version [Archive]

Mosu

15th June 2003, 15:51

New releases will be announced by replying to this thread. The current version is 0.7.2. Look for it on the last page of this thread.

Hi.

I'd like to use this thread to announce any new version I'll release. Bugreports are welcome here as well - although I still prefer to get them via Email :)

Today I'll start with release 0.4.4. Here's the ChangeLog since 0.4.3:

2003-06-15 Moritz Bunkus <moritz@bunkus.org>
* Several options now need an explicity track ID to specify which tracks of an input file the option should be applied to. These options include --atracks, --vtracks, --stracks, --sync, --default-track, --cues and --language.
* The Matroska reader now handles track selection correctly.
2003-06-13 Moritz Bunkus <moritz@bunkus.org>
* Added an option for identifying input files and their track types.

This release breaks the old syntax for the options mentioned above. This is especially important for any GUI which might use mkvmerge. On the other hand the new syntax is much more flexible than the old one - these options do not apply to all tracks in a file anymore but to only one specific track (you can still use -1 as the track ID and hit all tracks). For details read the man page/HTML documentation.

A note to the Windows users: Several people have reported crashes in the AVI reader on non-Windows-XP systems. Unfortunately I don't have access to any Win2k/Win98 machines at the moment, neither do I have a spare hard drive on which to install it. Needless to say that mkvmerge works fine for such files on both Windows XP AND Linux :( So please be patient with me until I've found a solution. Thanks.

Get the sources/binaries at http://www.bunkus.org/videotools/mkvtoolnix/

Joe999

16th June 2003, 07:19

Yay! I did a distupgrade today and noticed this being updated. Thanks for the hard work you've put into it!

ssjkakaroto

16th June 2003, 20:03

hi there mosu, i dont know if this is a error of the AVI reader but this is what i got with the win version:

Opened 'd:\test.mkv' for writing.
progress: 33801/33801 frames (100%)
Writing cue entries (the index)...
7 [main] mkvmerge 1372 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
1510 [main] mkvmerge 1372 open_stackdumpfile: Dumping stack trace to mkvmerge.exe.stackdump

and it created mkvmerge.exe.stackdump which is 2k long, but strangely the mkv file created works ok, here's the command i used:
mkvmerge --output d:\test.mkv --cues 0:iframes --noaudio d:\test.avi --cues 1:none --language 1:jpn --novideo d:\test.avi

Mosu

16th June 2003, 22:32

Originally posted by ssjkakaroto
hi there mosu, i dont know if this is a error of the AVI reader but this is what i got with the win version:

Opened 'd:\test.mkv' for writing.
progress: 33801/33801 frames (100%)
Writing cue entries (the index)...
7 [main] mkvmerge 1372 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
1510 [main] mkvmerge 1372 open_stackdumpfile: Dumping stack trace to mkvmerge.exe.stackdump

That's the error I was talking about in the first post. I've installed VMware and Win98 under VMware, but it's slow as hell on my Celeron 733, so don't expect a fix too soon :/

mkvmerge --output d:\test.mkv --cues 0:iframes --noaudio d:\test.avi --cues 1:none --language 1:jpn --novideo d:\test.avi

Please note that exactly these cues options are the defaults anyway. Stating from http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html : "The default is iframes for video tracks and none for all others." Just to shorten your command line a bit :)

ssjkakaroto

16th June 2003, 23:51

Please note that exactly these cues options are the defaults anyway. yeah, Pamel told me that on another post, but i was just testing it ;)
good thing is that it's working even with that error, so a fix isn't needed soon :)

Mosu

22nd June 2003, 21:13

Hi guys.

Time for another release. There have been a lot of changes since the last week. One thing I'd really like you to try is to run mkvmerge under Windows 98/Windows 2000. Several people reported problems and I'm eager to know if the switch from cygwin to mingw32 solved this problem.

The release is available at

http://www.bunkus.org/videotools/mkvtoolnix/

Windows binaries:

http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-0.5.0.zip
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-runtime.zip

Ok, here's the ChangeLog since the last version:

-----------------------
2003-06-22 Moritz Bunkus <moritz@bunkus.org>

* Released v0.5.0.

* Added 'ReferencePriority' element to the known elements for mkvinfo.

* Removed "(mkvinfo) " from mkvinfo's output in order to improve readability and save space.

* --sub-charset now also needs a track ID.

* Modified the verbosity levels for mkvinfo: The seek head subentries and cue subentries will only be shown at level 2 to make the output easier to read.

* The language and default track settings are now kept again if not overridden when reading from Matroska files.

2003-06-21 Moritz Bunkus <moritz@bunkus.org>

* Added mkvextract which can extract tracks from a Matroska file into other files.

2003-06-20 Moritz Bunkus <moritz@bunkus.org>

* Switched from cygwin to MinGW32 for the Windows binaries.

* Fixed a double free() on cleanup (after writing the cues) which resulted in a segfault sometimes.

* Added a SSA/ASS reader.

2003-06-19 Moritz Bunkus <moritz@bunkus.org>

* Support for reading text subtitles from Matroska files.

* Made the AAC reader automatically recognize if a MPEG4 AAC file contains the emphasis header (deprecated) or not (current standard).
--------------------

Comments, bugreports and stuff is welcome as always :)

Gaia

22nd June 2003, 22:00

Now it seems to work under Win98se:) I do more testing tomorrow.

ssjkakaroto

22nd June 2003, 23:01

Mosu, just tried on w2k using that exact same command-line and it didnt give me any errors this time :D
thx a lot for the upd8 :cool:

Mosu

22nd June 2003, 23:09

Thanks for the feedback, guys. So it was probably due to some cygwin specific stuff - and I'm just happy that it builds with mingw now.

Happy merging :)

ssjkakaroto

23rd June 2003, 03:19

Mosu, this time i tried to have a little more fun :p trying to mux:
-video file
-aac 2ch track
-ac3 2ch track
-srt sub
-ssa sub
and after the message:
Opened 'd:\test.mkv' for writing.
the program just hung with 100% cpu use :(
the file test.mkv was only 31kb and didnt got any bigger than that
heres my command line:
mkvmerge --output "d:\test.mkv" d:\video.avi --language 0:jpn "d:\Audio1.aac" --language 0:jpn --sync 0:-37 "d:\Audio2-DELAY -37ms.AC3" --language 0:eng d:\subs1.srt --language 0:eng d:\subs.ssatia

Mosu

23rd June 2003, 09:46

Originally posted by ssjkakaroto
Mosu, this time i tried to have a little more fun :p trying to mux:
-video file
-aac 2ch track
-ac3 2ch track
-srt sub
-ssa sub
and after the message:
Opened 'd:\test.mkv' for writing.
the program just hung with 100% cpu use :(
the file test.mkv was only 31kb and didnt got any bigger than that
heres my command line:
tia

Hmm. Ok, please try to leave out the aac track and see if that changes anything. As I've said I've rewritten the AAC parser, and it may very well be buggy.

If this does not help then try to find the file that mkvmerge chokes on by leaving out a single file each time. Please tell me the results.

If it is the AAC file could you then please send me the first 4megs of that file? Any file splitter will do, I don't care if the end of the file is borked. Please upload that file via FTP to mosu.no-ip.com, username upload, password only.

Thanks for your help :)

bond

23rd June 2003, 10:29

Jcsston's GUI can be obtained here (http://matroska.free.fr/downloads/mkvmerge/)

ssjkakaroto

23rd June 2003, 11:44

ok, when i get home tonight i'll send it to ya

Atamido

23rd June 2003, 17:16

Errrr..... The GUI hasn't been updated yet for the new command set. Don't use it yet for the new mkvtoolnix.

ChristianHJW

23rd June 2003, 17:28

Originally posted by bond
Jcsston's GUI can be obtained here (http://matroska.free.fr/downloads/mkvmerge/) .. dont work for latest mkvmerge, sorry ...

angelyote

23rd June 2003, 17:39

Worked like a charm under WinXP muxing 2 ogg tracks, 1 xvid and ssa subs resulting in 1.2g file split into 700m and 500m.

Dave
Looking forward to chapters in mkv :)

Mosu

23rd June 2003, 17:42

Originally posted by angelyote
Looking forward to chapters in mkv :)

Me too ;)

ssjkakaroto

23rd June 2003, 23:35

hey mosu, just tested one by one and the problem was in the ssa sub :p
all the others (including the aac track, do you still want me to send it to you?) would mux together without any problem. It seems that the ssa file that i created with subrip converting from the srt is incompatible with mkvmerge, i tried converting it to uft-8 and unicode formats but it didnt help. i couldn't even mux only the video and the ssa file, maybe there's something wrong with my command line
angelyote how did you mux it and what program did you use to create the ssa file?

tia

bill_baroud

24th June 2003, 01:09

i'm not sure you can mux ssa with mkvtoolunix ^^;;

you have to use Gabest Matroska Muxer and his Subtitle Source Filer :)

ssjkakaroto

24th June 2003, 02:11

now you can :)

* Added a SSA/ASS reader.

angelyote

24th June 2003, 02:32

I used srt2ssa that is available on the doom9 download page but there will be a problem. It won't convert with any of the heading information like [v4 styles] so you need to put those in yourself.

That's probably why your SSA isn't playing. vsfilter will play an ssa without proper section headers but you can't mux them.

Dave

Mosu

24th June 2003, 08:24

Originally posted by ssjkakaroto
hey mosu, just tested one by one and the problem was in the ssa sub :p
all the others (including the aac track, do you still want me to send it to you?)

No, of course not :) If it works than I don't need it :)

would mux together without any problem. It seems that the ssa file that i created with subrip converting from the srt is incompatible with mkvmerge, i tried converting it to uft-8 and unicode formats but it didnt help. i couldn't even mux only the video and the ssa file, maybe there's something wrong with my command line

It has to be in UTF-8. I don't support UTF-16 or any other multi byte UTF encoding at the moment.

Could you upload that SSA file, please? FTP server info is the same as in my last post. Thanks :)

My SSA reader is rather limited at the moment - e.g. it does not convert the {\fe...} markup correctly as I don't have a mapping from the numbers to iconv supported charsets...

ssjkakaroto

24th June 2003, 21:47

ok mosu, just uploaded it to you, it's named crashing_subs.ssa ;)

Mosu

4th August 2003, 21:22

As most of you have probably noticed: There's a new version available :) It's 0.6.0, the download link is http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-0.6.0.zip, and the most important changes are probably:

mkvmerge now supports RealVideo, RealAudio, chapters, tags, and SSA/ASS files stored in UTF-16 files. A number of small subtitle reading bugs were fixed.

mkvinfo can now output almost all tag and attachment elements along with some elements that were previously missing.

mkvextract can additionally copy chapters, tags, and attachments from Matroska files into separate files.

The (rather long) ChangeLog for this release looks like this:

2003-07-30 Moritz Bunkus <moritz@bunkus.org>
* base64tool: Added a tool for Base64 encoding/decoding needed for binary elements in the tags.

2003-07-29 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: Support for extracting chapter information.
* mkvmerge: Added support for simple chapter files (CHAPTER01=..., CHAPTER01NAME=Hello World etc).

2003-07-26 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Added support tags based on XML files.
* mkvextract: Rewrote the command line syntax. Added extracting attachments and tags as new options.
* mkvmerge: Fixed a bug in the SRT reader which would not always handle Unix/DOS style new line cases correctly.

2003-07-23 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Added support for the "SegmentTitle" (general title of the file written).

2003-07-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Added support for UTF-8 and UTF-16 encoded text files for the SRT and SSA/ASS readers.

2003-07-15 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: The SSA/ASS reader ignored the --sub-charset option and always used the current charset to recode the subtitles.

2003-07-14 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Added support for attaching files to the output file(s).
* mkvinfo: Support for the elements dealing with attachments (KaxAttachments, KaxAttached, KaxFileDescription, KaxFileName, KaxMimeType, KaxFileData).

2003-07-13 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Changed the RealVideo packaging method: Subpackets are assembled into complete packets so the demuxer does not have to do that anymore.
* mkvmerge: DisplayWidth and DisplayHeight, which form the display aspect ratio, are now always written to ease changing them later without having to completely remux the file.

2003-07-08 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Fixed some infinite-reading-from-a-file bug that occured on Windows when reading SSA/ASS files.
* mkvmerge: Fixed a bug which would mostly appear with subtitles that have very long ( > 60s) gaps between entries. Here the cluster would not been rendered properly leaving mkvmerge either comatose ( = endless loop) or just plain dead ( = crashing).

2003-07-07 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: Added support for the rest of the tags:KaxTagMultiComment, KaxTagMultiCommentName, KaxTagMultiCommentComments and KaxTagMultiCommentLanguage. Almost all tags have been successfully tested.

2003-07-06 Moritz Bunkus <moritz@bunkus.org>
* Added a RealMedia demuxer that can handle both RealVideo and RealAudio (all codecs).

2003-07-02 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: Added support for allmost all tags (totally untested): KaxTag KaxTagArchivalLocation KaxTagAudioEncryption KaxTagAudioGain KaxTagAudioGenre KaxTagAudioPeak KaxTagAudioSpecific KaxTagBibliography KaxTagBPM KaxTagCaptureDPI KaxTagCaptureLightness KaxTagCapturePaletteSetting KaxTagCaptureSharpness KaxTagChapterUID KaxTagCommercial KaxTagCropped KaxTagDate KaxTagDiscTrack KaxTagEncoder KaxTagEncodeSettings KaxTagEntity KaxTagEqualisation KaxTagFile KaxTagGeneral KaxTagGenres KaxTagIdentifier KaxTagImageSpecific KaxTagInitialKey KaxTagKeywords KaxTagLanguage KaxTagLegal KaxTagMood KaxTagMultiCommercial KaxTagMultiCommercialAddress KaxTagMultiCommercialEmail KaxTagMultiCommercialType KaxTagMultiCommercialURL KaxTagMultiDate KaxTagMultiDateDateBegin KaxTagMultiDateDateEnd KaxTagMultiDateType KaxTagMultiEntity KaxTagMultiEntityAddress KaxTagMultiEntityEmail KaxTagMultiEntityName KaxTagMultiEntityType KaxTagMultiEntityURL KaxTagMultiIdentifier KaxTagMultiIdentifierBinary KaxTagMultiIdentifierString KaxTagMultiIdentifierType KaxTagMultiLegal KaxTagMultiLegalAddress KaxTagMultiLegalType KaxTagMultiLegalURL KaxTagMultiPrice KaxTagMultiPriceAmount KaxTagMultiPriceCurrency KaxTagMultiPricePriceDate KaxTagMultiTitle KaxTagMultiTitleAddress KaxTagMultiTitleEdition KaxTagMultiTitleEmail KaxTagMultiTitleLanguage KaxTagMultiTitleName KaxTagMultiTitleSubTitle KaxTagMultiTitleType KaxTagMultiTitleURL KaxTagOfficialAudioFileURL KaxTagOfficialAudioSourceURL KaxTagOriginalDimensions KaxTagOriginalMediaType KaxTagPlayCounter KaxTagPopularimeter KaxTagProduct KaxTagRating KaxTagRecordLocation KaxTags KaxTagSetPart KaxTagSource KaxTagSourceForm KaxTagSubGenre KaxTagSubject KaxTagTargets KaxTagTitle KaxTagTrackUID KaxTagVideoGenre

2003-06-29 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Support for handling native video tracks (e.g. B frames) when reading Matroska files.
* mkvmerge: Implemented time slice durations , default block duration and block durations for slices where necessary.

2003-06-24 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: Support for KaxSegmentFilename, KaxTitle, KaxSlices, KaxTimeSlice, KaxSliceLaceNumber, KaxSliceFrameNumber, KaxSliceDelay and KaxSliceDuration.

Bug reports are always welcome :)

Sirber

4th August 2003, 22:50

Not Found

The requested URL /videotools/mkvtoolnix/win32/mkvtoolnix-0.6.0.zip, was not found on this server.
Apache/2.0.47 (Debian GNU/Linux) DAV/2 SVN/0.25.0 mod_ssl/2.0.47 OpenSSL/0.9.7b Server at www.bunkus.org Port 80

jcsston

4th August 2003, 22:57

Originally posted by Sirber
Not Found

The requested URL /videotools/mkvtoolnix/win32/mkvtoolnix-0.6.0.zip, was not found on this server.
Apache/2.0.47 (Debian GNU/Linux) DAV/2 SVN/0.25.0 mod_ssl/2.0.47 OpenSSL/0.9.7b Server at www.bunkus.org Port 80
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-0.6.0.zip, ;)
Funny typo Mosu
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-0.6.0.zip Works

karl_lillevold

5th August 2003, 00:10

Please take a look over in this thread (http://forum.doom9.org/showthread.php?s=&postid=353776#post353776) for a problem with mkvmerge's RM demuxer. It does not currently work correctly, and frames are lost during the conversion process.

Mosu

5th August 2003, 08:16

Originally posted by jcsston
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-0.6.0.zip, ;)
Funny typo Mosu
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-0.6.0.zip Works

Not really a typo, just the automatic URL recognition which got in my way ;)

Thanks for the correct link.

Mosu

5th August 2003, 20:20

Originally posted by karl_lillevold
Please take a look over in this thread (http://forum.doom9.org/showthread.php?s=&postid=353776#post353776) for a problem with mkvmerge's RM demuxer. It does not currently work correctly, and frames are lost during the conversion process.

Yeah, thanks. I'm working on it with some help from karl and Gabest. So at the moment mkvmerge should probably not be used for RealMedia files (the usual: all my sample files worked, and I'm not really into RealVideo...).

Next version will fix that (maybe at the end of the week).

Mosu

6th August 2003, 12:13

Another thing. I'd appreciate if you guys could report any bugs you find via my Anthill bug tracking system (http://www.bunkus.org/anthill/index.php) instead of posting here directly. It makes bug tracking a lot easier for me (hey, that's why it's called a bug tracking system ;)). I don't visit this forum all that often, so I might easily overlook bug reports if they're not in the few threads that I actually watch.

Thanks :)

Latexxx

6th August 2003, 16:32

"This application has failed to start because libiconv.dll was not founf..."

Edit: Never mind. http://gnuwin32.sourceforge.net/packages/libiconv.htm

robUx4

6th August 2003, 16:59

All you need is on Mosu's site :
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-runtime.zip

Latexxx

6th August 2003, 17:11

Originally posted by robUx4
All you need is on Mosu's site :
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-runtime.zip

I should have checked it first.

Liisachan

8th August 2003, 13:46

thankyou for updating...Chapter , attachment etc in 0.6.0 is simply impressive and it works fine for me, if the number of tracks is small

I tested 3 samples made by MatroskaMuxer
(1) Xvid + 1 Vorbis + 5 ssa = 7 tracks
(2) xvid + 1 vorbis + 16 ssa = 18 tracks
(3) xvid + 1 vorbis + 17 ssa = 19 tracks

Command line is like:
mkvmerge -o "out.mkv" --language 1:rus --language 2:rus --language 3:eng --language 4:jpn --language 5:fre --language 6:dut --language 7:rus "in.mkv" > debug.txt

mkvmerge 0.5.0 works fine for the all,
while 0.6.0 works only for (1)
0.6.0 will freeze for (2) and (3)

0.6.0 can handle Chapter / Attachment files for (1) but 0.6.0 cannot handle (2) and (3) even without chapters etc...

0.6.0 doesnt't like too many tracks, i wonder?

Mosu

8th August 2003, 14:06

Originally posted by Liisachan
0.6.0 doesnt't like too many tracks, i wonder?

Quite possible. I usually test with fewer files ;) I still have the mewmew.zip file you sent me the other day, and I'll try to reproduce and find that bug. If the subs you've experienced the crashes with are not from mewmew, could you please send them to moritz@bunkus.org ? That'd help debugging if, for some obscure reason, I cannot reproduce the bug with the files I have.

Thanks :)

Liisachan

8th August 2003, 14:24

Originally posted by Mosu
Quite possible. I usually test with fewer files ;) I still have the mewmew.zip file you sent me the other day, and I'll try to reproduce and find that bug. If the subs you've experienced the crashes with are not from mewmew, could you please send them to moritz@bunkus.org ? That'd help debugging if, for some obscure reason, I cannot reproduce the bug with the files I have.

Thanks :) Thank you very much for your swift answer.
(2) is Mew mew, available at http://matroska.free.fr/samples/index.html
(3) is another clip bigger than 100MB. I ll try to make it smaller so I can send it to you.

Funny thing is, the following worked for a MKV with many SSAs:
(1) mkvmerger50 -o tmp.mkv in.mkv
(2) mkvmerger60 -o out.mkv --chapters "chapter.txt" --attachment-description "foo" --attachment-mime-type "application/binary" --attach-file-once "foo.bar" tmp.mkv

ssjkakaroto

9th August 2003, 15:41

hi there, i think there's a bug with mkvmerge and 24khz audio, when i mux a single video file and a 24khz mp3 the resulting mkv file has the time doubled (24 min becomes 48 min) and the video plays twice as fast but the audio plays correctly, this doesnt happen if i use matroskamuxer from gabest
i'm using mkvtoolnix 0.6.0, mpc 6.4.5.9 and the latest matroskasplitter

tia

edit: this happens with version 0.5.0 too

Mosu

9th August 2003, 15:56

Originally posted by ssjkakaroto
hi there, i think there's a bug with mkvmerge and 24khz audio, when i mux a single video file and a 24khz mp3 the resulting mkv file has the time doubled (24 min becomes 48 min) and the video plays twice as fast but the audio plays correctly, this doesnt happen if i use matroskamuxer from gabest

Is this really MP3, not MPEG1 layer 2, 2.5 or something like that? Could you send me a short sample of the file, e.g. 1megs from the beginning? Just cut it with your favourite file splitting tool. Please upload that sample to my FTP server: address mosu.no-ip.com, username upload, password only.

Thanks.

ssjkakaroto

9th August 2003, 18:49

vdubmod detected it as mpeg 1 layer 3, but anyway i just uploaded it to you audio_24khz.mp3

cya

Liisachan

10th August 2003, 10:20

Thought I poseted that MKVmerge 0.6.0 doesnt like many subs.
I found that the same problem occurs even if you have only 2 tracks (audio + video no subs)

Suppose test.mkv was a 2-track MKV muxed by MatroskaMuxer and you wanted to do something like this.

mkvmerge -o out.mkv --language 3:eng test.mkv

MKVmerge 0.5.0 does work for this, while 0.6.0 doesnt (afaik)
Actually, it might be best if I used MKVmerge only-- for muxing, tagging, chapter setting etc etc, and then there wouldnt be this kind of problem of incompatibility...but I wanted to use SSAs in UTF-16 for some reasons

Anywayz some command lines that are valid in 0.5.0 are not valid in 0.6.0 and 0.6.0 will freeze...
Since this may not be MKVMerge's problem, I have poseted a related report in Alternative matroska splitter for directshow (http://forum.doom9.org/showthread.php?s=&threadid=54560&perpage=20&pagenumber=12) too

Mosu

10th August 2003, 10:30

Originally posted by Liisachan
I found that the same problem occurs even if you have only 2 tracks (audio + video no subs)

Suppose test.mkv was a 2-track MKV muxed by MatroskaMuxer and you wanted to do something like this.

mkvmerge -o out.mkv --language 3:eng test.mkv

This is a "bug" in Gabest's Matroska DShow filter which writes invalid reference times. The upcoming mkvmerge 0.6.1 will be able to handle that, but I'll also page Gabest to let know of this.

Actually, it might be best if I used MKVmerge only-- for muxing, tagging, chapter setting etc etc, and then there wouldnt be this kind of problem of incompatibility...but I wanted to use SSAs in UTF-16 for some reasons

You can. Since 0.6.0 mkvmerge also supports SSA/ASS/SRT subs that have the BOM (byte order marker) set and that are encoded in UTF-8, UTF-16 LE or UTF-16 BE. Just UTF-32 is not supported atm.

Liisachan

10th August 2003, 11:16

Originally posted by Mosu
Since 0.6.0 mkvmerge also supports SSA/ASS/SRT subs that have the BOM (byte order marker) set and that are encoded in UTF-8, UTF-16 LE or UTF-16 BE. thank you for the information. i didnt know that , as the doc says "Files saved with more than one byte per character (e.g. all UTF-16 formats) are not supported, UTF-8/ASCII only"-- i ll try utf-16 shortly. :)

Mosu

10th August 2003, 11:22

Originally posted by Liisachan
thank you for the information. i didnt know that , as the doc says "Files saved with more than one byte per character (e.g. all UTF-16 formats) are not supported, UTF-8/ASCII only"-- i ll try utf-16 shortly. :)

/me goes fixing the docs.

Just ignore those limiations that are listed for SSA/ASS. They don't apply anymore. I've just overlooked them :)

karl_lillevold

10th August 2003, 17:01

I ran across a DIV3 AVI sample with the wrong aspect ratio. It was encoded at 576x240 (2.4:1). I can use height adjustment in MPC to make it look OK. I am guessing the correct AR should be 1.85:1, so I tried to use mkvmerge to make a Matroska file with subs and corrected AR:

mkvmerge --aspect-ratio 1.85 -o sample.mkv sample.avi sample.srt

This resulted in the following adjustment:

+ Video track
+ Pixel width: 576
+ Pixel height: 240
+ Display height: 240
+ Display width: 444

Two problems:
1) would it not be better to increase display height, instead of shrinking display width? Note that the required adjustment in this case was opposite what is normally done for anamorphic style encodes, where width is stretched.

2) Even though the AR correction is sub-optimal, the numbers are correct, but it is ignored on playback.. I am using an older version of ffdshow, with latest MPC (6.4.5.9), external Matroska splitter (Gabest version 08.08) I guess this problem should go in another thread, but I am not sure which component should be doing the "work" in this case, work being setting up the overlay/renderer to adjust display size. Is the Matroska Splitter or ffdshow?

Mosu

10th August 2003, 17:12

Originally posted by karl_lillevold
Two problems:
1) would it not be better to increase display height, instead of shrinking display width? Note that the required adjustment in this case was opposite what is normally done for anamorphic style encodes, where width is stretched.

Yes, definitely. I'll change that behaviour.

2) Even though the AR correction is sub-optimal, the numbers are correct, but it is ignored on playback.. I am using an older version of ffdshow, with latest MPC (6.4.5.9), external Matroska splitter (Gabest version 08.08) I guess this problem should go in another thread, but I am not sure which component should be doing the "work" in this case, work being setting up the overlay/renderer to adjust display size. Is the Matroska Splitter or ffdshow?

I don't know, sorry. I'll point Gabest to this thread, though, maybe he can shed some light on this.

robUx4

10th August 2003, 17:24

Originally posted by karl_lillevold 1) would it not be better to increase display height, instead of shrinking display width? Note that the required adjustment in this case was opposite what is normally done for anamorphic style encodes, where width is stretched.[/B]

Not so sure. It depends if you want to be conservative (have more pixels than the display) or expanding. IMO the AR is worth when used as conservative. If you really need to resize (full screen) you can still expand the conservative value (the opposite is not true).

gabest

10th August 2003, 17:30

Using a smaller AR than the real frame size is not a problem because the video window is stretched according to the width/height ratio only, but it could be bad for realvideo when the decoder filter has to resize it internally because it connected to the old renderer which doesn't support a media type with AR values.

karl: I'm not sure if an older ffdshow can preserve the mediatype with the aspect ratio, even if you check "use overlay mixer", if this option exists at all.

karl_lillevold

10th August 2003, 18:19

I installed ffdshow 05.23, and when choosing "overlay mixer" it is able to preserve the AR (1.85 in this case).

@gabest: which old renderers do not support media types with AR values?

multicone

10th August 2003, 22:44

I use jcsston shell extension to set width x height directly in matroska file, works very good for me, it is here : http://matroska.free.fr/downloads/cdl/matroskapropv1.3_test4.exe

gabest

11th August 2003, 08:54

Originally posted by karl_lillevold
@gabest: which old renderers do not support media types with AR values? CLSID_VideoRenderer, {70E102B0-5556-11CE-97C0-00AA0055595A}

Mosu

11th August 2003, 18:51

Heya.

Here it is, the new mkvtoolnix version: 0.6.1. This is a pure bugfix release that addresses a lot of issues that 0.6.0 unfortunately contained. I would have been happier to have 0.6.0 as stable and bug free as 0.6.1 is now, but some bugs I simply wouldn't have found without your feedback, and for others there was simply not enough time.

Anyway, this is the ChangeLog:

2003-08-11 Moritz Bunkus <moritz@bunkus.org>
* Released v0.6.1.
* mkvmerge: RealVideo: Support for all kinds of frames including "short" and "merged" frames (results are identical to Gabest's output).

2003-08-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: The aspect ratio setting will only cause upscaling of the current video dimensions which are then put into KaxVideoDisplayWidth and KaxVideoDisplayHeight.
* mkvextract: Changed how the global elements are handled by taking the parent's size into account. This re-enables processing of files produced with the latest VirtualDubMod.
* mkvmerge: Changed how the Matroska reader handles global elements by taking the parent's size into account. This re-enables processing of files produced with the latest VirtualDubMod.
* mkvinfo: Changed how mkvinfo handles global elements by taking the parent's size into account. Hopefully this is now correct.
* mkvextract: Support for MultiComment tags.
* mkvmerge: Fixed support for reading MultiComment tags from XML tag files.
* mkvmerge: Allow some slightly broken Matroska files to be processed correctly if the reference blocks are off by at most 1ms.

2003-08-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: MP3: Better support for other MPEG versions and layers (number of samples per packet).
* mkvinfo: Added Adler32 calculation and display for frame contents with the -c option.
* mkvmerge: RealAudio: "dnet" is actually byte-swapped AC3 and is being treated as such (re-swapped and output as AC3).
* mkvmerge: Fixed a bug with chapters and splitting which would crash mkvmerge if no chapter belonged into the output file.

As always you can get it at
http://www.bunkus.org/videotools/mkvtoolnix/index.html , and the direct link for the Windows binaries is http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-0.6.1.zip .

Have a nice evening.

Note: Users of MMG (mkvmerge GUI) should also download this release and replace the mkvmerge.exe that comes with mmg with this new exe. I'm sure that SirElvis will soon update his package as well, but in the meantime just be sure to upgrade.

Don't use 0.6.1 - I've made a REALLY stupid bug. I'm in the process of compiling 0.6.2 which should be up in 20 minutes.

Mosu

11th August 2003, 20:08

A bug fix release for the bug fix release :)

As I said: Karl Lillevold found a serious bug in mkvmerge which would set the aspect ratio wrong in most cases. This has been fixed, and the new version is available at http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-0.6.2.zip

Thanks for your patience :)

ssjkakaroto

11th August 2003, 22:31

thx for the upd8 mosu :)

karl_lillevold

12th August 2003, 17:54

Originally posted by multicone
I use jcsston shell extension to set width x height directly in matroska file, works very good for me
Thanks. This works very well, but only if Display size has already been set. So DirectShow Matroska Muxer can not be used to create the file, because it does not set Display size, unless AR is required.

However, that brings up one minor issue where mkvmerge does not quite do the same as DS Matroska Muxer: for RV9 files requiring AR correction (anamorphic), Matroska Muxer will detect the AR correction, and place the right Pixel size and Display size in the Matroska file, such that the renderer does the AR correction. mkvmerge will use the Display size as the Pixel size. This will play back fine, but Gabest's RealMediaSplitter will do the resize in software with bilinear interpolation, feeding the renderer with the already AR corrected video.

Mosu tells me he will add this feature (AR correction detection for RV9) in the next version of mkvmerge.

Mosu

12th August 2003, 19:00

Originally posted by karl_lillevold
Mosu tells me he will add this feature (AR correction detection for RV9) in the next version of mkvmerge.

Yeah... I already have the code in my repository. The only thing that I still have to add is that if the user does not explicitely give an aspect ratio that mkvmerge will use the width and height as given in the RM container as the display width and display height for Matroska. I think that should be the correct way to do things.

Summary:

if (RV40) {
decode actual width/height from first video frame
use actual width/height for PixelWidth/PixelHeight
if (aspect ratio given on command line) {
use supplied aspect ratio for DisplayWidth/DisplayHeight
} else {
use RM's width/height as DisplayWidht/DisplayHeight
}
} else {
use RM's widht/height as PixelWidth/PixelHeight
if (aspect ratio given on command line) {
use supplied aspect ratio for DisplayWidth/DisplayHeight
} else {
use RM's width/height as DisplayWidht/DisplayHeight
}
}

hofmetzger

13th August 2003, 10:53

Well i'm a bit confused...

i used to create my mkv's with graphedit, but now i testet the new gui with mkvmerge (0.6.2). but the result is very disappointing! the file is too big, loading is to slow and seeking looks terrible:eek:

details:
"sources"
605mb divx5 avi
43MB vorbis audio
40MB vorbis audio

muxing with mkvmerge(mmg gui):
"S:\Divxstuff\__ripptools\mmg\mkvmerge\mkvmerge.exe" -o "S:\howard\howardmkvm.mkv" --cues 0:iframes --language 0:eng -A -d 0 -S "S:\howard\pass2.avi" --cues 22356:iframes --language 22356:ger -a 22356 -D -S "S:\howard\audio1deutsch.ogg" --cues 29055:iframes --language 29055:eng -a 29055 -D -S "S:\howard\audio2english.ogg"

result:
howardmkvm.mkv 704MB, takes 31 sec to load, distortet video after seeking (for a few frames)

muxing with graphedit (matroskamuxer):
result:
howardgred.mkv 693MB, plays immediatly (~1 sec), seeking looks as great as seeking can look...

i have to say, that i really have no clue, what mmg put in the commandline (the only option i know is the language tag), but i think mmg does it the way the devs want it to be done...

ill do further testing; just wantet to report this

Mosu

13th August 2003, 11:02

Originally posted by hofmetzger
muxing with mkvmerge(mmg gui):
"S:\Divxstuff\__ripptools\mmg\mkvmerge\mkvmerge.exe" -o "S:\howard\howardmkvm.mkv" --cues 0:iframes --language 0:eng -A -d 0 -S "S:\howard\pass2.avi" --cues 22356:iframes --language 22356:ger -a 22356 -D -S "S:\howard\audio1deutsch.ogg" --cues 29055:iframes --language 29055:eng -a 29055 -D -S "S:\howard\audio2english.ogg"

Please try to chose "none" for the cues for ALL audio tracks. That will decrease the file size, is the default anyway (the GUI does not show this properly atm!), and I'd really like to know if seeking is better without cues for audio tracks.

hofmetzger

13th August 2003, 11:51

I remuxed the file created with graphedit with mkvmerge (default options) resulting in a file with the problems described above. I did this becaus i used to do this mith mkvmerge 0.5, to set language-tag and because the file was one MB smaller than before. and...

Originally posted by Mosu
Please try to chose "none" for the cues for ALL audio tracks. That will decrease the file size, is the default anyway (the GUI does not show this properly atm!), and I'd really like to know if seeking is better without cues for audio tracks.

... well this explains it:

muxing with mkvmerge, no cues for audio:
"S:\Divxstuff\__ripptools\mmg\mkvmerge\mkvmerge.exe" -o "S:\howard\howardmkvm_wo_audio_cue.mkv" --cues 0:iframes --language 0:eng -A -d 0 -S "S:\howard\pass2.avi" --cues 22356:none --language 22356:ger -a 22356 -D -S "S:\howard\audio1deutsch.ogg" --cues 29055:none --language 29055:eng -a 29055 -D -S "S:\howard\audio2english.ogg"

result:
694MB plays immediatly, seeking is ok

so, i think sirelvis should change the defaults of his gui (great work anyway).
but what is cueing for?

and btw:
1. with a cd-size mkv as input, mkvmerge eats too much ram (i have 512, ~1000 virtually, got an errormessage from windows). all is fine if the input consists of several files (avi, ogg,...)

2. @mosu i think your bugtracking-system is a bit overdimensionated (is this an english word?). wouldnt this thread be enough for reporting bugs, as the forum will inform you about every new post? (i'm too lazy to write all this 2 times, well yes copy&paste it...)
i also could send emails if i want to report sth, this would save me some time - i have not to consult dict.cc for every second english term:rolleyes:

edit: forgot to thank you and all matroska people: "really great work! with this speed of development, matroska will be /the/ container of the future"

Mosu

13th August 2003, 12:25

Originally posted by hofmetzger
result:
694MB plays immediatly, seeking is ok

so, i think sirelvis should change the defaults of his gui (great work anyway).
but what is cueing for?

Ok, that shows that Gabest has a problem with the seeking and cues. I'll page him on that.

The cues are needed for proper seeking. E.g. key frames (I frames) are listed in the cues so that the demuxer knows where to jump to to find a key frame it can start decoding from. For video tracks this is essential, but for audio tracks this is not needed most of the time. The major audio codecs (including MP3, Vorbis, AAC, AC3) can be decoded from each frame boundary on, so you don't need any cue entries for them. Technically all audio frames are "I frames" for these codecs. That's why the file will be so much bigger: Each and every audio packet is listed in the cues, although you don't need it at all.

(Note: There are audio codecs that need cue entries. Some RealAudio codecs seem to fall into this category, and mkvmerge will forcefully create cue entries for them IF there's no video track even if the user wants them disabled.)

Now if you use cues for audio tracks as well then Gabest's demuxer seems to use the cue points for audio tracks and jumps to THEM, although a video cue point (I frame) may be further ahead in the file. As I said: I'll contact Gabest.

and btw:
1. with a cd-size mkv as input, mkvmerge eats too much ram (i have 512, ~1000 virtually, got an errormessage from windows). all is fine if the input consists of several files (avi, ogg,...)

I've never been able to reproduce this. I will try to do that, but it seems VERY strange that this happens - especially as you "only" use one video track and two audio tracks...

Sorry, no quick solution for that.

2. @mosu i think your bugtracking-system is a bit overdimensionated (is this an english word?). wouldnt this thread be enough for reporting bugs, as the forum will inform you about every new post? (i'm too lazy to write all this 2 times, well yes copy&paste it...)

Sure, I fully accept bug reports here, and I don't insist on having them posted in the bug tracking system. The system is primarily a means for me to keep track of bugs. Users can use it as well which I really like, but you don't have to. As long as I am aware of a bug report everything is fine ;)

E.g. after the 0.6.0 release last week: I got so many bug reports via IRC, mail and this forum that I wouldn't have been able to fix them all without the bug tracking system. So if you don't want to bother with it then that's fine with me ;)

Sirber

13th August 2003, 13:09

I don't know where to post this...

I have a 36 minutes 800 x 448 RMVB source, once muxed with graphedit, MPC crash on it and mkvinfo gave me this:

+ EBML head
+ Segment
|+ Seek head (subentries will be skipped)
|+ EbmlVoid
|+ Segment information
| + Timecode scale: 1000000
| + Duration: 10749.891s
| + Date: Wed Aug 13 07:59:49 2003 UTC
| + Muxing application: DirectShow Matroska Muxer
|+ Segment tracks
| + A track
| + Track number: 1
| + Track UID: 41
| + Track type: video
| + MinCache: 1
| + MaxCache: 1
| + Codec ID: V_REAL/RV40
| + CodecPrivate, length 34
| + Default duration: 33.333ms (30.000 fps for a video track)
| + Video track
| + Pixel width: 720
| + Pixel height: 540
| + Frame rate: 30.000031
| + A track
| + Track number: 2
| + Track UID: 18467
| + Track type: audio
| + MinCache: 1
| + MaxCache: 1
| + Codec ID: A_REAL/COOK
| + CodecPrivate, length 158
| + Audio track
| + Sampling frequency: 44100.000000
| + Channels: 6
| + Bit depth: 16
| + A track
| + Track number: 3
| + Track UID: 6334
| + Track type: subtitles
| + MinCache: 1
| + MaxCache: 1
| + Codec ID: S_TEXT/SSA
| + CodecPrivate, length 711
|+ Cluster

Muxed with mkvmerge:
mkvmerge -o out.mkv E01.rmvb E01.rm E01.ssa

Using RealMedia demultiplexer for E01.rmvb.
+-> Using video output module for stream 0 (FourCC: RV40).
Using RealMedia demultiplexer for E01.rm.
+-> Using generic audio output module for stream 0 (FourCC: cook).
Using SSA/ASS subtitle reader for E01.ssa.
+-> Using text subtitle output module for subtitles.
Opened 'out.mkv' for writing.
'die' called: real_reader_c: deliver_segments() failed: len 981288001, total 174
73.

DBG> dumping time info:
DBG> function: video_packetizer_c::process, # calls: 54998, elapsed time: 126661
34152750188000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000.000s, time/call: -0
.000ms
DBG> function: passthrough_packetizer_c::process, # calls: 49395, elapsed time:
0.000s, time/call: -350328080518535320000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000.000ms
DBG> dumping packetzer info:
DBG> video_packetizer_c: queue: 1; frames_output: 54998; ref_timecode: 2293833
DBG> passthrough_packetizer_c: packets processed: 49395, bytes processed: 0, pac
kets in queue: 52556280
DBG> textsubs_packetizer_c: queue: 70

it's infos:
+ EBML head
+ Segment
|+ EbmlVoid
|+ Segment information
| + Muxing application: libebml v0.5.0 + libmatroska v0.5.0
| + Writing application: mkvmerge v0.6.2
| + Duration: 0.000s
| + Date: Wed Aug 13 12:13:19 2003 UTC
| + Segment UID: 0x6f 0xc1 0x48 0xdd 0x41 0x59 0xc4 0x78 0xcb 0x10 0x67 0xce 0x39 0xe2 0x52 0xca
|+ Segment tracks
| + A track
| + Track number: 1
| + Track UID: 3567545064
| + Track type: video
| + MinCache: 1
| + Codec ID: V_REAL/RV40
| + CodecPrivate, length 34
| + MaxCache: 1
| + Default duration: 33.333ms (30.000 fps for a video track)
| + Video track
| + Pixel width: 800
| + Pixel height: 448
| + Display width: 800
| + Display height: 448
| + Lacing flag: 0
| + A track
| + Track number: 2
| + Track UID: 2478706374
| + Track type: audio
| + Codec ID: A_REAL/COOK
| + CodecPrivate, length 158
| + Audio track
| + Sampling frequency: 44100.000000
| + Channels: 6
| + Bit depth: 16
| + A track
| + Track number: 3
| + Track UID: 2497978022
| + Track type: subtitles
| + Codec ID: S_TEXT/SSA
| + CodecPrivate, length 399
| + Lacing flag: 0
|+ Cluster

Both seems to have problems, the frist with output rez and second with subs length.

Mosu

13th August 2003, 13:17

Originally posted by Sirber
[B]I have a 36 minutes 800 x 448 RMVB source, once muxed with graphedit, MPC crash on it and mkvinfo gave me this:

...
| + Codec ID: V_REAL/RV40
...
| + Video track
| + Pixel width: 720
| + Pixel height: 540

This is normal. RV40 (aka RealVideo9) has two dimensions: the one that the container itself lists are the intended display dimensions, and the video stream itself (the video packets) contain their real pixel dimensions. The upcoming mkvmerge version will handle this correctly, and Gabest's DShow muxer already does it: it decodes the dimensions stored in the video packet and uses those for the pixel width and pixel height.

gabest

13th August 2003, 13:27

The display dimension can't be smaller than the true resolution (800x448 720x540), that may crash the internal resizer of the rv decoder filter when used. For "real" real media files this can never happen and the resizer can only do upscaling :) I'll check the audio cue table prob now.

Sirber

13th August 2003, 13:39

Mosu

13th August 2003, 13:57

Originally posted by Sirber
'die' called: real_reader_c: deliver_segments() failed: len 981288001, total 17473.

Any chance you could upload that file to me (FTP: mosu.no-ip.com, username 'upload', password 'only')? Seems there are still cases with RV that I don't handle correctly.

| + Duration: 0.000s

Result of the "die". If 'die' is called then the resulting file is supposed to be broken.

Both seems to have problems, the frist with output rez and second with subs length.

Can you send me the SSA file in question? Either via FTP or mail to moritz@bunkus.org Thanks.

Sirber

13th August 2003, 14:03

Since my lastest mux worked, I flushed all the sources/tests. :( I'm gonna check with Part 2 of the source with mkvmerge and upload it to you in case of "non workiness" :), but this may take ~12h...

"Result of the "die". If 'die' is called then the resulting file is supposed to be broken."

File was playable to the end...

Mosu

13th August 2003, 14:07

Originally posted by Sirber
Since my lastest mux worked, I flushed all the sources/tests. :( I'm gonna check with Part 2 of the source with mkvmerge and upload it to you in case of "non workiness" :), but this may take ~12h...

Sure, I have the time ;) If you upload please let me know when it's finished.

"Result of the "die". If 'die' is called then the resulting file is supposed to be broken."

File was playable to the end...

"Yes but..."

Problem is that after copying everything there are several things that have to be done: fixing the file duration (that's why it's set to 0), writing cues. So seeking will be slower. Depending on when exactly the muxing stopped with the 'die' you may have the complete film in the file (e.g. if the error occured at the very end of the RM file).

Sirber

13th August 2003, 14:16

I'm going to work, so I'll mux it in remote control :D and check if the infos are correct. If not, I'll upload it to you. Second pass at 50%.

HomiE FR

13th August 2003, 16:29

@Mosu: Hi and thanks for you work on mkvtoolnix! I have a little question though: I really would like to see embedded fonts inside Matroska files. I think this matter has already been discussed if we use fonts as attachements (just like the mkvmerge documentation suggests). But no player currently handles those attachments, so I can't do anything until gabest has time and motivation for such a "less important" feature of the container.

But there could be another way to store fonts inside Matroska: the [Fonts] section inside ASS scripts. gabest said SubtitleSource can't do it right now and I believe he has many things more important to do before he updates this DShow plugin which already works right (apart from this feature). So could mkvmerge be able to store a full ASS script with the [Fonts] section inside a Matroska file? That way I believe that it would be possible to use custom embedded fonts for subtitles.
At the time being it doesn't seem to be the case, at least the fonts don't appear... (correct me if I'm wrong).

Moreover I think that MatroskaSplitter should be updated to read the full ASS script and not only the subtitles part. Is this right or do we only need a new mkvmerge version/Subtitle Source version?

Thanks in advance and keep up the good work.

HomiE FR

Mosu

13th August 2003, 18:08

Originally posted by HomiE FR
@Mosu: Hi and thanks for you work on mkvtoolnix! I have a little question though: I really would like to see embedded fonts inside Matroska files. I think this matter has already been discussed if we use fonts as attachements (just like the mkvmerge documentation suggests). But no player currently handles those attachments, so I can't do anything until gabest has time and motivation for such a "less important" feature of the container.

I think that Gabest, robux and someone else were chatting about this topic this afternoon, but I don't remember the conclusions. They were talking about using the fonts from the attachments section and how to activate them (e.g. either installing them automatically or just copying them to a temporary location for the duration of playback). So maybe Gabest will fix this sooner than you think ;)

Now to the ASS scripts. Normally I do store the complete script inside Matroska, not just the individual text entries. The "global" part is stored in Matroska's CodecPrivate element. But I've never tested storing an ASS file containing a font. How is the font encoded? Something like Base64 or uuencoded? If yes, then there shouldn't be any problem.

If playback works, though, I cannot tell. You'd have to ask Gabest.

Moreover I think that MatroskaSplitter should be updated to read the full ASS script and not only the subtitles part. Is this right or do we only need a new mkvmerge version/Subtitle Source version?

Asuming I haven't produced any bug when storing the ASS script inside Matroska you don't need a new mkvmerge version.

HomiE FR

13th August 2003, 18:53

From the ASS/SSA scripts specifications:
SSA’s font and picture file embeddeding is a form of UUEncoding.

It takes a binary file, three bytes at a time, and converts the 24bits of those bytes into four 6-bit numbers. 33 is added to each of these four numbers, and the corresponding ascii character for each number is written into the script file.

The offset of 33 means that lower-case characters cannot appear in the encoded output, and this is why the “filename” lines are always lower case.

Each line of an encoded file is 80 characters long, except the last one, which may be shorter.

If the length of the file being encoded is not an exact multiple of 3, then for odd-number filelengths, the last byte is multiplied by hexadecimal 100, and the most significant 12 bits are converted to two characters as above. For even-number filelengths, the last two bytes are multiplied by hexadecimal 10000, and the most significant 18 bits are converted to three characters as above.

There is no terminating code for the embedded files. If a new [section] starts in the script, or if another filename line is found, or the end of the script file is reached then the file is considered complete.

About playback, it doesn't seem to work since I have here a ASS script which has 3 embedded fonts that work right when the script remains outside. When I mux the ASS script using mkvmerge (I tried with 0.6.1 I think, maybe I'll give it another try now with 0.6.2) the default Arial font is used for the 3 embedded fonts.

But I think that using attachements for embedded fonts is a better way, since we don't have to code the font file and then put it into the ASS script. That's why I'm really interested when you say that gabest and robux talked about that matter lately! :)

I think that's all, I'll stay tuned! Thanks for the quick answer too.

Sirber

13th August 2003, 19:39

no prob with part 2... I'll try to play it when I return home.

Sirber

13th August 2003, 21:40

Sirber

13th August 2003, 21:56

I checked the file through rmeditor and with the output that is 100% correct, I got:

real_reader: out.rm: Data packet length is too small: 0. Other values: object_ve
rsion: 0x314c, id: 0x0008, timecode: 4079485135, flags: 0x21. File position: 490
62461. Aborting.
working... \ (99%)
Assertion failed: CheckMandatory(), file ../../src/EbmlMaster.cpp, line 128

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

[edit]

out.rm is going on your FTP...

[edit 2]

All files muxed, the ,mkv is 3h12:50 long. Source is 35 minutes... Also, subtitles lenght is wrong (I guess). Check bold stuff in the post above.

[edit 3]

Upload completed.

Liisachan

13th August 2003, 22:31

Originally posted by HomiE FR
But I think that using attachements for embedded fonts is a better way, since we don't have to code the font file and then put it into the ASS script. I have the same opinion here. Altho "to code the font" is very easy (just check one checkbox and SubStationAlpha will automatically generate [font] sections), uuencode will make font files 30-40% bigger. This is not preferable--especially when you want to embed a large file, say, like 1MB or more. If you wanted to use cute/cool/kawaii fonts in a CJK language, the font file would be huge. Altho, you could use something like SVG in the future (ie. to define subtitles as vectors--this is another XML and would make Matroska even more XML-ish)--I don't like raster picture subs, because you cannot resize/recolor them no matter what, while you can resize etc. softsub using MPC 6459, like "user style sheet" in CSS. Font embedding is the way to go.

Font embedding is not just for fancy effects. It's practical (or essential) for i18n. There are only few systems that has glyphs for, say, Thaana, Tatar, or minor Indian Glyphs. If you don't have an available glyph for the codepoint, you'll see a square instead of the letter, which means, you can't get subtitles properly. (Getting default Arial? You are lucky if Arial has that glyph!)

For instance, arialtat.ttf is just 63KB If you can dynamically call this attached font data, you can see Tatar subs on all the PCs in the world that can play Matroska. This is really something. The same goes for any glyphs like Thaana, etc. So font embedding makes Matroska even more portable in an internationalized/multilingualized way...

Besides, fansubbers are eager to embed fancy fonts, as you can imagine. One of my german friends is keep asking "Font embedding is now supported?" like everyday each time something in is version-uped ^^;
And, tho binary attachement is possible, that will be preferable for space efficiency, anyway SSA's [font] sections should be supported too, I think; because many subbers use them and many SSA files already have them. I don't like it, but many ppl are using it.
(Another reason I don't prefer [font] sections, is that I often get a BSOD trying to load an SSA with [font] with MPC.)

Anyway, you are not the only one who is waiting for font embedding features :)

Sirber

13th August 2003, 23:03

File length is 3h12:50, source length is about 35 minutes. is there a way to change the "length flag" coz I have 2 corrupted MKV with that bug... Both mkv play fine until the real end.

HomiE FR

13th August 2003, 23:47

Liisachan : Thanks for this interesting post! :) I see you really take care that every language talked on Earth (and maybe more :p ) will be supported, that's great. Apart from that, thanks for the pages you made about Matroska (the ones with the huge sample with 16 subtitles).

That's comforting to see that I'm not the one to wait for embedded fonts. I didn't check that embedded fonts UUE encoded were bigger than the original TTF ones, but I already used Sub Station Alpha to do a sample clip with 3 embedded fonts.
It works outside a Matroska container using VSFilter 2.28 and MPC but no success when muxed using SubtitleSource (which is normal since it's not supported) and mkvmerge (which is more disappointing cause Mosu said the whole script was put inside the Matroska file). I'm not aware of all the internal processes so I can't say more.

So I'll just wait I guess! :)

unplugged

14th August 2003, 18:17

little parenthesis: the "ms" postfix used with --cluster-length option never worked to me (neither with mkvmerge 0.6.2).

Mosu

14th August 2003, 18:23

Originally posted by unplugged
little parenthesis: the "ms" postfix used with --cluster-length option never worked to me (neither with mkvmerge 0.6.2).

Hmm... I should remove this option as it can do more harm than it can do good. If you're not a developper then don't use it.

unplugged

14th August 2003, 18:54

I have tried this parameter just to tweak a bit, generally mkvmerge create MKVs a little bigger than VDubMod (1.5.4.1), about ~4MB over 700MB XviD + Vorbis.
1 more thing, does mkvmerge accepts raw AAC files (.AAC)? And can you add support for HE-AAC files? :) (created with Nero 6)

Thanks

Mosu

14th August 2003, 19:25

Originally posted by unplugged
I have tried this parameter just to tweak a bit, generally mkvmerge create MKVs a little bigger than VDubMod (1.5.4.1), about ~4MB over 700MB XviD + Vorbis.

Don't use cues for audio tracks - if you already don't, then ignore this ;)

1 more thing, does mkvmerge accepts raw AAC files (.AAC)? And can you add support for HE-AAC files? :) (created with Nero 6)

The answers are: 1) If you mean 'AAC with ADTS headers' then yes, and 2) partially. Partially because auto detection of HE-AAC is not possible without decoding the AAC data. Therefore the next mkvmerge version will have an option that the user must explicitely enable for HE-AAC files.

Sirber

14th August 2003, 20:40

@Mosu

Have you checked your FTP?

Mosu

14th August 2003, 21:02

Originally posted by Sirber
Have you checked your FTP?

Yes, thanks, and I've already made some small adjustments. Your file was not broken, but my Real reader tended to read more packets than there are packets in the files. Next version will pay to the RM file headers and should not emit that error message anymore.

Sirber

14th August 2003, 22:39

Can you PM me when next version that handle this file correctly will be avalible? Thanks!!! :D

unplugged

16th August 2003, 02:46

Originally posted by Mosu
Don't use cues for audio tracks - if you already don't, then ignore this ;)
I have red somewere in past versions that *as default* mkvmerge creates cues only for video (at I-frames clusters) and not with audio (no cues at all).
In fact:
"mkvmerge -o av.mkv video.mkv audio.ogg"
or
"mkvmerge -o av.mkv video.mkv --cues 11556:none audio.ogg"
or
"mkvmerge -o av.mkv video.mkv --cues -1:none audio.ogg"
gives the same result (719618 KB), but VirtualDubMod (CVS-20030809) as well older versions gives anyway a little smaller output (716522 KB).
Hex editing these files and roughly comparing head and tail headers (info, metaseek ... cue-index list) shows that mkvmerge output and VDub output is nearly identical with only few KB of difference.
So this 3 Megs of difference must be in main body of file (streams packaging).
My point is I would love to use your cmd-line tool but what params must I pass to obtain VDub similar output?
Maybe silly problem, I know, but... what's those 3MB ?

Another strange thing, what's that long empty zeroed zone (00 00 00 00 00..) that *only recently* I see after meta-seek data?
I'm seeing it for first time since later MKV versions.

Sirber

17th August 2003, 17:48

Mosu

17th August 2003, 17:56

Originally posted by Sirber
'die' called: real_reader_c: deliver_segments() failed: len 867255361, total 17473.

I can't fix that without having a sample. Could you provide one, please?

Mosu

17th August 2003, 18:28

Originally posted by Sirber
Total is ~700Mo. On your FTP?

Sure ;) Thanks.

Eric B

17th August 2003, 18:29

Is there any tool/options with which I can add matroska tags from a XML file to a mkv file already and partially tagged with VirtualDubMod; and if possible, without rewriting all the file?

I've TCMP rc44, but the tag saver does not work very well...

Mosu

20th August 2003, 22:53

Originally posted by Eric B
Is there any tool/options with which I can add matroska tags from a XML file to a mkv file already and partially tagged with VirtualDubMod; and if possible, without rewriting all the file?

Nope, sorry.

Mosu

20th August 2003, 22:57

Heya.

I'm in the process of releasing 0.6.3 which is another bug fix release. A lot of fixes all over the place, but HE-AAC / AAC+ / SBR AAC is now officially supported - but ONLY MANUALLY! Read the ChangeLog entries and the documentation, please.

Here's the ChangeLog since the last release:

2003-08-20 Moritz Bunkus <moritz@bunkus.org>
* Released v0.6.3.
* mkvmerge: The Real reader accepts incomplete video packets and tries to re-assemble them instead of aborting with 'die: len != total'.

2003-08-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Implemented a switch that has to be used for SBR AAC / AAC+ / HE-AAC if the source file is an AAC file and the AAC file contains SBR AAC data (no automatic detection possible in this case!).

2003-08-14 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Low bitrate AC3 tracks from Real's DNET are identified as A_AC3/BSID9 or A_AC3/BSID10.
* mkvmerge: The RealMedia reader takes the number of packets into account when reading which results in better end-of-file detection.

2003-08-12 Moritz Bunkus <moritz@bunkus.org>
* Windows versions: Fixed a bug with files bigger than 2GB not being recognized. The accompanying error message was "File NAME has unknown type. Please have a look at the supported file types..."
* all tools: Fixed a bug which would only allow Matroska files up to 4GB to be read. The accompanying error message was "No segment found" or something similar.
* mkvinfo: Unknown elements are properly skipped now.

2003-08-11 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: For RV40 (RealVideo 9) the actual video dimensions are decoded from the first video frame.

The files are available on http://www.bunkus.org/videotools/mkvtoolnix/
(Win32 build: http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-0.6.3.zip )

Have fun :)

Liisachan

21st August 2003, 00:00

thank you (again) for keeping good jobs...
i'll try :)

i guess "−−aab−is−sbr" is a typo. you meant "--aac-is-sbr" right?

unplugged

21st August 2003, 05:23

I have red that someone enable ISO export option in Nero to obtain valid AAC tracks for mkvmerge (that it accepts).
First time I was forced to this too, because mp4extractor util (0.9.9) gave me strange AAC files from passed MP4s, not recognized by mkvmerge.
(cmd-line was "mp4extractor -t 1 filename.mp4")

But using Nero encoder's ISO export option is not good too, expecially if we make HE-AAC tracks, because the AAC files created by this way are marked internally as MPEG-2 stream!
As we know HE-AAC is NOT part of MPEG-2 AAC (at all), despite these files are further *fully* detected by lastest CoreAAC (SBR part used) the inconsistency is there.

So trying other ways I found that mp4creator not only creates but (instead of mp4extractor) does the extraction perfectly, it gives perfect MPEG-4 AAC files from MP4s encoded by either QuickTime and Nero (with ISO option disabled, of course).
Problem was mp4extractor!!!
Here is what works fine to me:

mp4creator -extract=1 filename.mp4

and every AAC output will be good for mkvmerge ;)

Mosu

21st August 2003, 08:14

Originally posted by Liisachan
thank you (again) for keeping good jobs...
i'll try :)

i guess "−−aab−is−sbr" is a typo. you meant "--aac-is-sbr" right?

Doh! Of course. Thanks :)

Mosu

21st August 2003, 08:19

Originally posted by unplugged
Here is what works fine to me:

mp4creator -extract=1 filename.mp4

and every AAC output will be good for mkvmerge ;)

Thanks for that info :)

Mosu

21st August 2003, 10:22

Originally posted by unplugged
I have red somewere in past versions that *as default* mkvmerge creates cues only for video (at I-frames clusters) and not with audio (no cues at all).

That's correct.

In fact:
"mkvmerge -o av.mkv video.mkv audio.ogg"
or
"mkvmerge -o av.mkv video.mkv --cues 11556:none audio.ogg"
or
"mkvmerge -o av.mkv video.mkv --cues -1:none audio.ogg"
gives the same result (719618 KB), but VirtualDubMod (CVS-20030809) as well older versions gives anyway a little smaller output (716522 KB).

Which older version exactly?

Hex editing these files and roughly comparing head and tail headers (info, metaseek ... cue-index list) shows that mkvmerge output and VDub output is nearly identical with only few KB of difference.
So this 3 Megs of difference must be in main body of file (streams packaging).

The output for video and Vorbis should be nearly identical. MP3 is handled differently by VDubMod, though - the MP3 packets are not split upon their borders but taken in the same way they're stored in the AVI which is due to limitation ins VDubMod.

But as your sources are Vorbis...

My point is I would love to use your cmd-line tool but what params must I pass to obtain VDub similar output?
Maybe silly problem, I know, but... what's those 3MB ?

I don't know. I'll have to make some comparisons sometime.

Another strange thing, what's that long empty zeroed zone (00 00 00 00 00..) that *only recently* I see after meta-seek data?
I'm seeing it for first time since later MKV versions.

That's the space reserved for the meta seek data. It is estimated at the beginning. You can do a two-pass muxing: first mux normally, then use mkvinfo to see how big the meta seek element really was, and then call mkvmerge a second time with --meta-seek-size and insert the size +20 bytes safety margin.

Liisachan

22nd August 2003, 12:49

Originally posted by Mosu
Since 0.6.0 mkvmerge also supports SSA/ASS/SRT subs that have the BOM (byte order marker) set and that are encoded in UTF-8, UTF-16 LE or UTF-16 BE. Just UTF-32 is not supported atm.

I tested :) MKVtoonix does work for SSA in UTF-16le-bom now, in most cases for me. Basically, this is handy than using GraphEdit. Thank you so much for this nice tool!!...is what I'd like to say, but, altho this works for most cases, I happened to encounter this annoying, strange case.
This is SSA in UTF-16le-bom (call this debug.ssa):
----
Dialogue: Marked=0,0:00:32.00,0:00:36.17,aaa,,0000,0000,0000,,some text
----
The problem is in this one line (with necessary headers). MKVtoolnix cannot mux this simple SSA for some reaons; muxing ends normally, but the resulted file is broken (i.e. no subs)
for instance...
mkvmerge -o out.mkv in.avi debug.ssa
mkvmerge -o out2.mkv --language 1:fre out.mkv
This gives me "Warning: Text subtitle block does not contain a block duration element. This file is broken."
The resulted video sample is here (http://matroska.tripod.co.jp/debug.zip) (just 21kb)
Funny thing is, MKVmerge will be happy if the in-time is 31.99 or 32.05 and will work fine, but it will fail if it is 32.00 32.01 etc. in the sample above. I'm guessing something must be wrong, as I can mux this SSA normally with MatroskaMuxer+graphedit. Thought, I cannot rule out the possibility that not MKVmerge but my SSA is somehow wrong, or this happnes only for me for some silly reasons of my PC...
This phenomenon will be reproduced even if I change the video...

Anyone has any suggestions?
:confused: :confused:

tyia

unplugged

22nd August 2003, 15:17

Originally posted by Mosu
Which older version exactly?
Couldn't say exactly, but I think previous 2-3 versions available as public CVS at sf.net
Originally posted by Mosu
The output for video and Vorbis should be nearly identical. MP3 is handled differently by VDubMod, though - the MP3 packets are not split upon their borders but taken in the same way they're stored in the AVI which is due to limitation ins VDubMod.
Aaah, yes :), I have noticed this about 2 weeks ago, when hex editing mkv created (from DivX-MP3 AVI) by VDubMod I have red in the header something like "MS_ACM" for audio part...
shit! :D
Since then I have re-muxed all my already muxed mkv or AVIs by this way:
1st extracting MP3 part (stamped as "MS_ACM" internally) with "demux" option into external file
2nd, *just for fun*, I run VBRFIX utility that can clean MP3s from VBR information or by other stuff, then I strip VBR Xing header
3rd I remux my video again with VDubMod disabling internal audio and adding externally the MP3 file previously stripped (just for fun) by VBRFIX.
By this way VDubMod create the MKV with "A_MPEG/L3" native packaging for audio part and the result even more smaller (don't remeber... 2-3 Mb??).

P.S.: VBRFIX is a nice MP3 stripping utility, but can remake correct the internal VBR index too and has batch mode (just drag over). www.willwap.co.uk (don't think... I'm not the author :p)

Mosu

22nd August 2003, 21:14

Originally posted by Liisachan
----
Dialogue: Marked=0,0:00:32.00,0:00:36.17,aaa,,0000,0000,0000,,some text
----
The problem is in this one line (with necessary headers).

Thanks for the detailed report and (VERY important in this case!) the test files.

The problem was not limited to SSA, but it was much more likely to show up with subtitles. The thing was that the very last packet in a cluster did not get its duration set properly. This is not bad in most cases as video and audio blocks usually have a fixed duration and are therefore not affected. But for subtitles this is fatal, of course.

Please download http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvmerge-0.6.3-200308022-1.zip and test that version.

Thanks again ;)

Mosu

22nd August 2003, 21:17

Originally posted by unplugged
By this way VDubMod create the MKV with "A_MPEG/L3" native packaging for audio part and the result even more smaller (don't remeber... 2-3 Mb??).

Looks like I'll have to do some tests soon. At the moment I don't have any definitive answer for you (how to make mkvmerge produce files that small), but I'll investigate.

Liisachan

22nd August 2003, 22:12

Originally posted by Mosu
Please download http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvmerge-0.6.3-200308022-1.zip and test that version. Yep, seems it has been fixed... :) :)

Liisachan

27th August 2003, 06:52

Another report...:(

after i mux Video+mono Audio into an MKV using MKVmerge 0.6.3,
MKVmerge cannot open that MKV it created by itself,
instead it gives me an application error (crash) after:
"Warning: matroska_reader: The number of channels was not set for track 2."

I can reproduce this problem in more than one combinations, such as XviD + WAV or XviD + AAC. This problem doesnt occur if the audio is stereo.

An MKV file with this problem (http://matroska.tripod.co.jp/audio-mono.zip) made by MKVmerge.

Mosu

27th August 2003, 08:20

Originally posted by Liisachan
Another report...:(

after i mux Video+mono Audio into an MKV using MKVmerge 0.6.3,
MKVmerge cannot open that MKV it created by itself,
instead it gives me an application error (crash) after:
"Warning: matroska_reader: The number of channels was not set for track 2."

Liisachan my favourite bug reporter :) Thanks. That's a rather stupid bug of me which is actually fixed in two lines of source code. I'll have that fixed soon - hopefully I'll have an exe to test for you soon.

Mosu

27th August 2003, 14:37

Liisachan, please test this new exe:
http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvmerge-0.6.3-20030827-1.zip

Thanks.

Liisachan

27th August 2003, 18:10

Thank you for the swift fix :)
Video + mono audio muxing now works fine.

As a side effect, the file size is significantly smaller than one made by the old one (both for stereo and mono audio). For instance:

Build 20030822-1 Build 20030827-1
XviD + AAC 344,038 KB 343,833 KB
XviD + MP3 + SSAs 238,932 KB 238,782 KB

The result is like 200KB smaller with the new MKVmerge.
Is this something expected?

Mosu

27th August 2003, 18:30

Originally posted by Liisachan
Thank you for the swift fix :)
Video + mono audio muxing now works fine.

Great to hear. Thanks for testing :)

As a side effect, the file size is significantly smaller than one made by the old one (both for stereo and mono audio). For instance:

Yes, that's expected. I've changed the way how the meta seek space is handled. (You know - that annoying warning about "Could not write meta seek information. Re-run with --meta-seek-size..." and stuff.) Now I write two meta seek elements, a short one at the beginning and the big one at the end. That change gets rid of that nasty size-guessing I had to use.

For those interested, here are the relevant sections from the (new) documentation:

The ChangeLog says:

2003-08-24 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Meta seek element is split into two elements. The first's located at the start of the file containing only a small number of level 1 elements. The clusters are referenced in a second meta seek element located at the end of the file. Removed the options "--meta-seek-size" and "--no-meta-seek". Added the option to disable that second meta seek entry, "--no-clusters-in-meta-seek".

mkvmerge's main documentation contains the following section about the Matroska file layout produced by mkvmerge:

MATROSKA FILE LAYOUT

The Matroska file layout is quite flexible. mkvmerge will render a file in a predefined way. The resulting file looks like this:

[EBML head] [segment {meta seek #1} {attachments} {chapters} [segment information] [track information] [cluster 1] {cluster 2} ... {cluster n} {meta seek #2} {tags}]

The elements in curly braces are optional and depend on the contents and options used. Some notes:

* meta seek #1 includes only a small number of level 1 elements, and only if they actually exist: attachments, chapters, tags, meta seek #2. Older versions of mkvmerge used to put the clusters into this meta seek element as well. Therefore some imprecise guessing was necessary to reserve enough space. It often failed. Now only the clusters are stored in meta seek #2, and meta seek #1 refers to the meta seek element #2.

* Attachment, chapter and tag elements are only present if they were added.

The shortest possible Matroska file would look like this:

[EBML head] [segment [segment information] [track information] [cluster 1]]

This might be the case for audio-only files.

Sirber

27th August 2003, 18:35

Nice! It's nice to see softwares getting better and better every hour :D

Mosu

27th August 2003, 20:05

I've just released another bug fix release: 0.6.4. It will probably be the last bug fix release from the 0.6.x line. Time for some new features :)

There have been a lot of bug fixes in almost all parts of mkvtoolnix. Some only fix things that happen seldom while others fix critical stuff.

The link is: http://www.bunkus.org/videotools/mkvtoolnix/ and http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-0.6.4.zip

A note for the Windows users: You should upgrade Gabest's Matroska filter to the newest version which was released today. Here's the link: http://prdownloads.sourceforge.net/guliverkli/mpc2kxp6461.zip?download

Linux users should update mplayer. This has something to do with the meta seek changes which are described in the ChangeLog and in mkvmerge's documentation under the heading 'MATROSKA FILE LAYOUT'.

Here's the ChangeLog:

2003-08-27 Moritz Bunkus <moritz@bunkus.org>
* Released v0.6.4.
* mkvextract: Support for re-creating dropped frames when extracting video to an AVI. Works only well if the frame durations in the source file are multiples of the frame rate, of course.
* mkvmerge: The MP3 packetizer did not start at 0 with its timecodes. It does now.
* mkvmerge: Proper support for dropped frames when reading AVI files.
* mkvmerge: Fixed some missing default values in the Matroska reader (e.g. mono audio files). Reported by Liisachan.

2003-08-25 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Improved all command line parsing error messages.
* mkvmerge: Improved the error message for the XML tag file parser if an invalid &-sequence is found.
* mkvextract: Strings are postprocessed so that the special characters &, <, >, " are replaced by their HTML equivalents &, &lt, > and ".

2003-08-24 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Disabled lacing by default and renamed --no-lacing to --enable-lacing. With all the proper info about the laced frames lacing is actually producing larger files than without lacing.
* mkvmerge: Meta seek element is split into two elements. The first's located at the start of the file containing only a small number of level 1 elements. The clusters are referenced in a second meta seek element located at the end of the file. Removed the options "--meta-seek-size" and "--no-meta-seek". Added the option to disable that second meta seek entry, "--no-clusters-in-meta-seek".

2003-08-22 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: Backwards compatibility: Accepts S_SSA and S_ASS as valid CodecIDs (new CodecIDs are S_TEXT/SSA and S_TEXT/ASS).
* mkvmerge: Bugfix: If a subtitle packet was the last packet in a cluster then its duration was not written resulting in a broken file.

2003-08-21 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: Added support for the following elements: KaxPrevFilename, KaxNextFilename, KaxTrackFlagEnabled, KaxTrackName, KaxCodecName, KaxCodecSettings, KaxCodecInfoURL, KaxCodecDownloadURL, KaxCodecDecodeAll, KaxTrackOverlay, KaxAudioPosition, KaxAudioOutputSamplingFreq, KaxVideoDisplayUnit, KaxVideoColourSpace, KaxVideoGamma, KaxVideoFlagInterlaced, KaxVideoStereoMode, KaxVideoAspectRatio, KaxClusterPosition,KaxClusterPrevSize, KaxBlockVirtual, KaxBlockAdditions, KaxBlockMore, KaxBlockAddID, KaxBlockAdditional, KaxReferenceVirtual, KaxSliceBlockAddID, KaxChapters, KaxEditionEntry, KaxChapterAtom, KaxChapterUID, KaxChapterTimeStart, KaxChapterTimeEnd, KaxChapterTrack, KaxChapterTrackNumber, KaxChapterDisplay, KaxChapterString, KaxChapterLanguage, KaxChapterCountry

ssjkakaroto

28th August 2003, 00:48

thx mosu :cool:

Liisachan

28th August 2003, 02:42

Thanks again for your good job.

I don't like to nag again and again, but let me report other bugs,
because they are fatal for me who should sometimes use Japanese in tags.

(1) I have just found that Mkvmerge doesn't like U+0800 or higher.

Call this file "tags.xml"

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE Tags SYSTEM "matroskatags.dtd">
<Tags>
<Tag>
<MultiTitle>
<Title>
<TitleType>1</TitleType>
<Name>###</Name>
</Title>
</MultiTitle>
</Tag>
</Tags>

mkvmerge -o out.mkv --tags:1 "tags.xml" in.mkv

If ### = U+7FFF (E7 BF BF in UTF8), this will work perfectly.
if ### = U+8000 (E8 80 80 in UTF8), mkvmerge will freeze.

sample xml demo files (http://matroska.tripod.co.jp/tag-demo.zip)

(2) I was once experienced another kind of problem--tagging worked but the resulted tag was broken.
It seemed that the last byte of the last 3-byte character (for one glyph in UTF-8) in the string was missing.
This might be related to another problem than (1) because the broken character should have been < U+0800
unluckily (or luckily?) I cannot reproduce this problem now.

(3) Feature Request: accept chapters.txt in UTF-8 so that any languages can be typed on any PC...

in other words, something like: --chapters-encoding UTF-8 --chapters "utf8.txt"

as the automatic conversion from the System Language to UTF-8 is not documented,
quite a few people in CJK areas are being confused, getting messed-up chapters by mistakenly typing
the chapter text in UTF-8 (as they believe the tags/chapters in Matroska should be utf-8) Besides, this way, you cannot type chapters, say, in French, if your system langauge is, say, Chinese.

[PS]
Altho many CJK (Chinese/Japanese/Korean) letters are around U+3xxx - U+7xxx, some CJK code points are in the range U+8000+ (these glyphs are commonly used, not rarely) That's why I said this is a fatal problem when tagging in a CJK langauge.

[\PS]

Liisachan

28th August 2003, 06:21

Originally posted by Liisachan
(2) I was once experienced another kind of problem--tagging worked but the resulted tag was broken.
It seemed that the last byte of the last 3-byte character (for one glyph in UTF-8) in the string was missing.

The condition for this problem is still unclear, as the exactly same tags.xml will work perfectly for an mkv file, and will not work (and the data will be broken) for another mkv file, and I cannot make a small demo for this problem atm. But here are some samples: when a UTF-8 string will be broken, it will be broken this way (the 2nd or 3rd of the last triplet will be weird)

input E3 81 82 E3 81 84 E3 81 86 E3 81 88 E3 81 8A
output E3 81 82 E3 81 84 E3 81 86 E3 81 88 E3 80 8A

input E3 82 84 E3 82 86 E3 82 88
output E3 82 84 E3 82 86 E3 80 88

input E3 81 9F E3 81 A1 E2 85 A1
output E3 81 9F E3 81 A1 E2 85 80

"input" means that this string in hex is in "tags.xml" as UTF-8 and is tagged using MKVmerge.
"output" shows how the string will be broken. This can be observed by
Mkvextract tags "tagged.mkv" > debug.utf8
The problem will not be fixed even if you use UTF-16 as input,
but the same string may not be broken in some cases, depending on the file to be tagged.

Mosu

28th August 2003, 10:29

Originally posted by Liisachan
Thanks again for your good job.

I don't like to nag again and again, but let me report other bugs,

Believe me, you're not nagging. In fact you're every programmer's dream of a user. Your bug reports are detailed, you always provide sample files to reproduce the bugs, and you're more than polite. What else could I ask for? :)

(1) I have just found that Mkvmerge doesn't like U+0800 or higher.
...
(3) Feature Request: accept chapters.txt in UTF-8 so that any languages can be typed on any PC...

I've addressed (1) and (3) and uploaded the following: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.6.4-20030828-1.zip

Please test this version. Maybe it also fixes (2), but so far I haven't looked at it.

(3): The new option is called '--chapter-encoding' but works just like you assumed. Please read the new mkvmerge.html which is part of the ZIP linked to above. It describes both the new options and how things are handled in the section "CHAPTERS".

Liisachan

28th August 2003, 11:56

Apparently (1) has been fixed.

(2) still remains. In case where the strings will be broken by official 0.6.4 , the new beta will just die saying

'die' called: cstrutf8_to_UTFstring: Invalid UTF-8 sequence encountered. Please
contact moritz@bunkus.org and request that he implements a better UTF-8 parser.

DBG> dumping time info:
DBG> dumping packetzer info:
pure virtual method called

abnormal program termination

I cannot make a small demo for this yet, but this problem seems to be subtle. For the same in.mkv,
mkvmerge -o out.mkv --tags 1:_tags.xml --language 1:jpn --language 2:jpn --language 3:eng --language 4:jpn in.mkv
does work with both versions, while
mkvmerge -o out.mkv --tags 1:_tags.xml --language 1:jpn --language 2:jpn --language 3:eng --language 4:jpn --language 5:dan in.mkv
does not work, resulting a broken tag string, or (the newest beta build will) dies.

Yes, the same MKV (20 tracks) + the same _tags.xml
if you put "--language 5:dan" it'll die. Weird.

This is _tags.xml

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE Tags SYSTEM "matroskatags.dtd">
<Tags>
<Tag>
<General>
<Subject>######</Subject>
</General>
</Tag>
</Tags>

###### = E3 81 9F E3 81 A1 (i.e. U+305F U+3061 or if your browser can show Japanese, たち ;) )
if _tags.xml does not contain Unicode characters, everything seems fine, even for this insane sample that has 20 tracks
:confused:

Mosu

28th August 2003, 12:13

Originally posted by Liisachan
Apparently (1) has been fixed.

Good.

(2) still remains.
...
I cannot make a small demo for this yet, but this problem seems to be subtle. For the same in.mkv,
mkvmerge -o out.mkv --tags 1:_tags.xml --language 1:jpn --language 2:jpn --language 3:eng --language 4:jpn in.mkv
does work with both versions, while
mkvmerge -o out.mkv --tags 1:_tags.xml --language 1:jpn --language 2:jpn --language 3:eng --language 4:jpn --language 5:dan in.mkv
does not work, resulting a broken tag string, or (the newest beta build will) dies.

Please upload the first 2megs or so of in.mkv somewhere - it should be enough to trigger the bug here as the tag parsing is done before the complete file is copied.

Thanks.

Liisachan

28th August 2003, 12:40

demo clip updated

sample2.zip (http://www.ak.wakwak.com/~f14g/sample2.zip)

mkvmerge -o out1.mkv --tags 1:tags-no-unicode.xml --language 1:jpn --language 2:jpn --language 3:eng --language 4:jpn --language 5:dan tmp.mkv

=OK

mkvmerge -o out2.mkv --tags 1:tags-unicode.xml --language 1:jpn --language 2:jpn --language 3:eng --language 4:jpn --language 5:dan tmp.mkv

= Die

PS.
Something must be very strange.
demo.bat in the zip is ok if I put it in
"C:\1234567890123456789012345\"
and, the problem appears if I put it in
"C:\123456789012345678901234\"
In other words, I can avoid this problem if the path is long...something very subtle must be happening, i think
:confused: :confused: :confused:

Mosu

28th August 2003, 18:41

Originally posted by Liisachan
demo clip updated

Thanks. I think I've fixed the bug. The problem was that the 'isspace()' function that I used for stripping leading and trailing white spaces from tags works differently on Windows than it does on Linux. On Windows it considered some of the perfectly valid UTF-8 characters to be white spaces as well...

I've fixed that by using 'isblank()' which only considers spaces and tab characters to be white spaces.

Please download http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.6.4-20030828-2.zip and test.

Thanks again.

Liisachan

29th August 2003, 00:01

Beautiful:) :) :)

Fixed! Thank you so much.
I was thinking this problem would be very subtle and complicated, but now it s gone!!! yay!

Mosu

29th August 2003, 08:59

Right after the release of 0.6.4 some bugs were discovered. I've fixed them, and I think that this warrants a new release. Hopefully the last bug fix release for the next couple of weeks ;)

The links, as always:
http://www.bunkus.org/videotools/mkvtoolnix/
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-0.6.5.zip

I suggest that all people who either use Unicode or RealMedia files upgrade to this release. Ok, the others should do that as well ;)

Please read mkvmerge.html, especially the section about CHAPTERS, if you want to use non-ASCII characters in chapter names! Basically it's now handled in the same way as SRT subtitles are handled. But again, please read that section :)

Here's the ChangeLog:

2003-08-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: On Windows the 'isspace()' function used to trim leading and trailing white spaces from tags considered some parts of valid UTF-8 character sequences to be white spaces as well. Fixed by replacing 'isspace()' with 'isblank()'. Reported by Liisachan.
* mkvmerge: Support for chosing the charset and language used in simple chapter files. Suggestion by Liisachan.
* Rewrote the UTF-8 conversion routines. They should now handle U+8000 characters correctly. Reported by Liisachan.
* mkvmerge: Real reader: For RV40 the actual dimensions were also used for the aspect ratio/display dimensions. This has been fixed: the actual dimensions are used for PixelWidth/PixelHeight, the dimensions stored in the RM container are used for the aspect ratio/DisplayWidth & DisplayHeight. Reported by Karl Lillevold.

Sirber

29th August 2003, 21:46

Nice!

Thanks for for your great work Mosu :D.

Kurtnoise

30th August 2003, 15:06

Hi !!

I think, there is a little mistake in mkvmerge.html for Subtitles : −T, −−nosubs
Don’t copy any subtitle track from this file.

I've tried -T with the last version 0.6.5 but mkvmerge bug....:( With -S no problem...Anybody I've noticed that ??

Mosu

30th August 2003, 15:13

Originally posted by Kurtnoise13
Hi !!

I think, there is a little mistake in mkvmerge.html for Subtitles :

I've tried -T with the last version 0.6.5 but mkvmerge bug....:( With -S no problem...Anybody I've noticed that ??

Yeah... Left-over from the old ogmtools documentation. Thanks. Btw, if you run mkvmerge without parameters (or with --help) then you'll get the short version of all command line parameters. This version should always be up to date even if mkvmerge.html is lagging behind.

Sirber

1st September 2003, 19:53

hi

mkvmerge can't mix correctly subs in SRT format that incldues "é" and other french characters. In SSA mode, the subs aren't displayed.

[edit]

SRT in UFT8 format seems to work.

Mosu

1st September 2003, 20:45

Originally posted by Sirber
hi

mkvmerge can't mix correctly subs in SRT format that incldues "é" and other french characters. In SSA mode, the subs aren't displayed.

[edit]

SRT in UFT8 format seems to work.

Use --sub-charset and set the appropriate codepage for the SRT subs.

Sirber

1st September 2003, 20:48

I have a question: I have a movie like this:

AVI(Video, Audio)
SRT(English subs)
SRT(French subs)

To set subs language I have to use this commandlines right?, cause on player I get English / English...

--language 2:eng --language 3:fre

Mosu

1st September 2003, 20:53

Originally posted by Sirber
I have a question: I have a movie like this:

AVI(Video, Audio)
SRT(English subs)
SRT(French subs)

To set subs language I have to use this commandlines right?, cause on player I get English / English...

--language 2:eng --language 3:fre

That's normally correct - but the id (the number before :eng or :fre) might be different depending on the sources.

Example 1: One AVI and two external SRT files. Here the ids are 0 and 0:

mkvmerge -o output.mkv theavi.avi --language 0:eng first.srt --language 0:fre second.srt

Example 2: One Matroska file with four tracks (video, audio, subs1, subs2). Here the IDs are normally 3 and 4, but you have to check with "mkvmerge -i source.mkv".

mkvmerge -o output.mkv --language 3:eng --language 4:fre source.mkv

Please read mkvmerge.html carefully, especially the section about track selection.

Sirber

1st September 2003, 20:57

thanks!

[edit]

Working :D

Mosu

1st September 2003, 21:01

Originally posted by Sirber
Working :D

Great :)

Sirber

1st September 2003, 21:36

Mosu

1st September 2003, 21:46

Originally posted by Sirber
*** Crash report *** :D

Y:\Storage\Films\mkv>mkvextract.exe tracks ..\Phone.mkv 1:vid.avi 2:aud.mp3 3:english.srt 4:french.srt
Extracting track ID 1 to an AVI file 'vid.avi'.
Extracting track ID 2 to a MP3 file 'aud.mp3'.
Extracting track ID 3 to a SRT file 'english.srt'.
Extracting track ID 4 to a SRT file 'french.srt'.
Progress: 0%

I got a popup saying I got a crash.

I can't say much about this without a sample file. But as the progress is still at 0% I hope that the crash occured right at the beginning. So could you please make a short sample file, e.g. the copy the first 5megs of the file, and upload it to my FTP server? Address mosu.no-ip.com, username 'upload', password 'only'.

Thanks.

Sirber

1st September 2003, 21:56

k

I'll soon.

[edit]

upping 46 sec, ~5 MB.

alx

4th September 2003, 09:36

Hi Mosu, my name is Alejandro, i´m a newbie into the matroska world and RV9, but i´m starting with my first steps in this "planet" ;)
First, i would like to thank you for all your work in this area, and apologize for my poor english and knowledge , but, my mother tongue is spanish and my experience in this area is near 0%.
I downloaded your last version of mkvmerge 0.6.5 with it´s latest runtime libraries and start reading its help with some files at hand to do some testing............."1.rmvb", "1.mp3", "2.mp3" and "1.srt".
Well, my first try was obvious......
mkvmerge -o "m:\test.mkv" "g:\testdir\1.rmvb" "g:\testdir\1.mp3"
and how this works fine (i could play test.mkv with MPC 6.4.6.3) then i tried......
mkvmerge -o "m:\test.mkv" "g:\testdir\1.rmvb" "g:\testdir\1.mp3" "g:\testdir\2.mp3" with the resulting test.mkv with 2 audio streams into it........again, plays ok with MPC.

The problem is when i tried to do the same, but this time adding the .srt file........the final test.mkv crashes MPC......i tried with different versions of MPC from 6.4.5.9 to the latest with same result and don´t know why. I guess the problem is with .srt file because all others tests were fine.

If i rename "1.srt" to "test.srt" and put in the same dir as the "test.mkv" (1.rmvb+1.mp3 o 1.rmvb+1.mp3+2.mp3) MPC plays OK and show the subtitles, but when i try to put subtitles inside the matroska container, MPC CRASH!

I made the .srt file using Subrip 1.17.1, setting the output format to "Subrip .srt"....here is part of the "1.srt" file:

1
00:00:40,400 --> 00:00:46,300
-¡Vamos, muchachos!
-¡Tenemos que salvar a Olivia!

2
00:06:09,200 --> 00:06:16,000
¡Salve, Roma! Victoriosa...
y vestida de luto.

3
00:06:17,500 --> 00:06:20,400
Ya libre de su pesada carga

4
00:06:20,500 --> 00:06:25,900
la nave regresa
a la bahía desde la cual partió.

and of course i tried to convert it to .ssa to do another test, but the results were bad again.

I downloaded MKVMERGE GUI 0.6.2-r2 and same results....(first try the old mkvmerge version inside this package and after that, tried replacing it with 0.6.5)
Of course i am doing something really wrong, because all other user in this channel can add subtitles to its matroska files, but i can´t. The question is WHAT I AM DOING WRONG???...

Any help would be apreciated.
Thanks again
Alejandro.

hofmetzger

4th September 2003, 09:50

you could try to open the files with notepad and save them as utf-8 instead of ansi.

and you are running 2k/xp right? if not you should think of an upgrade, caus most tools are running rather bad on Win9x machines (bad unicode support)...

Mosu

15th September 2003, 23:31

Hi guys,

here it is - the brand new mkvtoolnix release 0.7.0. A lot of things
have changed since 0.6.6.1, and here are the highlights:

- new: QuickTime/MP4 support with AAC-in-MP4 (including AAC+/HE-AAC) (note that you cannot playback QuickTime based videos, e.g. Sorenson, on Windows at the moment, but mplayer can).
- new: Full featured GUI as a replacement for the discontinued mmg by Florian Wagner.
- new: Full chapter support with XML chapter files.
- bugfixes: mkvmerge's Matroska reader has been improved, especially when splitting is active.
- new-but-deactivated: VobSub handler. Has to be specified, but it'll come soon (including compression)!

Some notes about the GUI. Florian Wagner, the creator of the original mmg (mkvmerge GUI), simply disappeared about a month ago. He didn't show up on IRC anymore, and his email server has been offline since. We don't think that he'll be back anytime soon. I've therefore decided to re-implement a GUI for mkvmerge, this time as an integral part of the mkvtoolnix package. Unfortunately I'm not a really good GUI designer, so there are definitely things to improve. I'll be happy about feedback :)

The links:
http://www.bunkus.org/videotools/mkvtoolnix/
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-0.7.0.rar

A lot of new code went into this release, so I expect bugs to show up. Keep the reports coming :)

Here's the complete ChangeLog since the last release:

2003-09-16 Moritz Bunkus <moritz@bunkus.org>
* Released v0.7.0.
* mkvextract: Add an UTF-8 BOM to extracted SSA/ASS and SRT subtitle files. Print warnings for missing durations for text subtitle tracks.

2003-09-14 Moritz Bunkus <moritz@bunkus.org>
* Added a complete GUI for mkvmerge, mkvmergeGUI (mmg) based on the work of Florian Wagner.

2003-09-12 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Support for setting the track names.
* mkvmerge: For Matroska source files: If the source contains chapters then these are kept unless the user specified chapters with --chapters.

2003-09-11 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Implemented an experimental VobSub reader and packetizer. No specs exist for these yet, though.
* mkvmerge: Improved the support for Matroska files with tracks with big gaps between entries, e.g. subtitle tracks whose entries are a minute or more apart.
* mkvmerge: When splitting is active and the source is a Matroska file then splitpoints were borked, and the first pass was slow as your average mole.
* mkvmerge: The track UIDs are kept when reading Matroska files even when splitting is active.

2003-09-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Added a QuickTime/MP4 reader. Can handle several QuickTime video and QuickTime audio formats as well as AAC (both 'normal' AAC and SBR AAC).

2003-09-08 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: DisplayWidth and DisplayHeight are kept intact when reading from a Matroska file but can be overridden with --aspect-ratio.

2003-08-30 Moritz Bunkus <moritz@bunkus.org>
* Wrote documentation, XML examples and the DTD for the XML chapter files.
* mkvinfo: Rewrote mkvinfo to use libebml's Read() function instead of manually reading each and every element.
* mkvmerge: Added support for XML based chapter files.

Bye :)

--
==> Ciao, Mosu (Moritz Bunkus)

bond

16th September 2003, 10:30

great!

he-aac muxing from mp4 works great (no need to tick the sbr option)

bond

16th September 2003, 10:58

mkvmerge gui seems to have problems detecting realaudio streams in mkv:
i muxed wmv9, he-aac and ra into a file (yeah baby :D ) -> worked great
if i load this file again in mkvmerge gui only wmv9 and he-aac are listed under "tracks"...
edit: i also created a "ra only" mka file and when i open it, it says "input file doesnt contain any tracks"

btw. it would be nice if there could be some big "mux" button somewhere in the gui (not to hide this option under "muxing")

Mosu

16th September 2003, 11:22

Originally posted by bond
mkvmerge gui seems to have problems detecting realaudio streams in mkv:
...

Sounds like a bug/missing feature. I'll investigate.

btw. it would be nice if there could be some big "mux" button somewhere in the gui (not to hide this option under "muxing")

Just hit Ctrl-R or select the menu. Come on, that's only one mouse click more ;)

ssjkakaroto

16th September 2003, 11:28

thx for the upd8 mosu :cool:

Dams

16th September 2003, 12:52

I'll test it.

Thk u for your support and developement, Mosu, of this nice GUI.

Best regards

Mosu

16th September 2003, 20:22

Originally posted by bond
mkvmerge gui seems to have problems detecting realaudio streams in mkv:
i muxed wmv9, he-aac and ra into a file (yeah baby :D ) -> worked great
if i load this file again in mkvmerge gui only wmv9 and he-aac are listed under "tracks"...
edit: i also created a "ra only" mka file and when i open it, it says "input file doesnt contain any tracks"

Ok, I've implemented RA-from-Matroska muxing. While I was at it I removed a serious bug muxing RV-from-Matroska. Please test this version and report what you find: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.7.0pre-20030916-1.rar

Thanks :)

Teegedeck

16th September 2003, 20:28

Congratulations on that new version!

Finally it can extract from an mkv just fine. Some maybe-issues:

- the aspect-ratio I enter in mmg is ignored by Gabest's latest splitter (no automatic resizing via overlay). Is this expected?
- the aspect-ratio information presented in matroska-props is that of the original, VDubMod-produced, mkv-contained video-stream, not the ratio that I entered in mmg while muxing. That expected, too?
- related: changing the display size in the props doesn't have any effect.
Edit: - the attachment-button doesn't seem to work for me

Great GUI, and mp4 parsing for HE AAC is something I've waited for!!

Edit: Ah, I'll give that new version you linked to a try.
Edit: To no avail. And trying an avi as input didn't change that.

bond

16th September 2003, 20:30

seems to work without a problem :)

Kurtnoise

16th September 2003, 22:24

Originally posted by bond
seems to work without a problem :)

yeaah...for me too ;) Thanks Mosu.

Mosu

16th September 2003, 22:29

Originally posted by Teegedeck
Congratulations on that new version!

Finally it can extract from an mkv just fine. Some maybe-issues:

- the aspect-ratio I enter in mmg is ignored by Gabest's latest splitter (no automatic resizing via overlay). Is this expected?
- the aspect-ratio information presented in matroska-props is that of the original, VDubMod-produced, mkv-contained video-stream, not the ratio that I entered in mmg while muxing. That expected, too?

These two are due to a bug in the GUI. I've moved the aspect ratio and FourCC input fields to the track settings on the input tab (that's where they belong!) since they're not global at all.

Please download and test this version: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.7.0pre-20030916-2.rar

- related: changing the display size in the props doesn't have any effect.

Which props? File properties? That piece of software is not from me, so I can't comment on it.

Edit: - the attachment-button doesn't seem to work for me

Please give me some more details. What are you doing exactly, and what does happen? Does mkvmerge print errors/warnings?

Teegedeck

16th September 2003, 22:43

Thanks for your immediate response, as always. :)

The attachment button just doesn't let any dialogue pop up, no error message or anything. The strangest thing is, it worked once. I've tried highlighting different tracks before going to the attachment tab, not highlighting anything, quite ignorant about how the GUI works as I am.

For your question, yes; I did mean the file properties.

On a sidenote: Ahhh, finally HE AAC; you can't imagine how good that feels on 1-CD-encodes!:cool:

Edit: Unfortunately, the update doesn't seem to do the trick, resizing-wise. Perhaps this would be Gabest's job, not yours.

ChristianHJW

17th September 2003, 00:10

Originally posted by Teegedeck Edit: Unfortunately, the update doesn't seem to do the trick, resizing-wise. Perhaps this would be Gabest's job, not yours. Gabest matroskasplitter will not be able to change the AR by itself, it always needs ffdshow-alpha from 23rd may for that, and 'use overlay' ticked !

Sirber

17th September 2003, 00:28

Originally posted by Teegedeck
On a sidenote: Ahhh, finally HE AAC; you can't imagine how good that feels on 1-CD-encodes!:cool:HE-AAC quality wasn't very good in my tests. High Freq were noisy...

Ramirez

17th September 2003, 02:17

Ha! Finally my Hebrew SSA subtitles are shown up correctly, Great work Mosu, thx! :)

Edit: Attachments works too, nice!

Liisachan

17th September 2003, 02:39

Originally posted by Ramirez
Ha! Finally my Hebrew SSA subtitles are shown up correctly, Great work Mosu, thx! :) Do you have any problems with 0.6.x?
I think Hebrew SSAs (in utf-16) were ok even with MKVmerge 0.6.3

Teegedeck

17th September 2003, 07:53

Originally posted by ChristianHJW
Gabest matroskasplitter will not be able to change the AR by itself, it always needs ffdshow-alpha from 23rd may for that, and 'use overlay' ticked !

Come on, for how stupid do you take me, Christian?!

Originally posted by Sirber
HE-AAC quality wasn't very good in my tests. High Freq were noisy...
Nonsense. Excuse me, but it is. Utter nonsense. Neither me nor anyone on hydrogenaudio.org found that. Go partake in the 64 kbps listening-test and identify those 'noisy' HE AAC-samples.

Edit: OK, the problem is solved, but not the mystery. The situation was like this: mkvs produced with mkvmerge 0.6x resized perfectly in mediaplayer classic while those produced with 0.7x didn't - also in mediaplayer classic. Now I configured MPC explitly to use the overlay mixer and not 'system default' and since then it does resize the 0.7-produced mkvs, too. Something must have triggered MPC behaving differently to 'old' and 'new' mkvs, but what?

I've also tried BSPlayer now, and it doesn't have any problems.

Ramirez

18th September 2003, 02:44

Originally posted by Liisachan
Do you have any problems with 0.6.x?
I think Hebrew SSAs (in utf-16) were ok even with MKVmerge 0.6.3

Hi :),in fact none of the 6.x versions worked for me (with SSA) I've always got either unreadable text (jebrish) or the subs simply wasn't displayed, dunno really what could be the problem (same SSA subs muxed in vdub played just fine)

Here is a one of the SSA subs which weren't work for me earlier ; maybe you can dig some info out of this? :)

Title: The Green Mile
Original Script: Hebrew
ScriptType: v4.00

[V4 Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, TertiaryColour, BackColour, Bold, Italic, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, AlphaLevel, Encoding
Style:Style1,Arial,18,8454143,8454143,8454143,0,0,0,1,2,2,2,30,30,25,0,177

[Events]
Format: Marked, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text

ChristianHJW

18th September 2003, 17:40

Originally posted by Teegedeck Come on, for how stupid do you take me, Christian?!

/me hides .... :scared: ....

Did you check with the matroska shell extension if the display size was set properly in the files ?

Teegedeck

19th September 2003, 00:00

;) Yes, as I wrote above the display size of the original mkv (the video-track) was maintained although I set a different aspect in mkvmerge. But I haven't checked whether this still is the case with Mosu's latest version. The automatic resizing with these new files just didn't seem to work in (mediaplayer classic), whether I changed the value in the matroska-props or in the muxer, whereas at the same time it worked for files produced with mkvmerge 6.x-produced files.

But as written in my preceding post, I've found out that it always worked in BSplayer and now also works in MPC, again, after I chose the overlay mixer vor video-output in the MPC-prefs. Why MPC acted differently on old and new mkvs eludes me.

BTW, how is aspect stored in mkv, or more precisely, why are display sizes shown in pixels when I chose a floating-point value like 1.85 in mkvmerge?

(And just to keep you entertained, ATM I curiously eyeing how mkvs run at double or triple speed when put onto an XCD and played back with latest MPC's internal XCD-splitter:devil:.)

Mosu

19th September 2003, 11:11

Originally posted by Teegedeck
But I haven't checked whether this still is the case with Mosu's latest version.

The latest version should have fixed this issue: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.7.0pre-20030916-2.rar

BTW, how is aspect stored in mkv, or more precisely, why are display sizes shown in pixels when I chose a floating-point value like 1.85 in mkvmerge?

Matroska does not know an aspect ration itself. It knows four attributes per video track: PixelWidth, PixelHeight, DisplayWidth and DisplayHeight. Pixel* are the dimensions of the encoded picture as the encoder/decoder sees them. Display* tells the player which resolution it should prefer when displaying the video, or at least which aspect ratio it should try to use (or at least select by default. The user must have the choice to change that, of course). The aspect ratio is simply DisplayWidth/DisplayHeight.

mkvmerge does not accept these values independently at the moment. This is due to the fact that most people just want to specify an aspect ratio and don't want to mess around with mathematics (e.g. calculating the needed Display* values themselves). mkvmerge will automatically calculate the Display* values depending on the original resolution and the aspect ratio given on the command line. It will always scale the resolution UP, never down. If someone actually wanted to set DisplayWidth and DisplayHeight himself then I can easily add options for that (which are of course mutually exclusive with the --aspect-ratio option).

hulkenstrong

21st September 2003, 20:54

How did ppl get AAC+ working?

1: I captured music video from tv.
2: Encoded video to xvid and audio to wav then used nero to produce AAC+ (used vbr streaming present)
3: First tried mkvmerge without gui. Then used gui also tried with AAC+ ticked and without.

Resulst the video freezez on first frame if i skip a few it plays but still only half the sample rate is displayed in coreaacdc 1.0b7.

What am I doing wrong or do I need to update something?

CoreAAC 1.ob7
mkvtoolnix-0.7.0
mkxds-v0.5.0
tried in WMP 6.4 and Bsplayer 086.500 both behave the same way.

Teegedeck

21st September 2003, 22:13

whoops, forgot to thank you for your explanation, Mosu! :)

[Toff]

22nd September 2003, 00:19

Originally posted by hulkenstrong
How did ppl get AAC+ working?
...
What am I doing wrong or do I need to update something?
...
CoreAAC 1.ob7
mkvtoolnix-0.7.0
mkxds-v0.5.0
You need to use Gabest's last (>=1.0.1.7) Matrosk Splitter : http://sourceforge.net/projects/guliverkli/

To create your file the best way is to use mkvmerge (>=0.7.0) and the mp4 file.
(the old way was to use .aac with the −−aac−is−sbr <TrackID> switch)

hulkenstrong

22nd September 2003, 05:24

Thanks for the information. Now its playing correct. Still a bit confused havent seen matroska splitter mentioned anywhere (and well i did read the other 7 pages quickly in this tread, must have missed it).

nanga parbat

24th September 2003, 14:38

hello,

as i have not found any working configuration, i will post that here.
i've been trying to use the ar flag with mkvtools(0.7.0pre-20030916-2), created a video only mkv with ar set to 1.825.
mkvinfo reports:
.
.
.
+ A track
+ Track number: 1
+ Track UID: 2791319198
+ Track type: video
+ MinCache: 1
+ Codec ID: V_MS/VFW/FOURCC
+ CodecPrivate, length 40 (FourCC: XVID, 0x44495658)
+ MaxCache: 1
+ Default duration: 40.040ms (24.975 fps for a video track)
+ Video track
+ Pixel width: 560
+ Pixel height: 368
+ Display width: 670
+ Display height: 368
+ Lacing flag: 0
+ Cluster

ar seems to be properly set.
now for playback: i have tried all combinations (i could imagine) of mpc(6465) internal matroska splitter, gabest MatroskaSplitter(20030829), xviddec alone, ffdshow(20030816)/xviddec, ffdshow/libavcodec and setting overlay mixer in mpc...
none of that combinations recognized set ar!
so, is this feature broken or have i overseen one step?
i'd be grateful if anyone could give me a hint.

thanks in advance, nanga.

bond

24th September 2003, 15:32

try ticking the overlay mixer option in ffdshow (uses overlay mixer2 not overlay mixer like mpc)...

nanga parbat

25th September 2003, 08:34

i have found two possible combinations that put out correct ar:

1) overlay mixer in ffdshow selected and video mixing renderer 9 (windowed) in mpc - video is displayed, but looks terrible, like with a very low resolution.

2) overlay mixer in ffdshow and video mixing renderer 9 (renderless) in mpc - ar correct, but no video (only some greenish gibber)

so both cases are kinda 'unpleasant' ;) to look at, either low res picture or no picture at all...

i don't know if that is a problem of my system or so, normal video displays well.

guidance!

P.S: using mpc internal splitter or gabest splitter doesn't behave any different here, as well as decoding with libavcodec or xvid (via ffdshow).

Liisachan

28th September 2003, 13:08

Originally posted by Ramirez
Hi :),in fact none of the 6.x versions worked for me (with SSA) I've always got either unreadable text (jebrish) or the subs simply wasn't displayed, dunno really what could be the problem (same SSA subs muxed in vdub played just fine)

Here is a one of the SSA subs which weren't work for me earlier ; maybe you can dig some info out of this? :)
Sorry no Idea, but I suppose the encoding (charset) was wrong.
I made a clip with Hebrew subs even when mkvmerge was 0.5.0 with GraphEdit, and with mkvmerge 0.6.x, using UTF-16 SSA.
Did you try UTF-* ???

As a side note, your SSA has Encoding=177 and Ive just found specifying this param is critically important for Win98....
If you make your SSA in UTF-* then everything works fine for win 2x/xp with Encoding=0. But if encoding=0 and if the codepage is not "Windows 1252" Code Page (English, French, German, etc.), then the resulted file doesnt play properly on Win98 (tho ok on WinXP/2000) even tho it is stored in UTF-8 and technically "Encoding" is seamless...

Mosu

3rd October 2003, 11:02

Hey ho,

after looking at my webserver's logs for the last couple of days and seeing that the latest pre-version had about twice as many downloads as the latest official release (0.7.0) I decided it was time to release a new thingy.

No, not really - but now I've finished all that I wanted to finish before releasing 0.7.1. It is a combination of bug fixes and new features, most prominent among them the new chapter editor that has been included in the GUI.

First the URLs:
http://www.bunkus.org/videotools/mkvtoolnix/
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-0.7.1.rar

Please read the new mkvmerge-gui.html that I've created. It is a first shot and is not really a good guide, but it'll explain some things that I don't want to repeat here (e.g. about the capabilities of the chapter editor).

I've changed some critical code in the heart of the muxer which has not been tested excessively. I've done my best to test all combinations of the changed options/new options, but I'm really looking forward to your feedback - especially to feedback about the chapter editor and mmg's new guide.

(Criticism like 'hey you don't know squat about writing good documentation' is not helpful - I already know that ;))

Anyway, here's the ChangeLog since the last release:

--------------------------
2003-10-03 Moritz Bunkus <moritz@bunkus.org>
* Released v0.7.1.
* Added a guide for mmg including some pictures.

2003-10-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Changed the lacing strategy again. New defaults are NOT to write duration elements for all blocks, NOT to use time slices and to USE lacing for most audio tracks. This will save some space. The downside is that the laced frames 'lose' their precise timecode information. Current demuxers don't care and will work nevertheless. More sophisticated applications that make use of these advanced information (duration elements, time slices) are not available at the moment. All these options can be toggled by the user with the new/modified options --disable-lacing, --enable-durations and --enable-timeslices.

2003-09-29 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Attachments are kept when reading Matroska files.

2003-09-28 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: Added a (nearly) full-featured chapter editor.

2003-09-26 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: XML chapters were not parsed correctly.

2003-09-24 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix/new feature: Rewrote the complete MP3 handling. Now files with ID3 tags (both v1 and v2) are handled correctly. All MPEG-1 audio files (all layers) should be handled correctly now.

2003-09-23 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: new feature: Support for extract HE-AAC tracks to .aac files. Bug fix: Missing elements (default values) are handled correctly for audio tracks.

2003-09-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bugfix: If attachments were given with path components then the path component wasn't discarded for the attachment's description on Windows (normally only the file name should be used as the attachment's name).

* mmg: Fixed wrong order of the options --chapters, --chapter-language and --chapter-charset.

2003-09-17 Moritz Bunkus <moritz@bunkus.org>
* mmg: Added a lot of checks on the data given by the user so that invalid data is reported by mmg and not by mkvmerge.
* mmg: Made the app a GUI app which gets rid of the "DOS box" on Windows.

2003-09-16 Moritz Bunkus <moritz@bunkus.org>
* mmg: bugfix: Moved the aspect ratio and FourCC input fields from the global tab to the input tab where they belong to.
* mkvmerge: new feature: RealAudio can be read from Matroska files.
* mkvmerge: bugfix: RealVideo was not read correctly from Matroska files.
* mkvmerge: bugfix: The SRT reader would abort if there was more than one empty line between subtitle entries line.
* mkvextract: bugfix: Proper BOMs are written according to the desired charset when extracting text subtitles.

ssjkakaroto

3rd October 2003, 22:30

thx for the upd8 mosu :)

HomiE FR

4th October 2003, 05:56

Thanks Mosu. I'll test it and report any bug I can find (even though I usually don't find any ;) ).

Yuuhi

5th October 2003, 09:04

I've tried the last versions, especially the chapter editorn and works great!!! TNX mosu!!! ;)

Mosu

5th October 2003, 09:42

Thanks for all the praise. Hmm... still no bug reports? Damn! :)

unplugged

5th October 2003, 13:23

Man, your work really rocks, mkvtoolix is so rich and powerful that matroska will gain much more popularity thanks to its features already applicable!
Is there one thing that mkvmerge can't do??? :p

Hope you and others will have time to work together with VdubMod team to co-improve entire the tools.

DKDIB

5th October 2003, 21:47

I noticed a couple of problems.
___

1- When I import a .mkv file with multiple audio streams, only the last one will be in the new Matrsoka (and I selected all strems, of course ;) ).

I did some tests using Matroskas with the follow audio streams:
mp3 128 + mp3 192;
mp3 192 + mp3 128;
mp3 128 + mp3 192 + mp3 128;
Vorbis 155 + Vorbis 127;
Vorbis 155 + mp3 128;
mp3 192 + Vorbis 127.

2- Even if I selected the default flag on an audio stream, there' s no default audio track in the output file (I checked it using Matroska Shell Extension 1.6).

It' ll happen with any kind of audio stream.
___

Sorry for my bad english. :(

Mosu

5th October 2003, 22:33

Originally posted by DKDIB
1- When I import a .mkv file with multiple audio streams, only the last one will be in the new Matrsoka (and I selected all strems, of course ;) ).

Ah yes, that was a bug in the GUI (how the GUI created the command line for mkvmerge, to be precise). I've already fixed it, and the next release (coming tomorrow, I think ;)) will contain this fix.

2- Even if I selected the default flag on an audio stream, there' s no default audio track in the output file (I checked it using Matroska Shell Extension 1.6).

This is a bug in the Shell Extension. The problem is that Matroska elements whose value is equal to their default value are not written to the file. For the 'default track' flag the value 'true' is the default. The result: Only for those tracks whose default flag is not set the defaultflag is actually written with a value of 'false'.

Now the Shell Extension does not yet handle these default values properly and thinks that, if the element is absent (for the 'true' case), that it is 'false'. In the other cases the element IS present but set to false. So for all tracks it'll show 'false'.

If you want to make sure that the default track is written correctly you should use mkvinfo. It will NOT show any 'Default Track' entry for the default tracks and 'Default Track: false' for all the other tracks of a kind.

Thanks for the report.

Mosu

5th October 2003, 22:37

Originally posted by unplugged
Man, your work really rocks, mkvtoolix is so rich and powerful that matroska will gain much more popularity thanks to its features already applicable!
Is there one thing that mkvmerge can't do??? :p

Thanks for the praise :) But yes, there are still things that mkvmerge does not handle. The most important one (in my opinion) is concatenating files ( = appending file 1 to file 2). At the moment only Avimux GUI can do that properly.

Among the other things I'd say are important is 'proper' support for B-Frames, reading MPEG4 video from MP4 files aaaaaaaand.... ummm... There are more things, most of them minor, though :)

Atamido

5th October 2003, 22:46

Originally posted by Mosu
The most important one (in my opinion) is concatenating files ( = appending file 1 to file 2). At the moment only Avimux GUI can do that properly.
Hey, the Matroska Stream Editor (http://forum.doom9.org/showthread.php?s=&threadid=62204) can do that too. :)

DKDIB

5th October 2003, 23:21

Mosu wrote:
> I've already fixed it [...]
> [...]
> If you want to make sure that the default track is written
> correctly you should use mkvinfo. [...]

Thanks a lot (or "arimicio") Mosu!!! :D

raistlin2k

6th October 2003, 15:16

Is it possible to add Vobsub-subs as attachments?
Do we have to wait for an updated vobsub-playback-filter for that to work? Or is it already working?

Thanks
Raist

Dragon Shenron

8th October 2003, 11:25

I tried to mux and split a 2h 15min movie and I experienced a problem. 1st pass went well, but after muxing the 1st part of the movie (during the 2nd pass), the 2nd part of the movie woudn't mux, the GUI just reported an error and the .mkv file was just 1.11 KB big (the 1st part works well). The log doesn't mention much, just that it opened the 2nd mkv for writing and that's all (I don't have the log anymore, I deleted it :( )
The inputs were:
1. avi -> XviD
2. ac3 -> 384 Kbps
3. srt subtitle
4. ogg type chapters

Splitting was set to size 705M.
0.7.0 version doesn't have this problem, just 0.7.1.

Mosu

8th October 2003, 11:39

Originally posted by Dragon Shenron
I tried to mux and split a 2h 15min movie and I experienced a problem. ...
0.7.0 version doesn't have this problem, just 0.7.1.

Thanks for the bug report. I'll investigate. This is probably due to the muxer changes I described earlier. Could you please re-mux, save the log and send it to me? moritz@bunkus.org

Thanks

Mosu

8th October 2003, 11:41

Originally posted by raistlin2k
Is it possible to add Vobsub-subs as attachments?
Do we have to wait for an updated vobsub-playback-filter for that to work? Or is it already working?

Thanks
Raist

VobSub-as-attachments will probably not work anytime soon, because we want to have 'proper' VobSub muxing instead (VobSub just being another track just like any other text subtitle track). Both would/will require changes to the VobSub playback filter, and Gabest seems to busy like never before, so I cannot give you a timeframe. Sorry.

KpeX

11th October 2003, 18:14

I was unable to mux 1 AC3 and 1 avi with mkvmerge 0.7.1, AC3 was a DVD source demuxed with besweet [ i.e. besweet -core ( -input "besweet.lst" -substream 0x80 -payload -output "file.ac3" ) -ota ( -d auto ) ], error message was 'invalid mp3 header value for the version' (no idea what that means). My commandline was something like "mkvmerge -o "output.mkv" "movie.avi" "soundtrack.ac3". The AC3 muxes fine with VdubMod, and I could demux the AC3 from the VdubMod-muxed MKV file with MKVExtract just fine.

Chez_Wimpy

12th October 2003, 06:59

So far I have been able to mux speex audio streams that were encoded with wav headers, however I would like to add them without the extra step. Is it possible to add support for muxing .spx directly to mkvtoolnix?

Thanks a lot. Great tool, even more so for CLI phobic people like me!

-CTB

Mosu

12th October 2003, 17:06

Originally posted by KpeX
I was unable to mux 1 AC3 and 1 avi with mkvmerge 0.7.1,
....

Thanks for the report. Could you please download http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.7.2-pre1.rar and see if it fixes your problem?

Thanks.

KpeX

12th October 2003, 19:18

Originally posted by Mosu
Could you please download http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.7.2-pre1.rar and see if it fixes your problem?

Yep, works fine with the new pre-version. Thanks for your work Mosu :D

Brother John

13th October 2003, 15:50

I started using matroska lately and after some muxing trouble with VDubMod I tried mkvtoolnix. Well, what can I say? Great work, Mosu!
However there are two things I'd like to address:

1. Are there any plans for frame accurate splitting in mkvmerge? Though splitting by time and limiting number of output files to 2 works ok that's the one feature I really miss.

2. How about including a manifest file (http://people.freenet.de/brotherjohn/mmg_manifest.zip) for mmg in the windows package? That way the GUI would fully support Win XP's visual styles while not hurting older versions of Windows. I'm running mmg with the manifest file right now without any problems. Feels just like created specifically for XP.

Mosu

13th October 2003, 18:19

Originally posted by Brother John
I started using matroska lately and after some muxing trouble with VDubMod I tried mkvtoolnix. Well, what can I say? Great work, Mosu!

Thanks :)

1. Are there any plans for frame accurate splitting in mkvmerge? Though splitting by time and limiting number of output files to 2 works ok that's the one feature I really miss.

Probably not. The problem is that frame-accurate splitting can only be achieved by re-encoding at the start of each file (from the second file on) if that file does not start with a key frame. Otherwise video would be distorted. mkvmerge is only a converter on the container level and will never include video codecs - and without video codecs no re-encoding.

However, I could include the option to split after 'n' frames, or after given set of frame numbers and try to find the closest key frame - much like I'm handling splitting at the moment. That wouldn't be frame accurate, but you could give the number of frames.

2. How about including a manifest file (http://people.freenet.de/brotherjohn/mmg_manifest.zip) for mmg in the windows package? That way the GUI would fully support Win XP's visual styles while not hurting older versions of Windows. I'm running mmg with the manifest file right now without any problems. Feels just like created specifically for XP.

Looks interesting. Me being a Linux guy I haven't even heard of such files before. What do they do exactly, or what does Windows XP derive from the information that this file provides? I can include it, sure, I'd just like to know a bit more about that mechanism :)

Latexxx

13th October 2003, 19:27

Originally posted by Mosu
Looks interesting. Me being a Linux guy I haven't even heard of such files before. What do they do exactly, or what does Windows XP derive from the information that this file provides? I can include it, sure, I'd just like to know a bit more about that mechanism :)

It just gives the program a crappy winxp outfit. Without the manifest file the buttons etc. in the program will have the tradiotional windows look. So the only difference is how your program does look like. All winxp pros don't even bother to keep the candy-looking interface turned on. It's slow and looks like crap. Include the manifest file if you don't want to get messages like "why doesn't this look like windows?" from l33t users.

Mosu

13th October 2003, 20:10

Originally posted by Latexxx
It just gives the program a crappy winxp outfit. Without the manifest file the buttons etc. in the program will have the tradiotional windows look. So the only difference is how your program does look like. All winxp pros don't even bother to keep the candy-looking interface turned on. It's slow and looks like crap. Include the manifest file if you don't want to get messages like "why doesn't this look like windows?" from l33t users.

I see. Thanks for the explanation. I'll skip that file, then :)

Brother John

13th October 2003, 20:35

frame accurate splitting: should have been more precise, sorry. Of course by »frame accurate« I mean »key frame accurate«. The option I'm looking for is something like: »split the file at frames no 10000, 20000 and 30000 or closest keyframe«.

The manifest file:
Latexxx basically said what it does. Without manifest mmg has the traditional look with rectangular buttons etc. even if the new WinXP look is activated.
I don't want to argue about crappy or not or slow or not. But as mmg does not have any problems with the XP styles why not include a manifest file and leave the choice to every individual user: WinXP look globally enabled --> mmg looks XP-ish, WinXP look disabled --> mmg looks traditional.

Btw: I like the skinning ability (though not the default style) and it doesn't feel slower than Win2k.

Atamido

13th October 2003, 20:38

Mosu

13th October 2003, 23:12

Originally posted by Brother John
frame accurate splitting: should have been more precise, sorry. Of course by »frame accurate« I mean »key frame accurate«. The option I'm looking for is something like: »split the file at frames no 10000, 20000 and 30000 or closest keyframe«.

Yes, that's definitely doable. Can't say anything on the timeframe, though, I'm rather busy these days. Anyway I've put it on my todo list.

The manifest file:
WinXP look globally enabled --> mmg looks XP-ish, WinXP look disabled --> mmg looks traditional.

Ok, if it's honoring the user setting then including it will not hurt anyone.

Mosu

14th October 2003, 15:34

Heya,

I've just released version 0.7.2 of mkvtoolnix. It is mainly a bug fix release but has some internal changes that may or may not work for you ;) Anyway, due to the bugs that I've fixed I strongly recommend that you upgrade to 0.7.2.

The URLs:
http://www.bunkus.org/videotools/mkvtoolnix/
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-0.7.2.rar

The ChangeLog since 0.7.1:
--------------------------
2003-10-14 Moritz Bunkus <moritz@bunkus.org>
* Released v0.7.2.
* mkvmerge: bug fix: If 'no linking' and splitting was active mkvmerge would abort on the start of the second output file due to timecodes that were calculated incorrectly.
* mkvmerge: Implemented some speedups for a couple of container formats and track types (mainly AVI reader, MP3/AC3/AAC packetizers). Especially noticeable when splitting is active as well.

2003-10-12 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: Support for extracting SBR AAC (previous 'fix' did not actually fix this).
* mkvextract: bug fix: All extracted subtitles where written to the first output file given, not to the one they were supposed to be written to.

2003-10-11 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: The 'abort' button was doing nothing under Windows.

2003-10-06 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Audio, video and subtitle track selection was translated into the wrong command line options.
* mkvmerge: Replaced the avilib based AVI reading functions with AVI classes from Cyrius.
-----------------------------

Have fun :)

Mosu

14th October 2003, 15:36

Originally posted by KpeX
I was unable to mux 1 AC3 and 1 avi with mkvmerge 0.7.1,
...

I'm pretty sure I've fixed that in version 0.7.2 (http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-0.7.2.rar).

cca

14th October 2003, 15:42

As I 'm downloading your new version of mkvtoolnix Mosu, I want to bring to your attention a bug that is still present in mkvtoolnix-0.7.2-pre1 and since there is no mention of it in the changelog I assume it is present in 0.7.2 also. The .SRT subtitle parser is still stalling when an empty line is encountered in the SRT text file. This bug was supposed to be fixed in 0.7.1 but I 'm still experiencing the bug. Can you look at it? Thanks.

Liisachan

14th October 2003, 15:54

I didn't realize there were already "Options that only apply to VobSub subtitle tracks" Does sub+idx already work in MKV?

Mosu

14th October 2003, 16:02

Originally posted by Liisachan
I didn't realize there were already "Options that only apply to VobSub subtitle tracks" Does sub+idx already work in MKV?

No, it's deactivated ;) Activating it and getting it right won't be a problem, but there still ain't a playback filter that's able to play VobSubs in mkv.

Mosu

14th October 2003, 16:03

Originally posted by cca
As I 'm downloading your new version of mkvtoolnix Mosu, I want to bring to your attention a bug that is still present in mkvtoolnix-0.7.2-pre1 and since there is no mention of it in the changelog I assume it is present in 0.7.2 also. The .SRT subtitle parser is still stalling when an empty line is encountered in the SRT text file. This bug was supposed to be fixed in 0.7.1 but I 'm still experiencing the bug. Can you look at it? Thanks.

Sure, will do. Could you please send me the .SRT file in question? moritz@bunkus.org Thanks.

KpeX

20th October 2003, 21:00

Originally posted by Mosu
I'm pretty sure I've fixed that in version 0.7.2 (http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-0.7.2.rar).

Correct, sorry for the late reply Mosu, this bug is confirmed squashed in 0.7.2.

Liisachan

20th October 2003, 23:39

The doc says "AAC audio files (only those with ADTS headers before each packet)" works, but it seems mkvmerge can already handle AAC without ADTS headers too (I happened to find it when I was trying to mux a .m4a file created by the AAC encoder come with Apple iTunes.)

1. Is such a .m4a "officially" supported by mkvmerge?
2. If so, I'd like to see "*.aac *.mp4 *.m4a" as the filemask for AAC in mmg

And here's a very small request for better usability:
3. Would like to have File > New in mmg, which would just clear all the forms (needed when you want to make more than one Matroska files in succession)

Mosu

21st October 2003, 09:22

Originally posted by Liisachan
The doc says "AAC audio files (only those with ADTS headers before each packet)" works, but it seems mkvmerge can already handle AAC without ADTS headers too (I happened to find it when I was trying to mux a .m4a file created by the AAC encoder come with Apple iTunes.)

Could you send me the first meg of that file via email please (moritz@bunkus.org)? Technically it should be impossible to handle such files so I'm more than curious what kind of a file this is.

1. Is such a .m4a "officially" supported by mkvmerge?

No, because without the headers I can detect neither the number of channels nor the sampling frequency, the AAC profile or the packet boundaries.

And here's a very small request for better usability:
3. Would like to have File > New in mmg, which would just clear all the forms (needed when you want to make more than one Matroska files in succession)

Good point, I'll add that. Thanks.

Liisachan

21st October 2003, 12:05

a small sample by iTunes, itunes.m4a, has just been sent to you.
I could even use this trick. to convert m4a to "normal" aac:

mkvmerge -o tmp.mka in.m4a
mkvextract tracks tmp.mka 1:_out.aac

_out.aac has a lot of headers like "FF F1 50 xx xx xx FC" periodically, while in.m4a doesn't have such things (I think)

Mosu

21st October 2003, 12:13

Originally posted by Liisachan
a small sample by iTunes, itunes.m4a, has just been sent to you.

Thanks. I'll take a look at it.

ChristianHJW

21st October 2003, 12:26

Originally posted by Mosu No, because without the headers I can detect neither the number of channels nor the sampling frequency, the AAC profile or the packet boundaries. .... you can, from the MP4 headers ?

Mosu

21st October 2003, 12:32

Originally posted by ChristianHJW
.... you can, from the MP4 headers ?

If the source file is a MP4 file then yes (and I guess that is what Liisachan has, although its extension is .m4a and not .mp4). If it's "only" the raw AAC packets then that's not possible.

In short: It's probably a .mp4 and I'll add .m4a to the GUI's file selection dialog.

Liisachan

21st October 2003, 12:47

using mp4creator60 and/or mp4UI, you can extract "AAC (ADTS)" from a "normal" .mp4 audio file, while you can only get "Raw MPEG-4 Audio File (*.bin)" from iTunes' m4a. I'd bet they are different.

bond

21st October 2003, 18:09

to my knowledge a .m4a file from itunes is just a .mp4 file with changed extension (to be able to distinguish audio from video files) nothing less, nothing more

i think it would be better to tell everyone to rename their m4a files to mp4 instead of supporting it, we must get rid of this ugly, apple self-made extension :D

Demi-god

21st October 2003, 19:32

I didn't realize there were already "Options that only apply to VobSub subtitle tracks" Does sub+idx already work in MKV?

No, it's deactivated Activating it and getting it right won't be a problem, but there still ain't a playback filter that's able to play VobSubs in mkv.

So everything at this point depends on Gabest making his Matroska Splitter recognise the vobsub tracks in an mkv file?

ChristianHJW

21st October 2003, 20:43

Originally posted by Demi-god
So everything at this point depends on Gabest making his Matroska Splitter recognise the vobsub tracks in an mkv file? ... even worse :( ... Toff could update the splitter filter in no time, there is not much to do unless the compressed vobsubs are being used, mainly mapping of the new codec ID to a ( not existing, still to be defined ) GUID, but we need Gabest to update vsfilter.dll so it can understand vobsub if they are NOT being read from an external file, but were embedded in a MKV ( or whatever ) file ...

Demi-god

22nd October 2003, 00:12

there is not much to do unless the compressed vobsubs are being used, mainly mapping of the new codec ID to a ( not existing, still to be defined ) GUID
Pardon my impatience, but is something preventing this from being done? Or is this something that Gabest needs to do in vsfilter.dll? Is the Matroska part ready to roll?

Atamido

22nd October 2003, 00:17

Originally posted by Demi-god
Pardon my impatience, but is something preventing this from being done? Or is this something that Gabest needs to do in vsfilter.dll? Originally posted by ChristianHJW
...but we need Gabest to update vsfilter.dll so it can understand vobsub if they are NOT being read from an external file... Is this what you were asking?

Liisachan

22nd October 2003, 00:42

Originally posted by bond
to my knowledge a .m4a file from itunes is just a .mp4 file with changed extension (to be able to distinguish audio from video files) nothing less, nothing more

That's what Audio Coding Wiki says, but there's more to it, at least for mp4UI:

(1) mp4UI 0.9.5 can extract AAC (ADTS) from aac files created by PsyTEL, QcuikTime, Nero, FAAC.
(2) mp4UI 0.9.5 can NOT extract AAC (ADTS) from aac files created by iTuens.

Now, I think this is mp4UI's problem. I found that iTunes' files do have ADTS headers (periodical FF F1 [or FF F9 for MPEG-2 AAC]...), tho the period seems longer than usual. Plus, mp4creator60 0.9.8 can extract AAC from iTunes' file. So they are "normal" after all. That's it. Sorry for the mess.
Just extended filemask for "m4a" would be enough.

Originally posted by bond
i think it would be better to tell everyone to rename their m4a files to mp4 instead of supporting it, we must get rid of this ugly, apple self-made extension :D
Well, foobar2000's FAAC plugin can create files with the extension m4a too. the extension itself is nothing new, and actually it's practical to distinguish mp4 audio files from mp4 movie files by extensions, unless you're using the same player for both.

As a side note, "m4a" was once proposed for "Matroska for Audio" which is now called "MKA"... It was obvious that Matroska couldn't use it, because it was already treated as an extension for MPEG-4 Audio back then.

Demi-god

22nd October 2003, 01:12

Is this what you were asking?
I wanted to know if Gabest is the only thing holding back the ability to mux vobsub subtitles into mkv files, or if the Matroska folks need to do something that they can do independent of Gabest, or if they need to specify something in coordination with Gabest.

Atamido

22nd October 2003, 01:16

Gabest needs to add the support into VSFilter. After that is done the proper GUID can be added to the splitter filter.

ChristianHJW

22nd October 2003, 01:27

Originally posted by Demi-god I wanted to know if Gabest is the only thing holding back the ability to mux vobsub subtitles into mkv files, or if the Matroska folks need to do something that they can do independent of Gabest, or if they need to specify something in coordination with Gabest.

Yes, we are waiting for Gabest only. Mosu can mux vobsub fine, and the files play in mplayer on Linux ...

RathO

22nd October 2003, 03:01

Gabest, wherever you are, the community needs you back! :D
(And the files sleeping on my computer waiting for subs to be muxed to mkv too!) ;)

Regards

Liisachan

24th October 2003, 08:52

1. Question about mkvmerge:

I'd like to use --title "Title not in English" and am wondering which encoding I can use for "Title not in English"
For instance, would this work? (I'm afraid I don't think so)

@rem .bat in UTF8
mkvmerge -o out.mkv in.mkv --title "Something in UTF8"

2. I think I can use a chapters in UTF-8, but mkvinfo 0.7.2 cannot read it so nicely. For instance,

mkvinfo chapter_in_japanese.mkv > test.txt

gave me something like this:

|+ Chapters
| + Edition entry
| + Chapter atom
| + UID: 3967978330
| + Start: 00:00:00.000
| + Display
| + String: oooooooooFOURCC
| + Language: jpn

Where "ooooooooo" is a correct (but incomplete) part of the string, and "FOURCC" is not a part of the string, but a buggy output.

Mosu

24th October 2003, 09:26

Originally posted by Liisachan
1. Question about mkvmerge:

I'd like to use --title "Title not in English" and am wondering which encoding I can use for "Title not in English"
For instance, would this work? (I'm afraid I don't think so)

@rem .bat in UTF8
mkvmerge -o out.mkv in.mkv --title "Something in UTF8"

Correct. --title (just like --track-name) uses the system's current locale for conversion to UTF-8. I probably should add yet another charset parameter that would apply to all command line arguments - that would fix it for you.

2. I think I can use a chapters in UTF-8, but mkvinfo 0.7.2 cannot read it so nicely. For instance,

mkvinfo chapter_in_japanese.mkv > test.txt

gave me something like this:

|+ Chapters
| + Edition entry
| + Chapter atom
| + UID: 3967978330
| + Start: 00:00:00.000
| + Display
| + String: oooooooooFOURCC
| + Language: jpn

Where "ooooooooo" is a correct (but incomplete) part of the string, and "FOURCC" is not a part of the string, but a buggy output.

Very interesting. If you still have the original chapter file, could you please send that one to me and tell me which charset they're in?

Liisachan

24th October 2003, 09:57

sent :)

Mkvextract gets the chapter info correctly,
so I believe muxing is ok, and it's just a small problem in mkvinfo
(hope so)

Here's a pic to show what i mean:
http://mion.wisnet.ne.jp/mkvinfo.png

Mosu

25th October 2003, 17:44

Originally posted by Liisachan
sent :)

Mkvextract gets the chapter info correctly,
so I believe muxing is ok, and it's just a small problem in mkvinfo
(hope so)

Here's a pic to show what i mean:
http://mion.wisnet.ne.jp/mkvinfo.png

Thanks. Unfortunately I cannot reproduce this - I get 'abcdefg' (normal output). For true multi byte strings mkvinfo might always output garbage because it cannot handle wide strings, and that will probably be like it for the foreseeable future.

Anyway, I've added a new option, '--command-line-charset'. With it you can set the charset that is used in the conversion to UTF-8 for strings given on the command line. It applies to the '--title' (mmg: "segment title", global tab), '--track-name' (mmg: "track name", input tab) and '--attachment-description' options. It can be set in mmg on the global tab.

This way you can have your batch file in UTF-8 like this:

@rem .bat in UTF-8

mkvmerge -o output.mkv input.avi --title 'something with UTF-8 coded characters' --command-line-charset UTF-8

The placement of this option is not important.

If you want to give it a try then download http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-0.7.2-build20031025-2.rar

Thanks :)

(Note to the others: Yes, this version does contain full support for VobSubs ;) Although there's still no filter for Windows that can handle them.)

raistlin2k

25th October 2003, 18:09

Toff could update the splitter filter in no time

It this only related to vobsub inside MKV or does it apply also to working audio-stream-names in mkv?

That's really the only thing why I don't move from OGM to MKV, the vobsub-inside-mkv would be nice too, but external subs are working as well, whereas audio-stream-names are NOT working at all.

Since MKV supports chapter-jumps to not-key-frames - impossible with OGM - I would really like to switch, so please check this audio-stream-problem ASAP.

Thanks
Raist

ChristianHJW

25th October 2003, 21:26

Copied from IRC :

<ChristianHJW> Toff : http://forum.doom9.org/showthread.php?s=&postid=390623#post390623
<Toff> i already updated the filter for that
<Toff> (even if there is a bug :D)
<Toff> (which is fixed here, but not yet sent to Gabest)
* Animaniac has joined #matroska
<ChristianHJW> Toff : tell him ... he may make his next rip in MKV already ... one saved soul :)

;) ....

raistlin2k

25th October 2003, 21:43

Thanks for that info! :)

Raist

Liisachan

25th October 2003, 22:38

Originally posted by Mosu
Thanks. Unfortunately I cannot reproduce this - I get 'abcdefg' (normal output).

I get "abcdefg" too if I set "language for non-unicode programs" = "English" This can be actually another problem
because the string is not abcdefg but ａｂ(U+FF41 U+FF42)...

anyway the first problem is not fixed in this newest beta, as long as I'm in the same mode (language for non-unicode programs = japanese)

Anyway, I've added a new option, '--command-line-charset'. With it you can set the charset that is used in the conversion to UTF-8 for strings given on the command line. It applies to the '--title' (mmg: "segment title", global tab), '--track-name' (mmg: "track name", input tab) and '--attachment-description' options. It can be set in mmg on the global tab.
This does work sometimes, but not always.
Let's just think about '???????' where the single quotation mark = 0x27, but there can be 0x27 in ???? thanks to U+27xx and U+xx27. This way, this can't work in UTF-16, and the same goes for some other encodings.
Another confusing problem is, Windows is meddling when it passes a string input/output, to/from mkvmerge...it'll convert charset by itself (in a lossy way, for instance ä will be converted to a if the codepage=japanese, and one Kanji will be converted to 2 meaningless alphabets if the codepage!=japanese)...plus you should hack the clipboard encoding if you'd like to enable one to paste something in unicode into the editbox in mmg...otherwise, windows defaults the clipboard encoding to "Lanugage for non-unicode program"
so...probably the safest way is not very cool:

--title @somefile.utf8.txt

This way you can have your batch file in UTF-8 like this:

@rem .bat in UTF-8

mkvmerge -o output.mkv input.avi --title 'something with UTF-8 coded characters' --command-line-charset UTF-8

Hmmm, in a bat file? well, utf-8 could be possible, but utf-16 will be impossible this way (in bat) because cmd.exe can't find mkvmerge as it'd think the command line would be "m k v m e r g e"

BUT, more importantly,,,,,,, finally SUB+IDX is coming!! :):D:)

Here's a cosmetic thing:
i suppose "Subtitle charset" list in mmg should be disabled if the track is S_VOBSUB

alx

29th October 2003, 21:22

Sorry to bother you ppl, but recently i want to mux an rmvb file with an mp3 file and this message appears in mmg.exe

Warning: real_reader: packet assembly failed. Expected packet length was 54842 but found only 1 sub packets containing 47372 bytes. Sub packet number: 316160. Trying to continue.
Warning: real_reader: G:\zzzdvd1\1.rmvb: Data packet length is too small: 0. Other values: object_version: 0x2091, id: 0x1222, timecode: 100, flags: 0x5f. File position: 651304067. Aborting this file.

The .mkv file was truncated, but when i play the rmvb file its ok, and the same happens when i play the .mp3 file

Any ideas why this happend¿?
Sorry for my poor english.
Alx.

Mosu

30th October 2003, 00:58

Originally posted by alx
Warning: real_reader: packet assembly failed. Expected packet length was 54842 but found only 1 sub packets containing 47372 bytes. Sub packet number: 316160. Trying to continue.

This means that the packet stream is missing some packets.

Warning: real_reader: G:\zzzdvd1\1.rmvb: Data packet length is too small: 0. Other values: object_version: 0x2091, id: 0x1222, timecode: 100, flags: 0x5f. File position: 651304067. Aborting this file.

This means that the file in question is damaged and that mkvmerge cannot recover from this error. Thank Real for a container without any syncword.

Without having the file in question I can't say if this could be processed completely, but I doubt it. Maybe RealPlayer has some strange error recovery method that I just can't think of.

alx

30th October 2003, 06:48

So, to make this long history short, do i have to make all the movie again?...........Another 20 hours looking nothing else than a % simbol running in a DOS BOX??? BUAAAAAAAAAAAAA!!!!
Hope Dark Cracker could use Producer 9.2 M7 in its AutoRV9 soon.......this new version has two seperate pass, like xvid.....

Thanks anyway MOSU....
Alx

ChristianHJW

30th October 2003, 10:09

Originally posted by Liisachan BUT, more importantly,,,,,,, finally SUB+IDX is coming!! :):D:)
Liisachan, dont use it for a final encode yet, Mosu has changed the way vobsub's get muxed into MKV completely recently, thanks to the precious input from Sigmund 'Dnumgis' Audal, a core VLC developer. More info on the ML, but we hope to be able to release it soon now, together with a working win32 build of VLC ....

Mosu

30th October 2003, 10:16

Originally posted by ChristianHJW
Liisachan, dont use it for a final encode yet, Mosu has changed the way vobsub's get muxed into MKV completely recently, thanks to the precious input from Sigmund 'Dnumgis' Audal, a core VLC developer. More info on the ML, but we hope to be able to release it soon now, together with a working win32 build of VLC ....

She wrote '...is coming' ;) I think that she's knowledgable enough that a pre version is exactly that, pre, not stable or official ;)

Liisachan

30th October 2003, 11:54

Yup, I know it more or less, thanks to the lists.
Please don't worry. :)

Actually , I'm always repoting in my webpage what I can know from the lists etc. As you can see, the support for SUB+IDX means a lot here in japan (or probably also in China etc) where SubRip can't work, and my readers is getting the following news almost realtime...
(1) 26/10 mmg pre supported SUB
(2) 26/10 but the way it supports VOB will be changed
(3) 29/10 MKS converted from VOB is a lot smaller, especially with zlib
For instance, ppl in japan read about (3) within one hour after Mosu had posted that in the list :D in short, ppl are very interested and this is long-awaited. I bet so many ppl will be thankful for your work here.

Human_USB

30th October 2003, 19:00

How come when I name stuff I still get "filename.MKV / audio 1" even though it's called "English" in MMG. I'm using version 0.7.2 and MPC 6.4.6.7 if that helps.

Thanks,
Jason

ChristianHJW

31st October 2003, 14:23

Originally posted by Human_USB How come when I name stuff I still get "filename.MKV / audio 1" even though it's called "English" in MMG. I'm using version 0.7.2 and MPC 6.4.6.7 if that helps. ... you need a little bit more patience, the changes are in the CVS of the next matroska DirectShow splitter already and will be released soon ...

Human_USB

31st October 2003, 23:25

Ok..... thanks for the information.

Jason

Beave

2nd November 2003, 02:16

Hi, I use mkvmerge quite a lot. Is it possible to cut a certain part out of an avi with that tool? I especially looking for that feature, that it takes the nearest keyframe when splitting. That's what I need for cutting out a part as well.
Or is there another cli tool better suited for that task?

pixolex

2nd November 2003, 17:22

Hi!

I'm just playing around with MKVmerge and...

I select in the first time audio 1 has a default track, i'm muxing again and now i choose audio 2 for default and there are a warning:

"Warning: Another default track for audio tracks has already been set. Not setting the 'default' flag for this track."

should't be deleted the flag for the previous track? And after that set the flag for the selected track!

Can't i change the order of the track to put Video in ID1 and the other two audio track in ID2 and ID3?

" +-> Using the MPEG audio output module for track ID 1.
+-> Using video output module for track ID 2.
+-> Using the MPEG audio output module for track ID 3.
Opened 'D:\FTP\DivX & Xvid\Diana Krall\exp1.mkv' for writing.
Writing cue entries (the index)...
Muxing took 3 seconds. "

Mosu

4th November 2003, 12:44

Originally posted by pixolex
should't be deleted the flag for the previous track? And after that set the flag for the selected track!

Yes, the GUI does not yet remove the old 'default track' flag that has been selected before. I'll fix that.

Can't i change the order of the track to put Video in ID1 and the other two audio track in ID2 and ID3?

No, reordering of the track numbers is not possible. Well it IS possible, with a little trick. This is your input:

" +-> Using the MPEG audio output module for track ID 1.
+-> Using video output module for track ID 2.
+-> Using the MPEG audio output module for track ID 3.

Now you can add this file twice (!) as an input file. For the first entry you only active the video track, the two audio tracks are deactivated. For the second entry you activate the two audio tracks and deactivate the video track. This way the video track gets ID1, the first MPEG audio track ID 2 and the second MPEG audio track ID 3.

Note that this won't matter at all for a player because this won't change the order of tracks regarding their track type: The first MPEG audio track has an ID lower than the second MPEG audio track. If the video comes before, in the middle of or after those two audio tracks really does not make any difference.