Reading this thread about proper ripping, a question came to my mind.

When I have 2 different CD/DVD drives would a Burst rip (fastest rip mode), with or without C2 and cache, be trusty when CRC values match on both drives? I actually think this way of ripping is very OK because it's highly improbable getting different CRC's when ripping non-damaged CD's. This could be a very fast way of getting a perfect rip.

Would there be any condition besides having different drive models? Do different models from same brand or manufacturer read CD's the same way and produce a wrong CRC?

Assuming the CD is not (yet) in the AccurateRip database, then ripping on different drives is as close as you get to a "DIY AccurateRip".

Then beware that two "different" drives may be more or less identical on the inside.

I don't trust AccurateRip database when confidence level number is low, left aside that a lot of my CD's aren't present in AR database.

You don't consider it significant if even one other person has gotten the exact same checksum as you? The odds of that happening randomly are one in four billion!

The only way that is ever likely to happen is if you yourself submitted results on the same CD ripped on a different system.

I didn't want to start a topic about AR confidence because this should be an other thread but: wrong results can be uploaded and one person can upload more than once. And why is it sometimes not all tracks have the same confidence? If an album is ripped accurately, the whole album should be OK, that is, all tracks should have the same confidence number.

But this is not what my topic is about

My intention was not to hijack your topic, but you made a statement that I felt needed to be challenged.

You are certainly within your rights to remain suspicious of low confidence levels, but I wanted readers to be aware that your feelings about this are not universal.

If a rip has a bad track and the others match, why through away the good info. That would lead to different numbers.

Alexxander, it's pretty obvious that you don't fully understand what you're talking about. A confidence of 1 is all you need to verify your rips so long as you aren't the person who submitted that result, you're not checking something that you downloaded, or otherwise burned from a source (with a proper write offset correction) that was previously submitted to the database.

The AR database is built on a per-track basis. All tracks need not have the same confidence number.

> And why is it sometimes not all tracks have the same confidence? If an album is ripped accurately, the whole album should be OK, that is, all tracks should have the same confidence number.

Guy 1 rips tracks 1,2 & 3. Guy 2 rips tracks 1,2,3 track 2 has an error - hence why track 2 would have a different confidence level to tracks 1 & 3. AR is track based.

...guy 3 rips only a couple of tracks off the CD because they are all that he wants from that particular disc.

OK, the database is track based, that explains my observation.

I've submitted to AR database since a very long time and there was a time I didn't knew about offset. Offset in EAC was set to zero and I'm sure I've submitted wrong rips, probably like a lot of people in past. And one can submit several times a rip of the same CD, right? If I see a confidence of 1 or even 2 I'm just not confident the track CRC is compared to a rip not mine or from an other person with a different drive. No, I'm not paranoid, I think

AR will not work until it has configured your offset, so I highly doubt you've submitted rips with no offset correction. Furthermore, I am pretty sure that AR will bin your submissions if it finds that your drive is not configured with the correct offset.

No, this is not right either.

Bottom line is that AR works on positive matches. Perhaps you can give a reasonable explanation how you will get the same hash for a bad rip from your original CD that someone else has previously submitted from his own original CD. I don't think you can, in fact I know you can't.

Feel free to be paranoid, but please stop with the nonsense about confidence levels, ok?

Alexxander


plz stop spreading bullshits, first you didn't know what you were speaking about, now you starting to lie to try to keep your dignity.

I use AR with EAC since it was introduced there have never been a time when you could use accuraterip without offset correction, it is the exact opposite: at the beginning of accuraterip EAC was asking to verify your offset with 3 disks & the database was small so it was hard to find those 3 CD, you needed a collection of more than 100 CD to have a small chance to have accuraterip set up correctly.

You don't look paranoid, at the beginning you looked ignorant, now that you insist you look stupid Sorry ...

If your offset wasn't set up, all you submitted to the AR database is a whole lot of nothing.
You only think you submitted something ...

I was talking about older EAC versions and it's possible I remember wrongly being able to use AR without setting offset.


So then there's more information stored in AR database than just the information coming from the audio CD? Or does every single audio CD has some kind of a unique disc id (like for example MAC addresses)?


With the requirement of having to set a correct offset to be able to use AR database, indeed the probability of someone else having the same hash for a bad rip is ultra low with a CRC-32.

This was no nonsense, just lack of information (and possibly memory too).

Thanks all for clearing up.

Edit: Thanks for your answer sauvage78, after all I agree, though I wouldn't have replied the way you did. Your Sorry ... is accepted.

You remember wrongly.

While there was a bug in EAC where it would incorrectly report the offset correction in the log as 0, it was never possible for you to submit to the AR database without AR first having offset configuration information.

This is what I do, and I caught enough issues to confirm that it's the next best thing to AcurateRip.

It's a very remote possibility, but you could still be at the mercy of bugs in the ripping software or drive firmware. Unfortunately, using two different ripping software is not practical. What I found practical is using two different ripping mode (secure on drive 1 and burst on drive 2), in the hope that you would hit different enough code paths.



I've seen a Samsung drive and Lite-On drive reporting similar style of errors (they are using the same MediaTek chipset). The actual errors were different (different CRCs), but it was too similar for comfort. I personally would use drive with different read offset to be sure that the hardware is actually different, and that block boundaries are not synchronized.

Maybe it's pure paranoia, but I like erring on the side of caution...

Jean

Hmm... I'm sorry, but I feel the same way about confidence level, confidence level of 1 or 2 does not satisfy me. I already asked Spoon to remember the drive offset of those submissions to be able to tell if those other matching submissions are using the same offset or not, that would help a lot with those low level of confidence.

Maybe I need to remind you about Simple Minds...
Peculiar AcurateRip result

Regards,

Jean

No need, Jean. I always keep you in mind when making generalizations about AR and confidences.

There are always exceptions, and while you can't feel comfortable about a confidence level of 1 or 2, you can't be about 3, 4 or even 30 for the exact same reason since MediaTek chipsets aren't exactly difficult to come by. Where do you draw the line?

People tend to want to get black and white answers around here, and sometimes I don't think it's worth muddying the waters with situations that have never been demonstrated as being anything but edge cases.

I counter your paranoia (and yes, like the previous poster, I think you're entering the realm of paranoia) with a better suggestion: use CUE tools to see if you get agreement with an alternate pressing.

i think XLD compares offset rips for AccurateRip results which is really neat. i hope EAC will add this feature soon.

It sounds like it will be in dBpoweramp. Not sure about the future of EAC though.