Merge media-player from git://gitorious.org/xdg-specs/xdg-specs.gitmedia-player

5 files changed, 1790 insertions, 0 deletions

diff --git a/media-player/changelog b/media-player/changelog
new file mode 100644
index 0000000..2c49764
--- /dev/null
+++ b/media-player/changelog
@@ -0,0 +1,70 @@
+1.1
+
+October 16, 2010
+  * Version 1.1 released. Updates escaping of colons, backslashes, and
+    semicolons.
+
+1.0
+
+September 9, 2010
+  * Version 1.0 released
+
+1.0 RC3
+
+September 1, 2010
+  * Fleshing out of the Compilations tag to allow album identifiers.
+
+1.0 RC2
+
+July 14th, 2010
+  * Wording changes
+  * Slightly more detail about compilations
+
+July 13, 2010
+  * Change license
+  * Add RFC-style language
+
+1.0 RC1
+
+May 30, 2010:
+  * Update string language and choices
+  * Add license
+  * Some standardization
+
+Fourth Draft
+
+April 15, 2010:
+  * Near complete revamp, fitting into constraints on identifier character
+    sets.
+  * Added compilation section.
+  * More detailed fleshing out of most information.
+
+January 25, 2010:
+  * Reworded abstract.
+  * Added lyrics section.
+  * Added multiple user support.
+  * Other small fixes/changes.
+
+Third Draft
+
+November 13, 2009:
+  * Clarified that full stops/periods must be used at all times for float
+    values.
+  * Moved tag sections up top and consolidated redundant information.
+  * Added WMA/APEv2/MP4 information.
+  * Implemented suggestions regarding naming of canonical and non-canonical
+    identifiers.
+
+Second Draft
+
+November 3, 2009:
+  * Removed integer/float. Everything uses float now.
+  * Clarify many things, including calculation of playcount.
+  * Reduced complexity of ignore files. Now they are just checked for
+    existence, not contents.
+
+First Draft
+
+October 14, 2009:
+  * Initial proposed draft.
+
diff --git a/media-player/metadata.xml b/media-player/metadata.xml
new file mode 100644
index 0000000..0fb87b4
--- /dev/null
+++ b/media-player/metadata.xml
@@ -0,0 +1,50 @@
+<specification title="Free Media Player Specifications">
+<description>This specification describes various metadata and behavioral items intended to reduce complexity and enhance functionality for users of free music and media players. It does this by proposing standards for common functionality needs where none currently exist.</description>
+
+<versions>
+    <version name="1.0">
+        <description>Free Music Player Specifications</description>
+        <date>09-09-2010<date>
+        <current/>
+    </version>
+</versions>
+
+<contributors>
+    <author vcard="K4jrIh97TD"\>
+<contributors>
+
+<adopters>
+    <organization name="Amarok" status="Participating">
+        <version name="Amarok" status="Participating" specversion="0.4draft"/>
+    </organization>
+
+    <organization name="Ampache" status="Participating">
+        <version name="Ampache" status="Participating" specversion="0.4draft"/>
+    </organization>
+
+    <organization name="Banshee" status="Participating">
+        <version name="Banshee" status="Participating" specversion="0.4draft"/>
+    </organization>
+
+    <organization name="Quod Libet" status="Participating">
+        <version name="Quod Libet" status="Participating" specversion="0.4draft"/>
+    </organization>
+
+    <organization name="Songbird" status="Participating">
+        <version name="Songbird" status="Participating" specversion="0.4draft"/>
+    </organization>
+
+    <organization name="VideoLAN" status="Participating">
+        <version name="VideoLAN" status="Participating" specversion="0.4draft"/>
+    </organization>
+
+    <organization name="XMMS2" status="Participating">
+        <version name="XMMS2" status="Participating" specversion="0.4draft"/>
+    </organization>
+
+    <organization name="Youki" status="Participating">
+        <version name="Youki" status="Participating" specversion="0.4draft"/>
+    </organization>
+
+</adopters>
+</specification>
diff --git a/media-player/specification.lyx b/media-player/specification.lyx
new file mode 100644
index 0000000..2a61fe9
--- /dev/null
+++ b/media-player/specification.lyx
@@ -0,0 +1,1049 @@
+#LyX 1.6.7 created this file. For more info see http://www.lyx.org/
+\lyxformat 345
+\begin_document
+\begin_header
+\textclass docbook
+\use_default_options false
+\language english
+\inputencoding auto
+\font_roman default
+\font_sans default
+\font_typewriter default
+\font_default_family default
+\font_sc false
+\font_osf false
+\font_sf_scale 100
+\font_tt_scale 100
+
+\graphics default
+\paperfontsize default
+\use_hyperref false
+\papersize default
+\use_geometry false
+\use_amsmath 0
+\use_esint 0
+\cite_engine basic
+\use_bibtopic false
+\paperorientation portrait
+\secnumdepth 3
+\tocdepth 3
+\paragraph_separation indent
+\defskip medskip
+\quotes_language english
+\papercolumns 1
+\papersides 1
+\paperpagestyle default
+\tracking_changes false
+\output_changes false
+\author "" 
+\author "" 
+\end_header
+
+\begin_body
+
+\begin_layout Title
+Free Media Player Specifications
+\end_layout
+
+\begin_layout Title
+Tag Specification
+\end_layout
+
+\begin_layout Date
+version 1.1; October 16, 2010
+\end_layout
+
+\begin_layout Author
+Copyright 2009-2010 by 
+\begin_inset Flex Element:Firstname
+status collapsed
+
+\begin_layout Plain Layout
+Jeff
+\end_layout
+
+\end_inset
+
+ 
+\begin_inset Flex Element:Surname
+status collapsed
+
+\begin_layout Plain Layout
+Mitchell
+\end_layout
+
+\end_inset
+
+ 
+\begin_inset CommandInset href
+LatexCommand href
+target "mitchell@kde.org"
+type "mailto:"
+
+\end_inset
+
+
+\end_layout
+
+\begin_layout Abstract
+This specification describes various audio file tag metadata intended to
+ increase interoperability between free music players for things such as
+ ratings, playcounts, performer roles, and more.
+ It does this by proposing standards for common functionality needs where
+ none currently exist, and doing so in a way that is easily adoptable cross-play
+er and cross-format.
+ It is designed to be robust against future needs and to prevent possible
+ conflicts with other tag identifiers and values.
+\end_layout
+
+\begin_layout Standard
+\begin_inset CommandInset toc
+LatexCommand tableofcontents
+
+\end_inset
+
+
+\end_layout
+
+\begin_layout Section
+Front Matter
+\end_layout
+
+\begin_layout Subsection
+License
+\end_layout
+
+\begin_layout Standard
+You may use this specification under either of the following licenses, at
+ your discretion.
+ Most will want to use it under Creative Commons; the GPL alternative is
+ in case future versions of the spec contain e.g.
+ code snippets that you would like to use in GPL programs:
+\end_layout
+
+\begin_layout Enumerate
+This specification is licensed under the Creative Commons Attribution-Share
+ Alike 3.0 Unported License.
+ You are free to copy, distribute and transmit this work, provided that
+ the copyright information and full URL to the license information page
+ (
+\begin_inset Flex URL
+status collapsed
+
+\begin_layout Plain Layout
+
+http://creativecommons.org/licenses/by-nd/3.0/
+\end_layout
+
+\end_inset
+
+) remain intact.
+ If you alter, transform, or build upon this work, you may distribute the
+ resulting work only under the same or similar license to this one.
+ 
+\end_layout
+
+\begin_layout Enumerate
+This program is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your option)
+ any later version.
+ This program is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
+ FOR A PARTICULAR PURPOSE.
+ See the GNU General Public License for more details.
+ See 
+\begin_inset Flex URL
+status collapsed
+
+\begin_layout Plain Layout
+
+http://www.gnu.org/licenses/
+\end_layout
+
+\end_inset
+
+.
+ 
+\end_layout
+
+\begin_layout Subsection
+Terminology
+\end_layout
+
+\begin_layout Standard
+Terminology follws that specified in RFC2119, 
+\begin_inset Quotes eld
+\end_inset
+
+Key words for use in RFCs to Indicate Requirement Levels
+\begin_inset Quotes erd
+\end_inset
+
+.
+ See 
+\begin_inset Flex URL
+status collapsed
+
+\begin_layout Plain Layout
+
+http://www.ietf.org/rfc/rfc2119.txt
+\end_layout
+
+\end_inset
+
+ for more information.
+\end_layout
+
+\begin_layout Section
+Audio Metadata Tags
+\end_layout
+
+\begin_layout Standard
+The metadata tag formats evolved from Quod Libet's VorbisComments suggestions
+ at 
+\begin_inset Flex URL
+status collapsed
+
+\begin_layout Plain Layout
+
+http://code.google.com/p/quodlibet/wiki/Specs_VorbisComments
+\end_layout
+
+\end_inset
+
+, however this attempts to not only address ambiguities and incompatibilities
+ with the specification at that URL, but also to define how this functionality
+ should be applied across formats.
+ It is intended that as usable ways of inserting the metadata described
+ become available for formats not currently specified, that this document
+ will be updated to meet those needs.
+\end_layout
+
+\begin_layout Standard
+All newly-specified tags carry an identifier 
+\begin_inset Quotes eld
+\end_inset
+
+FMPS_
+\begin_inset Quotes erd
+\end_inset
+
+ to tie the tags to this specification.
+ The reason is simple: since the official metadata specifications either
+ fail to define or define unusable tags, these values are only official
+ to the extent that this specification is adopted.
+ Without an identifier to give context to the meanings and limitations of
+ the values, there is a real possibility that a noncompliant media player
+ will use the same tag names in an incompatible fashion, whether intentionally
+ or not, and there is no way to determine whether a seemingly compatible
+ use of the tags by a noncompliant player actually results in user-intended
+ behavior.
+ The 
+\begin_inset Quotes eld
+\end_inset
+
+FMPS_
+\begin_inset Quotes erd
+\end_inset
+
+ identifier and this specification document is therefore used in a similar
+ fashion to XML schema declarations.
+\end_layout
+
+\begin_layout Standard
+As these identifiers are read and modified only by players and advanced
+ users, it is not expected to be a hindrance to adoption or to cause undue
+ burden on either.
+\end_layout
+
+\begin_layout Subsection
+Common Data and Tag Information
+\end_layout
+
+\begin_layout Standard
+This section provides 
+\begin_inset Quotes eld
+\end_inset
+
+up-front
+\begin_inset Quotes erd
+\end_inset
+
+ information that is pertinent to all tags described below, such as what
+ encoding to use and which tags to use in various formats.
+\end_layout
+
+\begin_layout Standard
+For all tag formats, the following is defined:
+\end_layout
+
+\begin_layout Itemize
+All identifiers are ASCII strings, and defined in the sections below.
+ All identifier strings must escape each colon (':'), semicolon (';') and
+ backslash ('
+\backslash
+') with a backslash.
+\end_layout
+
+\begin_layout Itemize
+All values (including numeric values) are stored as strings, which MUST
+ adhere to the allowed encoding and length limits in the relevant tag format
+ specifications, but SHOULD use Unicode whenever possible.
+\end_layout
+
+\begin_deeper
+\begin_layout Itemize
+To keep the specification simple, no ranges of control characters are defined
+ which should never be included in a string.
+ It is assumed that the used string-handling library will properly handle
+ any such characters encountered.
+ It is highly recommended, however, that no such control characters are
+ used, except when specified below.
+\end_layout
+
+\begin_layout Itemize
+All value strings must escape each colon (':'), semicolon (';') and backslash
+ ('
+\backslash
+') with a backslash.
+ 
+\end_layout
+
+\end_deeper
+\begin_layout Itemize
+Although identifier case is specified for the different types of tags, compariso
+ns against identifier strings MUST be case-insensitive.
+\end_layout
+
+\begin_layout Itemize
+A period/full stop is used to separate the digits in a float value from
+ the fractional part of the float.
+ All float values MUST include a period/full stop (1 is not acceptable;
+ 1.0 is correct).
+\end_layout
+
+\begin_layout Itemize
+Float values SHOULD be limited to six decimal places.
+\end_layout
+
+\begin_layout Itemize
+All lists are value strings.
+ For any lists, entries MUST be separated with a double semicolon ';;' and
+ fields within an entry MUST be separated with a double colon '::' (examples
+ in following sections).
+ These separation markers MUST NOT be escaped with backslashes.
+ This allows for easy splitting of list entries and entry fields with most
+ string libraries; the entries and fields can be split by double semicolon/doubl
+e colon, and the ensuing fields can have any escaped values substituted.
+\end_layout
+
+\begin_layout Standard
+The following sections describe where the information should be stored in
+ specific tag formats.
+\end_layout
+
+\begin_layout Subsubsection
+MP3
+\end_layout
+
+\begin_layout Standard
+MP3 values MUST be stored in a TXXX frame with the Description set to the
+ specified identifier and the Text set to the string representation of the
+ value.
+ The Description SHOULD be in CamelCase as specified in the following sections,
+ e.g.
+ FMPS_Rating.
+\end_layout
+
+\begin_layout Subsubsection
+VorbisComments
+\end_layout
+
+\begin_layout Standard
+Any file supporting VorbisComments (Vorbis, FLAC, Theora, Speex) MUST use
+ a comment with the Key set to the specified identifier and the Value set
+ to the string representation of the value.
+ The Key SHOULD be in all upper-case, e.g.
+ FMPS_RATING.
+\end_layout
+
+\begin_layout Subsubsection
+APEv2
+\end_layout
+
+\begin_layout Standard
+Any file supporting APEv2 MUST add a comment with the Key set to the specified
+ identifier and the Value set to the string representation of the value.
+ The Key SHOULD be in all upper-case, e.g.
+ FMPS_RATING.
+\end_layout
+
+\begin_layout Subsubsection
+MP4
+\end_layout
+
+\begin_layout Standard
+MP4 values MUST be stored at ----:com.apple.iTunes:Identifier with the value
+ a string representation of the tag's value.
+ The Identifier SHOULD be in CamelCase as specified in the following sections,
+ e.g.
+ FMPS_Rating.
+\end_layout
+
+\begin_layout Subsubsection
+Windows Media
+\end_layout
+
+\begin_layout Standard
+Windows Media values MUST be stored in the FMPS/Identifier namespace with
+ the value a string representation of the tag's value.
+ The Identifier SHOULD be in CamelCase as specified in the following sections,
+ e.g.
+ FMPS_Rating.
+\end_layout
+
+\begin_layout Subsection
+Rating Tags
+\end_layout
+
+\begin_layout Standard
+Most media players support the notion of rating content, however standards
+ for storing ratings in files do not exist.
+ Some file metadata formats completely lack rating fields; others require
+ personally identifiable information to be used as an identifier (such as
+ a user's email address) or an organizational identifier (which reduces
+ cross-player compatibility).
+ The goal therefore is simple: to avoid any personally identifying information
+ but to avoid tying the rating to a specific player.
+\end_layout
+
+\begin_layout Standard
+Three types of ratings are currently defined: user ratings, critic ratings,
+ and automatic (or algorithmic) ratings.
+\end_layout
+
+\begin_layout Standard
+Although users are more naturally able to understand integer ratings, only
+ advanced users will interact with these tags directly; otherwise they will
+ be presented to the user via a conforming application.
+ Meanwhile, there are tangible benefits to storing ratings as floating-point
+ numbers, mainly due to the fact that the increased precision allows for
+ a number of interesting and useful algorithmic rating schemes to be used.
+ However, using both integer and floating-point values unnecessarily increases
+ complexity of both this spec and application code.
+ Therefore, both values are stored as floating-point numbers.
+ Conversion to and from these and an integer scale presented to the user
+ in an application is easily accomplished in the application's code if it
+ is so desired.
+\end_layout
+
+\begin_layout Standard
+Four tags are defined, corresponding to the three types of defined ratings,
+ plus a canonical value: FMPS_Rating_User; FMPS_Rating_Critic; FMPS_Rating_Algor
+ithm; and FMPS_Rating (the canonical value).
+ A file that has no rating tag for a specific purpose is to be considered
+ unrated for that purpose (user, critic or algorithm).
+\end_layout
+
+\begin_layout Subsubsection
+All Rating Tags
+\end_layout
+
+\begin_layout Itemize
+Ratings SHALL be a float value between 0.0 and 1.0, inclusive.
+ 0.0 SHALL be the lowest possible rating; 1.0 is the highest possible rating.
+\end_layout
+
+\begin_layout Itemize
+Ratings SHOULD only be rounded when necessary, in order to increase cross-player
+ compatibility.
+\end_layout
+
+\begin_layout Subsubsection
+FMPS_Rating
+\end_layout
+
+\begin_layout Itemize
+The canonical rating value in FMPS_Rating SHOULD be set whenever a user
+ rates the track.
+ This is in addition to any value stored for that particular user in FMPS_Rating
+_User.
+ This value is canonical because if a player does not support multiple users
+ (or if no user identifier is set), this is the value that MUST be returned.
+\end_layout
+
+\begin_layout Itemize
+If a user removes ratings from a track in the media player's database, the
+ value of the FMPS_Rating tag SHOULD be cleared as well.
+\end_layout
+
+\begin_layout Subsubsection
+FMPS_Rating_User
+\end_layout
+
+\begin_layout Itemize
+If a player supports the notion of multiple users (perhaps from discovery
+ of the current user from the operating system) and wishes to allow the
+ users to keep separate ratings, it MUST store these values in the FMPS_Rating_U
+ser tag.
+\end_layout
+
+\begin_layout Itemize
+Applications supporting multiple user ratings SHOULD have a way for users
+ to define their preferred identifier.
+ 
+\end_layout
+
+\begin_layout Itemize
+The values are in the form of a list as defined in Section 2.1, with list
+ entries in the format of UserIdentifier::Value.
+ There MUST NOT be empty value strings.
+\end_layout
+
+\begin_layout Standard
+Example: 
+\begin_inset Quotes eld
+\end_inset
+
+Alice Abba::0.6;;Bob Beatles::0.8
+\begin_inset Quotes erd
+\end_inset
+
+.
+\end_layout
+
+\begin_layout Subsection
+FMPS_Rating_Critic
+\end_layout
+
+\begin_layout Itemize
+The values MUST be in the form of a list as defined in Section 2.1, with
+ list entries in the format of Publication::Critic::Rating.
+ If the critic is unaffiliated, or if the rating is by a publication with
+ no byline, the special value 
+\begin_inset Quotes eld
+\end_inset
+
+FMPS_Nothing
+\begin_inset Quotes erd
+\end_inset
+
+ MUST be used to denote this; there MUST NOT be empty strings.
+\end_layout
+
+\begin_layout Standard
+Example: 
+\begin_inset Quotes eld
+\end_inset
+
+Rolling Stone::Ralph Gleason::0.83;;musicOMH.com::FMPS_Nothing::0.76;;Metacritic::F
+MPS_Nothing::0.8;;FMPS_Nothing::Some Dude::0.9
+\begin_inset Quotes erd
+\end_inset
+
+
+\end_layout
+
+\begin_layout Subsubsection
+FMPS_Rating_Algorithm
+\end_layout
+
+\begin_layout Itemize
+The values MUST be in the form of a list as defined in Section 2.1, with
+ list entries in the format of Application::Algorithm::Rating.
+ All fields MUST be defined; fields MUST NOT be left empty.
+\end_layout
+
+\begin_layout Itemize
+In cases where the algorithm is intended to be global/collaborative/cross-applic
+ation, the Application value SHOULD be set to some agreed-upon value.
+ In other words, it is RECOMMENDED to use the application name for the Applicati
+on part of the identifier, but it MAY also be used to identify a 
+\begin_inset Quotes eld
+\end_inset
+
+group
+\begin_inset Quotes erd
+\end_inset
+
+ of algorithms, or some arbitrary other value that can be used for identificatio
+n.
+\end_layout
+
+\begin_layout Standard
+Example: 
+\begin_inset Quotes eld
+\end_inset
+
+Amarok::AutoRate::0.52;;VLC::Standard::0.6;;QuodLibet::RatingPlugin
+\backslash
+:X::0.35;;The Free Music Player Alliance::Rating Algorithm 1::0.5
+\begin_inset Quotes erd
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
+A note on the floating point values: some players may only allow users to
+ rate in increments of whole numbers between 1 and 5; others 0 and 10; and
+ so on.
+ However, players SHOULD ensure that the rating they display and use for
+ any purpose adheres to that saved in the tag whenever possible, only rounding
+ this number when absolutely necessary.
+\end_layout
+
+\begin_layout Standard
+For instance, if a track has a rating of 0.9 and an application only shows
+ ratings using five star icons in full-star increments, this would be rounded
+ within the application to five stars.
+ Howeer, if the player also shows the rating numerically, the application
+ would display 4.5 in the numeric field instead of the same 5 shown in the
+ star icons, thus more accurately reflecting the user's set rating.
+\end_layout
+
+\begin_layout Subsection
+Playcount Tags
+\end_layout
+
+\begin_layout Standard
+As with ratings, there are multiple kinds of playcount tags (user and algorithmi
+c) in addition to a canonical value.
+ The user tag tracks how many times a song has been played for a user.
+ The auto/algorithmic value can be used in an application-specific way to
+ do interesting things; for instance, to cumulatively track exact percentages
+ of tracks played, in order to display to the user the number of days/hous/minut
+es/seconds they have spent listening to a particular song.
+ 
+\end_layout
+
+\begin_layout Standard
+Three tags are defined, corresponding to the two types of defined playcounts,
+ plus a canonical value: FMPS_Playcount_User; FMPS_Playcount_Algorithm;
+ and FMPS_Playcount (the canonical value).
+ A file that has no playcount tag for a specific purpose is to be considered
+ unplayed for that purpose (user or algorithm).
+\end_layout
+
+\begin_layout Subsubsection
+All Playcount Tags
+\end_layout
+
+\begin_layout Itemize
+Playcounts MUST be a float value not less than 0.0.
+ 0.0 is valid and means unplayed.
+\end_layout
+
+\begin_layout Itemize
+The maximum value SHALL be 0.000001 less than the largest value able to be
+ stored in a 32-bit unsigned integer: 4,294,967,294.999999.
+ This is so that playcount values can be rounded to an integer equivalent,
+ if necessary (e.g.
+ for display to the user).
+\end_layout
+
+\begin_layout Subsubsection
+User Playcount Criteria
+\end_layout
+
+\begin_layout Standard
+The user playcount isn't meant to be set by the user, but rather to follow
+ these rules that define user behavior.
+ A file is to be considered 
+\begin_inset Quotes eld
+\end_inset
+
+played
+\begin_inset Quotes erd
+\end_inset
+
+ if it meets the following criteria, inspired by Last.fm's scrobbling rules:
+\end_layout
+
+\begin_layout Itemize
+If the track is less than thirty seconds long, the entire song MUST be played.
+\end_layout
+
+\begin_layout Itemize
+If the track is more than thirty seconds long but less than eight minutes
+ long, at least fifty percent of the file MUST be played, calculated via
+ length of track.
+ For instance, if a track is one minute long, at least thirty seconds of
+ the track must have been played, although if the user skips backwards multiple
+ times and listens to the same ten seconds of the track three times in a
+ row, this may be considered a valid playcount.
+\end_layout
+
+\begin_layout Itemize
+If the track is longer than eight minutes, at least four minutes of the
+ track MUST be played.
+\end_layout
+
+\begin_layout Standard
+User playcounts have an additional restriction in that they MUST be float
+ values representing integers (1.0, 141.0, etc.).
+ They are never fractional values; a song was either played, or it wasn't.
+\end_layout
+
+\begin_layout Subsubsection
+FMPS_Playcount
+\end_layout
+
+\begin_layout Itemize
+The canonical playcount value in FMPS_Playcount SHOULD be set whenever a
+ user plays a track.
+ This is in addition to any value stored for that user in FMPS_Playcount_User.
+ This value is canonical because if a player does not support multiple users
+ (or if no user identifier is set) this is the value that MUST be returned.
+\end_layout
+
+\begin_layout Itemize
+If a user has an identifier set to store per-user playcounts, when this
+ value is set it MUST be set to the value of that user's playcount.
+ In other words, the last value held in FMPS_Playcount will be equivalent
+ to the latest user's personal playcount, if any.
+\end_layout
+
+\begin_layout Itemize
+If a user resets the playcount for a track in the media player's database,
+ the value of the FMPS_Playcount tag SHOULD be cleared as well.
+\end_layout
+
+\begin_layout Itemize
+FMPS_Playcount MUST store 
+\begin_inset Quotes eld
+\end_inset
+
+full plays
+\begin_inset Quotes erd
+\end_inset
+
+ of a track according to the rules in Section 2.4.2.
+\end_layout
+
+\begin_layout Subsubsection
+FMPS_Playcount_User
+\end_layout
+
+\begin_layout Itemize
+If a player supports the notion of multiple users (perhaps from discovery
+ of the current user from the operating system) and wishes to allow the
+ users to keep separate playcounts, it MUST store these values in the FMPS_Playc
+ount_User tag.
+\end_layout
+
+\begin_layout Itemize
+Applications supporting multiple user playcounts SHOULD have a way for users
+ to define their preferred identifier.
+ 
+\end_layout
+
+\begin_layout Itemize
+The values MUST be in the form of a list as defined in Section 2.1, with
+ list entries in the format of UserIdentifier::Value.
+ There MUST NOT be empty strings.
+\end_layout
+
+\begin_layout Itemize
+FMPS_Playcount_User MUST store 
+\begin_inset Quotes eld
+\end_inset
+
+full plays
+\begin_inset Quotes erd
+\end_inset
+
+ of a track according to the rules in Section 2.4.2.
+\end_layout
+
+\begin_layout Standard
+Example: 
+\begin_inset Quotes eld
+\end_inset
+
+Alice Abba::1.0;;Bob Beatles::133.0
+\begin_inset Quotes erd
+\end_inset
+
+.
+\end_layout
+
+\begin_layout Subsubsection
+FMPS_Playcount_Algorithm
+\end_layout
+
+\begin_layout Itemize
+The values MUST be in the form of a list as defined in Section 2.3.1, with
+ list entries in the format of Application::Algorithm::Playcount.
+ All fields MUST be defined; fields MUST NOT be left empty.
+\end_layout
+
+\begin_layout Itemize
+In cases where the algorithm is intended to be global/collaborative/cross-applic
+ation, the Application value SHOULD be set to some agreed-upon value.
+ In other words, it is RECOMMENDED to use the application name for the Applicati
+on part of the identifier, but it MAY also be used to identify a 
+\begin_inset Quotes eld
+\end_inset
+
+group
+\begin_inset Quotes erd
+\end_inset
+
+ of algorithms, or some arbitrary other value that can be used for identificatio
+n.
+\end_layout
+
+\begin_layout Itemize
+For algorithms, a track's length MUST be considered to be worth 1.0 playcounts;
+ the user skipping parts of the track MAY decrease the value below 1.0, and
+ the user repeating parts of the track MAY increase this value past 1.0.
+\end_layout
+
+\begin_layout Standard
+Example: 
+\begin_inset Quotes eld
+\end_inset
+
+Amarok::AutoPlaycount::152.69;;VLC::Standard::198.0;;QuodLibet::PlaycountPlugin
+\backslash
+:X::1652.19;;The Music Player Alliance::Playcount Algorithm 1::0.5
+\begin_inset Quotes erd
+\end_inset
+
+
+\end_layout
+
+\begin_layout Subsection
+Performer Roles
+\end_layout
+
+\begin_layout Standard
+Performer roles allow you to describe the performers in a track.
+ Current support for these roles in tag formats is often sporadic or difficult
+ to parse.
+ As many of these tags as desired can be specified, to include all relevant
+ performer information.
+\end_layout
+
+\begin_layout Itemize
+Performer roles use the identifier 
+\begin_inset Quotes eld
+\end_inset
+
+FMPS_Performers
+\begin_inset Quotes erd
+\end_inset
+
+.
+ The value MUST be a list in the form of Performer::Role, where Role is
+ the user-defined role (
+\begin_inset Quotes eld
+\end_inset
+
+Guitar
+\begin_inset Quotes erd
+\end_inset
+
+, 
+\begin_inset Quotes eld
+\end_inset
+
+Guitar (Backup)
+\begin_inset Quotes erd
+\end_inset
+
+, 
+\begin_inset Quotes eld
+\end_inset
+
+Vocals
+\begin_inset Quotes erd
+\end_inset
+
+).
+\end_layout
+
+\begin_layout Standard
+Example: 
+\begin_inset Quotes eld
+\end_inset
+
+Willy Nelson::Guitar;;Eric Clapton::Guitar (Backup);;B.B.
+ King::Vocals
+\begin_inset Quotes erd
+\end_inset
+
+
+\end_layout
+
+\begin_layout Subsection
+Lyrics
+\end_layout
+
+\begin_layout Standard
+Embedding lyrics into a file allows users to save custom lyrics and to still
+ see the lyrics when not connected to the Internet.
+ Since different users may wish to have different sets of lyrics (for example,
+ if customizing lyrics against a music-only track) and different Internet
+ sources may have different lyrics, it is possible to store multiple lyrics
+ values by specifying a source.
+\end_layout
+
+\begin_layout Itemize
+The identifier for the (canonical) lyrics text is 
+\begin_inset Quotes eld
+\end_inset
+
+FMPS_Lyrics
+\begin_inset Quotes erd
+\end_inset
+
+.
+ The value MUST be a string.
+ Spaces, tabs, and newlines SHOULD be preserved when saving the string,
+ and SHOULD be displayed properly to the user.
+\end_layout
+
+\begin_layout Itemize
+Lyrics MAY also be stored in FMPS_Lyrics_Sources as a list (as defined in
+ Section 2.1), in which case the form MUST be Source::Data.
+\end_layout
+
+\begin_layout Standard
+Example: 
+\begin_inset Quotes eld
+\end_inset
+
+Alice Aardvark::[lyrics];;Bob Baboon::[lyrics];;http
+\backslash
+://www.lyricssite.net::[lyrics]
+\begin_inset Quotes erd
+\end_inset
+
+
+\end_layout
+
+\begin_layout Subsection
+Album/Compilation (
+\begin_inset Quotes eld
+\end_inset
+
+Various Artists
+\begin_inset Quotes erd
+\end_inset
+
+) Identifier
+\end_layout
+
+\begin_layout Standard
+Compilations (or 
+\begin_inset Quotes eld
+\end_inset
+
+Various Artists
+\begin_inset Quotes erd
+\end_inset
+
+ albums) can be difficult for music players to discover.
+ Sometimes the user places all files from a compilation in one directory
+ and expects that the music player will understand this; sometimes the user
+ has them in different directories but with the same album name and expects
+ that the music player will understand this; and so on.
+\end_layout
+
+\begin_layout Standard
+Although there are existing solutions to identify albums and songs that
+ belong to the same album (such as MusicBrainz identifiers) many users have
+ not or do not want to tag their songs with MusicBrainz information.
+ This tag therefore provides a simple way for an application to assign a
+ album identifier to a track, indicating to what album a track belongs.
+ It also provides a simple way of marking the album as a compilation or
+ not.
+\end_layout
+
+\begin_layout Standard
+This enables such use-cases as allowing a user to mark multiple tracks that
+ are part of a single compilation, and then have those tracks show up as
+ being together in a compilation the next time the user adds the tracks
+ to the music player.
+\end_layout
+
+\begin_layout Standard
+This section purposefully does not define information about the album/compilatio
+n; it is expected that the user must supply that information in appropriate
+ existing tags, e.g.
+ ALBUM and ALBUMARTIST for VorbisComments.
+\end_layout
+
+\begin_layout Itemize
+The identifier for the album/compilation tag is FMPS_Albums_Compilations.
+ Although this tag will be most useful for compilation/Various Artists albums,
+ there may still be significant utility for a player in using this tag to
+ identify single-artist albums.
+ As a result, players MUST NOT make assumptions about whether the presence
+ of this tag identifies the track as belonging to a compilation/Various
+ Artists album and MUST explicitly derive this information from the tag
+ value.
+\end_layout
+
+\begin_layout Itemize
+Values MUST be a list (as defined in Section 2.1) in the form of Application::Typ
+e::Identifier.
+ Applications MAY have more than one identifier, if the user wants to mark
+ a track as being present in multiple compilations, or to give user-defined
+ names to a compilation.
+ However, each list entry MUST be unique.
+ Similarly to other tags in this specification, there may be significant
+ utility in interoperating on the application names.
+\end_layout
+
+\begin_layout Itemize
+Type MUST be one of the following values, without quotes: 
+\begin_inset Quotes eld
+\end_inset
+
+Album
+\begin_inset Quotes erd
+\end_inset
+
+ (indicating a general-purpose album, usually by a single artist) or 
+\begin_inset Quotes eld
+\end_inset
+
+Compilation
+\begin_inset Quotes erd
+\end_inset
+
+ (indicating a compilation album, usually by multiple/various artists).
+ Checks against this value MUST be case-insensitive.
+ More values may be added in the future; if a player encounters an unknown
+ value it SHOULD default to type 
+\begin_inset Quotes eld
+\end_inset
+
+Album
+\begin_inset Quotes erd
+\end_inset
+
+.
+ 
+\end_layout
+
+\begin_layout Standard
+Example: 
+\begin_inset Quotes eld
+\end_inset
+
+Amarok::Album::2982ab29ef;;AmarokUser::Compilation::My Compilation;;Banshee::Com
+pilation::ad8slpbzl229zier;;FMPSAlliance::Album::de9f2c7fd25e1b3afad3e85a0bd17d9
+b100db4b3
+\begin_inset Quotes erd
+\end_inset
+
+
+\end_layout
+
+\end_body
+\end_document
diff --git a/media-player/specification.txt b/media-player/specification.txt
new file mode 100644
index 0000000..ac60e8e
--- /dev/null
+++ b/media-player/specification.txt
@@ -0,0 +1,529 @@
+Free Media Player Specifications
+
+Tag Specification
+
+version 1.1; October 16, 2010
+
+Copyright 2009-2010 by Jeff Mitchell [mitchell@kde.org]
+
+Abstract
+
+This specification describes various audio file tag metadata 
+intended to increase interoperability between free music players 
+for things such as ratings, playcounts, performer roles, and 
+more. It does this by proposing standards for common 
+functionality needs where none currently exist, and doing so in a 
+way that is easily adoptable cross-player and cross-format. It is 
+designed to be robust against future needs and to prevent 
+possible conflicts with other tag identifiers and values.
+
+Table of Contents
+
+    1 Front Matter
+        1.1 License
+        1.2 Terminology
+    2 Audio Metadata Tags
+        2.1 Common Data and Tag Information
+            2.1.1 MP3
+            2.1.2 VorbisComments
+            2.1.3 APEv2
+            2.1.4 MP4
+            2.1.5 Windows Media
+        2.2 Rating Tags
+            2.2.1 All Rating Tags
+            2.2.2 FMPS_Rating
+            2.2.3 FMPS_Rating_User
+        2.3 FMPS_Rating_Critic
+            2.3.1 FMPS_Rating_Algorithm
+        2.4 Playcount Tags
+            2.4.1 All Playcount Tags
+            2.4.2 User Playcount Criteria
+            2.4.3 FMPS_Playcount
+            2.4.4 FMPS_Playcount_User
+            2.4.5 FMPS_Playcount_Algorithm
+        2.5 Performer Roles
+        2.6 Lyrics
+        2.7 Album/Compilation (“Various Artists”) Identifier
+
+
+1 Front Matter
+
+1.1 License
+
+You may use this specification under either of the following 
+licenses, at your discretion. Most will want to use it under 
+Creative Commons; the GPL alternative is in case future versions 
+of the spec contain e.g. code snippets that you would like to use 
+in GPL programs:
+
+1. This specification is licensed under the Creative Commons 
+  Attribution-Share Alike 3.0 Unported License. You are free to 
+  copy, distribute and transmit this work, provided that the 
+  copyright information and full URL to the license information 
+  page (http://creativecommons.org/licenses/by-nd/3.0/) remain 
+  intact. If you alter, transform, or build upon this work, you 
+  may distribute the resulting work only under the same or 
+  similar license to this one. 
+
+2. This program is free software; you can redistribute it and/or 
+  modify it under the terms of the GNU General Public License as 
+  published by the Free Software Foundation; either version 2 of 
+  the License, or (at your option) any later version. This 
+  program is distributed in the hope that it will be useful, but 
+  WITHOUT ANY WARRANTY; without even the implied warranty of 
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 
+  GNU General Public License for more details. See http://www.gnu.org/licenses/
+  . 
+
+1.2 Terminology
+
+Terminology follws that specified in RFC2119, “Key words for use 
+in RFCs to Indicate Requirement Levels”. See http://www.ietf.org/rfc/rfc2119.txt
+ for more information.
+
+2 Audio Metadata Tags
+
+The metadata tag formats evolved from Quod Libet's VorbisComments 
+suggestions at http://code.google.com/p/quodlibet/wiki/Specs_VorbisComments
+, however this attempts to not only address ambiguities and 
+incompatibilities with the specification at that URL, but also to 
+define how this functionality should be applied across formats. 
+It is intended that as usable ways of inserting the metadata 
+described become available for formats not currently specified, 
+that this document will be updated to meet those needs.
+
+All newly-specified tags carry an identifier “FMPS_” to tie the 
+tags to this specification. The reason is simple: since the 
+official metadata specifications either fail to define or define 
+unusable tags, these values are only official to the extent that 
+this specification is adopted. Without an identifier to give 
+context to the meanings and limitations of the values, there is a 
+real possibility that a noncompliant media player will use the 
+same tag names in an incompatible fashion, whether intentionally 
+or not, and there is no way to determine whether a seemingly 
+compatible use of the tags by a noncompliant player actually 
+results in user-intended behavior. The “FMPS_” identifier and 
+this specification document is therefore used in a similar 
+fashion to XML schema declarations.
+
+As these identifiers are read and modified only by players and 
+advanced users, it is not expected to be a hindrance to adoption 
+or to cause undue burden on either.
+
+2.1 Common Data and Tag Information
+
+This section provides “up-front” information that is pertinent to 
+all tags described below, such as what encoding to use and which 
+tags to use in various formats.
+
+For all tag formats, the following is defined:
+
+• All identifiers are ASCII strings, and defined in the sections 
+  below. All identifier strings must escape each colon (':'), 
+  semicolon (';') and backslash ('\') with a backslash.
+
+• All values (including numeric values) are stored as strings, 
+  which MUST adhere to the allowed encoding and length limits in 
+  the relevant tag format specifications, but SHOULD use Unicode 
+  whenever possible.
+
+  – To keep the specification simple, no ranges of control 
+    characters are defined which should never be included in a 
+    string. It is assumed that the used string-handling library 
+    will properly handle any such characters encountered. It is 
+    highly recommended, however, that no such control characters 
+    are used, except when specified below.
+
+  – All value strings must escape each colon (':'), semicolon 
+    (';') and backslash ('\') with a backslash. 
+
+• Although identifier case is specified for the different types 
+  of tags, comparisons against identifier strings MUST be 
+  case-insensitive.
+
+• A period/full stop is used to separate the digits in a float 
+  value from the fractional part of the float. All float values 
+  MUST include a period/full stop (1 is not acceptable; 1.0 is 
+  correct).
+
+• Float values SHOULD be limited to six decimal places.
+
+• All lists are value strings. For any lists, entries MUST be 
+  separated with a double semicolon ';;' and fields within an 
+  entry MUST be separated with a double colon '::' (examples in 
+  following sections). These separation markers MUST NOT be 
+  escaped with backslashes. This allows for easy splitting of 
+  list entries and entry fields with most string libraries; the 
+  entries and fields can be split by double semicolon/double 
+  colon, and the ensuing fields can have any escaped values 
+  substituted.
+
+The following sections describe where the information should be 
+stored in specific tag formats.
+
+2.1.1 MP3
+
+MP3 values MUST be stored in a TXXX frame with the Description 
+set to the specified identifier and the Text set to the string 
+representation of the value. The Description SHOULD be in 
+CamelCase as specified in the following sections, e.g. 
+FMPS_Rating.
+
+2.1.2 VorbisComments
+
+Any file supporting VorbisComments (Vorbis, FLAC, Theora, Speex) 
+MUST use a comment with the Key set to the specified identifier 
+and the Value set to the string representation of the value. The 
+Key SHOULD be in all upper-case, e.g. FMPS_RATING.
+
+2.1.3 APEv2
+
+Any file supporting APEv2 MUST add a comment with the Key set to 
+the specified identifier and the Value set to the string 
+representation of the value. The Key SHOULD be in all upper-case, 
+e.g. FMPS_RATING.
+
+2.1.4 MP4
+
+MP4 values MUST be stored at ----:com.apple.iTunes:Identifier 
+with the value a string representation of the tag's value. The 
+Identifier SHOULD be in CamelCase as specified in the following 
+sections, e.g. FMPS_Rating.
+
+2.1.5 Windows Media
+
+Windows Media values MUST be stored in the FMPS/Identifier 
+namespace with the value a string representation of the tag's 
+value. The Identifier SHOULD be in CamelCase as specified in the 
+following sections, e.g. FMPS_Rating.
+
+2.2 Rating Tags
+
+Most media players support the notion of rating content, however 
+standards for storing ratings in files do not exist. Some file 
+metadata formats completely lack rating fields; others require 
+personally identifiable information to be used as an identifier 
+(such as a user's email address) or an organizational identifier 
+(which reduces cross-player compatibility). The goal therefore is 
+simple: to avoid any personally identifying information but to 
+avoid tying the rating to a specific player.
+
+Three types of ratings are currently defined: user ratings, 
+critic ratings, and automatic (or algorithmic) ratings.
+
+Although users are more naturally able to understand integer 
+ratings, only advanced users will interact with these tags 
+directly; otherwise they will be presented to the user via a 
+conforming application. Meanwhile, there are tangible benefits to 
+storing ratings as floating-point numbers, mainly due to the fact 
+that the increased precision allows for a number of interesting 
+and useful algorithmic rating schemes to be used. However, using 
+both integer and floating-point values unnecessarily increases 
+complexity of both this spec and application code. Therefore, 
+both values are stored as floating-point numbers. Conversion to 
+and from these and an integer scale presented to the user in an 
+application is easily accomplished in the application's code if 
+it is so desired.
+
+Four tags are defined, corresponding to the three types of 
+defined ratings, plus a canonical value: FMPS_Rating_User; 
+FMPS_Rating_Critic; FMPS_Rating_Algorithm; and FMPS_Rating (the 
+canonical value). A file that has no rating tag for a specific 
+purpose is to be considered unrated for that purpose (user, 
+critic or algorithm).
+
+2.2.1 All Rating Tags
+
+• Ratings SHALL be a float value between 0.0 and 1.0, inclusive. 
+  0.0 SHALL be the lowest possible rating; 1.0 is the highest 
+  possible rating.
+
+• Ratings SHOULD only be rounded when necessary, in order to 
+  increase cross-player compatibility.
+
+2.2.2 FMPS_Rating
+
+• The canonical rating value in FMPS_Rating SHOULD be set 
+  whenever a user rates the track. This is in addition to any 
+  value stored for that particular user in FMPS_Rating_User. This 
+  value is canonical because if a player does not support 
+  multiple users (or if no user identifier is set), this is the 
+  value that MUST be returned.
+
+• If a user removes ratings from a track in the media player's 
+  database, the value of the FMPS_Rating tag SHOULD be cleared as 
+  well.
+
+2.2.3 FMPS_Rating_User
+
+• If a player supports the notion of multiple users (perhaps from 
+  discovery of the current user from the operating system) and 
+  wishes to allow the users to keep separate ratings, it MUST 
+  store these values in the FMPS_Rating_User tag.
+
+• Applications supporting multiple user ratings SHOULD have a way 
+  for users to define their preferred identifier. 
+
+• The values are in the form of a list as defined in Section 2.1, 
+  with list entries in the format of UserIdentifier::Value. There 
+  MUST NOT be empty value strings.
+
+Example: “Alice Abba::0.6;;Bob Beatles::0.8”.
+
+2.3 FMPS_Rating_Critic
+
+• The values MUST be in the form of a list as defined in Section 
+  2.1, with list entries in the format of 
+  Publication::Critic::Rating. If the critic is unaffiliated, or 
+  if the rating is by a publication with no byline, the special 
+  value “FMPS_Nothing” MUST be used to denote this; there MUST 
+  NOT be empty strings.
+
+Example: “Rolling Stone::Ralph 
+Gleason::0.83;;musicOMH.com::FMPS_Nothing::0.76;;Metacritic::FMPS_Nothing::0.8;;FMPS_Nothing::Some 
+Dude::0.9”
+
+2.3.1 FMPS_Rating_Algorithm
+
+• The values MUST be in the form of a list as defined in Section 
+  2.1, with list entries in the format of 
+  Application::Algorithm::Rating. All fields MUST be defined; 
+  fields MUST NOT be left empty.
+
+• In cases where the algorithm is intended to be 
+  global/collaborative/cross-application, the Application value 
+  SHOULD be set to some agreed-upon value. In other words, it is 
+  RECOMMENDED to use the application name for the Application 
+  part of the identifier, but it MAY also be used to identify a “
+  group” of algorithms, or some arbitrary other value that can be 
+  used for identification.
+
+Example: “
+Amarok::AutoRate::0.52;;VLC::Standard::0.6;;QuodLibet::RatingPlugin\:X::0.35;;The 
+Free Music Player Alliance::Rating Algorithm 1::0.5”
+
+A note on the floating point values: some players may only allow 
+users to rate in increments of whole numbers between 1 and 5; 
+others 0 and 10; and so on. However, players SHOULD ensure that 
+the rating they display and use for any purpose adheres to that 
+saved in the tag whenever possible, only rounding this number 
+when absolutely necessary.
+
+For instance, if a track has a rating of 0.9 and an application 
+only shows ratings using five star icons in full-star increments, 
+this would be rounded within the application to five stars. 
+Howeer, if the player also shows the rating numerically, the 
+application would display 4.5 in the numeric field instead of the 
+same 5 shown in the star icons, thus more accurately reflecting 
+the user's set rating.
+
+2.4 Playcount Tags
+
+As with ratings, there are multiple kinds of playcount tags (user 
+and algorithmic) in addition to a canonical value. The user tag 
+tracks how many times a song has been played for a user. The 
+auto/algorithmic value can be used in an application-specific way 
+to do interesting things; for instance, to cumulatively track 
+exact percentages of tracks played, in order to display to the 
+user the number of days/hous/minutes/seconds they have spent 
+listening to a particular song. 
+
+Three tags are defined, corresponding to the two types of defined 
+playcounts, plus a canonical value: FMPS_Playcount_User; 
+FMPS_Playcount_Algorithm; and FMPS_Playcount (the canonical 
+value). A file that has no playcount tag for a specific purpose 
+is to be considered unplayed for that purpose (user or 
+algorithm).
+
+2.4.1 All Playcount Tags
+
+• Playcounts MUST be a float value not less than 0.0. 0.0 is 
+  valid and means unplayed.
+
+• The maximum value SHALL be 0.000001 less than the largest value 
+  able to be stored in a 32-bit unsigned integer: 
+  4,294,967,294.999999. This is so that playcount values can be 
+  rounded to an integer equivalent, if necessary (e.g. for 
+  display to the user).
+
+2.4.2 User Playcount Criteria
+
+The user playcount isn't meant to be set by the user, but rather 
+to follow these rules that define user behavior. A file is to be 
+considered “played” if it meets the following criteria, inspired 
+by Last.fm's scrobbling rules:
+
+• If the track is less than thirty seconds long, the entire song 
+  MUST be played.
+
+• If the track is more than thirty seconds long but less than 
+  eight minutes long, at least fifty percent of the file MUST be 
+  played, calculated via length of track. For instance, if a 
+  track is one minute long, at least thirty seconds of the track 
+  must have been played, although if the user skips backwards 
+  multiple times and listens to the same ten seconds of the track 
+  three times in a row, this may be considered a valid playcount.
+
+• If the track is longer than eight minutes, at least four 
+  minutes of the track MUST be played.
+
+User playcounts have an additional restriction in that they MUST 
+be float values representing integers (1.0, 141.0, etc.). They 
+are never fractional values; a song was either played, or it 
+wasn't.
+
+2.4.3 FMPS_Playcount
+
+• The canonical playcount value in FMPS_Playcount SHOULD be set 
+  whenever a user plays a track. This is in addition to any value 
+  stored for that user in FMPS_Playcount_User. This value is 
+  canonical because if a player does not support multiple users 
+  (or if no user identifier is set) this is the value that MUST 
+  be returned.
+
+• If a user has an identifier set to store per-user playcounts, 
+  when this value is set it MUST be set to the value of that 
+  user's playcount. In other words, the last value held in 
+  FMPS_Playcount will be equivalent to the latest user's personal 
+  playcount, if any.
+
+• If a user resets the playcount for a track in the media 
+  player's database, the value of the FMPS_Playcount tag SHOULD 
+  be cleared as well.
+
+• FMPS_Playcount MUST store “full plays” of a track according to 
+  the rules in Section 2.4.2.
+
+2.4.4 FMPS_Playcount_User
+
+• If a player supports the notion of multiple users (perhaps from 
+  discovery of the current user from the operating system) and 
+  wishes to allow the users to keep separate playcounts, it MUST 
+  store these values in the FMPS_Playcount_User tag.
+
+• Applications supporting multiple user playcounts SHOULD have a 
+  way for users to define their preferred identifier. 
+
+• The values MUST be in the form of a list as defined in Section 
+  2.1, with list entries in the format of UserIdentifier::Value. 
+  There MUST NOT be empty strings.
+
+• FMPS_Playcount_User MUST store “full plays” of a track 
+  according to the rules in Section 2.4.2.
+
+Example: “Alice Abba::1.0;;Bob Beatles::133.0”.
+
+2.4.5 FMPS_Playcount_Algorithm
+
+• The values MUST be in the form of a list as defined in Section 
+  2.3.1, with list entries in the format of 
+  Application::Algorithm::Playcount. All fields MUST be defined; 
+  fields MUST NOT be left empty.
+
+• In cases where the algorithm is intended to be 
+  global/collaborative/cross-application, the Application value 
+  SHOULD be set to some agreed-upon value. In other words, it is 
+  RECOMMENDED to use the application name for the Application 
+  part of the identifier, but it MAY also be used to identify a “
+  group” of algorithms, or some arbitrary other value that can be 
+  used for identification.
+
+• For algorithms, a track's length MUST be considered to be worth 
+  1.0 playcounts; the user skipping parts of the track MAY 
+  decrease the value below 1.0, and the user repeating parts of 
+  the track MAY increase this value past 1.0.
+
+Example: “
+Amarok::AutoPlaycount::152.69;;VLC::Standard::198.0;;QuodLibet::PlaycountPlugin\:X::1652.19;;The 
+Music Player Alliance::Playcount Algorithm 1::0.5”
+
+2.5 Performer Roles
+
+Performer roles allow you to describe the performers in a track. 
+Current support for these roles in tag formats is often sporadic 
+or difficult to parse. As many of these tags as desired can be 
+specified, to include all relevant performer information.
+
+• Performer roles use the identifier “FMPS_Performers”. The value 
+  MUST be a list in the form of Performer::Role, where Role is 
+  the user-defined role (“Guitar”, “Guitar (Backup)”, “Vocals”).
+
+Example: “Willy Nelson::Guitar;;Eric Clapton::Guitar 
+(Backup);;B.B. King::Vocals”
+
+2.6 Lyrics
+
+Embedding lyrics into a file allows users to save custom lyrics 
+and to still see the lyrics when not connected to the Internet. 
+Since different users may wish to have different sets of lyrics 
+(for example, if customizing lyrics against a music-only track) 
+and different Internet sources may have different lyrics, it is 
+possible to store multiple lyrics values by specifying a source.
+
+• The identifier for the (canonical) lyrics text is “FMPS_Lyrics”
+  . The value MUST be a string. Spaces, tabs, and newlines SHOULD 
+  be preserved when saving the string, and SHOULD be displayed 
+  properly to the user.
+
+• Lyrics MAY also be stored in FMPS_Lyrics_Sources as a list (as 
+  defined in Section 2.1), in which case the form MUST be 
+  Source::Data.
+
+Example: “Alice Aardvark::[lyrics];;Bob 
+Baboon::[lyrics];;http\://www.lyricssite.net::[lyrics]”
+
+2.7 Album/Compilation (“Various Artists”) Identifier
+
+Compilations (or “Various Artists” albums) can be difficult for 
+music players to discover. Sometimes the user places all files 
+from a compilation in one directory and expects that the music 
+player will understand this; sometimes the user has them in 
+different directories but with the same album name and expects 
+that the music player will understand this; and so on.
+
+Although there are existing solutions to identify albums and 
+songs that belong to the same album (such as MusicBrainz 
+identifiers) many users have not or do not want to tag their 
+songs with MusicBrainz information. This tag therefore provides a 
+simple way for an application to assign a album identifier to a 
+track, indicating to what album a track belongs. It also provides 
+a simple way of marking the album as a compilation or not.
+
+This enables such use-cases as allowing a user to mark multiple 
+tracks that are part of a single compilation, and then have those 
+tracks show up as being together in a compilation the next time 
+the user adds the tracks to the music player.
+
+This section purposefully does not define information about the 
+album/compilation; it is expected that the user must supply that 
+information in appropriate existing tags, e.g. ALBUM and 
+ALBUMARTIST for VorbisComments.
+
+• The identifier for the album/compilation tag is 
+  FMPS_Albums_Compilations. Although this tag will be most useful 
+  for compilation/Various Artists albums, there may still be 
+  significant utility for a player in using this tag to identify 
+  single-artist albums. As a result, players MUST NOT make 
+  assumptions about whether the presence of this tag identifies 
+  the track as belonging to a compilation/Various Artists album 
+  and MUST explicitly derive this information from the tag value.
+
+• Values MUST be a list (as defined in Section 2.1) in the form 
+  of Application::Type::Identifier. Applications MAY have more 
+  than one identifier, if the user wants to mark a track as being 
+  present in multiple compilations, or to give user-defined names 
+  to a compilation. However, each list entry MUST be unique. 
+  Similarly to other tags in this specification, there may be 
+  significant utility in interoperating on the application names.
+
+• Type MUST be one of the following values, without quotes: “
+  Album” (indicating a general-purpose album, usually by a single 
+  artist) or “Compilation” (indicating a compilation album, 
+  usually by multiple/various artists). Checks against this value 
+  MUST be case-insensitive. More values may be added in the 
+  future; if a player encounters an unknown value it SHOULD 
+  default to type “Album”. 
+
+Example: “Amarok::Album::2982ab29ef;;AmarokUser::Compilation::My 
+Compilation;;Banshee::Compilation::ad8slpbzl229zier;;FMPSAlliance::Album::de9f2c7fd25e1b3afad3e85a0bd17d9b100db4b3”
+
diff --git a/media-player/specification.xml b/media-player/specification.xml
new file mode 100644
index 0000000..9bd44d2
--- /dev/null
+++ b/media-player/specification.xml
@@ -0,0 +1,92 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<!-- XML file was created by LyX 1.6.7
+  See http://www.lyx.org/ for more information -->
+<article lang="en_US">
+<articleinfo>
+<title>Free Media Player Specifications</title>
+</articleinfo><articleinfo>
+<title>Tag Specification</title>
+<date>version 1.1; October 16, 2010</date><author>
+Copyright 2009-2010 by <firstname>Jeff</firstname> <surname>Mitchell</surname> <ulink url="mitchell@kde.org"></ulink></author><abstract>
+<para>This specification describes various audio file tag metadata intended to increase interoperability between free music players for things such as ratings, playcounts, performer roles, and more. It does this by proposing standards for common functionality needs where none currently exist, and doing so in a way that is easily adoptable cross-player and cross-format. It is designed to be robust against future needs and to prevent possible conflicts with other tag identifiers and values.</para>
+</abstract><toc></toc></articleinfo><sect1>
+<title>Front Matter</title>
+<sect2>
+<title>License</title>
+<para>You may use this specification under either of the following licenses, at your discretion. Most will want to use it under Creative Commons; the GPL alternative is in case future versions of the spec contain e.g. code snippets that you would like to use in GPL programs:</para><orderedlist>
+<listitem><para>This specification is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported License. You are free to copy, distribute and transmit this work, provided that the copyright information and full URL to the license information page (<url>http://creativecommons.org/licenses/by-nd/3.0/</url>) remain intact. If you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one. </para></listitem><listitem><para>This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. See <url>http://www.gnu.org/licenses/</url>. </para></listitem></orderedlist></sect2><sect2>
+<title>Terminology</title>
+<para>Terminology follws that specified in RFC2119, &ldquo;Key words for use in RFCs to Indicate Requirement Levels&rdquo;. See <url>http://www.ietf.org/rfc/rfc2119.txt</url> for more information.</para></sect2></sect1><sect1>
+<title>Audio Metadata Tags</title>
+<para>The metadata tag formats evolved from Quod Libet's VorbisComments suggestions at <url>http://code.google.com/p/quodlibet/wiki/Specs_VorbisComments</url>, however this attempts to not only address ambiguities and incompatibilities with the specification at that URL, but also to define how this functionality should be applied across formats. It is intended that as usable ways of inserting the metadata described become available for formats not currently specified, that this document will be updated to meet those needs.</para>
+<para>All newly-specified tags carry an identifier &ldquo;FMPS_&rdquo; to tie the tags to this specification. The reason is simple: since the official metadata specifications either fail to define or define unusable tags, these values are only official to the extent that this specification is adopted. Without an identifier to give context to the meanings and limitations of the values, there is a real possibility that a noncompliant media player will use the same tag names in an incompatible fashion, whether intentionally or not, and there is no way to determine whether a seemingly compatible use of the tags by a noncompliant player actually results in user-intended behavior. The &ldquo;FMPS_&rdquo; identifier and this specification document is therefore used in a similar fashion to XML schema declarations.</para>
+<para>As these identifiers are read and modified only by players and advanced users, it is not expected to be a hindrance to adoption or to cause undue burden on either.</para><sect2>
+<title>Common Data and Tag Information</title>
+<para>This section provides &ldquo;up-front&rdquo; information that is pertinent to all tags described below, such as what encoding to use and which tags to use in various formats.</para>
+<para>For all tag formats, the following is defined:</para><itemizedlist>
+<listitem><para>All identifiers are ASCII strings, and defined in the sections below. All identifier strings must escape each colon (':'), semicolon (';') and backslash ('\') with a backslash.</para></listitem><listitem><para>All values (including numeric values) are stored as strings, which MUST adhere to the allowed encoding and length limits in the relevant tag format specifications, but SHOULD use Unicode whenever possible.</para><itemizedlist>
+<listitem><para>To keep the specification simple, no ranges of control characters are defined which should never be included in a string. It is assumed that the used string-handling library will properly handle any such characters encountered. It is highly recommended, however, that no such control characters are used, except when specified below.</para></listitem><listitem><para>All value strings must escape each colon (':'), semicolon (';') and backslash ('\') with a backslash. </para></listitem></itemizedlist></listitem><listitem><para>Although identifier case is specified for the different types of tags, comparisons against identifier strings MUST be case-insensitive.</para></listitem><listitem><para>A period/full stop is used to separate the digits in a float value from the fractional part of the float. All float values MUST include a period/full stop (1 is not acceptable; 1.0 is correct).</para></listitem><listitem><para>Float values SHOULD be limited to six decimal places.</para></listitem><listitem><para>All lists are value strings. For any lists, entries MUST be separated with a double semicolon ';;' and fields within an entry MUST be separated with a double colon '::' (examples in following sections). These separation markers MUST NOT be escaped with backslashes. This allows for easy splitting of list entries and entry fields with most string libraries; the entries and fields can be split by double semicolon/double colon, and the ensuing fields can have any escaped values substituted.</para></listitem></itemizedlist><para>The following sections describe where the information should be stored in specific tag formats.</para><sect3>
+<title>MP3</title>
+<para>MP3 values MUST be stored in a TXXX frame with the Description set to the specified identifier and the Text set to the string representation of the value. The Description SHOULD be in CamelCase as specified in the following sections, e.g. FMPS_Rating.</para></sect3><sect3>
+<title>VorbisComments</title>
+<para>Any file supporting VorbisComments (Vorbis, FLAC, Theora, Speex) MUST use a comment with the Key set to the specified identifier and the Value set to the string representation of the value. The Key SHOULD be in all upper-case, e.g. FMPS_RATING.</para></sect3><sect3>
+<title>APEv2</title>
+<para>Any file supporting APEv2 MUST add a comment with the Key set to the specified identifier and the Value set to the string representation of the value. The Key SHOULD be in all upper-case, e.g. FMPS_RATING.</para></sect3><sect3>
+<title>MP4</title>
+<para>MP4 values MUST be stored at ----:com.apple.iTunes:Identifier with the value a string representation of the tag's value. The Identifier SHOULD be in CamelCase as specified in the following sections, e.g. FMPS_Rating.</para></sect3><sect3>
+<title>Windows Media</title>
+<para>Windows Media values MUST be stored in the FMPS/Identifier namespace with the value a string representation of the tag's value. The Identifier SHOULD be in CamelCase as specified in the following sections, e.g. FMPS_Rating.</para></sect3></sect2><sect2>
+<title>Rating Tags</title>
+<para>Most media players support the notion of rating content, however standards for storing ratings in files do not exist. Some file metadata formats completely lack rating fields; others require personally identifiable information to be used as an identifier (such as a user's email address) or an organizational identifier (which reduces cross-player compatibility). The goal therefore is simple: to avoid any personally identifying information but to avoid tying the rating to a specific player.</para>
+<para>Three types of ratings are currently defined: user ratings, critic ratings, and automatic (or algorithmic) ratings.</para>
+<para>Although users are more naturally able to understand integer ratings, only advanced users will interact with these tags directly; otherwise they will be presented to the user via a conforming application. Meanwhile, there are tangible benefits to storing ratings as floating-point numbers, mainly due to the fact that the increased precision allows for a number of interesting and useful algorithmic rating schemes to be used. However, using both integer and floating-point values unnecessarily increases complexity of both this spec and application code. Therefore, both values are stored as floating-point numbers. Conversion to and from these and an integer scale presented to the user in an application is easily accomplished in the application's code if it is so desired.</para>
+<para>Four tags are defined, corresponding to the three types of defined ratings, plus a canonical value: FMPS_Rating_User; FMPS_Rating_Critic; FMPS_Rating_Algorithm; and FMPS_Rating (the canonical value). A file that has no rating tag for a specific purpose is to be considered unrated for that purpose (user, critic or algorithm).</para><sect3>
+<title>All Rating Tags</title>
+<itemizedlist>
+<listitem><para>Ratings SHALL be a float value between 0.0 and 1.0, inclusive. 0.0 SHALL be the lowest possible rating; 1.0 is the highest possible rating.</para></listitem><listitem><para>Ratings SHOULD only be rounded when necessary, in order to increase cross-player compatibility.</para></listitem></itemizedlist></sect3><sect3>
+<title>FMPS_Rating</title>
+<itemizedlist>
+<listitem><para>The canonical rating value in FMPS_Rating SHOULD be set whenever a user rates the track. This is in addition to any value stored for that particular user in FMPS_Rating_User. This value is canonical because if a player does not support multiple users (or if no user identifier is set), this is the value that MUST be returned.</para></listitem><listitem><para>If a user removes ratings from a track in the media player's database, the value of the FMPS_Rating tag SHOULD be cleared as well.</para></listitem></itemizedlist></sect3><sect3>
+<title>FMPS_Rating_User</title>
+<itemizedlist>
+<listitem><para>If a player supports the notion of multiple users (perhaps from discovery of the current user from the operating system) and wishes to allow the users to keep separate ratings, it MUST store these values in the FMPS_Rating_User tag.</para></listitem><listitem><para>Applications supporting multiple user ratings SHOULD have a way for users to define their preferred identifier. </para></listitem><listitem><para>The values are in the form of a list as defined in Section 2.1, with list entries in the format of UserIdentifier::Value. There MUST NOT be empty value strings.</para></listitem></itemizedlist><para>Example: &ldquo;Alice Abba::0.6;;Bob Beatles::0.8&rdquo;.</para></sect3></sect2><sect2>
+<title>FMPS_Rating_Critic</title>
+<itemizedlist>
+<listitem><para>The values MUST be in the form of a list as defined in Section 2.1, with list entries in the format of Publication::Critic::Rating. If the critic is unaffiliated, or if the rating is by a publication with no byline, the special value &ldquo;FMPS_Nothing&rdquo; MUST be used to denote this; there MUST NOT be empty strings.</para></listitem></itemizedlist><para>Example: &ldquo;Rolling Stone::Ralph Gleason::0.83;;musicOMH.com::FMPS_Nothing::0.76;;Metacritic::FMPS_Nothing::0.8;;FMPS_Nothing::Some Dude::0.9&rdquo;</para><sect3>
+<title>FMPS_Rating_Algorithm</title>
+<itemizedlist>
+<listitem><para>The values MUST be in the form of a list as defined in Section 2.1, with list entries in the format of Application::Algorithm::Rating. All fields MUST be defined; fields MUST NOT be left empty.</para></listitem><listitem><para>In cases where the algorithm is intended to be global/collaborative/cross-application, the Application value SHOULD be set to some agreed-upon value. In other words, it is RECOMMENDED to use the application name for the Application part of the identifier, but it MAY also be used to identify a &ldquo;group&rdquo; of algorithms, or some arbitrary other value that can be used for identification.</para></listitem></itemizedlist><para>Example: &ldquo;Amarok::AutoRate::0.52;;VLC::Standard::0.6;;QuodLibet::RatingPlugin\:X::0.35;;The Free Music Player Alliance::Rating Algorithm 1::0.5&rdquo;</para>
+<para>A note on the floating point values: some players may only allow users to rate in increments of whole numbers between 1 and 5; others 0 and 10; and so on. However, players SHOULD ensure that the rating they display and use for any purpose adheres to that saved in the tag whenever possible, only rounding this number when absolutely necessary.</para>
+<para>For instance, if a track has a rating of 0.9 and an application only shows ratings using five star icons in full-star increments, this would be rounded within the application to five stars. Howeer, if the player also shows the rating numerically, the application would display 4.5 in the numeric field instead of the same 5 shown in the star icons, thus more accurately reflecting the user's set rating.</para></sect3></sect2><sect2>
+<title>Playcount Tags</title>
+<para>As with ratings, there are multiple kinds of playcount tags (user and algorithmic) in addition to a canonical value. The user tag tracks how many times a song has been played for a user. The auto/algorithmic value can be used in an application-specific way to do interesting things; for instance, to cumulatively track exact percentages of tracks played, in order to display to the user the number of days/hous/minutes/seconds they have spent listening to a particular song. </para>
+<para>Three tags are defined, corresponding to the two types of defined playcounts, plus a canonical value: FMPS_Playcount_User; FMPS_Playcount_Algorithm; and FMPS_Playcount (the canonical value). A file that has no playcount tag for a specific purpose is to be considered unplayed for that purpose (user or algorithm).</para><sect3>
+<title>All Playcount Tags</title>
+<itemizedlist>
+<listitem><para>Playcounts MUST be a float value not less than 0.0. 0.0 is valid and means unplayed.</para></listitem><listitem><para>The maximum value SHALL be 0.000001 less than the largest value able to be stored in a 32-bit unsigned integer: 4,294,967,294.999999. This is so that playcount values can be rounded to an integer equivalent, if necessary (e.g. for display to the user).</para></listitem></itemizedlist></sect3><sect3>
+<title>User Playcount Criteria</title>
+<para>The user playcount isn't meant to be set by the user, but rather to follow these rules that define user behavior. A file is to be considered &ldquo;played&rdquo; if it meets the following criteria, inspired by Last.fm's scrobbling rules:</para><itemizedlist>
+<listitem><para>If the track is less than thirty seconds long, the entire song MUST be played.</para></listitem><listitem><para>If the track is more than thirty seconds long but less than eight minutes long, at least fifty percent of the file MUST be played, calculated via length of track. For instance, if a track is one minute long, at least thirty seconds of the track must have been played, although if the user skips backwards multiple times and listens to the same ten seconds of the track three times in a row, this may be considered a valid playcount.</para></listitem><listitem><para>If the track is longer than eight minutes, at least four minutes of the track MUST be played.</para></listitem></itemizedlist><para>User playcounts have an additional restriction in that they MUST be float values representing integers (1.0, 141.0, etc.). They are never fractional values; a song was either played, or it wasn't.</para></sect3><sect3>
+<title>FMPS_Playcount</title>
+<itemizedlist>
+<listitem><para>The canonical playcount value in FMPS_Playcount SHOULD be set whenever a user plays a track. This is in addition to any value stored for that user in FMPS_Playcount_User. This value is canonical because if a player does not support multiple users (or if no user identifier is set) this is the value that MUST be returned.</para></listitem><listitem><para>If a user has an identifier set to store per-user playcounts, when this value is set it MUST be set to the value of that user's playcount. In other words, the last value held in FMPS_Playcount will be equivalent to the latest user's personal playcount, if any.</para></listitem><listitem><para>If a user resets the playcount for a track in the media player's database, the value of the FMPS_Playcount tag SHOULD be cleared as well.</para></listitem><listitem><para>FMPS_Playcount MUST store &ldquo;full plays&rdquo; of a track according to the rules in Section 2.4.2.</para></listitem></itemizedlist></sect3><sect3>
+<title>FMPS_Playcount_User</title>
+<itemizedlist>
+<listitem><para>If a player supports the notion of multiple users (perhaps from discovery of the current user from the operating system) and wishes to allow the users to keep separate playcounts, it MUST store these values in the FMPS_Playcount_User tag.</para></listitem><listitem><para>Applications supporting multiple user playcounts SHOULD have a way for users to define their preferred identifier. </para></listitem><listitem><para>The values MUST be in the form of a list as defined in Section 2.1, with list entries in the format of UserIdentifier::Value. There MUST NOT be empty strings.</para></listitem><listitem><para>FMPS_Playcount_User MUST store &ldquo;full plays&rdquo; of a track according to the rules in Section 2.4.2.</para></listitem></itemizedlist><para>Example: &ldquo;Alice Abba::1.0;;Bob Beatles::133.0&rdquo;.</para></sect3><sect3>
+<title>FMPS_Playcount_Algorithm</title>
+<itemizedlist>
+<listitem><para>The values MUST be in the form of a list as defined in Section 2.3.1, with list entries in the format of Application::Algorithm::Playcount. All fields MUST be defined; fields MUST NOT be left empty.</para></listitem><listitem><para>In cases where the algorithm is intended to be global/collaborative/cross-application, the Application value SHOULD be set to some agreed-upon value. In other words, it is RECOMMENDED to use the application name for the Application part of the identifier, but it MAY also be used to identify a &ldquo;group&rdquo; of algorithms, or some arbitrary other value that can be used for identification.</para></listitem><listitem><para>For algorithms, a track's length MUST be considered to be worth 1.0 playcounts; the user skipping parts of the track MAY decrease the value below 1.0, and the user repeating parts of the track MAY increase this value past 1.0.</para></listitem></itemizedlist><para>Example: &ldquo;Amarok::AutoPlaycount::152.69;;VLC::Standard::198.0;;QuodLibet::PlaycountPlugin\:X::1652.19;;The Music Player Alliance::Playcount Algorithm 1::0.5&rdquo;</para></sect3></sect2><sect2>
+<title>Performer Roles</title>
+<para>Performer roles allow you to describe the performers in a track. Current support for these roles in tag formats is often sporadic or difficult to parse. As many of these tags as desired can be specified, to include all relevant performer information.</para><itemizedlist>
+<listitem><para>Performer roles use the identifier &ldquo;FMPS_Performers&rdquo;. The value MUST be a list in the form of Performer::Role, where Role is the user-defined role (&ldquo;Guitar&rdquo;, &ldquo;Guitar (Backup)&rdquo;, &ldquo;Vocals&rdquo;).</para></listitem></itemizedlist><para>Example: &ldquo;Willy Nelson::Guitar;;Eric Clapton::Guitar (Backup);;B.B. King::Vocals&rdquo;</para></sect2><sect2>
+<title>Lyrics</title>
+<para>Embedding lyrics into a file allows users to save custom lyrics and to still see the lyrics when not connected to the Internet. Since different users may wish to have different sets of lyrics (for example, if customizing lyrics against a music-only track) and different Internet sources may have different lyrics, it is possible to store multiple lyrics values by specifying a source.</para><itemizedlist>
+<listitem><para>The identifier for the (canonical) lyrics text is &ldquo;FMPS_Lyrics&rdquo;. The value MUST be a string. Spaces, tabs, and newlines SHOULD be preserved when saving the string, and SHOULD be displayed properly to the user.</para></listitem><listitem><para>Lyrics MAY also be stored in FMPS_Lyrics_Sources as a list (as defined in Section 2.1), in which case the form MUST be Source::Data.</para></listitem></itemizedlist><para>Example: &ldquo;Alice Aardvark::[lyrics];;Bob Baboon::[lyrics];;http\://www.lyricssite.net::[lyrics]&rdquo;</para></sect2><sect2>
+<title>Album/Compilation (&ldquo;Various Artists&rdquo;) Identifier</title>
+<para>Compilations (or &ldquo;Various Artists&rdquo; albums) can be difficult for music players to discover. Sometimes the user places all files from a compilation in one directory and expects that the music player will understand this; sometimes the user has them in different directories but with the same album name and expects that the music player will understand this; and so on.</para>
+<para>Although there are existing solutions to identify albums and songs that belong to the same album (such as MusicBrainz identifiers) many users have not or do not want to tag their songs with MusicBrainz information. This tag therefore provides a simple way for an application to assign a album identifier to a track, indicating to what album a track belongs. It also provides a simple way of marking the album as a compilation or not.</para>
+<para>This enables such use-cases as allowing a user to mark multiple tracks that are part of a single compilation, and then have those tracks show up as being together in a compilation the next time the user adds the tracks to the music player.</para>
+<para>This section purposefully does not define information about the album/compilation; it is expected that the user must supply that information in appropriate existing tags, e.g. ALBUM and ALBUMARTIST for VorbisComments.</para><itemizedlist>
+<listitem><para>The identifier for the album/compilation tag is FMPS_Albums_Compilations. Although this tag will be most useful for compilation/Various Artists albums, there may still be significant utility for a player in using this tag to identify single-artist albums. As a result, players MUST NOT make assumptions about whether the presence of this tag identifies the track as belonging to a compilation/Various Artists album and MUST explicitly derive this information from the tag value.</para></listitem><listitem><para>Values MUST be a list (as defined in Section 2.1) in the form of Application::Type::Identifier. Applications MAY have more than one identifier, if the user wants to mark a track as being present in multiple compilations, or to give user-defined names to a compilation. However, each list entry MUST be unique. Similarly to other tags in this specification, there may be significant utility in interoperating on the application names.</para></listitem><listitem><para>Type MUST be one of the following values, without quotes: &ldquo;Album&rdquo; (indicating a general-purpose album, usually by a single artist) or &ldquo;Compilation&rdquo; (indicating a compilation album, usually by multiple/various artists). Checks against this value MUST be case-insensitive. More values may be added in the future; if a player encounters an unknown value it SHOULD default to type &ldquo;Album&rdquo;. </para></listitem></itemizedlist><para>Example: &ldquo;Amarok::Album::2982ab29ef;;AmarokUser::Compilation::My Compilation;;Banshee::Compilation::ad8slpbzl229zier;;FMPSAlliance::Album::de9f2c7fd25e1b3afad3e85a0bd17d9b100db4b3&rdquo;</para></sect2></sect1></article>
\ No newline at end of file