[Fwd: Re: First draft of FMP Specs doc]

[Jeff Mitchell]

[Jeff Mitchell]

OK I will take the time now to reply -- a really ungodly time but it is necessary so why not now.

Here are some thoughts not necessarily in the best order, sorry for that, I blame the late night time.

1. First of all, the spec is good in terms of quality - thank you very much for investing the time into it that you did. However, I am not quite sure on the necessity of a float and an integral value for the rating at the same time. A floating point value is as you pointed out much more useful to algorithms (even though on a scale from 0 to 100, an integral value would be enough IMO), and a float value can be easily rounded to an integer in the application where needed. It just makes it more complicated for the application to deal with the files, and the ratings.

2. I think we need to somewhat loosen the correlation between the value and the representation in the app. If there is a value of 23, an application that represents the value to the user as "0 to 5 stars", would map 23 to 1 star, as well as 37, but 46 would be 2 stars. That's OK and in this example this makes sense. I think what I'm up to is to either entirely remove, or reformulate/emphasise that passage in the draft as being a PURE EXAMPLE only, applications should entirely decide for themselves how to represent the values. I know that you meant nothing else, I would just like it if it would become more clear that what the draft deals with is entirely a numeric rating, and visual representation and algorithmic use of these values are up to the apps.

3. However, point 2 leads to the fact that at the same time at which we loose the connection between the value and the representation, we should emphasize that at a basic level, INTERNALLY, not VISUALLY, all conforming applications should TRY to treat an equal value (i.e. from the same file at the same time) identically. Simplest example would be sorting all songs by rating in the application (of course this also comes with a visual representation, i.e. a sorted list view, but I'm thinking in sorted model terms here). All applications, in so far they support sorting by rating, should sort the songs with their respective ratings identically. I think a passage like that should be included, or if present (sorry if I don't have the entire draft in mind right now) should be emphasized.

4. As far as FMPS_Performer goes, I would like to point to the MusicBrainz/Picard tagging specification http://wiki.musicbrainz.org/PicardTagMapping, which includes many tags for various Performer roles. It is already widely in use by many people and would serve a similar purpose. Youki already fully supports PicardTagMapping, it is just currently unable to show all the data (there exists a plugin which lists all performers including what instrument/vocal/etc. they performed but I don't know whether it is currently working).

5. As to the file system directives, I have no comment on this yet.

Now one last thing related to Youki/MPX specifically:

We use a fork of Taglib, Taglib-GIO which I rewrote from the default 1.4 Taglib to use the GIO Framework for I/O to have a wider range of source to read from. READ from, therein lies the crux. I have not yet implemented write support, which should be rather simple to do though (but would need rather extensive testing so I can be sure everything is allright). This is no matter that stands in the way of the spec, I just wanted to point out that at this point in time, I would be only able to implement reading support for the FMPS draft, writing support at any time (but I am not sure if it's gonna be soon) I implement writing support in Taglib-GIO.

Thanks again for all the work so far Jeff,

Regards,

Milosz

2009/10/27 Jeff Mitchell <mitc...@kde.org>

Hey guys,

So everyone on this list expressed interest in such a spec.

Nobody on this list replied.

I know everyone has been busy -- but without any sort of reply, there
can't be any sort of progress -- and I don't know about you guys, but
I'd love to finally get something implemented  :-)

Please -- take the time to read it, see how simple but flexible it is,
and let me know your thoughts.

--Jeff

--
Please note that according to the German law on data retention,
information on every electronic information exchange with me is
retained for a period of six months.
[Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]

[Jeff Mitchell]

[Jeff Mitchell]

2009/10/27 Jeff Mitchell <mitc...@kde.org>

> 3. However, point 2 leads to the fact that at the same time at which we

> loose the connection between the value and the representation, we should
> emphasize that at a basic level, INTERNALLY, not VISUALLY, all
> conforming applications should TRY to treat an equal value (i.e. from
> the same file at the same time) identically. Simplest example would be
> sorting all songs by rating in the application (of course this also
> comes with a visual representation, i.e. a sorted list view, but I'm
> thinking in sorted model terms here). All applications, in so far they
> support sorting by rating, should sort the songs with their respective
> ratings identically. I think a passage like that should be included, or
> if present (sorry if I don't have the entire draft in mind right now)
> should be emphasized.

I don't really follow. Are you suggesting that the spec should mandate a
sorting order, or...?

Hey Jeff,

No I only meant that a value of let's say 47 should "mean" the same thing in all apps, otherwise portability is impaired. I know that the spec implies nothing short of that, too, but I think it would be good to emphasize this. The way in which it is visually implemented is up to the app, but if let's say there was a plugin for both Amarok and Youki (ported to each other) that does some random song selection, it should treat a file with a value of "47" the same way in both apps. Just that. (I know, I know, that is already what you want, just if we could make it more clear.)

Regards,

Milosz

 

-- 

[Jeff Mitchell]

One more thing: I think automatic and user ratings separated is a good thing. While Youki does not "rate" songs automatically per se, it assigns a lot of statistical values to each song in fact. But wouldn't then it be better to call it "FMPS_Rating_Automatic" and "FMPS_Rating_User" and have them be in one format (float or int) than to put it up to the separation into a float and int value whose names don't even really tell which is which? (Just trying to improve, no big criticism!)

Regards,

Milosz

2009/10/27 Jeff Mitchell <mitc...@kde.org>

Milosz Derezynski wrote:
> rating at the same time. A floating point value is as you pointed out
> much more useful to algorithms (even though on a scale from 0 to 100, an
> integral value would be enough IMO), and a float value can be easily
> rounded to an integer in the application where needed. It just makes it
> more complicated for the application to deal with the files, and the
> ratings.

It's true, it is more complicated. That was somewhat the reasoning for
having the separate values, that apps can only implement (the more
complex) both values if needed.

I agree that if there is only one value, either should suffice for both
needs. What I'd be interested in knowing is if there are other
applications besides Amarok that have both user-defined and automatic
ratings. For us I can certainly see the utility of having both; are we
the only ones?

(Keep in mind that the spec was specifically written such that not all
values are required; it would certainly work, in an interoperability
sense, for most apps to only implement integers and only the apps that
can use it to implement floats too.)

> 2. I think we need to somewhat loosen the correlation between the value

> and the representation in the app. If there is a value of 23, an
> application that represents the value to the user as "0 to 5 stars",
> would map 23 to 1 star, as well as 37, but 46 would be 2 stars. That's
> OK and in this example this makes sense. I think what I'm up to is to
> either entirely remove, or reformulate/emphasise that passage in the
> draft as being a PURE EXAMPLE only, applications should entirely decide
> for themselves how to represent the values. I know that you meant
> nothing else, I would just like it if it would become more clear that
> what the draft deals with is entirely a numeric rating, and visual
> representation and algorithmic use of these values are up to the apps.

Sure. That makes sense.

> 3. However, point 2 leads to the fact that at the same time at which we
> loose the connection between the value and the representation, we should
> emphasize that at a basic level, INTERNALLY, not VISUALLY, all
> conforming applications should TRY to treat an equal value (i.e. from
> the same file at the same time) identically. Simplest example would be
> sorting all songs by rating in the application (of course this also
> comes with a visual representation, i.e. a sorted list view, but I'm
> thinking in sorted model terms here). All applications, in so far they
> support sorting by rating, should sort the songs with their respective
> ratings identically. I think a passage like that should be included, or
> if present (sorry if I don't have the entire draft in mind right now)
> should be emphasized.

I don't really follow. Are you suggesting that the spec should mandate a
sorting order, or...?

> 4. As far as FMPS_Performer goes, I would like to point to the
> MusicBrainz/Picard tagging
> specification http://wiki.musicbrainz.org/PicardTagMapping, which
> includes many tags for various Performer roles. It is already widely in
> use by many people and would serve a similar purpose. Youki already
> fully supports PicardTagMapping, it is just currently unable to show all
> the data (there exists a plugin which lists all performers including
> what instrument/vocal/etc. they performed but I don't know whether it is
> currently working).

OK, I'll take a look and see how it might affect thing. Thanks for the
pointer.

> We use a fork of Taglib, Taglib-GIO which I rewrote from the default 1.4
> Taglib to use the GIO Framework for I/O to have a wider range of source
> to read from. READ from, therein lies the crux. I have not yet
> implemented write support, which should be rather simple to do though
> (but would need rather extensive testing so I can be sure everything is
> allright). This is no matter that stands in the way of the spec, I just
> wanted to point out that at this point in time, I would be only able to
> implement reading support for the FMPS draft, writing support at any
> time (but I am not sure if it's gonna be soon) I implement writing
> support in Taglib-GIO.

No problem. But at least you'll have something that you can read that
makes it nicer for users bringing their files to your app.  :-)

[Jeff Mitchell]

One other thing: It's not really something that should go into the spec per se, I think, but something we should still think about: The writing of the data. I personally would like to do it in a deferred way in Youki, because writing to the file while a rating occurs (automatic or per user) would stall the app for a time that could be considerable while e.g. a song change is occurring. Maybe we could put something into the spec that says that files don't need to be updated immediately (or not? not so sure...). Anyway just a thought on the technical side of things.

Regards,

Milosz

2009/10/27 Milosz Derezynski <intern...@gmail.com>

[Jeff Mitchell]

[Jeff Mitchell]

[Jeff Mitchell]

2009/10/27 Jeff Mitchell <mitc...@kde.org>

What I do think is important is to define what constitutes a

"playcount". e.g. has a song been played if five seconds of it were played?

I think taking a cue from Last.fm here might be good -- if more than
fifty percent of the song's length has been played, then the song has
been played. (And if the song is very short -- maybe under 30 seconds --
then the entire track must be played. This prevents the playcount going
up because someone didn't switch the song within 3 seconds :-)  )

--Jeff

Oh yeah ok that is of course important. I guess doing it like Last.fm is a good idea. Let me take a look quick on how Youki does it (I think Youki's algorithm for that comes straight from Last.fm)... hmm right now it does no checking on the time played at all (I could have sworn it did). OK so I agree to use Last.fm's definition of played.

Anyone else care to chime in?

Regards,

Milosz 

[Jeff Mitchell]

[Jeff Mitchell]