[Matroska-devel] Hi, question about the MKV tags
sjimeno at ya.com
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
- 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
- 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
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
PS. If somebody has tested my program FileList for Tags
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
>> But it's not still completed because of the difficulties that I have
>> with Cover Art.
>> Cover Art are in a Attachments block (separated of Tags block) that is a
>> for everything that also includes fonts, text and subtitles and located
>> 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
>> 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
>> 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
>> 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
>> 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
>> To show edit form --> double click in List Item.
>> This program is designed for audio files MKA, although it also reads
>> files MKV. Apply Tags edition is disabled at the moment due to the
>> above mentioned.
>> Regards. Santiago Jimeno
>> Matroska-devel mailing list
>> Matroska-devel at lists.matroska.org
>> Read Matroska-Devel on GMane:
> Steve Lhomme
> Matroska association Chairman
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> Read Matroska-Devel on GMane:
More information about the Matroska-devel