Skip Menu |

This queue is for tickets about the CDDB CPAN distribution.

Report information
The Basics
Id: 38150
Status: resolved
Priority: 0/
Queue: CDDB

People
Owner: Nobody in particular
Requestors: chuck [...] ece.cmu.edu
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: bug in CDDB.pm rev 1.17
Date: Fri, 21 Mar 2008 12:43:14 -0400
To: rcaputo [...] cpan.org
From: Chuck Cranor <chuck [...] ece.cmu.edu>

Message body is not shown because it is too large.

On Sun Aug 03 19:06:39 2008, chuck@ece.cmu.edu wrote: Show quoted text
> Hi- > > There is a bug in CDDB.pm that is mostly being masked by the CDDB's > fuzzy matching (at least on my system). The current code is mishandling > the 2 second (150 frame) interval at the start of a disc. The fix > is simple (remove the "+ 150" from line 519)
I'm not sure this recommendation is correct. For example, this Java example says that the first track (beginning at 0m0s) starts at frame 150: http://www.cs.princeton.edu/introcs/51data/CDDB.java.html Wikipedia says the first track starts at 2 seconds, which is 150 frames / 75 frames per second. So again, the first track's 0m0s start time is at 150 frames. I think CDDB.pm's calculation may be in error for considering the frames in the TOC's MSF data. The algorithms I've seen truncate the frames. By adding them, CDDB.pm's track times could accumulate significant error.
Also, the test program looks for the "FreeDB / TESTCD", which is in the jazz genre and has an ID of 03015501. The existing disc ID calculation matches the test ID.
It turns out that the test program had the wrong test CD TOC information. According to the FreeDB test data, track start times include the 2sec lead-in, so CDDB.pm shouldn't be adding it. When I remove the "+ 150", the correct input data passes all tests. Thank you for the report. I will release CDDB 1.20 tonight with the fix. Sorry for the delay.