Fwd: ATF: Stop spreading FUD about other media players
Jeff Mitchell
kde-dev at emailgoeshere.com
Fri Jul 21 14:48:25 UTC 2006
Quoting Martin Aumueller <aumueller at uni-koeln.de>:
> I think this is exactly the point why it is necessary to have it
> configurable.
> This is the only downside of ATF, as I see it. If you happen to already have
> unique ids within your files from some other source, there is no reason to
> not use all the ATF features. To sum it up: I'd be happy if the meaning and
> description of the ATF checkbox would be changed to 'allow automatic meta
> data changes in music files'.
That's true...if we want to do other things like stats in tags, we
should broaden the scope. I *do* think that having some kind of
identifiable name for the group of metadata related features is a
plus. Saying something like "stats have been added to the automatic
meta data changes features" is cumbersome...use an easy-to-remember
name and people will get the association (and if they don't, they
probably wouldn't have gotten it anyways).
However, using uniqueids from other sources is probably an
impossibility. You have to have two things:
Vendor ID: Some text string describing who you are so you can identify
the tag as belonging to you. Not having the Amarok name in the ID
would be foolhardy IMHO, as for our own coding sanity we need to
ensure that the UID we're using is our correct one and adheres to our
specifications (length, which characters are allowed, etc.). But
other players won't want to play nicely with this, just as we wouldn't
want to use an iTunes UID tag (if it existed) since we don't know when
the format will change, what it might change to, and any other
under-the-hood changes.
UID: As mentioned before, it's a configurable length, and could be a
bit vector, or could be ASCII. We use ASCII with some restrictions on
which characters are allowed (to prevent problems with needing to
escape quotes, no newline characters, etc.) with an 8-character
length. Other people/programs may want a 10-character length, or
16-character length, or any of the 63 lengths other than ours that are
possible (for MP3s; other formats support longer ones).
So the UID really consists of a combination of two unique pieces of
metadata; one that specifies the program, and one that specifies the
file. Trying to get other applications to adhere to some
specification is likely to turn out to be frustrating; however, if
other programs want to provide interoperability with our UIDs, it
would not be impossible. We would have to have a common vendor string
(ours could be changed to comply) and have a common specification of
what characters and length comprise the UID itself with changes only
occurring after the agreement of all affected parties. Needless to
say, this appeals to me in a Utopian sense, but it doesn't sound
realistic.
--Jeff
More information about the Amarok
mailing list