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

Steve Lhomme slhomme at matroska.org
Tue Feb 1 21:50:12 CET 2011


On Tue, Feb 1, 2011 at 12:57 PM, Santiago Jimeno <sjimeno at ya.com> wrote:
> Steve said "The reason for this is that some apps may support attachments
> and not tags. The cover art system is much simpler to support than tags
> (when done properly)."
>
> Indeed it's easier of supporting. But the practical problem is presented
> when it's necessary to support at the same time the edition with Tags and
> Pictures modifications and besides in two different blocks. This complicates
> the code a lot. The ideal thing would be Tags and Picture were in oneself
> block and with preference at the file end.

Then you could argue chapters should be in tags. So there is just one
system to deal with everything. But these features are made modular on
purpose. We are not going to change that now.

> If the target of the file is streaming for network reading, picture should
> be before Cluster. But if the target is to make a file that can be modified
> later on (for example to organize a collection in a PC) the picture location
> should be, as before I said, at the file end next to Tags.

In fact I think cover art is very unlikely to be edited further by the
user (unless it was not originally present). Tags that are open-ended
(which unlimited possible extensions) can always be enhanced with more
data. Cover Art rarely differs.

All the rationale behind the choice of positions can be found here :
http://www.matroska.org/technical/order/index.html

> Anyway if Tags and Picture are edited (mainly if one adds information) will
> necessarily go at the end. On the other hand it's more difficult of working
> when picture is in the same block with fonts and subtitles.

Subtitles are in the stream, not as attachments. It is true for fonts.

> In another message Steve said:  "In fact right now nobody cares about tags."
> But not only the external programs. I take enough time working in tags and
> my impression is that the programs that make Matroska files neither take
> care of it. Tags is not generally added when a file is converted to
> Matroska, even when the original file already includes them. I think that
> one acts in such way that once made the Matroska file is expected that
> nobody modifies it.

I don't think it's reasonable to add tags and assuming noone will
change them. Even the content I buy on music stores, I customize the
tags to meet my archiving system.

> When adding or editing Tags and Pictures is necessary to modify also
> SeekHead. For this is necessary (it should be mandatory) this block has a
> VOID space later. Well, this is the situation of some files tested:

mkclean leaves room for tags indeed (not attachments). mkvtoolnix also
produces a large void at the beggining of the file for such changes.
I'm not sure it should be a rule to impose, but more a guideline.

> - Haali adds only 14 bytes of VOID space. If one adds Tags at the file end
> we would need a minimum of 17 bytes for Seek entry. Conclusion:  one cannot
> add SeekHead entry. Less still if one modifies Pictures in Attachments.
>
> - Direct Show adds 130 bytes of VOID space. A little fair but enough.
>
> - MkvMerge doesn't add VOID space in versions 4.0.0 and 4.1.1. Fortunately
> in the remaining versions Mosu is very generous and he adds a VOID space of
> 4000 bytes. We are of luck that most of files Matroska are made with
> mkvmerge.
>
> - An example of complicated design for Tags is the sample provided for
> pictures in cover_art.mkv file. Tags and Attachments are before Cluster. If
> one modifies them then they will go at the file end. But the VOID space
> after SeekHead is 0 bytes. Finally I have been able to modify the file
> deleting 4 bytes of CRC that had each entry to be able to include the new
> entries for Tags and Attachments.

Look at the section "Optimum layout after editing tags" in the Order Guideline.
When editing tags/attachments and they don't fit in their original
place, they should be moved at the end. That leaves plenty of room at
the front to add new elements in the SeekHead.

> I think it would be necessary to setting some clearer norms for impeling the
> inclusion of Tags in the files and to favor its edition. But as the
> specifications leave a wide field of freedom at least some recommendations
> should be made.
>
> - The VOID space after SeekHead should be if not mandatory at least very
> recommendable

Correct. I will try to add that somewhere. The ordering guideline may
be the most appropriate place for now, as it discusses each "level-1"
elements placement in general.

> - Tags should be at the file end with preference.

In fact the preference is at the front. Although in most cases where
it will have been edited, it will end up at the end.

> - In pictures case, if the target of the file is not streaming, the
> Attachments block should be after Cluster. Mkvmerge uses two SeekHead
> blocks, one for master elements at beginning of file and another before the
> cluster blocks. This good design approach could also be applied to
> Attachments. One Attachments could be before Cluster for fonts and subtitles
> and other one after Cluster for Pictures and maybe also for Lyrics.

In fact the 2 SeekHead approach was dropped recently. Noone could
remember why it was done in the first place. And it's more complex to
support on the player side.

> - But the ideal thing would be to be able to include Pictures like a
> SimpleTag inside Tags. For not modifying the design of the Matroska
> container substantially it could be optional according to the file target
> (streaming or other) to put the Pictures in Attachments or in Tags but not
> in both at the same time.

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.

> So I propose to declare official a SimpleTag for Pictures with the following
> outline:
>
> TagName: PICTURE OR COVERTART
>
> TagBinary:  Identical structure of Attachments Picture including in the
> binary code FILEDESC, FILENAME, FILEMIMETYPE and FILEDATA, that is to say,
> the ID3 APIC structure. In the event of being necessary the compatibility
> for UTF8 the whole binary code can be converted to Base64 (thus vorbis does
> it). But this fills 25% more space

So you want to add attachments inside a TagBinary element ? That
deserves some reflection... I still don't know what's wrong with
attachments as they are now.

> Regards. Santiago
>
> PS. If somebody has tested my program FileList for Tags
> http://personales.ya.com/sjimeno/Download/MATROSKAFileList.zip
> I would thank the comments or suggestions

Error 2755 in the MSI installer (Vista 64 bits in english)

> ----- 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: Monday, January 31, 2011 1:32 PM
> Subject: Re: [Matroska-devel] Hi, question about the MKV tags
>
>
>> The reason for this is that some apps may support attachments and not
>> tags. The cover art system is much simpler to support than tags (when
>> done properly).
>>
>> And yes, when editing tags/cover art you have to check if it can fit
>> in the original place, if not you have to :
>> - void the old version
>> - write the new version at the end
>> - update the segment size
>> - update the position of the tags/attachment in the SeekHead section
>>
>> That's more or less what you'd have to do in any container anyway,
>> except some may not have a Void element and would always put these
>> data at the end (not nice for network reading).
>>
>> On Mon, Jan 31, 2011 at 1:23 PM, Santiago Jimeno <sjimeno at ya.com> wrote:
>>>
>>> Hi all
>>>
>>> In the email I sent speaking about CodecSpecs a while ago, I said that I
>>> would write other about Tags.
>>> I think the current message provides me this opportunity.
>>>
>>> Reading Tags is relatively easy (in spite of Nested Tags) in Visual .NET
>>> because of the easiness that .NET provides to work with XML Documents.
>>>
>>> Editing or re-writing Tags is complicated. But I have it done in my
>>> program
>>> FileList.
>>> But it's not still completed because of the difficulties that I have
>>> found
>>> with Cover Art.
>>>
>>> Cover Art are in a Attachments block (separated of Tags block) that is a
>>> bag
>>> for everything that also includes fonts, text and subtitles and located
>>> in
>>> any place of the file. The result in this case is that, in spite of its
>>> initial advantages, it doesn't exist a program for editing Tags and I
>>> think
>>> it's for the extreme difficulty that implies to almost modify the whole
>>> file. I think that to have two different blocks for Tags and Pictures is
>>> not
>>> a good design. In Flac files a similar thing happens.
>>>
>>> I am working in two possible solutions.
>>> 1.- Declaring VOID the block part that contains Pictures and writing them
>>> at
>>> the file end (next to Tags) in a second Attachments block.
>>> 2.- Including them in a new SimpleTag <TagName> COVERART inside TAGS,
>>> maintaining its structure. The binary data could be written as
>>> <TagBinary>
>>> or as <TagString> in Base64 so that was compatible with UTF8 (Vorbis
>>> Comments do it this way).
>>>
>>> If somebody wants to test FileList program, one can download it in
>>> http://personales.ya.com/sjimeno/Download/MATROSKAFileList.zip
>>> To show edit form --> double click in List Item.
>>> This program is designed for audio files MKA, although it also reads
>>> video
>>> files MKV. Apply Tags edition is disabled at the moment due to the
>>> problem
>>> above mentioned.
>>>
>>> Regards. Santiago Jimeno
>>>
>>> _______________________________________________
>>> 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
>> _______________________________________________
>> 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