IPB

Welcome Guest ( Log In | Register )

3 Pages V  < 1 2 3  
Reply to this topicStart new topic
AccurateRip - Future Direction
greynol
post Feb 1 2010, 17:54
Post #51





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



Actually a CUE sheet does little good with discs that have data tracks. You need a log file that shows the start and length of each track (including the data track).


--------------------
Placebophiles: put up or shut up!
Go to the top of the page
+Quote Post
Akkurat
post Feb 1 2010, 18:02
Post #52


REACT Mod developer


Group: Developer
Posts: 929
Joined: 14-November 07
From: Finland
Member No.: 48750



Ahh, brain fart, of course logfile, not cuesheet, fixed the previous post, thanks greynol.
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Feb 9 2010, 08:57
Post #53





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



QUOTE (spoon @ Feb 1 2010, 00:33) *
Here is the proposed new CRC calculation, which should still allow the fast parallel calculation:

Or I could switch to CRC32 which would deal with NULL samples better and a) encourage the use of the offset finding crc, b) field 1001 questions why track 1 and n do not match the CRC32 calculation.


Greetings, Mr. Spoon.

If you haven't made a final decision yet, i have couple of things to say.

First, i think current AccurateRip checksum is enough for all intents and purposes. I've given my reasons in the other thread.

I don't think it's worth the effort to replace it with that 64-bit one.

Concerning CRC32, i think i found a way to do parallel calculation of it (fast enough for offset detection). I can give some technical details if you are interested.

This post has been edited by Gregory S. Chudov: Feb 9 2010, 09:06


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
spoon
post Feb 9 2010, 10:22
Post #54


dBpowerAMP developer


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



I do not think there is a need for parallel calculation as the drive offset finding crc can be used to find the exact pressing offset.


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
hellokeith
post Feb 14 2010, 08:39
Post #55





Group: Members
Posts: 288
Joined: 14-August 06
Member No.: 34027



Spoon,

This is a suggestion. I do realize what areas it could impact in terms of time, complexity, and cost. Just throwing it out there.

I posted this in another thread regarding source of AR submissions.
QUOTE
AR does not provide any indication of the source of submissions. Should it? Ultimately that is a question only the maintainers of AR will answer, so my speculation is really quite irrelevant. But if it did..

On 2006 June 28 at 14:47:19 this album was submitted from IP 213.49.53.xxx from an Optiarc drive with offset -7.

All I have to do is lookup that class C IP block for a general geolocation (city level) and look at the drive type, and I know immediately if it was me or a friend or a complete stranger in Botswana. See 2 entries with all different field values, and you would know immediately that this is no coincidence.
Go to the top of the page
+Quote Post
viktor
post Feb 14 2010, 12:19
Post #56





Group: Members
Posts: 297
Joined: 17-November 06
Member No.: 37682



about using md5 or sha1:

http://en.wikipedia.org/wiki/MD5#Collision_vulnerability

i donno if that's what steve called irrelevant, but i'd feel hesitant to use a "broken" hash algorithm.
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Feb 14 2010, 13:31
Post #57





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



There's no need for a strong hash algorithm in AccurateRip. In fact, there's no need for any hash algorithm in AccurateRip. Hash is needed only for cryptography. For applications such as AccurateRip traditionally and with good reason developers use various CRCs. Set of requirements for CRCs and hashes is different, they are good for different purposes. It would be wrong to say that hash is stronger than CRC. Their strengths and weaknesses are different. For example, CRC32 can guarantee that you will get a different checksum when less than 32 bits of the data is corrupted. No hash function can guarantee that. In terms of collisions, CRC is stronger than any hash of the same size.

This post has been edited by Gregory S. Chudov: Feb 14 2010, 13:38


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
spoon
post Feb 14 2010, 16:01
Post #58


dBpowerAMP developer


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



Also if you wanted extra bits, you could potentially use the other pressings to match, popular CDs might have 14 CRCs there, if you match all 14.

Not sure why it is too important to have IP address of submission, surely you know if you have ripped and submitted?

This post has been edited by spoon: Feb 14 2010, 16:04


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
hellokeith
post Feb 15 2010, 02:44
Post #59





Group: Members
Posts: 288
Joined: 14-August 06
Member No.: 34027



QUOTE (spoon @ Feb 14 2010, 10:01) *
Not sure why it is too important to have IP address of submission, surely you know if you have ripped and submitted?


Due to a hard drive crash a few years back, I can guarantee I've ripped and submitted at least a few same CD's on the same PC w/ same drive but different OS. You also have the issue of people ripping same disc on multiple machines in the same household and ripping same disc on their work PC.

I don't know if IP address is the perfect solution, but some detail of submission source would go a long way.
Go to the top of the page
+Quote Post
radu
post Feb 16 2010, 15:30
Post #60





Group: Members
Posts: 43
Joined: 6-August 03
Member No.: 8198



So... In what stage of developing is this? When can we expect a public release?
Go to the top of the page
+Quote Post
spoon
post Feb 16 2010, 15:40
Post #61


dBpowerAMP developer


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



Different pressing detection code is already in beta (dBpoweramp R14), this new CRC I have written the code but not tested it, so a few weeks, EAC would need updating also which is separate.


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
spoon
post Feb 16 2010, 23:38
Post #62


dBpowerAMP developer


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



Details on the current AR CRC calculation routines (yet to be updated to the new CRC calculation):

http://forum.dbpoweramp.com/showthread.php?t=20641


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Feb 17 2010, 09:45
Post #63





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



Why create another CRC that is not much stronger than previous one? If you want a strong CRC, why not CRC32?


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post

3 Pages V  < 1 2 3
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: 26th July 2014 - 00:33