FMPS Sepcs

[Jeff Mitchell]

On 5/6/2010 9:22 AM, Christoph Reiter wrote:
> 2010/5/5 Jeff Mitchell <mitchell at kde.org>
>>
>> On 5/5/2010 10:53 AM, Christoph Reiter wrote:
>>> "All values are strings in UTF-8 encoding."
>>>
>>> We are using UTF-16 for id3v2.4 (I'm not quite sure why, but I guess
>>> it's because id3v2.3 didn't support utf-8 - Joe sure had a reason for
>>> it)
>>> And I see no problem with it.
>>
>> Hm. I think I'll reword that to essentially say "tags should adhere to
>> the allowed encoding and length limits in the relevant specifications,
>> but should use Unicode whenever possible." That way players/tagging
>> libraries can take their pick so long as they adhere to the appropriate
>> standards. In fact, ID3v2.3 isn't the only problem; Windows Media/ASF
>> file specify UTF-16LE.
> 
> The new text looks better.. I was just wondering if there was a reason to
> force UFT-8 (And I never had a look at WMA..).

Nope, other than that for most media players this makes it
easier...however, the tagging libraries should really take care of this
conversion under the hood, so even that claim is dubious. Note that most
other players will be writing the value as UTF-8 (in ID3v2.4), which is
spec-valid, so I'm assuming you can still read that even if you guys
store as UTF-16.

>> Are there uses you have thought about that aren't satisfied by that
>> limitation?
> 
> I have to admit, I don't quite get the usecase of this section.
> If you replace the word "compilation" with "album" it kind of
> descripes the "album" tag used now.
> 
> How does Amarok use these for example?

I assume you just mean the normal, standard "album" tag, as in "Greatest
Hits". An issue we see is that, when you throw Various
Artist/Compilation albums into the mix, relying on album/artist
combinations often doesn't work out so well. Even album/albumartist
combinations often don't work, most often because the user doesn't enter
an album artist (in some cases due to tagging software that doesn't know
how to do it), and sometimes because they lack consistency in the tag names.

We've ended up coding lots of various heuristics into our collection
scanner to detect things like whether files in the same directory have
the same album name but different artists, and so on. All of these
things are hacky/kludgy. We do allow them to mark albums as various
artists/compilations, but if they have to fully rescan their files, or
reorganize their files in some way, they could end up losing all of this
work.

The idea behind this, therefore, is to have a way to know the following:

a) This track is part of a compilation (the existence of this tag
confirms that).
b) What compilation it belongs to.

The user marks tracks as a compilation, and as a result we generate a
compilation ID and save this compilation ID into the files. Then,
whenever the files are scanned again, no matter where they are (even if
they are organizing their files by artist/album and thus the tracks are
spread out all over the place), we know that they all belong together
under the same album when displayed to the user.

IOW, we can use this to override the heuristics and guesswork -- it
allows us to make the user the boss.

> It's no limitation, but requires code to check if the entered value is allowed.

Now, that all (above) being said -- I'm reconsidering this. Instead of
randomly-generated IDs, some apps may want to allow the user to type
their own identifier, and I could indeed see users wanting to do this,
and being able to pull up a list of compilations and adding or removing
tracks from them. So I'll change this to the same valid string wording
as elsewhere.

>>> 1.4.2 All Playcount Tags
>>> 1.5 Performer Roles
>>>
>>> It might be nice if the spec would mention how to handle existing
>>> solutions for performer roles, rating, playcount like TMCL for
>>> performer roles in ID3, POPM for rating and playcount,
>>> WM/SharedUserRating for rating in WMA...
>>
>> I'm not sure what you mean by "handle existing solutions" -- I don't see
>> what there is to handle. In fact the spec explicitly stays away from
>> those tag-specific solutions because of the disparities in their
>> capabilities/possible values/etc.
> 
> Keeping the POPM tag with FMPS_Rating in sync (with a defined
> mapping) would give us the option to know when a non FMPS
> player has changed the rating and adapt to that.
> 
> But on a second thought it's not worth it.

It's an interesting idea, but I can see ways that it could easily be
broken. My feeling is that if individual apps want to go that extra
mile, cool -- but since we can't control all of the apps using POPM,
even if they do crazy things with it (as we are all well aware lots of
apps do crazy things with tags), we shouldn't worry about figuring out
algorithms to deal with said crazy things.

--Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20100506/ec1b4f20/attachment.pgp>