Internet-Draft | Matroska Tags | May 2024 |
Lhomme, et al. | Expires 6 November 2024 | [Page] |
This document defines the Matroska tags, namely the tag names and their respective semantic meaning.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 6 November 2024.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Matroska is a multimedia container format defined in [Matroska]. It can store timestamped multimedia data
but also chapters and tags. The Tag Elements
add important metadata to identify and classify the information found
in a Matroska Segment
. It can tag a whole Segment
, separate Track Elements
, individual Chapter Elements
or Attachment Elements
.¶
While the Matroska tagging framework allows anyone to create their own custom tags, it's important to have a common set of values for interoperability. This document intends to define a set of common tag names used in Matroska.¶
This document is a work-in-progress specification defining the Matroska file format as part of the IETF Cellar working group. It uses basic elements and concept already defined in the Matroska specifications defined by this workgroup [Matroska].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
When a Tag is nested within another Tag, the nested Tag becomes an attribute of the base tag. For instance, if you wanted to store the dates that a singer used certain addresses for, that singer being the lead singer for a track that included multiple bands simultaneously, then your tag tree would look something like this:¶
In this way, it becomes possible to store any Tag as attributes of another tag.¶
Multiple items SHOULD never be stored as a list in a single TagString. If there is more than one tag of a certain type to be stored, then more than one SimpleTag SHOULD be used.¶
The TagName SHOULD consists of capital letters, numbers and the underscore character '_'.¶
The TagName SHOULD NOT contain any space.¶
TagNames starting with the underscore character '_' are not official tags; see Section 4.1.¶
The fields with dates SHOULD have the following format: YYYY-MM-DD hh:mm:ss.mss YYYY = Year, MM = Month, DD = Days, HH = Hours, mm = Minutes, ss = Seconds, mss = Milliseconds. To store less accuracy, you remove items starting from the right. To store only the year, you would use, "2004". To store a specific day such as May 1st, 2003, you would use "2003-05-01".¶
Fields that require a Float SHOULD use the "." mark instead of the "," mark. To display it differently for another local, applications SHOULD support auto replacement on display. Also, a thousandths separator SHOULD NOT be used.¶
For currency amounts, there SHOULD only be a numeric value in the Tag. Only numbers, no letters or symbols other than ".". For instance, you would store "15.59" instead of "$15.59USD".¶
The TargetType element allows tagging of different parts that are inside or outside a given file. For example, in an audio file with one song you could have information about the album it comes from and even the CD set even if it's not found in the file.¶
For application to know the kind of information (like TITLE) relates to a certain level (CD title or track title), we also need a set of official TargetType names. For now audio and video will have different values and names. That also means the same tag name can have different meanings depending on where it is (otherwise, we would end up with 15 TITLE_ tags).¶
TargetTypeValue | Audio strings | Video strings | Comment |
---|---|---|---|
70 | COLLECTION | COLLECTION | the high hierarchy consisting of many different lower items |
60 | EDITION / ISSUE / VOLUME / OPUS | SEASON / SEQUEL / VOLUME | a list of lower levels grouped together |
50 | ALBUM / OPERA / CONCERT | MOVIE / EPISODE / CONCERT | the most common grouping level of music and video (e.g., an episode for TV series) |
40 | PART / SESSION | PART / SESSION | when an album or episode has different logical parts |
30 | TRACK / SONG | CHAPTER | the common parts of an album or a movie |
20 | SUBTRACK / PART / MOVEMENT | SCENE | corresponds to parts of a track for audio (like a movement) |
10 | - | SHOT | the lowest hierarchy found in music or movies |
An upper level value tag applies to the lower level. This means that if a CD has the same artist for all tracks, you just need to set the ARTIST tag at level 50 (ALBUM) and not to each TRACK (but you can). That also means that, if some parts of the CD have no known ARTIST, the value MUST be set to nothing (a void string "").¶
When a level doesn't exist it MUST NOT be specified in the files, so that the TOTAL_PARTS and PART_NUMBER elements match the same levels.¶
Here is an example of how these organizational
tags work: If you set 10 TOTAL_PARTS to
the ALBUM level (40) it means the album contains 10 lower parts. The lower part in question
is the first lower level that is specified in the file. So, if it's TRACK (30), then that
means it contains 10 tracks. If it's MOVEMENT (20), that means it's 10 movements, etc.¶
Tag
values can be either strings or binary blobs. This document inherits security
considerations from the EBML [RFC8794] and Matroska [Matroska] documents.¶