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