Skip to main content

Topic: AccurateRip - Future Direction (Read 36603 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • greynol
  • [*][*][*][*][*]
  • Global Moderator
AccurateRip - Future Direction
Reply #50
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).
13 February 2016: The world was blessed with the passing of a truly vile and wretched person.

Your eyes cannot hear.

  • Akkurat
  • [*][*][*][*][*]
  • Developer
AccurateRip - Future Direction
Reply #51
Ahh, brain fart, of course logfile, not cuesheet, fixed the previous post, thanks greynol.

AccurateRip - Future Direction
Reply #52
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.
  • Last Edit: 09 February, 2010, 03:06:19 AM by Gregory S. Chudov
CUETools 2.1.4

  • spoon
  • [*][*][*][*][*]
  • Administrator
AccurateRip - Future Direction
Reply #53
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.

  • hellokeith
  • [*][*][*][*]
AccurateRip - Future Direction
Reply #54
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.

  • viktor
  • [*][*][*][*]
AccurateRip - Future Direction
Reply #55
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.

AccurateRip - Future Direction
Reply #56
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.
  • Last Edit: 14 February, 2010, 07:38:26 AM by Gregory S. Chudov
CUETools 2.1.4

  • spoon
  • [*][*][*][*][*]
  • Administrator
AccurateRip - Future Direction
Reply #57
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?
  • Last Edit: 14 February, 2010, 10:04:14 AM by spoon

  • hellokeith
  • [*][*][*][*]
AccurateRip - Future Direction
Reply #58
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.

  • radu
  • [*]
AccurateRip - Future Direction
Reply #59
So... In what stage of developing is this? When can we expect a public release?

  • spoon
  • [*][*][*][*][*]
  • Administrator
AccurateRip - Future Direction
Reply #60
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
  • [*][*][*][*][*]
  • Administrator
AccurateRip - Future Direction
Reply #61
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

AccurateRip - Future Direction
Reply #62
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