Odd AccurateRip results, Accurate, but different CRC's. Options

[EagleScout1998]

For reasons I won't go into, I had to re-rip a CD. This particular disc was still in the dBpoweramp cache, displaying the CRC values of the previous rips. One odd thing I noticed was that, even though all tracks were reported as Accurate, one of the CRC's was red (all the others were green).

Now, I've read that the last 5 frames of the last track and the first five frames of the first track do not figure into the AccurateRip CRC calculation. But the track in question is neither the first nor the last track.

Curious, I ripped the same track with the same drive several times and these were the results.

LITE-ON DVDRW LH-20A1S
Rip #1 - Accurate (2) - 25BD6EF2
Rip #2 - Accurate (12) ACEC4A37
Rip #3 - Accurate (12) ACEC4A37
Rip #4 - Accurate (12) ACEC4A37
Rip #5 - Accurate (12) ACEC4A37
Rip #6 - Accurate (2) - 25BD6EF2
Rip #7 - Accurate (2) - 25BD6EF2
Rip #8 - Accurate (12) ACEC4A37

[pdq]

Possibly you yourself had submitted the erroneous CRC twice and that's what is being reported?

[greynol]

It's usually a good idea to do a sample by sample comparison of the two versions of the track when this kind of thing happens.

[psycho]

I, personally would go with the file with CRC ACEC4A37, simply because more people had that CRC.

Anyway, could it be possible that there are two different pressings in question here?

[greynol]

Could be one pressing with a manufacturing defect.

[spoon]

It seems a good test base as it varies between the two CRCs.

Which dBpoweramp version are you using?

The CRCs shown on the screen are file crcs, not accuraterip crcs, so in options >> secure settings:

Report Contents >> Complete
Add to Information Log [check]

Then Options drop menu >> After Ripping >> Display Information Log [check]

Then if you can post the 2 sets of logs, one for one CRC and the other.

[EagleScout1998]

I am using version 12.4 (Reference).

I don't know if this is all the log information you need...

CODE

Information ripping to FLAC, 'Track 11' to 'E:\(00) Rips\(00) Rips\Celine Dion\Celine Dion - The Colour of My Love\11 - I Remember L.A..flac'
   Track 11:  Ripped LBA 203415 to 222380 (4:12) in 0:09. Filename: E:\(00) Rips\(00) Rips\Celine Dion\Celine Dion - The Colour of My Love\11 - I Remember L.A..flac
     AccurateRip: Accurate (confidence 12)     [Pass 1]
     CRC32: ACEC4A37
  

Information ripping to FLAC, 'Track 11' to 'E:\(00) Rips\(00) Rips\Celine Dion\Celine Dion - The Colour of My Love\11 - I Remember L.A..flac'
   Track 11:  Ripped LBA 203415 to 222380 (4:12) in 0:06. Filename: E:\(00) Rips\(00) Rips\Celine Dion\Celine Dion - The Colour of My Love\11 - I Remember L.A..flac
     AccurateRip: Accurate (confidence 2)     [Pass 1]
     CRC32: 25BD6EF2

[spoon]

Sorry it is R13 which add the AccurateRip CRC to the log file, are you able to try the R13 alpha version?

[exec]

Possibly you yourself had submitted the erroneous CRC twice and that's what is being reported?

If this is the case, isn't that a problemwith AR? The two "strange" CRCs shouldn't be part of the AR database then.

Let's imagine that you rip a CD more times with different drives and get results like EagleScout1998: one or two tracks always don't seem to fit in the rest of the CD's AR results.
Could this be because of scratches? Is it likely that you get always the same CRCs with scratched tracks when you use different drives (I don't think so)?

And wouldn't it be a nice feature (of dbpoweramp) that you can omit some results when transferring your data to the AR database? When something seems strange, you then can choose not to transfer this data to avoid probably spoiling the AR database.

[Eli]

The probability of anyone else ever having the same error as you, that you may submit multiple times, is very very low, so you only spoil the DB for yourself when submitting erroneous data multiple times.

[rohangc]

I have seen this same phenomenon myself. From an ordinary end user's perspective, if AR reports something as 'accurate', then I actually assume that it is accurate. How many people actually think twice before submitting their results to the AR database?

AR is a program that relies on user input for its functionality. This approach is inherently vulnerable to the problem of its users feeding it wrong information. Hence, this is an issue that the AR developers must address.

[spoon]

For CDs with a confidence of > 2, erronous submitted results (ie bad rips) do not make it tot the database.

[greynol]

Spoon, could you elaborate on what you mean by this? How are you able to distinguish a bad rip from a different pressing?

[spoon]

Just %'s, there are 4 billion posibilities in the CRC a different pressing will verify that with mulitple submissions where as errors will not (chances of 2 people having the same error are low).

[Eli]

I know this has been addressed before, but if either EAC or dBpoweramp in secure mode give accurate or secure results that do not match the AR database, ideally these would be added, even if they do not match someone else's submissions as they are likely to be accurate.

[greynol]

Just %'s, there are 4 billion posibilities in the CRC a different pressing will verify that with mulitple submissions where as errors will not (chances of 2 people having the same error are low).

Thanks for the clarification.

It sounded like you were trying to say something quite different than this earlier; like results with a confidence equal or under two were automatically purged or not allowed in rather than the chances of an erroneous rip matching someone else's erroneous result are essentially zero.

I still firmly suspect that the problem here is a consistent manufacturing defect unless you think both submissions to the database were his but done with different user IDs(?).

I know this has been addressed before, but if either EAC or dBpoweramp in secure mode give accurate or secure results that do not match the AR database, ideally these would be added, even if they do not match someone else's submissions as they are likely to be accurate.

I don't believe it matters which mode was used. IIRC, the only things keeping a result from making the database was a previous submission by the same user ID or that another pressing already exists and there is no match for the currently submitted CRC, in which case it goes into holding until a match is made by a submission with a different user ID.

This post has been edited by greynol: Jan 22 2008, 04:15

[spoon]

If there ever was an issue with the database, I could write a routine to purge the low % results, but do not see that as required for a long time.

>I still firmly suspect that the problem here is a consistent manufacturing defect unless you think
>both submissions to the database were his but done with different user IDs(?).

I do not think you can jump to conclusions until you see the actual ripped files and compare. It might even be a bug with the drives firmware.

[greynol]

>I still firmly suspect that the problem here is a consistent manufacturing defect unless you think
>both submissions to the database were his but done with different user IDs(?).

I do not think you can jump to conclusions until you see the actual ripped files and compare. It might even be a bug with the drives firmware.

Either way (the disc or the drive), AR is reporting that both versions of the rip are correct; which indicates that this is a consistent problem between different user IDs, no?

[Eli]

I know this has been addressed before, but if either EAC or dBpoweramp in secure mode give accurate or secure results that do not match the AR database, ideally these would be added, even if they do not match someone else's submissions as they are likely to be accurate.

I don't believe it matters which mode was used. IIRC, the only things keeping a result from making the database was a previous submission by the same user ID or that another pressing already exists and there is no match for the currently submitted CRC, in which case it goes into holding until a match is made by a submission with a different user ID.

Yes, but if there was some intelligent interaction between these secure rippers and the database (ie secure/accurate flag on submission), and the rip of the whole disc is secure but does not match AR then its likely an accurate rip of a new pressing. Increasing true positive results would make more people happy with the database, leading to more users, and more data.

[spoon]

>which indicates that this is a consistent problem between different user IDs, no?

Seems that way.

[exec]

>which indicates that this is a consistent problem between different user IDs, no?

Seems that way.

How the user IDs are generated? Is it possible that someone can change his ID?

[spoon]

Anything is possible (we have had in the past hack attempts against the AR database where deliberate bad data, and lots of it was submitted - that is why I try not to talk too much about specifics of the backend of AR, it would make such attacks easier), so there are mallicious attempts, the idea of something good for the community does not go down well with certain people, just like that park bench, some want to smash it up.

I do not think anything mallicious in this instance though.

This post has been edited by spoon: Jan 23 2008, 12:50

[bhoar]

Anything is possible (we have had in the past hack attempts against the AR database where deliberate bad data, and lots of it was submitted - that is why I try not to talk too much about specifics of the backend of AR, it would make such attacks easier), so there are mallicious attempts, the idea of something good for the community does not go down well with certain people, just like that park bench, some want to smash it up.

I do not think anything mallicious in this instance though.

Spoon-

I've put forth something like this scenario before...what if:

- A user has four or five machines he rips CDs on. All have dbpoweramp R13 installed on them, properly accuraterip configured.
- Drives are configured as best as possible, though the user has seen instances where he configured the drives as per the dbpoweramp test results, but later found the tests gave different results for the same drive and therefore disabled some drive features that perhaps shouldn't have been enabled.
- For testing and development purposes, he rips the same stack of CDs repeatedly, across machines. This stack includes both clean CDs as well as various types of damaged CDs.
- From time to time, he has to rebuild a machine, so there may be more than four or five IDs
- He submits results regularly.
- The source public IP he submits from changes on a regular basis (not sure what part of the address is constant, if any).

What are the chances that this user is, inadvertently, polluting the results data from time to time? The key part here is that the same physical set of CDs, some damaged, are being submitted over various installs, machines, drives, configurations and public IP addresses.

-brendan

This post has been edited by bhoar: Jan 23 2008, 17:39

[pdq]

I think the key feature of AccurateRip is not to be able to tell you (falsely perhaps, due to erroneous or malicious entries) that your rip is inaccurate. At best there is only a suggestion that your rip is inaccurate.

The real value is to be able to tell you with virtually 100% certainty that your rip IS accurate, and I don't see how any amount of false data in the database is going to interfere with that. It's not as if someone can predict what CRC people are going to get from an inaccurate rip and put that result into the database to trick people.

[Fandango]

Another thing that always made me wonder: what if someone downloaded a lossless album rip from a P2P network, burnt it to CD-R or CD-RW (with wrong offsets) and the re-ripped the tracks and then submitting the AR results?

I can imagine that this might happen quite often with very popular albums, people download a rip and burn it to CD-R (instead of leaving it on their HDD) and then some day they want to create MP3 tracks from the album, re-rip with EAC or dBpoweramp and innocently submit the AR results.

The least harmful that can happen is that the database is polluted with CRCs of a "different pressing" that never actually existed in stores. The worst thing that can happen is that CRCs of an erranous lossless rip are uploaded en masse (maybe with correct offsets!). Or a MP3 album... or whatever.

It seems quite problematic considering the fact that many people do get their music "second handedly".

This post has been edited by Fandango: Jan 23 2008, 18:32