[Matroska-devel] Hi, question about the MKV tags
sjimeno at ya.com
Wed Feb 2 03:27:44 CET 2011
Thank you to accept my suggestion regarding the VOID space behind SeekHead.
Regarding installation error see you this post:
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.
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).
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
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
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
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
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.
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"
----- 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: Tuesday, February 01, 2011 9:50 PM
Subject: Re: [Matroska-devel] Hi, question about the MKV tags
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
> 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
> later on (for example to organize a collection in a PC) the picture
> 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 :
> Anyway if Tags and Picture are edited (mainly if one adds information)
> necessarily go at the end. On the other hand it's more difficult of
> 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
> 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
> 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.
> 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
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
> 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
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
> cluster blocks. This good design approach could also be applied to
> Attachments. One Attachments could be before Cluster for fonts and
> 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
> 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
> 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
> 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
>>> 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
>>> 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:
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> Read Matroska-Devel on GMane:
Matroska association Chairman
Matroska-devel mailing list
Matroska-devel at lists.matroska.org
Read Matroska-Devel on GMane:
More information about the Matroska-devel