From a150899221a5badff9740703b754f901b4f52762 Mon Sep 17 00:00:00 2001 From: cinap_lenrek Date: Thu, 14 Apr 2011 17:27:24 +0000 Subject: fill /acme --- acme/bin/source/acd/discid | 159 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 159 insertions(+) create mode 100644 acme/bin/source/acd/discid (limited to 'acme/bin/source/acd/discid') diff --git a/acme/bin/source/acd/discid b/acme/bin/source/acd/discid new file mode 100644 index 000000000..1bc9dbf66 --- /dev/null +++ b/acme/bin/source/acd/discid @@ -0,0 +1,159 @@ + +CDDB DISCID +----------- + +Both forms of CDDB access require that the software compute a "disc +ID" which is an identifier that is used to access the CDDB. The disc +ID is a 8-digit hexadecimal (base-16) number, computed using data from +a CD's Table-of-Contents (TOC) in MSF (Minute Second Frame) form. The +algorithm is listed below in Appendix A. + +It is crucial that your software compute the disc ID correctly. If it +does not generate the correct disc ID, it will not be compatible with CDDB. +Moreover, if your software submits CDDB entries with bad disc IDs to the +CDDB archives, it could compromise the integrity of the CDDB. + +[...] + +APPENDIX A - CDDB DISCID ALGORITHM +---------------------------------- + +The following is a C code example that illustrates how to generate the +CDDB disc ID. [...] A text description +of the algorithm follows, which should contain the necessary information +to code the algorithm in any programming language. + + +struct toc { + int min; + int sec; + int frame; +}; + +struct toc cdtoc[100]; + +int +read_cdtoc_from_drive(void) +{ + /* Do whatever is appropriate to read the TOC of the CD + * into the cdtoc[] structure array. + */ + return (tot_trks); +} + +int +cddb_sum(int n) +{ + int ret; + + /* For backward compatibility this algorithm must not change */ + + ret = 0; + + while (n > 0) { + ret = ret + (n % 10); + n = n / 10; + } + + return (ret); +} + +unsigned long +cddb_discid(int tot_trks) +{ + int i, + t = 0, + n = 0; + + /* For backward compatibility this algorithm must not change */ + + i = 0; + + while (i < tot_trks) { + n = n + cddb_sum((cdtoc[i].min * 60) + cdtoc[i].sec); + i++; + } + + t = ((cdtoc[tot_trks].min * 60) + cdtoc[tot_trks].sec) - + ((cdtoc[0].min * 60) + cdtoc[0].sec); + + return ((n % 0xff) << 24 | t << 8 | tot_trks); +} + +main() +{ + int tot_trks; + + tot_trks = read_cdtoc_from_drive(); + printf("The discid is %08x", cddb_discid(tot_trks)); +} + + +This code assumes that your compiler and architecture support 32-bit +integers. + +The cddb_discid function computes the discid based on the CD's TOC data +in MSF form. The frames are ignored for this purpose. The function is +passed a parameter of tot_trks (which is the total number of tracks on +the CD), and returns the discid integer number. + +It is assumed that cdtoc[] is an array of data structures (records) +containing the fields min, sec and frame, which are the minute, second +and frame offsets (the starting location) of each track. This +information is read from the TOC of the CD. There are actually +tot_trks + 1 "active" elements in the array, the last one being the +offset of the lead-out (also known as track 0xAA). + +The function loops through each track in the TOC, and for each track +it takes the (M * 60) + S (total offset in seconds) of the track and +feeds it to cddb_sum() function, which simply adds the value of each digit +in the decimal string representation of the number. A running sum of this +result for each track is kept in the variable n. + +At the end of the loop: +1. t is calculated by subtracting the (M * 60) + S offset of the lead-out +minus the (M * 60) + S offset of first track (yielding the length of +the disc in seconds). + +2. The result of (n modulo FFh) is left-shifted by 24 bits. + +3. t is left shifted by 8. + +The bitwise-OR operation of result 2., 3. and the tot_trks number is +used as the discid. + +The discid is represented in hexadecimal form for the purpose of +xmcd cddb file names and the DISCID= field in the xmcd cddb file itself. +If the hexadecimal string is less than 8 characters long, it is +zero-padded to 8 characters (i.e., 3a8f07 becomes 003a8f07). All +alpha characters in the string should be in lower case, where +applicable. + +Important note for clients using the MS-Windows MCI interface: + +The Windows MCI interface does not provide the MSF location of the +lead-out. Thus, you must compute the lead-out location by taking the +starting position of the last track and add the length of the last track +to it. However, the MCI interface returns the length of the last track +as ONE FRAME SHORT of the actual length found in the CD's TOC. In most +cases this does not affect the disc ID generated, because we truncate +the frame count when computing the disc ID anyway. However, if the +lead-out track has an actual a frame count of 0, the computed quantity +(based on the MSF data returned from the MCI interface) would result in +the seconds being one short and the frame count be 74. For example, +a CD with the last track at an offset of 48m 32s 12f and having a +track length of 2m 50s 63f has a lead-out offset of 51m 23s 0f. Windows +MCI incorrectly reports the length as 2m 50s 62f, which would yield a +lead-out offset of 51m 22s 74f, which causes the resulting truncated +disc length to be off by one second. This will cause an incorrect disc +ID to be generated. You should thus add one frame to the length of the +last track when computing the location of the lead-out. + +The easiest way for Windows clients to compute the lead-out given information +in MSF format is like this: + +(offset_minutes * 60 * 75) + (offset_seconds * 75) + offset_frames + +(length_minutes * 60 * 75) + (length_seconds * 75) + length_frames + 1 = X + +Where X is the offset of the lead-out in frames. To find the lead-out in +seconds, simply divide by 75 and discard the remainder. -- cgit v1.2.3