RE: Searching

<[email protected]> Thu, 29 Aug 2002 15:11:07 -0400
Newsgroups gmane.comp.audio.freedb.devel
Message-ID <000001c24f8f$d43ab4d0$6501a8c0@heck>
> Would this really be necessary? I mean, the server software 
> could answer with the (best-)matching track offset - exactly 
> it currently does. I don't think we need an extra function to 
> get all linked entries.

Let me give some examples.

Example#1.  In the spring I wrote an extension to Gnucleus (the
open-source gnutella client).  The user selects an album (thru a search
interface) and the program goes and gets all the tracks.  It evaluated
search results based on a fuzzy text match and based on the playtime of
the search result.  To do this playtime comparison I had to get the
offsets of all the editions of an album (I did it by looking at similar
albums in the search results).

Example#2.  Now I'm doing a retager/renamer for MP3's and Ogg files, and
based on the postings I see I think other people are working on the same
thing (mine will be free and probably open-source).  If a set of files
have ID3 tags then I can do a freedb text search.  Then I take a result
and see if it matches the name and playtime of the files.  Note that I
might only have some of the tracks in an album.  Again, I need all the
possible offsets for the search results.

> > I could also do manual
> > 'eye-ball' work to verify that the master-album's data is 
> correct for 
> > all the albums I own.
> 
> Well, I guess that's then. We can always start a freedb 
> cleanup campaign - especially if we have a database editing 
> interface on the website. But this only makes sense when we 
> have the entries linked properly.
> 
> > An initial, partial, implementation wouldn't be too hard, but it 
> > wouldn't save any space - it would take a little more.  It would
> > involve:
> > (1) Adding the link field to the database.  This means changing the 
> > server code to parse and return this new field. (If the 
> field doesn't 
> > exist then the album is its own master).  I think Yuri was talking 
> > about adding some new fields, so this new field could be 
> added at the 
> > same time.
> 
> Yes, I think the set number field Yuri proposed would be very 
> helpful. As for the LINK-field, I don't think we need to give 
> that info to the users - this can be handled internally 
> without any disadvantages.

Yes, it is better to handle it internally, but it is also more work.

Tom.

> 
> - Joerg
> 
> _______________________________________________
> fdb-dev mailing list
> [email protected]
> http://dtype.org/mailman/listinfo/fdb-dev
>