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

Tue Feb 1 12:57:38 CET 2011

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.

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.

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.

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.

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:

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

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

- Tags should be at the file end with preference.

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

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

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

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