Ripped CD via Sofware vs Manual Copy/Paste File Differences

[audiventory]

@diecaster be polite, if you want to communicate.

[diecaster]

18 minutes ago, audiventory said:

@diecaster be polite, if you want to communicate.

 

How can you not understand the benefit of AccurateRip when it comes to verifying the accuracy of rips? Even if the benefit were not obvious, it has been explained to you multiple times in multiple ways over the course of at least a year. The only logical explanation is that you cannot agree to the benefits of AccurateRip because you think doing so would diminish the value of your software.

[audiventory]

16 minutes ago, diecaster said:

How can you not understand the benefit of AccurateRip when it comes to verifying the accuracy of rips?

 

Just as engineer, who always feel responsibility, I trust figures.

 

And multiple repeating of words like "obtuse", "how can you not understand", "50 other people from 50 other CDs", "1 in 1.153617588 E+334" can not magically change reality, that is based on elementary everyday technical math.

 

For me it sounds like "earth is flat", "earth is flat", "earth is flat",..., "you obtuse, how you can't understand, that earth is flat"...

 

Also I consider using of words like "obtuse" like "have no more proper arguments, just repeating past sentences".

[mansr]

1 hour ago, diecaster said:

How can you not understand the benefit of AccurateRip when it comes to verifying the accuracy of rips? Even if the benefit were not obvious, it has been explained to you multiple times in multiple ways over the course of at least a year. The only logical explanation is that you cannot agree to the benefits of AccurateRip because you think doing so would diminish the value of your software.

I think he may be struggling with the concept of causality. He seems to believe that the possibility of a false negative from AccurateRip means that looking at the database can somehow introduce errors in the already completed rip. Needless to say, that isn't how reality works.

[audiventory]

30 minutes ago, mansr said:

AccurateRip means that looking at the database can somehow introduce errors in the already completed rip.

 

The database using don't correct audio information in completed rip.

 

The database try to give us information, with unknown degree of trust, to decission, that we should do about ripping correctness.

 

1. I consider unknown degree of trust as factor of higher risk of wrong decission about ripping correctness.
    
2. Also, checksum from the database can't help recover damaged audio data.

[tmtomh]

5 hours ago, firedog said:

If you have multiple identical rips in AccurateRip, it does mean your rip is accurate.
But failure in AccurateRip doesn't necessarily mean there is anything wrong with your CD or the rip.  It means your CD didn't match what's in the database. 
"The same" CD can be very slightly different depending on what country it was produced in or even what CD pressing plant it was produced in within the same country. These very small differences can be enough to get a "not accurate" result from AccurateRip. But the actual  rip is fine and errorless. 
In addition (and not related to accuraterip) I've had rips with  say, one track with "errors" that were not sonically detectable. 

 

I hear what you're saying and I agree with you. I guess I wasn't clear - the situation I was referring to was your final "In addition" example: A rip with one track (or in some cases 2-3 tracks) that AccurateRip said was NG, even if the secure ripping app itself did not report any errors (and in some cases, not even any retries). To my mind such rips are not technically accurate, and I have confirmed that with a couple of them by running a null test with a known-Accurate rip of the same CD pressing/mastering - in each case I've found the errors. As you say, they are tiny (like a few samples each) and inaudible. But I don't consider those rips to be Accurate rips, even though they are functionally fine.

 

As for country or pressing-plant variations, yes, absolutely, one sees that a lot - but in my experience those will usually end up as AccurateRip confirmed rips - they'll just be confirmed against an unusually small number of other rips in the database, because there's something very minor about the pressing that's different, and relatively few people own that particular pressing.

 

On a slightly tangential note, aside from different first-track offsets, the most frequent production/pressing variation I've seen between otherwise identical CDs is that one version has a loss of digital sync somewhere in the production process, meaning that every 1-2 seconds one version of the CD has a missing or extra sample compared to the other one. This too is totally inaudible. But it is strange IMHO.

[tmtomh]

2 hours ago, audiventory said:

 

The database using don't correct audio information in completed rip.

 

The database try to give us information, with unknown degree of trust, to decission, that we should do about ripping correctness.

 

1. I consider unknown degree of trust as factor of higher risk of wrong decission about ripping correctness.
    
2. Also, checksum from the database can't help recover damaged audio data.

 

You're simply incorrect, as has been explained to you multiple times. You are misapplying the figures and the mathematical concepts you claim to understand.

[audiventory]

8 minutes ago, tmtomh said:

You're simply incorrect, as has been explained to you multiple times.

 

I remember: what "incorrect" was found there

 

Do you really think, that multiple repeats do true from any claims?

Read details above:

 

 

And do you remember your words?

On 12/19/2018 at 4:36 PM, tmtomh said:

Finally, I would recommend you completely ignore @audiventory on the subject of the AccurateRip database

 

Or you hope that multiple repeats force me to agree with you?

[firedog]

1 hour ago, tmtomh said:

I hear what you're saying and I agree with you. I guess I wasn't clear - the situation I was referring to was your final "In addition" example: A rip with one track (or in some cases 2-3 tracks) that AccurateRip said was NG, even if the secure ripping app itself did not report any errors (and in some cases, not even any retries). To my mind such rips are not technically accurate, and I have confirmed that with a couple of them by running a null test with a known-Accurate rip of the same CD pressing/mastering - in each case I've found the errors. As you say, they are tiny (like a few samples each) and inaudible. But I don't consider those rips to be Accurate rips, even though they are functionally fine.

Sorry, I wasn't being clear. There are "insecure" rips and rips that are secure that show that show no match in AR. I meant that I get a rip that is shown to have one track that "isn't secure" (with errors) or no match in dbpoweramp when all the other tracks seem fine. This isn't necessarily connected to AR, just to the rip. Generally, even with repeated and focused listening - I can't hear anything wrong with the track that's in "error".
AccurateRip is great as it gives us assurance the rips are accurate, but we don't have to go overboard about how significant that is. Lots of "inaccurate" rips are apparently only suffering from very minor errors/differences that aren't audible. The times I've had "errors" or "inaccurate" rips where the error was audible, it was clearly audible - and the result of either a scratched or dirty disc. No one would be think such a rip was okay, even without AccurateRip. 

[tmtomh]

2 hours ago, audiventory said:

 

I remember: what "incorrect" was found there

 

Do you really think, that multiple repeats do true from any claims?

Read details above:

 

 

And do you remember your words?

 

Or you hope that multiple repeats force me to agree with you?

 

I recommended that someone else ignore you on this subject, because you are mistaken about it, and someone who (like that other poster) shows up here looking for guidance is going to be misled by your obsessive and misguided campaign against using AccurateRip. It is precisely for that reason that I don't want to ignore what you say about it, because when you revive your mistaken and misleading claims about AccurateRip, it's important to counter with the correct information about it.

 

As for the other threads you keep quoting and linking to, I appreciate that - anyone who peruses those threads will see that @mansr and others have indeed demonstrated quite clearly and simply that you're wrong, and how and why you're wrong. 

[audiventory]

28 minutes ago, tmtomh said:

I recommended that someone else ignore you on this subject, because you are mistaken about it,

 

Let's show example for other people, before writing of advices.

Do you think, that you can recommend something in ripper subject?

You are expert? What is your background?

 

 

28 minutes ago, tmtomh said:

As for the other threads you keep quoting and linking to, I appreciate that - anyone who peruses those threads will see that @mansr and others have indeed demonstrated quite clearly and simply that you're wrong, and how and why you're wrong.

 

Yes. I remember, how and what was "demostrated" and who upvoted there.

I remember, what is math, that "destroyed" my formulas

 

 

You can infinite repeat "simply that you're wrong".

But it change nothing.

 

Let's develop the topic.

[diecaster]

@audiventory

 

There is a very basic concept here that you either choose to disregard or are incapable of understanding.

 

Since there is only one correct checksum for each track on a CD, the only checksum results that different people with different CDs will get over and over when ripping a particular release of a CD are the checksums of accurately ripped tracks. Please take the time to understand that sentence. If there is an error when ripping the track, the checksum will not match.

 

Errors are random so the checksum results of tracks with errors will differ. The likelihood of two 600MB CDs having the same 1 bit error is 1 in 1.153617588 E+334. That number gets even bigger when there are multibit errors. This is why the AccurateRip database does not get corrupt with bad rip results being reported as good rips. The bad rips don't generate the same checksums over and over. Only the good rips generate the same checksums over and over. Read and understand that sentence. Bad rip results are weeded out of the database as a natural part of the system process.

 

If you are are unwilling to take the time to learn how AccurateRip actually works and why it is a reliable verification system, you should stop posting in any thread that discusses how to get the best and most accurate rips. Because you respond with incorrect information and are misleading people for your financial gain.

 

[audiventory]

18 minutes ago, diecaster said:

If you are are unwilling to take the time to learn how AccurateRip actually works and why it is a reliable verification system

 

Let's list things that I missed: 1), 2), 3), etc.

 

 

18 minutes ago, diecaster said:

you should stop posting in any thread that discusses how to get the best and most accurate rips

18 minutes ago, diecaster said:

The likelihood of two 600MB CDs having the same 1 bit error is 1 in 1.153617588 E+334.

 

Do you prohibit me to write? It's nice final argument in addition to "1.153617588 E+334" repeating

 

You can rip such way as you want. And belive in things that you want.

 

And let's say something new instead posting of repeatable posts about "1.153617588 E+334".

[diecaster]

3 minutes ago, audiventory said:

Do you prohibit me to write?

 

You should be prohibited from misleading people for financial gain, yes.

[firedog]

2 minutes ago, audiventory said:

 

Let's list things that I missed: 1), 2), 3), etc.

 

 

 

Do you prohibit me to write? It's nice final argument in addition to "1.153617588 E+334" repeating

 

You can rip such way as you want. And belive in things that you want.

 

And stop posting repeatable posts about "1.153617588 E+334".

 

Let's says something new.

He doesn't have to say anything new. His post is correct and you are wrong. All the proof that you are wrong is either written here or linked to here. Instead of demanding "new" discussion" go back and actually learn so that you understand why you are wrong. 

[audiventory]

7 minutes ago, diecaster said:

You should be prohibited from misleading people for financial gain, yes.

 

It's nice argument in discussion

 

I have reputation and keep it for business too.

And I can't allow myself to write things, that mislead "for financial gain".

 

Is you expert, who can estimate my knowledge in audio?

[diecaster]

2 minutes ago, audiventory said:

 

Is you expert, who can estimate my knowledge in audio?

 

The fact that you don't understand how and why AccurateRip works and why it is a valid rip verification system is mind boggling.

[audiventory]

2 minutes ago, diecaster said:

The fact that you don't understand how and why AccurateRip works and why it is a valid rip verification system is mind boggling.

 

To claim, "the fact that..." you should just prove, that you are expert.

[audiventory]

20 minutes ago, firedog said:

He doesn't have to say anything new. His post is correct and you are wrong. All the proof that you are wrong is either written here or linked to here. Instead of demanding "new" discussion" go back and actually learn so that you understand why you are wrong. 

 

If you think, that me need "go back and actually learn so that you understand why you are wrong", it is not mean that it is true. I can give same advice.

 

Why you think, what you know more, than I, in rippers?

[tmtomh]

1 hour ago, audiventory said:

 

Let's show example for other people, before writing of advices.

Do you think, that you can recommend something in ripper subject?

You are expert? What is your background?

 

https://en.wikipedia.org/wiki/Argument_from_authority

 

(And you're not even making a good Appeal from Authority argument, since you've amply and repeatedly demonstrated in this and other threads that you are not in fact an authority when it comes to this particular subject.)

[audiventory]

35 minutes ago, tmtomh said:

(And you're not even making a good Appeal from Authority argument, since you've amply and repeatedly demonstrated in this and other threads that you are not in fact an authority when it comes to this particular subject.)

 

If you claim, that I'm wrong, I expect, what you, as expert, know, what you say.

 

As 20+ year engineer, team lead, ripper designer and professional researcher, I don't see your applicable background in the ripper issues.

I see emotions and phrases like "you are mistaken about it" without detailed discussion. "It" is so general.

 

At last, I here under real name and I should keep my reputaton, that is important part of my business.
But you here as tmtomh and claim that I'm wrong.

 

I'd be happy, if you take my formula-to-formula and discuss it. But I don't see it. I see "you are mistaken about it" instead.

 

So I expect safe proofs of your authority in the ripper issues, though:

• May be you programmer of the checksum database and actually know that inside there?
   
• May be you have designed ripper, that we can learn?
   
• May be you have references to your scientific researches in rippers?
   
• Do you have wrote articles though?
   
• What is your education?
   
• What is your math experience?

[Ralf11]

2 hours ago, audiventory said:

 

Is you expert, who can estimate my knowledge in audio?

 

I am a bit of an expert who can estimate your knowledge in probability theory.

 

You are wrong.

[tmtomh]

1 hour ago, audiventory said:

 

If you claim, that I'm wrong, I expect, what you, as expert, know, what you say.

 

As 20+ year engineer, team lead, ripper designer and professional researcher, I don't see your applicable background in the ripper issues.

I see emotions and phrases like "you are mistaken about it" without detailed discussion. "It" is so general.

 

At last, I here under real name and I should keep my reputaton, that is important part of my business.
But you here as tmtomh and claim that I'm wrong.

 

I'd be happy, if you take my formula-to-formula and discuss it. But I don't see it. I see "you are mistaken about it" instead.

 

So I expect safe proofs of your authority in the ripper issues, though:

• May be you programmer of the checksum database and actually know that inside there?
   
• May be you have designed ripper, that we can learn?
   
• May be you have references to your scientific researches in rippers?
   
• Do you have wrote articles though?
   
• What is your education?
   
• What is your math experience?

 

Again, this is an appeal to authority argument, because the experience you cite is not relevant to the issue up for discussion - it's about basic math and probability, and multiple people, including myself, have clearly and repeatedly pointed out the fundamental error of your argument concerning AccurateRip (basically, you are assuming variables are independent when they are dependent). My profession is irrelevant - not only because the question at issue does not require an advanced degree, but also more importantly because I am not the only one who has pointed out your error (and others, including mansr, have qualifications that are unimpeachable in this area - although even there, no one including mansr himself would think it's a good idea to believe him just because of his credentials).

 

I have not designed a ripper and I am not a programmer of the checksum database - but this is irrelevant, and you know it. The reason it's irrelevant is that we are not talking about ripping apps, but rather about the AccurateRip database. (Yes of course, ripper apps are the means by which people upload AccurateRip data to the database - but that uploading function is a trivial part of programming a ripping app, and moreover, the link between rippers and the database is precisely what makes secure-rip results and AccurateRip database dependent rather than independent variables.)

 

You're just going around in circles. No one is disputing that you are a programmer; no one is disputing that different algorithms, methods, and hardware designs can be, and have been, used in optical drives and ripping apps. None of that is at issue here - and therefore your experience with that is totally irrelevant to the question of whether or not the AccurateRip database is a valuable tool. Folks can use the db or not as they see fit - but your arguments against the database are based on flawed claims or assumptions.

[diecaster]

1 hour ago, audiventory said:

 

If you claim, that I'm wrong, I expect, what you, as expert, know, what you say.

 

As 20+ year engineer, team lead, ripper designer and professional researcher, I don't see your applicable background in the ripper issues.

I see emotions and phrases like "you are mistaken about it" without detailed discussion. "It" is so general.

 

At last, I here under real name and I should keep my reputaton, that is important part of my business.
But you here as tmtomh and claim that I'm wrong.

 

I'd be happy, if you take my formula-to-formula and discuss it. But I don't see it. I see "you are mistaken about it" instead.

 

So I expect safe proofs of your authority in the ripper issues, though:

• May be you programmer of the checksum database and actually know that inside there?
   
• May be you have designed ripper, that we can learn?
   
• May be you have references to your scientific researches in rippers?
   
• Do you have wrote articles though?
   
• What is your education?
   
• What is your math experience?

 

Wow. You think you CV is impressive? How many copies of your program are out there in real world?

 

The AccurateRip database has over 3.9 million unique disks in it. It has over 2 million keys disks that can be used to calculate read offset. The database has registered over 351 million accurate rips. There are 4477 drives in the database and there are 359142 users participating. The AccurateRip database was setup and is managed by the same team that wrote dBpoweramp.

 

I somehow thinks these credentials are more impressive than yours. All you are doing here is embarrassing yourself more and more. Stop and educate yourself before you make a total fool of yourself.

[kumakuma]

1 hour ago, audiventory said:

 

As 20+ year engineer, team lead, ripper designer and professional researcher, I don't see your applicable background in the ripper issues.

 

 

You claim to be an expert in ripping issues but your software tells a different story.

 

I compared it to XLD here on my Mac with the same CD and found the following:

 

-  It is many times slower than XLD

 

- There appears to be no indication in the log file as to whether or not the CD was correctly ripped or not

 

- It accesses the drive in a herky-jerky manner which will probably cause excessive wear and tear on the drive

 

I can't imagine using your software to rip anything other than perhaps the occassional CD that other programs can't rip.

 

Your user interface also needs serious attention.