[Matroska-devel] Hi, question about the MKV tags

Steve Lhomme slhomme at matroska.org
Wed Feb 2 21:09:08 CET 2011


On Wed, Feb 2, 2011 at 3:27 AM, Santiago Jimeno <sjimeno at ya.com> wrote:
> Thank you to accept my suggestion regarding the VOID space behind SeekHead.
>
> Regarding installation error see you this post:
> http://blog.colinmackay.net/archive/2007/06/21/36.aspx
>
> As for covertart, including it in audio files was, as you know, an idea of
> ID3 that integrated it in Tags block and with binary code. All Tags systems
> adapted as better they could this idea. Generally transcribing the same APIC
> ID3 format almost literally.

But none of them had proper file attachment support. That's why they
used this hack.

> All the current systems (ID3, iTunes-MP4, WMA-ASF, APE, VORBIS) integrate
> coverart inside the Tags block. This is fundamentally for effectiveness when
> writing and editing. There are only two exceptions FLAC and MATROSKA.
> Sometimes WMA, if there is one Picture of big size, put it outside of the
> Tags block. But this is due to a space problem caused by a design error
> (there is only an Int16 to specify Data Length, with what the maximum size
> for each picture is 65535 bytes).

I understand that cover art may be considered as a metadata.

> FLAC works with Vorbis Comments Tags system. Previously it included coverart
> in a PICTURE block separated since Vorbis had not decided where to include
> it. When Vorbis decided to include coverart put it inside the Tags block.
> Now FLAC can write coverart in two places: in the old place and inside
> Vorbis Comments (??). Of course, FLAC won't change neither this as Martin
> Leese of FLAC team told me.
>
> Steve said "I still don't know what's wrong with attachments as they are
> now."
> There is not wrong with Attachments just as they are. It's a good idea for
> streaming. But for all the other cases it's more effective and more rational
> to include them in the Tags block. When all Tags systems make it this way
> for something will be. I only can add  my suggestions for my experience
> working with Tags. Maybe if you try to write code to edit Tags and covertart
> you coincide with me. As for the blocks location it's also ineffective to

The thing is, cover art is usually for the entire segment, whereas in
Matroska tags are often not for the whole segment. That's why I think
it's good that it's easy and straightforward to be able to read cover
art without having to support all the tag system. Attachments are flat
and very easy to parse. Tags have different level and signification
depending on some values. So anything could be easily misunderstood as
cover art if not implemented properly.

> locate them in the file middle knowing that when being edited they will be
> placed at the file end. When editing Attachments and Tags in cover_art.mkv
> file and are transferred at the file end  leaves a excessive VOID space of
> aprox. 416000 bytes (very possibly useless). On the other hand the normal
> thing is not that the pictures are already inserted and we don't need to
> change them, the normal thing is that there is not any and we have to put
> them.

That's actually a good point to separate the cover art in attachment
and tags that are usually edited. In the system you propose, adding
one byte in the existing tags would make a big empty void in the file.
That's ugly. Like I said, cover art are rarely edited. They are either
added or removed, but rarely modified. And as the "ordering guideline"
suggests, there are many good reasons why all these metadata should be
at the front whenever possible.

> Steve said: "Adding binary in tags should be avoided, because it's not
> implied how to interpret it. For pictures it could be JPEG, PNG, SVG, etc.
> Attachments have a MIME type for that, tags don't. You can notice in the
> specs the very few formats with binary values are those with only one
> possible format."
> The APIC ID3 format, the same one also adopted by Matroska in Attachments,
> includes all necessary data to interpret the binary code that goes next and
> one can put it perfectly inside the Tags block. When all Tags are declared
> as UTF8 string, like in Vorbis case, what they have made with covertart is
> to translate the whole package to Base68 that is compatible with UTF8.

We're certainly not going to use Base64 when our format is good at
handling binary data. ID3 is badly designed and basically a hack over
something missing in MP3 and then other formats. There's no reason to
copy its flaws.

> Lastly, like FLAC case, I can only do suggestions. The decisions and the
> future of Tags depend on Matroska team if one wants that the Tags system is
> something more than a project. I'm collaborating to improve the development
> of Matroska Tags with my 'almost' completed editor (I think it's the only
> one at the moment). But as you say at the beginning of your message: "So
> there is just one system to deal with everything"

Well, there has many many "only one moment" in the past about tag
changes. I think we have reached a good consensus on everything that
is possible. Maybe adding a MIME type next to binary data in tags
could be a good move. But the recommended/default cover art should be
in attachments in my opinion. That also makes it easier to make tools
to scan for "files" inside matroska files if they are all in the same
place.

-- 
Steve Lhomme
Matroska association Chairman



More information about the Matroska-devel mailing list