Second Draft of Free Music Player Specifications ready

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

http://groups.google.com/group/fmps/topics

The group is read-only, and per agreement with those involved (that
replied) further discussion will take place on xdg@...

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:

http://gitorious.org/~jefferai/xdg-specs/jefferais-xdg-specs/blobs/mediaspecs/specifications/FMPSpecs/specification.txt

--Jeff



_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Peter van Hardenberg-2]

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:

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

On Tue, Nov 3, 2009 at 1:07 PM, Jeff Mitchell <mitchell@...> 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

http://groups.google.com/group/fmps/topics

The group is read-only, and per agreement with those involved (that
replied) further discussion will take place on xdg@...

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:

http://gitorious.org/~jefferai/xdg-specs/jefferais-xdg-specs/blobs/mediaspecs/specifications/FMPSpecs/specification.txt

--Jeff

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

--
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

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

Peter van Hardenberg wrote:
> 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.

No problem.

> 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.

Good idea. I'll put that in the next draft.

> 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.

<snip>

I have an alternate proposal, based off of yours: what if the automatic
ratings were identified by the algorithm used. The algorithm could
include User as the canonical rating, and Critic ratings -- I really
like that idea and could see interesting uses for it -- as human brains
are an algorithm unto themselves. Then algorithms could be identified by
name. That way, if two players wanted to collaborate on a rating
algorithm, they could easily interoperate; otherwise, no one will
(hopefully) clobber each other. So you'd end up with something like:

FMPS_Rating_User (canonical rating, set by user)
FMPS_Rating_Critic_Ralph=Gleason
FMPS_Rating_Critic_Metacritic
FMPS_Rating_Algorithm_Supercool (collaborative)
FMPS_Rating_Algorithm_AmarokAutorating (player-specific)

Of course, nothing stops one from putting in a frame like

> Amarok_AutomaticRating
> Songbird_AutomaticRating
> Songbird_Rating_User:pvh
> Songbird_Rating_Metacritic

but one could be assured that if it starts with FMPS, it adheres to the
spec.

Thoughts?

--Jeff



_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Toma-4]

Howdy,

Is there anyway of unifying and some-what future-proofing the MP3/Vorbis sections? What if some other codec becomes popular and uses some sort of other method? Im not entirely savvy in this area, but it would seem like something that would be better to have across the board. I guess with the current layout additional subsections could be added later.

TLDR; Lose mp3/vorbis specific bits, change spec to cover both in 1 swoop.

Toma

2009/11/4 Jeff Mitchell <mitchell@...>

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

http://groups.google.com/group/fmps/topics

The group is read-only, and per agreement with those involved (that
replied) further discussion will take place on xdg@...

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:

http://gitorious.org/~jefferai/xdg-specs/jefferais-xdg-specs/blobs/mediaspecs/specifications/FMPSpecs/specification.txt

--Jeff


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

Tom Haste wrote:
> Howdy,
>
> Is there anyway of unifying and some-what future-proofing the MP3/Vorbis
> sections? What if some other codec becomes popular and uses some sort of
> other method? Im not entirely savvy in this area, but it would seem like
> something that would be better to have across the board. I guess with
> the current layout additional subsections could be added later.
>
> TLDR; Lose mp3/vorbis specific bits, change spec to cover both in 1 swoop.

Since you a) didn't bother to read it, and b) don't know what you're
talking about, please refrain from sticking your nose into discussions
where you can contributing nothing useful.

Thanks,
Jeff



_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Philipp Wolfer-2]

On Wed, Nov 4, 2009 at 2:33 PM, Jeff Mitchell <mitchell@...> wrote:

> Tom Haste wrote:
>> Howdy,
>>
>> Is there anyway of unifying and some-what future-proofing the MP3/Vorbis
>> sections? What if some other codec becomes popular and uses some sort of
>> other method? Im not entirely savvy in this area, but it would seem like
>> something that would be better to have across the board. I guess with
>> the current layout additional subsections could be added later.
>>
>> TLDR; Lose mp3/vorbis specific bits, change spec to cover both in 1 swoop.
>
> Since you a) didn't bother to read it, and b) don't know what you're
> talking about, please refrain from sticking your nose into discussions
> where you can contributing nothing useful.

I'm not sure if I understood Tom's comment as it was intended, but I
see a valid point here:

In every section 1.1, 1.2 and 1.3 there are notes about storing the
tags as UTF-8 and subsections about storing the tag in ID3 and Vorbis
Comments. Since those rules should apply for all tags it would be good
to extract them into a separate Implementation section. This would
make it easier to extend it to other tagging formats.

Otherwise good work on the specification so far. I've a few points I
want to address, but I will comment later when I have more time.

Philipp
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

Tom Haste wrote:

>> 2009/11/4 Jeff Mitchell <mitchell@... <mailto:mitchell@...>>
>>
>>     Tom Haste wrote:
>>     > Sigh. Im going to unsubscribe from the xdg list, as it always
>>     dives into
>>     > snarky comments. Im not going to bother sending this to the list as
>>     > well. All I was simply asking, in a light and querying manner, was if
>>     > the 2 sections could be left out. Instead of informing me (if it was
>>     > such a SIMPLE issue it wouldnt take long to explain) ], you've
>>     gone and
>>     > made a fairly rude comment in a public forum about me and my SIMPLE
>>     > query. Feel free to reply to me and the list if you would like to
>>     > explain in a simple and understanding way that merging the 2 concepts
>>     > into 1 is such a rediculous idea.
>>     >
>>     > But again, refer to my first statement, as I will not be recieving it.
>>
>>     TL;DR
>>
>>     --Jeff
> Let me simplify it for you;
>
>
> Fuck you.
>
>
> Sincerly,
> Toma.

OK. Since you obviously can't grasp it yourself, I'll provide the
explanation.

In your original email to the list, you asked if it wouldn't be better
to make a specific change, which you qualified by "Im not entirely savvy
in this area, but it would seem like something that would be better to
have across the board."

No problems there. Totally reasonable thing to ask, especially for
someone not so familiar with the tag specifications as you said you are.

However, those four little letters "TLDR" established you not as a less
experienced person simply asking a question but as a jackass who is
wasting everyone's time by commenting on a spec that he couldn't be
bothered to read that deals with metadata specifications that he already
admitted he's not savvy about.

That you then followed this up with a direct command (no "wouldn't it be
better" or "I suggest" in it) that doesn't actually help or contribute
to the specification (and in fact is flat-out wrong) makes it all the
more irritating.

I've spent a lot of time getting various people together from all sorts
of projects to work on this, as well as spent a lot of time writing the
first two drafts. So excuse me if I ask a jackass (see above) with
nothing to contribute (which will be explained in my response to
Philipp's email) to stay out of the discussion.

"Fuck you" was classy, though. Real classy.

--Jeff



_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

Philipp Wolfer wrote:
> I'm not sure if I understood Tom's comment as it was intended, but I
> see a valid point here:
>
> In every section 1.1, 1.2 and 1.3 there are notes about storing the
> tags as UTF-8 and subsections about storing the tag in ID3 and Vorbis
> Comments. Since those rules should apply for all tags it would be good
> to extract them into a separate Implementation section. This would
> make it easier to extend it to other tagging formats.

This wasn't what Tom was suggesting, but it is indeed a good idea to
consolidate those commonalities into an implementation section. It helps
improve cleanliness, although doesn't really have anything to do with
extending to other tagging formats.

What Tom was suggesting was to remove the bits that cover how to
implement the spec in MP3 and Vorbis and consolidate them in some way
that's not clear. This makes no sense. If the various tags all had
support for this stuff built-in, there'd be no need to even be having
this discussion on finding a workable way to store these values. So you
need to have the spec discuss how to actually implement these values in
the context of what is available with the various tag formats (MP3 using
frame X, Vorbis using normal comments, eventually MP4 using atom Y, and
so on).

The values themselves (and the identifiers) are standardized across the
tag formats, which is the best we can do; but you certainly need to
specify where in each tag format to store them.

--Jeff



_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Daniel Stone]

On Wed, Nov 04, 2009 at 09:21:13AM -0500, Jeff Mitchell wrote:
> However, those four little letters "TLDR" established you not as a less
> experienced person simply asking a question but as a jackass who is
> wasting everyone's time by commenting on a spec that he couldn't be
> bothered to read that deals with metadata specifications that he already
> admitted he's not savvy about.

I read the 'TL;DR' in his original email as being a one-sentence précis
of the paragraph above: a lightning summary for people who couldn't be
bothered to read his email properly.  So you may have quite radically
misunderstood his point there ...

TL;DR: The abuse may have been unwarranted.


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

Daniel Stone wrote:

> On Wed, Nov 04, 2009 at 09:21:13AM -0500, Jeff Mitchell wrote:
>> However, those four little letters "TLDR" established you not as a less
>> experienced person simply asking a question but as a jackass who is
>> wasting everyone's time by commenting on a spec that he couldn't be
>> bothered to read that deals with metadata specifications that he already
>> admitted he's not savvy about.
>
> I read the 'TL;DR' in his original email as being a one-sentence précis
> of the paragraph above: a lightning summary for people who couldn't be
> bothered to read his email properly.  So you may have quite radically
> misunderstood his point there ...
>
> TL;DR: The abuse may have been unwarranted.

I don't buy it. Nor do I accept your conclusion of "abuse".

Let's move on. There's a spec to discuss.

--Jeff



_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

Peter van Hardenberg wrote:

> I'd still really like to see the so-called canonical rating take the root of
> the rating namespace. This is, I think, more self-documenting; when in
> doubt, read the least specialized rating. I suppose there may also be
> applications out there which would want to set the rating automatically.
> These would be "canonical" (within the context of this discussion), but
> not "user".
>  
>
>     FMPS_Rating_User (canonical rating, set by user)
>     FMPS_Rating_Critic_Ralph=Gleason
>     FMPS_Rating_Critic_Metacritic
>     FMPS_Rating_Algorithm_Supercool (collaborative)
>     FMPS_Rating_Algorithm_AmarokAutorating (player-specific)

OK, so you're thinking:

FMPS_Rating (canonical user-defined rating)
FMPS_Rating_Critic_Ralph=Gleason
FMPS_Rating_Critic_Metacritic
<snip>

Sounds good to me.

> I like where this is going. I'm thinking something like -- any keys in
> the form FMPS_Rating{_*} must be in the range of 0.0 - 1.0.

Yes, this should be explicitly mentioned.

> One issue we haven't discussed here is how to approach the varying
> styles used in different tag formats. I'd prefer it if we followed local
> conventions. For example, APE and Vorbis comment tags are
> usually CAPSSMUSHEDTOGETHER, whereas ASF is NameSpace/TagName.

I can live with local conventions, but for ease of readability for
someone actually trying to modify their tags by hand -- plus ease of
parsing -- I'd prefer to keep the underscores. So FMPS_Rating on MP3 and
FMPS_RATING on Vorbis work?

> It's worth mentioning that MUSICBRAINZ has claimed its own namespace and
> we should probably follow their lead with that.

Yes, I was planning on that for ASF (just haven't written that in yet).

> I would suggest we include an Appendix section which would give the
> recommended forms for currently available tag formats and advise
> implementors to try to follow local conventions and to propose
> unspecified forms to the XDG list for adoption by the group.

That sounds good.

--Jeff



_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

Peter van Hardenberg wrote:

> On Thu, Nov 5, 2009 at 2:29 PM, Jeff Mitchell <mitchell@...
> <mailto:mitchell@...>> wrote:
>
>
>     OK, so you're thinking:
>
>     FMPS_Rating (canonical user-defined rating)
>     FMPS_Rating_Critic_Ralph=Gleason
>     FMPS_Rating_Critic_Metacritic
>     <snip>
>
>     Sounds good to me.
>
>
> Yes, except FTMPS_Rating_Critic_Ralph=Gleason would violate the rule below.
>  
>
>     > I like where this is going. I'm thinking something like -- any keys in
>     > the form FMPS_Rating{_*} must be in the range of 0.0 - 1.0.

I don't follow:

FMPS_Rating:0.95
FMPS_Rating_Critic_Ralph=Gleason:0.85
FMPS_Rating_Critic_Metacritic:0.82

Is there some violation there?

> Looking at http://wiki.musicbrainz.org/Picard_Tag_Mapping suggests that
> for MP3
> leaving a space would be more common, and for Vorbis, using an underscore.
>
> For MP4 we already have a namespace tool, so it would probably be
> something like:
> ----:org.kde.taglib:RATING as per the unit tests.

I can live with that, except I believe org.freedesktop.fmps (or
org.freedesktop.xdg.fmps) would be more appropriate. I would imagine the
latter as it's more fully-descriptive.

--Jeff



_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg