Second Draft of Free Music Player Specifications ready

Peter van Hardenberg pvh at
Tue Nov 3 13:37:18 PST 2009

Hi all,

Sorry I didn't get a chance to respond again to the last version of the
thread. Thanks for posting a second draft of the specs. They're shaping up
nicely and this version is a good improvement.

Deciding on floats for rating seems like mostly a good decision. If a number
is > 0 and < 1 it's a pretty safe conclusion that it's a float rating. On
the other hand, it means any track rated maximally will be a "1", which is
widely used as a very low value. Perhaps the solution there is to say that
the float value must include a decimal point and a zero to eliminate
ambiguity of interpretation.

I'd like to voice some concern about writing two forms of rating to the
file. Also, though Amarok tracks two forms of rating, I don't think the
current automatic vs user distinction makes sense. For example, if I
introduce automatic rating to Songbird through an extension, I don't think
it would be good for me to overwrite the existing Amarok inserted value
created by a different algorithm. If you feel strongly about including it,
perhaps instead of using two specific forms of rating (auto and user), we
could consider arbitrary types of rating.

For example, the syntax could be something along the lines of:

or for more specific kinds of rating



and so on. I think having a single canonical rating would be a big
advantage, even if there are other values present.


On Tue, Nov 3, 2009 at 1:07 PM, Jeff Mitchell <mitchell at> wrote:

> Hello,
> The second draft of the Free Music Player Specifications is ready. A few
> words before the link.
> First, for those new to the discussion, an archive of previous emails in
> the discussion can be found at
> The group is read-only, and per agreement with those involved (that
> replied) further discussion will take place on xdg at
> I want to thank Milosz Derezynski and Peter van Hardenberg, who replied
> to the first draft with suggestions.
> Now, some comments about this second draft.
> It was suggested that instead of both integer and float values, one or
> the other should be picked. It made sense to have floats in all but one
> instance (user playcounts), so floats is what I went with. Overall this
> decreases the spec's complexity a good amount.
> I attempted to clarify things where confusion seemed to exist in
> replies; for instance, Milosz's suggestion that it be encouraged that
> applications should treat values as they are whenever possible, even if
> in some cases they need to round them to display them to the user (for
> instance, in a graphical fashion).
> I cleaned up the filesystem directive section at Peter's request; it's
> indeed simpler (and probably quicker) to just check each directory for a
> fmps_ignore file than to check it for text values inside that file and
> react appropriately.
> I looked at Performer Roles on the MusicBrainz site at Milosz's request,
> and decided to keep them in the spec for now. The main reason is that
> while MusicBrainz supports MP3 and VorbisComments formats, it has no
> capability to support performer roles for WMA or MP4 formats, whereas
> there is no reason why support for these formats could not be included
> in this specification. Another reason is that the FMPS spec defines
> using comments (TXXX for MP3) which eases processing as TXXX is easily
> supported by almost any tagging library. By contrast, for MP3 at least,
> parsing the TMCL list can be difficult.

> That all said, here's the second draft of the spec:
> --Jeff
> _______________________________________________
> xdg mailing list
> xdg at

Peter van Hardenberg
Victoria, BC, Canada
"Everything was beautiful, and nothing hurt." -- Kurt Vonnegut

Peter van Hardenberg
Victoria, BC, Canada
"Everything was beautiful, and nothing hurt." -- Kurt Vonnegut
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the xdg mailing list