Extending TagLib::Tag's interface.
kde-dev at emailgoeshere.com
Thu Apr 24 13:32:30 CEST 2008
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?
Warning: long response ahead, but hopefully it'll give you some things to
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
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,
More information about the taglib-devel