Fingerprinting ... was Re: Thanks for MusicBrainz patch

[Sergey Ivanov]

Yes, probably libofa is not actively maintained (last changes where
made in March of this year) , but It doesn't mean that It doesn't
work. And according to musicbrainz.org this is the only solution used
by MusicBrainz. Yes, may be lastfm Fingerprinting better (i don't
know), but in case of using It in MusicBrainz tagger system we get
ugly puffed code, where one part of tagger uses one system, other part
- another system. More then that MB tagger would be depend on lastfm
service implementation, because of user authentication problem, so If
you don't have lastfm subscription, then you may sit and relax 'cos
you also don't have track identification system.

> The Problem appears as soon as you don't consider the fingerprinting process
> to be only usable or usefull for tagging purposes but store it in the database
> to identify a song. Storing 2 different is a possibility but not clever. It
> will confuse Users and Devs and they would have to decide for every feature
> that uses fingerprints which fingerprint to use.
What is the main goal of storing track fingerprints in DB? As I think,
is to prevent duplicates in collection. But one track compressed with
different coders and with different settings gives different
fingerprints, that's why this fingerprint needes to be processed by
musicdns service to return PUID, and MB base also contains several
PUIDs for a single track. So It works not so smooth. More then that,
I'm not sure that It's a great idea to store so huge (~750 bytes from
135sec sample of track by libofa) chunk of data as fingerprint In user
DB.