### Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: How AccurateRip does calculate the discIDs ? (Read 10429 times)
0 Members and 1 Guest are viewing this topic.

## How AccurateRip does calculate the discIDs ?

##### 2010-02-28 22:21:53
Hi

Firstly the last part of AccurateRip discID is the cddb discID, right ?

Then I suppose the rest is calculated using the TOC , but does it uses track length in seconds (as cddb) and performs a different algorithm or does it take account of more precise information for example tracks length in frames ?

Can we be sure two different albums having the same track lengths in seconds (which is highly improbable for most albums but totally possible for 2-track singles) (and which will get the same cddb discID) will have a different AccurateRip discID ?

Or taking it reverse can we be sure (or 99,9% sure) an AccurateRip discID correspond to a single existing CD ? or does it at least tell something about two such CDs ?

## How AccurateRip does calculate the discIDs ?

##### Reply #1 – 2010-02-28 22:46:34
I can tell you how the ID is calculated, but I will have to leave the odds of collision to someone with more math skills than I.

An AR ID looks like this: 017-002f3efc-0258c6fd-e0122511 (this is for a Sheryl Crow disc).

The first part, 017, is the number of tracks, formatted with three digits.

The second part, 002f3efc, is the sum of all the TOC indexes (AKA LBAs). The lead out is treated as track n + 1.

The third part, 0258c6fd, is the sum of all the indexes times their track number. Again, the lead out is treated as track n + 1.

As you noticed, the last part, e0122511, is the disc's FreeDB/CDDB ID.

## How AccurateRip does calculate the discIDs ?

##### Reply #2 – 2010-03-01 02:44:57
That and current AR hash calculation can be found here:
http://www.hydrogenaudio.org/forums/index....showtopic=53583

## How AccurateRip does calculate the discIDs ?

##### Reply #3 – 2010-03-01 09:29:48
It does not matter if there are collisions on the Disc ID as multiple pressings / discs can all live side by side in the database.

## How AccurateRip does calculate the discIDs ?

##### Reply #4 – 2010-03-01 12:25:21
Or taking it reverse can we be sure (or 99,9% sure) an AccurateRip discID correspond to a single existing CD ? or does it at least tell something about two such CDs ?

As Spoon points out, two different CDs with matching discID's can live side-by-side. And different pressings do, leading to "false negatives" when you are submitting the first rip of a pressing concurrent to one which is already filed as accurate.

Two different discs with same discID will be treated just like different pressings.

So apart from the different pressings issue -- including the "seemingly different pressings but actually different", the only interesting collision is the event where disc A and disc B have the same disc ID, and where an erroneous rip of A matches a submission of B.  Then the "collision" of A and B falsely identifies the error as accurate. Find such an eventand I'll buy you a beer. Find such an event where A and B are different CDs, not merely different pressings, and I'll buy you more than one beer
High Voltage socket-nose-avatar

## How AccurateRip does calculate the discIDs ?

##### Reply #5 – 2010-03-01 21:43:18
Thanks a lot for all these explanations
The whole perfectly answer my question

## How AccurateRip does calculate the discIDs ?

##### Reply #6 – 2010-03-01 23:28:16
Actually I still have questions

Why does the first part, number of tracks, does not appear in CUETools reports ?
Is it used when asking AccurateRip database ?

I understand disc ID collisions are no problem, cool
Anyway discID collisions (I mean two totally different albums having the same ID) are almost impossible, no ?
Even with the colossal number of existing albums I believe it's almost impossible there exists two totally different CDs with the same exact TOC
Though it might be possible for CD singles I guess it is really improbable when there is at least 4 tracks or 20 min of music
And also that the probability of getting the same AccurateRip discID whereas different TOC is almost null
So an AccurateRip discID is almost surely linked to a single existing album (eventually in different pressings)
Right ?

So on this example (Protest the Hero - Fortress)
Code: [Select]
`[Verification date: 28.02.2010 13:41:10]    [Disc ID: 0010d0be-0084b66f-8b09ac0a]    Pregap length 00:50:59.    Track [ CRC ] Status    01 [f1877e25] (00/24) No matches    02 [7dd00c91] (00/23) No matches    03 [c63dc326] (00/23) No matches    04 [fd0d9c32] (00/23) No matches    05 [92ff52ad] (00/23) No matches    06 [0c4542ba] (00/24) No matches    07 [d853bb6d] (00/23) No matches    08 [8cdc9a98] (00/23) No matches    09 [7c836d5d] (00/23) No matches    10 [00b2a409] (00/23) No matches    Offsetted by 664:    01 [e5313db5] (04/24) Accurately ripped    02 [b340fb51] (04/23) Accurately ripped    03 [23a0e3bd] (04/23) Accurately ripped    04 [a25eb750] (04/23) Accurately ripped    05 [06b589aa] (04/23) Accurately ripped    06 [66a8835e] (04/24) Accurately ripped    07 [95da091a] (04/23) Accurately ripped    08 [378757f7] (04/23) Accurately ripped    09 [cf2ac92e] (04/23) Accurately ripped    10 [31427cec] (04/23) Accurately ripped        Track [ CRC32 ] [W/O NULL] [ LOG ]    -- [C67B45E5] [FE7B09E0] CRC32    01 [EA289664] [FD25EC51]    02 [5510B103] [BA8D8A92]    03 [824866FF] [E5E4E8B1]    04 [BB51AF5F] [B78BD2C6]    05 [A64F03C2] [7D8C9937]    06 [6EDFD398] [CE4DDB5B]    07 [FEB2FA66] [4B709F32]    08 [E12A46EE] [CC3FB96A]    09 [6F24489A] [5930857B]    10 [19CA3B60] [BE57D634]`

We can be almost sure the other 19 results on this discID correspond to other pressings of this album (or maybe results on which HTOA handling screwed up ?), isn't it ?
Or could they be from a totally different album (there is another album with the same freedb id : http://www.freedb.org/freedb_search.php?wo...p;grouping=none )

I know it has no importance, the confidence here is 4 so my rip is for sure accurate but I'm curious

## How AccurateRip does calculate the discIDs ?

##### Reply #7 – 2010-03-01 23:51:55
Aside from the location of the 01 index of the first track which is well-defined in the TOC, HTOA has no bearing on anything having to do with AccurateRip.

The other results could be for a pressing that exists outside the offset window which is +/- 5 frames for CUETools (link).

Since the AR disc ID is merely a hash calculated from the information found in the TOC, it is possible for there to be collisions from discs with a different TOC.  I have no idea what the odds are, and as was previously stated, it doesn't really matter.

## How AccurateRip does calculate the discIDs ?

##### Reply #8 – 2010-03-02 00:48:35
So an AccurateRip discID is almost surely linked to a single existing album (eventually in different pressings)
Right ?

With your reservation for singles, then the probability is really really close to zero, yes.

So on this example (Protest the Hero - Fortress)

[...]

We can be almost sure the other 19 results on this discID correspond to other pressings of this album (or maybe results on which HTOA handling screwed up ?), isn't it ?

[...]

I know it has no importance, the confidence here is 4 so my rip is for sure accurate but I'm curious

A few such results do puzzle me as well. Have you tried to shift the offset in CUETools by + or - 5878, as in the link Greynol posts?
High Voltage socket-nose-avatar

## How AccurateRip does calculate the discIDs ?

##### Reply #9 – 2010-03-02 02:39:11
We'll probably find out more about this when CUETools DB gets more populated, for now i only have 3 examples of alleged AR id collisions, and in each case those are different pressings of the same CD, probably just with offset outside of CUETools range: http://db.cuetools.net/?discid=016-0027624...e1d551-d8121610, http://db.cuetools.net/?discid=011-00150ab...b4859c-950b930b, http://db.cuetools.net/?discid=010-000f950...823fc1-810a120a
CUETools 2.1.6

## How AccurateRip does calculate the discIDs ?

##### Reply #10 – 2010-03-02 09:56:51
probably just with offset outside of CUETools range

Which suggests the range should be wider, right? At least as an option? ;-)
High Voltage socket-nose-avatar

## How AccurateRip does calculate the discIDs ?

##### Reply #11 – 2010-03-02 10:47:53
You could never verify the first or last track as it would be outside the 5 sectors ignored at the start or end.

## How AccurateRip does calculate the discIDs ?

##### Reply #12 – 2010-03-02 15:25:06

cuetools db is a great idea
I will try cuetools 2.0.5

I will try to change offset of the rip and check again
if I understand well it will bring problems with first and last tracks anyway it will be cool to see if it brings results for other tracks

## How AccurateRip does calculate the discIDs ?

##### Reply #13 – 2010-03-02 18:43:25
You could never verify the first or last track as it would be outside the 5 sectors ignored at the start or end.

You can easily verify the first or last track when this area is comprised of null samples, which is really not that uncommon at all.  This is especially the case when the applied offset is negative (the data coming before the first track).

it will bring problems with first and last tracks

Not necessarily!