> > The only really good thing about the CDDB protocol is that it allows a
> > disc which almost matches the ID to be picked out, just in case there
> > are multiple versions of a disc with different properties.
> Wouldn't it be better to first send the checksum as now to see if there is
> an exact match, then as a fallback send the whole TOC for fuzzy matching?
> The largest possible TOC is still only a couple of hundred bytes.
> The fuzzy matching needs to be done on the server unless we can come
> up with a good ``fuzzy hash'' function, and I'm sure that giving the
> server the TOC information would significantly improve the accuracy of
> subsequent matches.
Will the client be responsible for first submitting the MD5 hash, and if that
fails, resubmitting a request using the full TOC? I like the idea of only
submitting a hash first, but with the speed of the hash function and power of
the server, should the request be composed of just the TOC (and other vital
information for the hash), which the server can MD5 itself to search for the
exact match, and subsequently use to perform a fuzzy search if there is no
exact match? It would reduce the bandwidth requirement for CDs without exact
matches (situations which I encounter fairly often while using CDDB). Would
this be a serious drain on available bandwidth/computing power?
-- /\/\att /\/\astracci mmastrac nospam at ucalgary.ca"The act of breaking into a computer system has to have the same social stigma as breaking into a neighbor's house. It should not matter that the neighbor's door is unlocked." [Ken Thompson, 1983 Turing Award Lecture]