Vorbis comment

VorbisComment is a base-level Metadata format initially created for use with Ogg Vorbis . It has since been adopted in the specifications of Ogg encapsulations for other Xiph.Org codecs including Theora , Speex and FLAC . Although the syntax of VorbisComment is well-specified, various conventions exist for the field names in use. The goal for this page is to codify best practices and collect proposals for standardization of VorbisComment field names. VorbisComment is the simplest and most widely-supported mechanism for storing metadata with Xiph.Org codecs. For other existing and proposed mechanisms, see Metadata . The current VorbisComment recommendation contains a recommended set of field names for comments. Comments are intended to be free-form, but for the purposes of interoperability, it is helpful to define tag sets for particular applications, and provide some guidelines for machine parsing. Note that some field names have to be non-free-form to achieve machine parsing. The binary FLAC picture structure is base64 encoded and placed within a VorbisComment with the tag name "METADATA BLOCK PICTURE". This is the preferred and recommended way of embedding cover art within VorbisComments. It has the following benefits: Easy to use for developers since the identical (or similar) structure is also used by FLAC and MP3. The cover art can either be linked or embedded within the stream. Common picture file formats are supported (jpg and png). A description may be included and the picture type (front cover, back cover...) and image mime type are provided. Base64 encoded data is invariant under UTF-8 and a valid UTF-8 string, so obeys the rules for comment data. Failure to decode a picture block should not prevent playback of the file (failure to deal with the particularly large packet required by the comment header is a separate problem with the player implementation). Base64 encoding is used as in section 4 of RFC4648 . We note that line feeds are not allowed and padding characters ('=') are required. Applications adding picture blocks should inform users that some applications or hardware may not support them and should provide a method to remove the blocks (this is expected to be trivial for applications capable of adding them). The unencoded format is that of the FLAC picture block . The fields are stored in big endian order as in FLAC, picture data is stored according to the relevant standard. Picture data should be stored in PNG or JPEG formats or linked separately. It is recommended readers support both PNG and JPEG Allowed values for the MIME string are "image/", "image/png", "image/jpeg" and "-- " (the link indicator) and "" (length 0). An empty MIME string indicates type "image/" Fields present in the ID3V2.4.0 Attached Picture Frame (APIC Frame) take the same interpretation as in the ID3V2.4.0 format with the following exceptions (following the FLAC format): The description field is UTF-8 (encoded without ID3V2's initial 'encoding byte') String fields are not null terminated: their preceding length fields are used instead. Support for linked images is optional for applications handling picture blocks. When a linked picture is indicated the following rules are observed: The picture data is a complete URL indicating the picture to be used, relative URLs are allowed (note relative URLs do not start with a protocol specifier and are retrieved with the same protocol as the file being processed). Links are ISO-8859-1 encoded Applications MAY retrieve linked images via the file:// protocol. Applications MUST obtain user approval if they wish to retrieve images via remote protocols. Link targets may become unavailable: applications supporting linked images SHOULD recover gracefully from this and MAY report the absence to the user. The type of the linked file is not restricted to JPEG and JFIF and applications MAY support other formats If the application does not support linked images, the target is unavailable, not pe