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

Steve Lhomme slhomme at matroska.org
Thu Feb 3 07:27:04 CET 2011


On Wed, Feb 2, 2011 at 11:23 PM, Santiago Jimeno <sjimeno at ya.com> wrote:
> 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).

Yes but again. Your reason to put it at the end is for editing. My
reason to put it at the wrong is for better reading. For example
seeking in HTTP is slow. It's much better if everything is at the
front.

> 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

Not yet. I will try but I don't know when.

> 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
>
>
> _______________________________________________
> 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
>



-- 
Steve Lhomme
Matroska association Chairman



More information about the Matroska-devel mailing list