The offset detetion is simply a CRC (checksum) of 1 frame, in the first track, the program can hunt for the right offset.
>DB2-OD gets either CRC32 or ARCS or something else? based on the 5 leading and 5 ending framesCRC32, correct.
[DB2] In addition a 2xCRC32's should be generated:[CRC1][..............CRC2............][CRC1]So CRC1 is the first say 5 frames and last 5 frames of the track, CRC2 is all the track. These 2 CRCs could be submitted to a 2nd database, where the CRC1 will go into the current offset finding slot, no changes on the backend! (apart from creating the 2nd database)
In the DB are stored comp ident - big long OLE type identifier, CRC of track + crc of offset.
They are calculated over ~544 samples, so the bug does into come into play, the offset is just 1 frame about 50 in (off the top of my head).
>There are 16 M tracks in the DB and its size is 14 GB, so that tells me that there are an average of 5 entries per trackI would say that is right.
4. Fix & Additional Development: Use a different hash, MD5, sha-1, these would increase storage of the database by 5x (160bits of sha-1).
We used everything from the CD TOC to cut the number of collisions, including the data track on CD Extra.
Yes each submission has a record, resubmissions are dropped, not replaced.