FMPS

[Jeff Mitchell]

On Mon, 25 Jan 2010 13:08:03 -0500, Steven Robertson <steven at strobe.cc>
wrote:
>> And if you don't, reply and say what you feel needs to be changed.
> 
> I'd like to see a few additional statistics standardized, particularly
> "lastplayed" timestamp, and optionally a "laststarted" timestamp,
> "added" (or "firstplayed") timestamp, and "skipcount". These tags
> provide both users and algorithms more to work with when deciding what
> to play next based on statistics. I understand that not all players
> track, expose, or write this information, but Quod Libet will do so
> regardless of adoption in the spec.

Interesting idea. Do you think this belongs in an algorithm section (i.e.
algorithms can specify their own subidentifiers, like at e.g.
FMPS_Rating_Algorithm_QuodLibet_laststarted) or at a more global scope? The
latter seems ideal, but the former seems more robust in case other players
are not writing some or all of these values into the tags (for instance,
Ampache may not write anything at all, but may read these tags). This way
you can make sure that Quod Libet will always write the values you need for
your algorithm (and other players could interoperate if they collaborate on
an algorithm with you). Granted the result would be more player-specific,
but that might be better than relying on global values that aren't always
properly being kept up-to-date.
 
> The need for 'FMPS_' is understandable, but it's still ugly as sin.

I don't *really* understand comments like this one. It's not like it's
exposed to the user. I mean, I get it, but given that some kind of context
is necessary, people seem to be making a bigger deal out of it than need be
:-)

> Xiph tag identifiers are case insensitive, and I would be more
> comfortable if, for those formats, identifier case was not part of the
> spec. Quod Libet uses Mutagen, which will not write uppercase Xiph
> tags by design.

I got a request to use RFC-style MUST/SHOULD/etc. which should help
clarify these things (will put that in soon). Case is in the spec not as a
requirement but for consistency. Xiph tag identifiers may be
case-insensitive but the spec uses UPPERCASE throughout in its examples
(http://xiph.org/vorbis/doc/v-comment.html), regardless of what Mutagen
does by design.

The latest draft of the spec (which is in progress, not published as a
draft yet, but viewable at the same URL) takes this into account -- it
makes it clear that the cases specified are suggested for consistency and
that converting strings to all uppercase/lowercase when performing
comparisons is a good idea. This should keep case-based interoperability
issues from occurring. The RFC-style language will help clarify that
further, when I add that in.

--Jeff