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

Santiago Jimeno sjimeno at ya.com
Wed Feb 2 23:23:56 CET 2011


Only some puntualización:

Steve said: "In the system you propose, adding one byte in the existing tags 
would make a big empty void in the file"
Not if they are already at the end of the file, a block is substituted for 
other and the file only increases 1 byte, without empty spaces, because 
there is not any other block at the end (a simple file append).

Santiago said: "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)."
Of this enormous bytes number that I mention, correspond to the Tags 315 
bytes, the rest is the space left empty for the pictures.

Steve said: "Like I said, cover art are rarely edited. They are either added 
or removed, but rarely modified."
The pictures can be extracted, modified and added again. But even this way, 
in fact they can only be added or deleted (for me this is editing the 
pictures). But if one is added the block necessarily moves at the end and 
leaves VOID space  .

Regarding picture structure in Attachments, anyone can realize that it's 
almost identical to APIC ID3. Here a comparison of both structures.

ID3                     MATROSKA
----                     FileName
Mime type           FileMimeType
Picture type         ----
Description          FileDescription
Picture data         FileData

Lastly, as I said in my message, I only do suggestions, the decisions belong 
to you. Now I should work according to the current norms of the container. I 
will try to finish the editor when I can (I work in the one in my free 
time).

Have me to the current of your opinion if you are able to install the 
program and to test  it

Regards. Santiago

----- Original Message ----- 
From: "Steve Lhomme" <slhomme at matroska.org>
To: "Discussion about the current and future development of Matroska" 
<matroska-devel at lists.matroska.org>
Sent: Wednesday, February 02, 2011 9:09 PM
Subject: Re: [Matroska-devel] Hi, question about the MKV tags


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
_______________________________________________
Matroska-devel mailing list
Matroska-devel at lists.matroska.org
http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
Read Matroska-Devel on GMane: 
http://dir.gmane.org/gmane.comp.multimedia.matroska.devel





More information about the Matroska-devel mailing list