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

Martin Aumueller aumuell at reserv.at
Fri Oct 12 14:44:26 CEST 2007


The two proposed schemes (musicbrainz and last.fm) try to track songs, not 
files. That's very useful, but a bit different. A combination of both would 
be best. The md5sums done by strigi could come in handy for doing that.

On Friday 12 October 2007, Maximilian Kossick wrote:
> 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


More information about the Amarok-devel mailing list