Kamion migration and backup tool

Jeff Mitchell kde-dev at emailgoeshere.com
Sun Oct 14 00:06:47 CEST 2007


On Saturday 13 October 2007, Tobias G. Pfeiffer wrote:
> Hi!
>
> On Saturday 13 October 2007, 17:44, Jeff Mitchell wrote:
> > Agreed.  Neither MusicBrainz nor Last.fm need to be dependencies for AFT
> > to work, so I'd rather not make them dependencies for it.  AFT should
> > track files, and MusicBrainz/Last.fm should identify songs.  Two
> > separate but complimentary goals.
>
> The aim of AFT is to keep metadata for a song when the file containing this
> song has been moved, right?

Not really.  The aim is to let any part of Amarok that has been made to take 
advantage of it keep track of the current location of a file.  It's not 
metadata-specific...statistics, playlists, and the like could all take 
advantage of it.

> So, provided that such a fingerprint is really 
> unique up to a certain degree, I think it is a good thing to look at a file
> that has just been added, compute the fingerprint and see that this file
> contains the song we have stored metadata for and which apparently does not
> exist any more. This also enables Amarok to keep track of changes to the
> ID3 tag (or other changes to the file, e.g. conversion from mp3 to ogg)
> that have been made outside the collection. Problems only arise when two
> files give the same fingerprint...

These problems have already all been worked out in a smart way in AFT in 1.4, 
and the same algorithms would apply for 2.0.  But I still don't think using 
MB or Last.fm fingerprints are a good choice for the ID, not in the least 
because you'd have to scan every bit of every file in order to see the 
benefit -- in addition to the scan that Strigi's already done.

--Jeff


More information about the Amarok-devel mailing list