[Matroska-users] Re: [Matroska-general] new mkvtoolnix release 0.7.1

Moritz Bunkus moritz at bunkus.org
Fri Oct 3 18:02:58 CEST 2003


> Mosu, can you give us some numbers, just out of curiosity ?

Ok, the pre-Releases were not really downloaded more often than the
0.7.0 - that was only the case in the last week or so.

Here's a run-down of how often releases/sources were downloaded: (only
showing 300 downloads or more and the most recent release, 0.7.1, which
is only about five hours old):

    147 mkvtoolnix-0.7.1.rar
    342 mkvtoolnix-
    485 mkvtoolnix-0.4.4.zip
    518 mkvtoolnix-0.7.0.tar.bz2
    557 mkvtoolnix-0.6.6.rar
    828 mkvtoolnix-0.7.0pre-20030916-2.rar
   1065 mkvtoolnix-0.6.3.zip
   1066 mkvtoolnix-0.6.2.zip
   1117 mkvtoolnix-0.5.0.zip
   1155 mkvtoolnix-0.6.5.zip
   2703 mkvtoolnix-0.7.0.rar
   2747 mkvtoolnix-0.6.0.zip

> Eheheheh ... i wished i had the same skills, does that thrown a bad 
> shadow on them ( = my documentation skills ) :D ??

:) Well I have done my share of writing docs (including a pretty long
guide on DVD ripping under Linux which is now hopelessly outdated), but
I suffer from the same problem each programmer suffers from. We just
don't really know what Joe User knows about our software, which problems
he has using it and what he'd like to know first. So we often write docs
that are fine for other programmers but that don't really help new

That's why I'm always open for suggestions, especially on the guide.

> I admit i completely lost track meanwhile about what timeslices etc. 
> are, but let me put a big questionmark behind that :
> Is it really the right thing to do ? Maybe current parsers dont support 
> it, but who cares ? Abandon the advantages of timeslices, just to save a 
> little bit of overhead ? I ask for opnions pls. ....

Lemme put it this way. You have two options if you want to know the
duration of each and every frame in a file. The first is not to use
lacing at all. In this case you can either use the difference between
the current frame and the next frame's timecodes, or you can use
additional BlockDuration elements. This makes the file large.

If you DO use lacing in order to save space you have to use timeslices
IF you want to know all frame durations. However, using timeslices
totally defeats the purpose of lacing - with fully timesliced blocks the
files will be even bigger.

My personal opinion is that normally you don't need the durations for
all frames if you 'just' want to play your file back. If you want to
edit this file, then you would probably want to have all those
durations. At the moment there's only VDubMod which is a full movie
editor, and I'm thinking more in the direction of Adobe Premiere. For
simple playback you don't need those durations. And that's what the big
majority of users wants and needs. That's why I've chosen not to use
timeslices PER DEFAULT anymore. The user still has the choice to
explicitely activate them, though.

> Does that mean that a ID3 tagged MP3 file can be converted into a tagged 
> MKA, and the tags are converted 1:1 ?

No. ID3 tags are just discarded! Before everyone thinks 'oh wtf!?' let
me explain, please. ID3 can have files attached to them, e.g. JPEG
images, similar to our attachment systems. ID3 tags do not represent a
valid 'frame for playback' so I don't really know which timecodes I
should chose for them. Because of the files these frames can get really
ugly big - and putting those into Matroska blocks might be a bad idea.

Automatic transformation of ID3 into Matroska tags is possible, of
course, but it hasn't been implemented. I think that I'd prefer an extra
application that can do that, e.g. read a MP3 file with ID3 tags and
output a XML file suitable for mkvmerge. Otherwise mkvmerge will do more
and more things automatically, and probably no one besides myself will
know what all those things are... And let's be honest - not all that
many people read the mkvmerge documentation completely. (I don't blame
them ;))

> Mosu, a wonderful release !!! Now give us vobsubs's and i care that we 
> can play them :) !!

;) That won't be too soon I'm afraid. We still haven't agreed on how we
handle content encodings (via appending strings to the codecids or by
introducing new track info elements, and how exactly they look
etc...). And - most important - Gabest has still now shown up :(

 ==> Ciao, Mosu (Moritz Bunkus)

More information about the Matroska-general mailing list