Extending TagLib::Tag's interface.

[Jeff Mitchell]

On Tuesday 22 April 2008, Peter van Hardenberg wrote:
> >> For ID3v2, I was considering following iTunes' example and creating a
> >> comment with that fieldname as description.
> >
> > Consider doing this properly and using e.g. User-Defined Text
> > Information frames as in part 4.2.6 of the id3v2.4 standard.
> >
> > Just because iTunes doesn't follow the standard doesn't mean you
> > shouldn't either...   :-)
> >
> > --Jeff
>
> Hi Jeff,
>
> You're absolutely right. I always prefer to follow the standard. At the
> same time, I'd like to be able to read iTunes' data and maintain
> compatibility with it. TagLib has bowed to what is effectively iTunes'
> "bug" around ID3v2 genre tags, but I think a compelling case can be made
> for eliminating the numeric genre altogether.
>
> What is Amarok doing these days with in-track storage of metadata?
>
> -pvh

Warning: long response ahead, but hopefully it'll give you some things to 
consider.

AFAIK TagLib bowed to it in the sense that it tried to maintain compatibility 
with other libraries in such a basic field as genre (I don't know the 
details, so half-guessing there); but as comments and the like are free-form 
text, it's a different matter.

Amarok doesn't store much metadata in-track.  In general, aside from an 
experiment or two, we prefer to "stay the hell away" from users' files unless 
the users explicitly request something in there.  It's just good policy; no 
one likes their data being touched without their knowing it.

We have in the past considered writing e.g. play counts and ratings into 
files, but we've always shied away from it in the end for a variety of 
reasons, one simply being that it's only relevant if the user plays it in 
Amarok.  Aside from the whole "don't touch my data if I don't tell you to 
touch it" thing, other considerations if you were to look at play counts are:

1) We don't know what all past and future players use for such information -- 
will they use pre-defined fields, or will they use text fields (and if so 
what format), or will they put it in comment fields?  Oftentimes there are 
predefined fields, and they're not used, in favor of some proprietary method 
(sure, you could interoperate with the "iTunes" comment tag, but that doesn't 
help you get *your* name out there, does it?  And in one of our experiements, 
the frame had our name and website as mandated by the ID3 spec, and we got 
some users railing about how Amarok was marketing itself in *their* 
files...  :-(  )

2) If things are not totally synced across players, you start muddying up the 
metadata as each player writes their own information.

3) Different programs will interpret different things differently...obvious I 
know, but for instance, what is the definition of a "play" when you're 
considering play count?  Some players mark it as played the moment it starts, 
even if it's then immediately skipped.  Some consider it played if it's 
played for more than half the song length.  Some mark it played at the end.  
So even if you do interoperate with other players in storing metadata in the 
file, you don't know that it'll always behave as the user expects it, 
especially if they get used to *your* way.

4) If people have a generic USB mass storage player, which are very common 
(alongside iPods, which do playcounts, and MTP devices, which do playcounts 
but AFAIK are often broken in that regard), the player won't handle 
playcounts.  Maybe in the U.S. market where people are gaga over iPods you 
can make somewhat of an assumption, but this doesn't hold nearly so true in 
international markets.  So even if people always use your app for playback on 
the computer, the idea of storing metadata in their files doesn't actually 
help you any more than a database does.

Could these issues be solved?  Sure, if people would all agree to adhere to 
certain standards.  You know, like the standards that iTunes (and many other 
players) don't fully ahdere to.  Don't expect this to happen.

You do get a bonus by storing information in people's files: they'll last even 
if your app is uninstalled and reinstalled later, or if your app's database 
is wiped, or if a file is moved somewhere.

When you mix these various issues together, our conclusion at least was that 
our database was sufficient -- at least people don't have expectations that 
things will magically work outside of Amarok when they won't.

And I'll strongly voice again that you should probably check with your user 
community before adding any features that write to files at Songbird's, 
rather than the user's, whim.  When some ideas have floated in our IRC 
channel or mailing lists, as well as an experiment in our SVN version, we've 
had a large amount of backlash against it.  Even if 90% of people think it's 
a great idea (which judging from our experience would be a high percentage), 
the minority can be extremely vocal and extremely angry, and did I mention 
extremely vocal?

Of course, right now Amarok is Linux-only, so we tend to deal with a generally 
more aware population in terms of data integrity.  :-)

Hope this helps,
Jeff