Need Audio CD Ripping Software Recommendations

[mansr]

1 hour ago, rando said:

For most albums CRC is a known quantity that can be checked against all the available databases as I stated. 

 

However, returning to your point, the exact value is not in contention at this juncture.  If I rip a single track five or fifty times it should yield the exact same CRC value if the digital data is uncorrupted by disc/read error.  Should it not?

A manufacturing fault could result in every "good" rip containing the same error. Now if this is the case, you have no chance of ever getting the correct data. Getting the same as everybody else is the best you can hope for.

[mansr]

6 minutes ago, audiventory said:

"Hope" is exact word

Not checking with the database isn't going to improve your odds.

[mansr]

3 minutes ago, audiventory said:

Improve. You have correct error detection probability Pripper lesser 1.0.

 

If you add checking with checksum database, the database correct error detection probability Pdb (also lesser 1.0).

 

Total correct error detection probability P = Pripper * Pdb.

 

P is lesser Pripper and P is lesser Pdb, because numbers in right part of formula both are lesser 1.0.

 

So Total error detection probaility is improved if only 1 of mthods is used.

 

See formula and details (part "Simultaneous using of CD's checksum comparison and low level fault detection") https://samplerateconverter.com/educational/best-cd-ripping-software

That's not how it works.

[mansr]

5 minutes ago, audiventory said:

How it works?

I'm sure you're capable of figuring that out by yourself.

[mansr]

12 minutes ago, audiventory said:

I can't read your minds.

Can you read books? That should suffice.

[mansr]

I guess I have to spell this out. When ripping a CD, you may encounter an error. The error may be intrinsic to your disc due to a smudge, a scratch, or a manufacturing defect. It may also be transient, caused by vibrations or dust temporarily interfering with the optical detector. Transient errors can be detected and, hopefully, avoided by reading the same sector multiple times and looking for a stable result. Intrinsic errors, however, will remain no matter how many times the sector is read. Some will be corrected by the drive, some more will be reported as uncorrectable. There is also the possibility of undetected errors, which is where the online databases enter the picture. Once every local check has passed, validation against a database serves as an additional check against undetected errors. If you get the same checksum as thousands of other users, the chances of you having encountered a random, undetected error are very slim indeed.

 

The simple multiplication of probabilities suggested by Audiventory is not correct. The probability of getting a correct rip does not depend on whether or not we compare it to other rips. We're not dealing with statistically independent variables here.

[mansr]

Let's not forget that Audiventory sells ripping software. I'm guessing it doesn't support AccurateRip.

[mansr]

Audiventory is going about this all wrong. Suppose you rip a CD. Either you got the correct data, or you didn't. If you want to, you can compare the checksum of your rip against those of others. Doing this will not alter the correctness of yours, which is still either right or wrong. The database check is a validation. If your checksum matches many other rips, it is most probably correct, unless you all got the same errors, which would imply a manufacturing flaw. For a disc with many submissions, there likely are a few outliers with different checksums. These are either results of bad rips or caused by variations in how CD drives handle things like lead-in and lead-out. The latter is more likely to occur with discs that don't quite follow the original spec regarding data placement and track assignment. If the database has a few different checksums with many entries each, we're probably looking at multiple issues with slight differences. In this case, matching any one of them is an indication of a correct rip on your part.

 

The idea that verifying your rip against the database would somehow reduce your chances of getting it right is simply preposterous.

[mansr]

6 hours ago, audiventory said:

12 hours ago, mansr said:

Let's not forget that Audiventory sells ripping software.

How it change my formulas?

It gives you incentive to misrepresent the utility of the database if your software doesn't use it.

[mansr]

Just now, audiventory said:

You try explain things that demand math for explanation without math.

There's no need for maths to see that you are clearly wrong.

[mansr]

This has nothing to do with probabilities, at least not in the way you seem to think.

[mansr]

Think about the process for a moment. First you rip the CD, possibly with errors. Then you look at the database. Audiventory is suggesting that looking at the database after ripping the CD somehow increases the error rate in the past.

[mansr]

8 minutes ago, audiventory said:

First, I want to be sure, that you understand, that I talks about probabilities as term of mathematical probability theory.

I understand that, but I don't understand why. It isn't applicable here.

[mansr]

It doesn't matter what kind of process it is. Checking a rip against the database doesn't alter its correctness.

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

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

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

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

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

[mansr]

1 minute ago, audiventory said:

I can't understand, how the ripper work is bound with audio data content? What is ripper?

Some rippers do multiple overlapping reads to detect if the drive has dropped some samples. I don't know why a drive would do that, but presumably it has happened, or the feature wouldn't have been added.

[mansr]

Just now, Ralf11 said:

How does AccurateRip obtain the data in their database?  I did not see that on their web site.

People can submit results of their own rips.