Difference between revisions of "SHOUTcast XML Metadata Specification"
m (Updates for forthcoming changes)
|Line 1:||Line 1:|
Revision as of 22:57, 28 October 2014
- 1 Introduction
- 2 Specification Details
- 3 General Comments
- 4 Non-MP3 Field Mapping
The aim of this file is to show the different aspects of metadata which can be obtained as part of the SHOUTcast 2.0 system. This aims to be a complete list of what is provided in the xml file which the server will provide and is based on the metadata obtained from the media being played (directly or guessed). As a result, not all fields will be filled in though this depends on the setup being used and what the SHOUTcast source implements.
The following is an example xml file output showing the different aspects of the metadata which could be returned along with specific notes about certain fields i.e. those which can appear multiple times or those from older mappings. One thing to notice is that this is somewhat similar to the ID3v2.3 tag as well as some aspects of the ID3v2.4 tag.
Actual SHOUTcast 2 sources are not guaranteed to return the majority of the fields shown but provision is provided for them to be sent if detected from source media.
Extended Specification Details
The main section of the xml file is to provide metadata information from the source media as has been shown in the previous section. In additon to this, there is an extension for the information provided which is optional and is for providing title information for the media to follow the currently playing source media.
The extended section goes instead the <metadata/> block and is formatted as follows:
<extension> <!-- Title of the currently playing media --> <title seq="1">Artist - Title</title> <title seq="2">The Next Artist - The Next Title</title> . <!-- Titles go upto the maximum number of titles the source knows off --> <title seq="XX">The Last Artist - The Last Title</title> <!-- Title of the next item to be played --> <soon>The Next Artist - The Next Title</soon> </extension>
There is not a limit on how many titles can be sent though there is not much benefit of sending many titles as the SHOUTcast server is unlikely to use more than the current and the next titles. However the means to provide more titles is provided if there is a need.
The format of the titles after seq=1 need to be in the form of 'artist - title' where it is possible to format and provide the titles in this manner, otherwise just 'title' will suffice.
Where possible titles for seq=1 also need to be provided in the same manner as 'artist - title' though the DNAS will typically ignore this and generate the title to show clients based on the actual metadata passed. However it may resort to using this if there is an issue with the metadata provided, so ideally this title should be providing the fully formed version as well as for all other titles provided (as mentioned previously).
The <soon/> block must correctly report the title of the next item to be played otherwise it must be not specified in the xml if it is not known or cannot be reliably obtained e.g.
- Using older versions of Winamp (prior to v5.61) in shuffle mode, there is no ability to query the next item to be played and so <soon/> would not be set.
- Using any Winamp version not in shuffle mode, then it is possible to calculate the next item and so <soon/> can be set.
The TDRC (recording time) field is used to replace the following date specifiers from the ID3v2.3 tag if found - TDAT, TYER and TIME. This is done to form 'yyyy-MM-ddTHH:mm:ss'. Additionally, if no TYER is found but TRDC is then the TYER field will be generated from the TRDC field for backwards compatibility.
The TDOR (original release time) will be created from the TORY (original release year) if the TORY field is read from the file, otherwise no other mapping of these fields happens.
Suggested Fields To Support
If an xml file is able to be created, then the minimum which can be provided is the TIT2 entry due to this being the most important information used throughout the SHOUTcast 2.0 system especially when working with legacy client connections. The following example xml shows the minimum which can be provided and is equivalent of the typical v1 style of the metadata formatted as 'artist - title' :
<?xml version="1.0" encoding="UTF-8" ?> <metadata> <TIT2>Song Title - Song Artist</TIT2> </metadata>
The typical metadata fields expected to be available from sources, though not guaranteed as the information may not be available from the source media are as follows:
Tag Name Description TIT2 Title TALB Album TPE1 Artist TYER Year COMM Comment TCON Genre TRSN Stream Title WORS Station Website TENC Identifier for the Source e.g. SHOUTcast Source DSP Plug-in v2.1.3 042
It can be noted that this is similar to the information available from an ID3v1 tag with some stream related additions. However this is just a recommendation which provides the client some greater flexibility over the handling of the stream metadata. If not then the least number of fields to support should ideally be TIT2, TCON, TRSN, WORS and TENC.
The following example shows a complete xml metadata response with the suggested fields (excluding the Extended Specification Details):
<?xml version="1.0" encoding="UTF-8" ?> <metadata> <TIT2>I Was Made For Lovin' You</TIT2> <TALB>The Very Best Of KISS</TALB> <TPE1>Kiss</TPE1> <TYER>2002</TYER> <COMM></COMM> <TCON>Hard Rock</TCON> <TRSN>My Radio Station</TRSN> <WORS>http://www.shoutcast.com</WORS> <TENC>SHOUTcast Source DSP v126.96.36.199</TENC> </metadata>
Anyone using the xml file should not fail if tags appear in it which have not been listed in this document. In situations where this does happen then these extra tags should just be ignored. Some of the tags not considered in this version are:
Tag Name Description MLLT MPEG audio lookup tables for seeking SYTC Synchronized tempo codes (table of tempo changes in music and how) SYLT Synchronized lyrics RVAD Relative volume adjustment EQUA Equalization RVRB Reverb RBUF Recommended buffer size AENC Audio encryption LINK Linked ID3v2 data OWNE Date of purchase COMR Commercial purchase offers ENCR Encryption method registration GRID Group identification registration
GEOB - General Binary Glob
mime - mime type filename - associated filename id = text identifier Data is base64 encoded
APIC - Picture Data
IMPORTANT NOTE: Support of APIC in the xml file is now deprecated as of March 2011 and is instead provided as an in-stream packet of its own instead of in this.
ETCO - Event Code Field
The ETCO tag has a format property where the supported values are:
0 - absolute time in MPEG frames 1 - absolute time in milliseconds
The ETCO tag can have one or more event sub-tags. The type property for the event tag is the type of event we're interested in (see ID3v2 docs for list of codes). The time property is the time the event occurs in units indicated by the format property of the outer ETCO tag.
TCON - Genre Field
TCON has a complicated internal format which consists of a series of optional genre codes stored in parenthesis which are followed by subgenre clarification strings (though everything is optional) e.g.
(24)Death Metal (12)(24)Cuban (15) Die Kitty Die (24)Death Metal(12)Cuban
There are also two special 'codes' where 'RX' means remix and 'CR' means cover.
Due to genre being something we care about it is parsed as indicated in the example xml.
TMED - Media Type Field
The TMED field has a somewhat complicated internal format in that it can be just a string or it can be a media reference from a predefined list with a refinement e.g.
From my album collection (VID) (VID)Stereo (TT/45)From my old 45 collection
This field is not currently as important to be parsed out as with the genre (TCON) field but is provided for a more complete set of information.
Non-MP3 Field Mapping
This section covers the mapping of metadata for files other than MP3 as is supported by the the SHOUTcast 2.0 tools.
If an ID3v2 tag is found then handling will follow the standard MP3 handling. If there is no tag then metadata guessing will be used as appropriately.
If there are any Vorbis comment are found in the FLAC file then the following mappings will be used to get an equivalent complement of metadata to match what is read from an ID3v2 tag:
Vorbis Comment ID3v2 Entry Vorbis Comment ID3v2 Entry TITLE TIT2 VERSION TPE4 ALBUM TALB TRACKNUMBER TRCK TRACK TRCK TOTALTRACKS TRCK ARTIST TPE1 PERFORMER TPE2 COPYRIGHT TCOP LICENSE TOWN ORGANIZATION TPUB ORGANISATION TPUB GENRE TCON DATE TDRC ISRC TSRC ALBUMARTIST TPE2 ALBUM ARTIST TPE2 COMMENT COMM COMPOSER TCOM PUBLISHER TPUB DISCNUMBER TPOS DISKNUMBER TPOS DISC TPOS DISK TPOS TOTALDISKS TPOS TOTALDISCS TPOS BAND TPE2 LYRICS USLT CONDUCTOR TPE3 ENCODING SETTINGS TSSE ENCODER SETTINGS TSSE ENCODERSETTINGS TSSE BPM TBPM RATING POPM COVERARTMIME APIC COVERART APIC
Fields which are not in this list are then mapped to the custom text (TXXX) field with the key being the "description". Any picture metadata in the file will be mapped to the APIC field which is then transmitted in its own in-stream packet instead of in the xml.
OGG files are handled in a similar manner to FLAC files though there are some differences with the them. As there is no picture metadata in OGG files the COVERARTMIME and COVERART fields will be mapped to the APIC field due to a number of programmes which generate and adding artwork to OGG files in this way.