IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
How AccurateRip does calculate the discIDs ?
Bregalad
post Feb 28 2010, 23:21
Post #1





Group: Members
Posts: 18
Joined: 9-October 08
Member No.: 59840



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 ?
Go to the top of the page
+Quote Post
sbooth
post Feb 28 2010, 23:46
Post #2





Group: Members
Posts: 84
Joined: 18-December 05
Member No.: 26493



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
Go to the top of the page
+Quote Post
greynol
post Mar 1 2010, 03:44
Post #3





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
spoon
post Mar 1 2010, 10:29
Post #4


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2724
Joined: 24-March 02
Member No.: 1615



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.


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
Porcus
post Mar 1 2010, 13:25
Post #5





Group: Members
Posts: 1779
Joined: 30-November 06
Member No.: 38207



QUOTE (Bregalad @ Feb 28 2010, 23: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 wink.gif


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
Bregalad
post Mar 1 2010, 22:43
Post #6





Group: Members
Posts: 18
Joined: 9-October 08
Member No.: 59840



Thanks a lot for all these explanations biggrin.gif
The whole perfectly answer my question
Go to the top of the page
+Quote Post
Bregalad
post Mar 2 2010, 00:28
Post #7





Group: Members
Posts: 18
Joined: 9-October 08
Member No.: 59840



Actually I still have questions blush.gif

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 rolleyes.gif

This post has been edited by Bregalad: Mar 2 2010, 00:30
Go to the top of the page
+Quote Post
greynol
post Mar 2 2010, 00:51
Post #8





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
Porcus
post Mar 2 2010, 01:48
Post #9





Group: Members
Posts: 1779
Joined: 30-November 06
Member No.: 38207



QUOTE (Bregalad @ Mar 2 2010, 00:28) *
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.



QUOTE (Bregalad @ Mar 2 2010, 00:28) *
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 rolleyes.gif


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?


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Mar 2 2010, 03:39
Post #10





Group: Developer
Posts: 683
Joined: 2-October 08
From: Ottawa
Member No.: 59035



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.4
Go to the top of the page
+Quote Post
Porcus
post Mar 2 2010, 10:56
Post #11





Group: Members
Posts: 1779
Joined: 30-November 06
Member No.: 38207



QUOTE (Gregory S. Chudov @ Mar 2 2010, 03:39) *
probably just with offset outside of CUETools range

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


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
spoon
post Mar 2 2010, 11:47
Post #12


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2724
Joined: 24-March 02
Member No.: 1615



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


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
Bregalad
post Mar 2 2010, 16:25
Post #13





Group: Members
Posts: 18
Joined: 9-October 08
Member No.: 59840



Thanks again for the answers

cuetools db is a great idea biggrin.gif
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
Go to the top of the page
+Quote Post
greynol
post Mar 2 2010, 19:43
Post #14





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (spoon @ Mar 2 2010, 02:47) *
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).

QUOTE (Bregalad @ Mar 2 2010, 07:25) *
it will bring problems with first and last tracks

Not necessarily! smile.gif

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


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 20th April 2014 - 10:00