mkvtoolnix: new version [Archive] - Page 2

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 ;)