AFT in 2.0 (was: Re: Kamion migration and backup tool)

[Maximilian Kossick]

On Friday 12 October 2007, Jeff Mitchell wrote:
> On Thursday 11 October 2007, Dan Meltzer wrote:
> > On 10/11/07, Jeff Mitchell <kde-dev at emailgoeshere.com> wrote:
> > > On Saturday 06 October 2007, Ian Monroe wrote:
> > > > *what you'd really want to migrate and backup is in the MySQL,
> > > > PostgreSQL or sqlite database in the statistics table. Thanks to file
> > > > tracking we don't have to worry about if the users put the file in a
> > > > different location really on different computers.
> > >
> > > Speaking of file tracking, that'll have to get sorted at some point for
> > > 2.0. It'll have to be totally rewritten, considering the original
> > > implementation was heavily integrated into MetaBundle and CollectionDB
> > >
> > > :-)  ...except for the basic algorithm (which is the hard part anyways,
> > >
> > > really).  Just another thing to tick up on our TODO list.
> >
> > Would it make sense to use musicbrainz UUID here to identify tracks
> > rather than our own method?  It seems like musicbrainz UUID is become
> > a commonly used method of identifying a unique track, xspf supports
> > it, xesam supports it, and I think some forms of metadata support it.
>
> Perhaps.  There are a few drawbacks though.
>
> The first is that AFAIK, it attempts to fingerprint files and then figure
> out what file it really is.  This fingerprinting probably has to read/hash
> the entire file.  One of the reasons AFT was so unobtrusive was that it was
> extremely fast to calculate but with good results.
>
> It also means another dependency that must be compiled in, and not one that
> I think many people really care about or many packagers will really
> require, in order for it to work.  AFT in stable has no dependencies.
>
> Also it only works for mp3/vorbis/cd media, again, AFAIK.  AFT worked for
> any file that you could have in your collection.
>
> I've also heard that the libraries are buggy and are not maintained well
> and prone to breakage.  In fact, Amarok stable doesn't compile against the
> version of tunepimp/musicbrainz installed on my computer, which are the
> only versions Gentoo has.
>
> So together all this leads me to think that using musicbrainz as the basis
> for file tracking is not a great idea.  But feel free to enlighten me if I
> got something wrong.
>
> --Jeff

What about the new last.fm fingerprinting [1]? Could we use that algorithm 
instead of our own?

Max

[1] http://blog.last.fm/2007/08/29/audio-fingerprinting-for-clean-metadata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20071012/6c1cb458/attachment.pgp