AFT in 2.0

Jeff Mitchell kde-dev at emailgoeshere.com
Fri Oct 12 16:53:59 CEST 2007


Martin Aumueller wrote:
> 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.
>   
I didn't know Strigi calculates/keeps md5sums for every file.  That's
great, because it means our always-on collection scanner (I'm assuming
we'll have a way to have it act as the provider of data what with the
talk of Xesam) will be able to be queried for new locations of md5sums,
and since it'll track files outside of when Amarok is open and I assume
integrates with inotify, things should be even smoother in Amarok 2.0
without needing to wait for (or force) an incremental rescan.  (Of
course, you'd still have to have logic to deal with things like, the
md5sum has changed but a file still exists in the same path and other
conditions.)  Pie in the sky, but it does look like that's where things
are headed.

As for MusicBrainz/Last.fm, Martin is correct.  They have their uses,
but I don't think it's a good solution for AFT.  However, the most
frequent request/question I get in private emails about AFT is, "how can
I use this to find duplicate songs?"  And for that, integrating MB/L.fm
fingerprinting data would be extremely useful.  In fact, AFT could
compliment it, because once the fingerprints are calculated they could
be stored in the database so they don't have to be recalculated, and
then AFT could update that database as necessary to prevent unneeded
recalculations if the file has changed (like a metadata update).

--Jeff

>>> 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