Need Audio CD Ripping Software Recommendations

[diecaster]

Look here:

 

http://forums.stevehoffman.tv/threads/dbpoweramp-is-superior-to-eac-for-secure-ripping.179662/#post-4337030

 

Here is a quote:

 

"AR [AccurateRip] checksums, when they match, are virtually 100% reliable. For each accurate rip match, the chances of the disk getting the same checksum but the data being different are 1 in 4 billion. If you have 3 AR matches the chance of the data being wrong is 1 in 4 billion times 4 billion times 4 billion. So accuraterip is pretty durn accurate."

 

Just think about how low the odds are for a match error when there are 20 AccurateRip matches in the database. I did the math. It is 1 in 1.0995116277760003e+192. Or 1 in 4,000,000,000^20.

 

That is a really huge number which means it is just about impossible for there to be an error..

 

This shows, really it proves, why AccurateRip is far better than any method @audiventory suggest or recommends.

 

[tmtomh]

6 minutes ago, diecaster said:

Look here:

 

http://forums.stevehoffman.tv/threads/dbpoweramp-is-superior-to-eac-for-secure-ripping.179662/#post-4337030

 

Here is a quote:

 

"AR [AccurateRip] checksums, when they match, are virtually 100% reliable. For each accurate rip match, the chances of the disk getting the same checksum but the data being different are 1 in 4 billion. If you have 3 AR matches the chance of the data being wrong is 1 in 4 billion times 4 billion times 4 billion. So accuraterip is pretty durn accurate."

 

Just think about how low the odds are for a match error when there are 20 AccurateRip matches in the database. I did the math. It is 1 in 1.0995116277760003e+192. Or 1 in 4,000,000,000^20.

 

That is a really huge number which means it is just about impossible for there to be an error..

 

This shows, really it proves, why AccurateRip is far better than any method @audiventory suggest or recommends.

 

 

Yes absolutely. Unfortunately, @audiventory is absolutely convinced that AccurateRip is inferior to the methods he is suggesting, and he chimes in with his same nonsense - and it is indeed nonsense - every time this subject comes up.

 

He actually seems fairly civil and cheerful in his comments, but it's a waste talking to him, because he's one of those people who will not allow you to disagree with him - he will only allow you to "misunderstand" him. He genuinely doesn't understand that people do in fact get what he's trying to say - and they still think he's wrong.

[mansr]

9 minutes ago, diecaster said:

Here is a quote:

 

"AR [AccurateRip] checksums, when they match, are virtually 100% reliable. For each accurate rip match, the chances of the disk getting the same checksum but the data being different are 1 in 4 billion. If you have 3 AR matches the chance of the data being wrong is 1 in 4 billion times 4 billion times 4 billion. So accuraterip is pretty durn accurate."

That's not correct. No matter how many other rips got the same checksum, the probability that yours matches by random chance despite having errors is still 1 in 4 billion. The calculation above gives the probability that all the rips are different, which isn't a particularly interesting number.

[audiventory]

15 minutes ago, diecaster said:

For each accurate rip match, the chances of the disk getting the same checksum but the data being different are 1 in 4 billion.

 

It is mean probability of appearing of repeatable checksum. It is not related to error detection.

[diecaster]

8 minutes ago, mansr said:

That's not correct. No matter how many other rips got the same checksum, the probability that yours matches by random chance despite having errors is still 1 in 4 billion. The calculation above gives the probability that all the rips are different, which isn't a particularly interesting number.

 

No. What is being said is that each time another disc is added to the database with that same checksum, the chance the checksum is wrong goes down. I certainly worded my commentary incorrectly.

[audiventory]

27 minutes ago, tmtomh said:

because he's one of those people who will not allow you to disagree with him

 

I should to agree with you just to be agree with you?

 

27 minutes ago, tmtomh said:

he chimes in with his same nonsense - and it is indeed nonsense

 

To such states, you need to show technical evidences. "Nonsense" is technical term.

When I try discuss simplest formulas, it is denied immediately. Why it so?

 

May be former communication engineer, who develop and analize systems, with experience more 18 years, know something about errors in information systems, isn't it?

 

 

 

[mansr]

35 minutes ago, diecaster said:

No. What is being said is that each time another disc is added to the database with that same checksum, the chance the checksum is wrong goes down. I certainly worded my commentary incorrectly.

Yes, each matching rip strengthens the confidence in the checksum. The chance that your specific rip matches by accident is, however, constant.

 

The important thing to realise here is that verification against the database is independent of any other methods used to ensure a good rip. Adding another check can never make the others less effective. It does, however, slightly increase the chance of incorrectly flagging a good rip as bad. I don't really see that being a problem, though.

[mansr]

32 minutes ago, audiventory said:

When I try discuss simplest formulas, it is denied immediately. Why it so?

Because they are misapplied.

[audiventory]

21 minutes ago, diecaster said:

No. What is being said is that each time another disc is added to the database with that same checksum, the chance the checksum is wrong goes down. I certainly worded my commentary incorrectly.

 

Quote

For each accurate rip match, the chances of the disk getting the same checksum but the data being different are 1 in 4 billion. If you have 3 AR matches the chance of the data being wrong is 1 in 4 billion times 4 billion times 4 billion.

 

4 billion looks like to total number of checksums. 4 billion of number combinations are need to try to guarantee unique checksum for each CD.

May be lost in translation, but I'm not sure exactly, that the author of the quote want to write in the second sentence. What he meant as "wrong": wrong calculated checksum or similar checksums for different CDs?

If he said about correct ripping ("wrong calculated checksum"), there no probability that matches (input database data) are correct initially.

 

[DaQi]

So...?

Use DBPoweramp for Windows - its good. I've used it and recommend it. It uses Accuraterip which if your rip matches with appears to mean there is some chance in many billions that you didn't get a good rip.  Many here agree. 

 

Or...

Use safe CD ripper, no idea how good it is because I haven't tried it. It uses lots of math about probabilities. Lots to talk about how good it is from the developer. Not as many here agree. 

[audiventory]

1 minute ago, mansr said:

Because they are misapplied.

Again non-technical.

[audiventory]

1 minute ago, DaQi said:

Not as many here agree.

 

Truth is not depend how many is agree

 

 

[jhwalker]

Take a typical track ripped from a CD.  If even ONE byte (among several millions) changes in the rip, the resultant CRC will be WILDLY different; i.e., a COMPLETELY different string.  That's just how CRCs work.

 

Thus if you have a match to EVEN ONE other rip, it means the odds are literally billions to one that both are correct (or both incorrect in EXACTLY the same way, which is absurd).  To get the same CRC from two DIFFERENT rips of the same track is so wildly improbable as to defy imagination (IOW, it doesn't happen).

[audiventory]

11 minutes ago, jhwalker said:

Take a typical track ripped from a CD.  If even ONE byte (among several millions) changes in the rip, the resultant CRC will be WILDLY different; i.e., a COMPLETELY different string.  That's just how CRCs work.

 

Thus if you have a match to EVEN ONE other rip, it means the odds are literally billions to one that both are correct (or both incorrect in EXACTLY the same way, which is equally absurd).  To get the same CRC from two DIFFERENT rips of the same track is so wildly improbable as to defy imagination (IOW, it doesn't happen).

 

When checksums are different is not matter.

 

But when checksums are same, we don't know like it to original data checksum or not.

 

Example: we have 100 similar ripped checksums Srip, but original studio file may have other cheksum Sorig.

 

And millions of CDs in the database can't guaranty that Srip = Sorig. Because, I think, that the million may be copied from damaged (or altered by some unknown me reasons) matrix.

[diecaster]

21 minutes ago, audiventory said:

 

When checksums are different is not matter.

 

But when checksums are same, we don't know like it to original data checksum or not.

 

Example: we have 100 similar ripped checksums Srip, but original studio file may have other cheksum Sorig.

 

And millions of CDs in the database can't guaranty that Srip = Sorig. Because, I think, that the million may be copied from damaged (or altered by some unknown me reasons) matrix.

 

When checksums are the same on multiple CDs, we know that the CDs in the wild match. There is no way to know if the CDs put out by the CD production plants are the same as the actual master but they should be if the CD production plant is doing their job correctly.

 

Using your software, which does not compare against anything but the single CD being ripped, there is no way to know if the rip matches the master or any other CD in the wild. In other words, your software tells us nothing about the potential accuracy or inaccuracy of the ripped data compared to anything other than the one single source CD.

 

What would be better data?

 

1. A CD rip compared to the single source CD only.

 

Or:

 

2. A CD rip compared to CD rips of multiple copies of the same CD title using a well engineered checksum system.

 

The answer is obviously number 2.

[tmtomh]

40 minutes ago, audiventory said:

 

When checksums are different is not matter.

 

But when checksums are same, we don't know like it to original data checksum or not.

 

Example: we have 100 similar ripped checksums Srip, but original studio file may have other cheksum Sorig.

 

And millions of CDs in the database can't guaranty that Srip = Sorig. Because, I think, that the million may be copied from damaged (or altered by some unknown me reasons) matrix.

 

There is no way at all to guarantee that a CD's CRC exactly matches the CRC of a studio file. But that has nothing to do with ripping method - and you know it. So first you need to clearly acknowledge that this "what is the true original CRC" problem has nothing to do with the AccurateRip database - and in fact has nothing to do with ripping at all. If you do not acknowledge this fact, then no one here should pay any attention to what you say.

 

That said, your entire argument in this thread is based on your "simple formula" that multiples two methods: 0.999% CD ripper accuracy times 0.999% AccurateRip database accuracy equals 0.998% total accuracy.

 

Of course 0.999 x 0.999 = .998 (actually, 0.998001,  but we'll leave that aside for the moment). But that's not the question. The question is, does 0.999 x 0.999 = 0.998 represent mathematically the actual reality of securely ripping CDs and checking the AccurateRip database? And the answer is No.

 

The reason, as @mansr noted earlier in the thread, is that we are not dealing with independent variables here. The AccurateRip database is a large aggregation of multiple CD rippers, drives, and discs, and as the number of entries increases, the inaccuracies or flaws of individual drives or CDs become less and less significant (because the chances of all those drives misreading the same frames/sectors of all those copies of the CD are astronomically small). So as the database grows, its accuracy limit will be 100% - that is, it will never be 100%, but 100% is what it will more and more closely approach.

 

You cannot say the same for your single-ripper/single-software model. In fact, you already know you can't say this, because in another thread where you and I went 12 rounds on this same issue, you were very clear about how you want to figure out which CD rippers are the most accurate: You wrote that you want to get a bunch of drives and a bunch of ripping programs, and test them all out with each other to find out which drive (and I guess maybe which software too) is the best.

 

Of course, that is impractical - which is why you have not done it, and why no one else has done it either.

 

But the AccurateRIp database is precisely a doable, feasible version of your "ideal" experiment: It's 10s of thousands of individual optical drives that have done more than 340 million rips of 3.8 million unique CD titles/albums. But instead of demonstrating which optical drives are the most accurate as you foolishly seek to do, the AccurateRip database makes the drive irrelevant by its sheer volume, instead demonstrating which RIPS THEMSELVES are the most accurate - which is the whole point of this enterprise anyway.

[mansr]

5 minutes ago, tmtomh said:

Second, your entire argument in this thread is based on your "simple formula" that multiples two methods: 0.999% CD ripper accuracy times 0.999% AccurateRip database accuracy equals 0.998% total accuracy.

 

Of course 0.999 x 0.999 = .998 (actually, 0.998001,  but we'll leave that aside for the moment). But that's not the question. The question is, does 0.999 x 0.999 = 0.998 represent mathematically the actual reality of securely ripping CDs using the AccurateRip database? And the answer is No.

The fallacy here is obvious. Simply invert the numbers and calculate the probability of an error occuring. Using the numbers above, the probability of an error in the rip is 0.001, same for the database. The combined probability of error would thus be 0.001 x 0.001 = 0.00001. That's quite different from the 0.002 probability arrived at earlier. How can this be? Simple, both calculations are wrong. The probabilities are not independent and can't be simply multiplied.

[audiventory]

5 hours ago, diecaster said:

There is no way to know if the CDs put out by the CD production plants are the same as the actual master but they should be if the CD production plant is doing their job correctly.

 

5 hours ago, tmtomh said:

There is no way at all to guarantee that a CD's CRC exactly matches the CRC of a studio file. But that has nothing to do with ripping method - and you know it.

 

Main issue here, what we don't know what disk is wrong producted and what one is not.

 

In case of wrong disk production:

 

1. It is "data correctness" of initially wrong disk?
2. How initially wrong disk may be ripped correctly with or without checksum database?

 

[audiventory]

5 hours ago, tmtomh said:

Of course 0.999 x 0.999 = .998 (actually, 0.998001,  but we'll leave that aside for the moment). But that's not the question. The question is, does 0.999 x 0.999 = 0.998 represent mathematically the actual reality of securely ripping CDs and checking the AccurateRip database? And the answer is No.

 

These number are not real (I wrote above), they are lesser 1 always, and it is main issue.

 

What is our main task? It is correct error detection.

 

1. When you use 2 source of error detection, this event of correct error detection happen, when both of sources detect error correctly.

 

Mathematical probability of this case: P = P1 * P2.

 

P < P1 and P < P2 always, because P1 and P2 are lesser 1 always.

 

2. If you will use as error source only P1 (standalopne as example) or only P2 (database as example) you get higher probability of correct error detection, than their common work.

 

I never state that P1 > P2 or P1 < P2. I don't know these values.

[audiventory]

6 hours ago, mansr said:

Simply invert the numbers and calculate the probability of an error occuring. Using the numbers above, the probability of an error in the rip is 0.001, same for the database. The combined probability of error would thus be 0.001 x 0.001 = 0.00001. That's quite different from the 0.002 probability arrived at earlier. How can this be? Simple, both calculations are wrong.

 

Tech talks? I'm wrong?

 

No! I'm happy

 

You talks about event "error occuring".

 

But 0.0001 = 1-0.999 in your post is probability of "error is detected non-correctly".

 

And totally 4 events there are, not 2.

 

You get only probability "0.001 x 0.001 = 0.00001" of event "full system detect error non-correctly".

 

Probabilities of events "source A detect correctly, but source B - not" and "source B detect correctly, but source A - not" are lost.

 

Updated: Events are corrected

 

[mansr]

5 hours ago, audiventory said:

Main issue here, what we don't know what disk is wrong producted and what one is not.

Which is more likely, that your disc is damaged or that everybody else's discs are damaged in the exact same way?

 

In the case of a manufacturing flaw causing incorrect data to be stamped on the disc, there's nothing we can do. The best case, and what we should aim for, is error-free recovery of the data actually on the disc. The question of whether that is equal to the master sent to the pressing plant is outside the scope of this exercise.

[audiventory]

47 minutes ago, mansr said:

Which is more likely, that your disc is damaged or that everybody else's discs are damaged in the exact same way?

 

I'm not expert in CD manufacturing. All below in the post is my thoughts only.

 

Here "damaged" mean:

1. Produced correctly, but original data are altered by some reason(s).

2. Errors (physical pits) at all disks are the same due a plant issue(s).

 

Both cases may produce (or not produce) different errors at different ripping systems even for clear and non-damaged (out of plant) CDs.

 

I suppose most probabably that disk will readed successfully with the same checksum at different systems.

 

But in this case, I don't know:

1. There are (or are not) bugs  with checksum calculation in a ripper software.

2. Original checksum.

 

 

Resume:

 

I have no 100% sureness, that ripped audio stuff is 100% similar to studio stuff.

 

In this case, I don't see necessity in my checksum comparison with some abstract checksums that have other people.

 

 

[n2it]

The c2 is one measurement of error of the rip.  The checksum (used for AccurateRip) is a mathematical representation of the rip (that would include all the inputs such as C2 errors, other errors not detected by C2, source, repeated manufacturing defects, source, etc.).   I see a few things that in I don't agree with

 

1. The checksum is dependent upon the C2 pointer errors, but C2 errors certainly not the only source of error in the checksum.  In audiventory's math, the C2 is being treated as a separate error from the checksum, when, in fact it is already included in the checksum!

 

So audiventory it is saying: 

probability detection with database = (probability of c2 error detection)*(probability of db error detection)

 

however, db error is the measurement all of the errors that could happen to the CD

probability of db error detection = (probability of c2 error detection)*(probability of repeated manufacturing error detection)*(probabilities of other error in ripping/manufacturing/etc detection)

 

so if you agree that the checksum (i.e. db) includes the C2 error (and for ease of argument, that the other errors are negligible), audiventory is saying:

probability detection with database = (probability of c2 error detection)*(probability of c2 error detection)

 

Does anybody else see what is wrong? It has the probability of C2 error twice - so audiventory is actually double counting the error.

 

2. Precision vs accuracy.  Since with or without the database, we have no way of checking against the actual source, then it all comes down to defining the target. 

 

Without the database, the only thing you know with any certainty is whether or not you got C2 errors.  In order to know if you are precisely you would want to do mulitple rips of the same CD and compare the results.  But again, that tells you nothing about if you are near or close to the target.  You might introduce other CD players (e.g. you could have an offset error or some other jitter error) and compare the results - and you would hopefully get the same results which would give you confidence in the precision of your rip.  You have no basis on whether it had hit the target.  You only know that you got the same rip each time.

 

With the database,  (on top of C2 error checking correction), at least gives aconfidence that you and others have hit the same target.  If the C2 errors are uncorrected, it is very unlikely that you will match.  If your non C2 detectable ripping errors are a factor, it is unlikely you would match - that is an error in the the "without" database that is important and something that audiventory doesn't account for if the equations.  So if I do match, with a lot of people, at least I've hit some target that says I don't have a ripping or equipment issue (or that we all have the same manufacturing error that would exist in either the with or without case).  To me that is better than the without case: with the "with" I get both the C2 error checking, validation of no other ripping errors and a reasonable level of confidence in the accuracy (i.e. a better target then nothing).

 

 

[n2it]

By the way, I really like dbpoweramp for ripping and have used if for all of my ripping.  It has C2 error detection and correction as well as AccurateRip.   It uses 4 databases to compare/get tagging information.  It has a conversion program that allows you to easily convert to batch convert a different format.  You can also rip to multiple formats at once.  It is multi-threaded, so the only limitation for speed is the speed of your cd player.

[mansr]

For a bit of "fun," create an audio CD containing  a 1 kHz square wave. This will have 44 samples in most periods but 45 in some to maintain the average. Now try ripping this with a "secure" ripper and watch it struggle as it tries to figure out how to line up overlapping reads.