Hi all, <div class="gmail_quote"> 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: FMPS_Rating or for more specific kinds of rating FMPS_Rating_Automatic or FMPS_Rating_Critic or FMPS_Rating_User:pvh Perhaps; FMPS_Rating Amarok_AutomaticRating Songbird_AutomaticRating Songbird_Rating_User:pvh Songbird_Rating_Metacritic and so on. I think having a single canonical rating would be a big advantage, even if there are other values present. -pvh <div class="gmail_quote"><div><div></div><div class="h5">On Tue, Nov 3, 2009 at 1:07 PM, Jeff Mitchell <<a href="mailto:mitchell@kde.org" target="_blank">mitchell@kde.org</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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 <a href="http://groups.google.com/group/fmps/topics" target="_blank">http://groups.google.com/group/fmps/topics</a> The group is read-only, and per agreement with those involved (that replied) further discussion will take place on <a href="mailto:xdg@lists.freedesktop.org" target="_blank">xdg@lists.freedesktop.org</a> 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. </blockquote></div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5"> That all said, here's the second draft of the spec: <a href="http://gitorious.org/%7Ejefferai/xdg-specs/jefferais-xdg-specs/blobs/mediaspecs/specifications/FMPSpecs/specification.txt" target="_blank">http://gitorious.org/~jefferai/xdg-specs/jefferais-xdg-specs/blobs/mediaspecs/specifications/FMPSpecs/specification.txt</a> --Jeff </div></div>_______________________________________________ xdg mailing list <a href="mailto:xdg@lists.freedesktop.org" target="_blank">xdg@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/xdg" target="_blank">http://lists.freedesktop.org/mailman/listinfo/xdg</a> </blockquote></div> -- Peter van Hardenberg Victoria, BC, Canada "Everything was beautiful, and nothing hurt." -- Kurt Vonnegut </div> -- Peter van Hardenberg Victoria, BC, Canada "Everything was beautiful, and nothing hurt." -- Kurt Vonnegut