Ripped CD via Sofware vs Manual Copy/Paste File Differences

[tmtomh]

@cjf I can only speculate about the 70-byte difference, but I think I know what is causing it (or at least the general idea behind it). Audio CDs do not have filesystems in the same way a computer drive or CD-ROM disc does. Any drive that reads them has to approximate exactly where the data begins for a track. And different optical drives have different built-in offsets, which changes (usually by just a few samples, but sometimes by 100s of samples) where they start reading a track.

 

So my guess is that in CD-ripping mode, your drive's offset is 35 samples, which would equal 70 bytes.

 

In other words, assuming that there were no actual glitches in the ripping or copying process for all the tracks you ripped and copied from your CD, I would guess that the resulting files you have are indeed identical, and that the 70 byte difference exists in the form of 35 fewer samples at the beginning of each of one of your two sets of tracks.

 

Generally speaking, you are better off using a dedicated ripping app rather than the "caveman" method of cut and paste. The latter will work fine in most cases, but the former method is the only way to ensure an accurate rip (if that's possible - with a damaged CD sometimes it's not) with full error correction.

 

Finally, I would recommend you completely ignore @audiventory on the subject of the AccurateRip database - his math is wrong when he claims that using the database reduces the accuracy/error detection of CD rips, and if you look at what he posts pretty much anywhere in these forums, you'll see that this issue of AccurateRip is almost all he ever posts about, and the argument has been done to death.

[tmtomh]

Agreed - except take "wrong" out of quotation marks, as it was clearly and simply demonstrated in that thread exactly why and how your math was incorrect.

[tmtomh]

4 hours ago, mansr said:

I don't think that's it. Firstly, it's stereo so one sample is 4 bytes. Secondly, an offset should merely move the point for switching files, not make all of them larger. My guess is that the file headers are different.

Ah, hadn't thought of that. Makes sense!

[tmtomh]

4 hours ago, diecaster said:

 

I have CDs that skip and stutter that iTunes happily ripped disclosing no errors. I stopped using iTunes to rip CDs a long time ago!!

 

I have never had a problem with a CD that was marked as accurate by AccurateRip. 

 

This iTunes issue is exactly what drove me to learn about and start using secure ripping apps too. I too never have had a problem with a CD marked accurate by AccurateRip.

 

I have, however, run into a handful of tracks (out of about 400+ albums) that ripped with zero errors and yet were reported as not accurate by AccurateRip. In a couple of cases, I downloaded AccurateRip-confirmed copies of those tracks and did a null test between those and my rip. And sure enough, the two tracks were bit-identical, except for a tiny blip or glitch. Now, that glitch was not audible when playing the CD - but it does show the value of AccurateRip, because it is possible that a secure ripping app is able to do two consecutive, identical passes of a section of a track, but both of those passes still are not actually accurate. These cases are very rare - but when they happen, they illustrate the intrinsic benefit of the crowdsourcing of the AccurateRip database.

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

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

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

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