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: Relative ease in generating AR hashes for multiple offsets (Read 2793 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Relative ease in generating AR hashes for multiple offsets

This thread stems from a comment I made in another discussion:
> In fact, the algorithm change has actually made checking against alternate pressings more difficult.

I do not believe this, if the official way of checking pressing is used, not the scatter gun try every offset known to man method...

Sour grapes.

That it isn't "official" is hardly relevant. The exploitation of your mal-formed "checksum" was quite elegant and worked quickly. You'll be hard pressed demonstrating that using this exploitation to compare a rip against alternate pressings was any less accurate or effective.

Regarding the scatter gun every offset known to man method, isn't that a fitting description of how your offset hash is used?

Relative ease in generating AR hashes for multiple offsets

Reply #1
Why is it sour grapes? There is a correct way of doing it, and an incorrect way...it is relevant as say a programmer bypassing the official API for foobar when creating a component, then complaining about it later when the program changes and their component no longer functions. Follow the "offical" guide lines and it is not an issue.

The offset hash was designed for that purpose, that is how offsets of drives are found, even if there are 2 or 3 false positives for a given track, it does not matter as a false positive on an offset match will not match the overall CRC for a track.

Relative ease in generating AR hashes for multiple offsets

Reply #2
Re: sour grapes
Let's just say I'm projecting.  This is especially so considering that it has not been proven nor will it likely ever be proven that AR2 will provide any tangible improvement over AR1, despite your good intentions.  Rather, it has the negative affect of starting to render obsolete a very beneficial part of an important piece of software.

Re: what you believe
That you have chosen to redefine what I've said so that you can disagree is your business.  It doesn't really go very far in refuting my claim, however.  Gregory Chudov made it plainly clear that your method is more computationally expensive and because of this he wasn't going to implement it.

Anyway the fact remains, there is nothing about AR2 that provides for the ability to check against alternate pressings that didn't already exist beforehand. (EDIT: No longer relevant due to thread split)

Relative ease in generating AR hashes for multiple offsets

Reply #3
«more difficult» isn't really well justified by «more computationally expensive», at least not as long as we are this far from brute-force password-cracking?

Relative ease in generating AR hashes for multiple offsets

Reply #4
Sure it is.  When you liken the situation to hacking, are you doing so based on my use of the word exploitation or are you actually familiar with what's being discussed?

Relative ease in generating AR hashes for multiple offsets

Reply #5
*sigh*  Flat out claiming an implication which ... well I wouldn't ask for so much that it were logically valid, but ...

«Takes time to run, so I wouldn't bother to use it» and «is difficult to implement, so won't bother to write it», are two completely distinct complaints over AccurateRip2.

There is absolutely nothing that says that just because your computer spends more time completing algorithm1 than algorithm2, then algorithm1 is more «difficult». It might be so in certain cases (I mentioned one for the sake of completeness, only to see it being used to dub me an idiot), that the easy one is cheaper, but the stating it as an implication or even an inference ...?

Matter of fact is, there are lots of algorithms that are «more computationally expensive», but less difficult (just ask your local professor of a relevant discipline of applied mathematics).

Relative ease in generating AR hashes for multiple offsets

Reply #6
Your speaking in generalities answers my question.

I won't be bothered with this until you get yourself up to speed on the differences between the "official" method and Chudov's workaround as well as the differences between AR1 and AR2.  I know you are more than capable based on what I think I know of your mathematical background.  Ignoring that for the moment, you could have at least gotten yourself up to speed from just an historical perspective.

Disappointing!

Relative ease in generating AR hashes for multiple offsets

Reply #7
Your speaking in generalities answers my question.


Your speaking in generalities is itself the logical failure of your argument. Normally you would be able to catch the obvious error that coincidence isn't implication, normally you wouldn't resort to error-in-one-error-in-all, and fairly often you would even require that level of precision from others. Take that as a compliment (I mean, sincerely), but please also take a sincere suggestion that you carefully consider erring on the safe side when exercising moderator privileges in discussions where your personal biases could get the better of you.

Relative ease in generating AR hashes for multiple offsets

Reply #8
Now you're suggesting that I would use my status as a moderator to somehow influence this discussion?

So much for arguing on the merits.