Skip to main content

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: AccurateRip - Future Direction (Read 49942 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

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).

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.
CUETools 2.1.6

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.

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.


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.
CUETools 2.1.6

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?

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.

AccurateRip - Future Direction

Reply #59
So... In what stage of developing is this? When can we expect a public release?

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.


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.6