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 >