How AccurateRip does calculate the discIDs ? Options

[Bregalad]

Hi
I have some questions about the AccurateRip discIDs, I searched but didn't find anything about this

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 ?

[sbooth]

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.

This post has been edited by sbooth: Feb 28 2010, 23:48

[greynol]

That and current AR hash calculation can be found here:
http://www.hydrogenaudio.org/forums/index....showtopic=53583

[spoon]

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.

[Porcus]

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

[Bregalad]

Thanks a lot for all these explanations
The whole perfectly answer my question

[Bregalad]

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

[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

This post has been edited by Bregalad: Mar 2 2010, 00:30

[greynol]

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.

This post has been edited by greynol: Mar 2 2010, 01:06

[Porcus]

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?

[Gregory S. Chudo...]

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

[Porcus]

probably just with offset outside of CUETools range

Which suggests the range should be wider, right? At least as an option? ;-)

[spoon]

You could never verify the first or last track as it would be outside the 5 sectors ignored at the start or end.

[Bregalad]

Thanks again for the answers

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

[greynol]

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!

This post has been edited by greynol: Mar 2 2010, 20:29