On 5/6/2010 9:22 AM, Christoph Reiter wrote: > 2010/5/5 Jeff Mitchell <[email protected]> >> >> 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
