View Single Post
  #84  
Old Sep 10, 2009, 04:02 PM
Zorbfish Zorbfish is offline
Senior Member
 
Join Date: Sep 2007
Posts: 267
Default

I thought much of this has already been stated, but I guess I need to do it again.

1. Discid matching has been in the script since day 1. In fact, it currently records any discids sent to it already and stores them for use in future matching. The script performs matching on both discids and track times to ensure all possible matches are caught and returned to the user to choose which disc to read. What does not exist as far as I know is a way for public submission. Perhaps it's already implemented on the staff-side, that I do not know.

2. Track time rounding is accounted for when trying to match against tracks. Whether you round up or down does not matter. I personally do not round it up or down and just drop the frame count. Only if a track length is off by more than 3 seconds does the match fail. CDDB/freedb uses a more complex method for fuzzy matching but does essentially the same thing.

3. There are going to be discs that will fail in the db. These albums are ones that contain pre-gap (track 0) tracks and data tracks. Redbooks will fall into this category as well...

As an example, WOODSOFT's Altis will fail when reading from the (physical) disc because it has a small data track at the end which is not listed here. To fix this we could add the data track to the end of this tracklist but then it breaks for someone who searches using only the audio data (sans data track). Our goal is to support both transparently. This will require the reimplementation of the track/tracklist table that Gigablah is working on. Once it is done I will fix this.
Reply With Quote