Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Odd AccurateRip results (Read 23980 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Odd AccurateRip results

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

Odd AccurateRip results

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

Odd AccurateRip results

Reply #3 –
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?
lame -V 0

Odd AccurateRip results

Reply #5 –
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.

Odd AccurateRip results

Reply #6 –
I am using version 12.4 (Reference).

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

Code: [Select]
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

Odd AccurateRip results

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

Odd AccurateRip results

Reply #8 –
Quote from: pdq on
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.

Odd AccurateRip results

Reply #9 –
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.

Odd AccurateRip results

Reply #10 –
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.

Odd AccurateRip results

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

Odd AccurateRip results

Reply #13 –
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).

Odd AccurateRip results

Reply #14 –
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.

Odd AccurateRip results

Reply #15 –
Quote from: spoon on
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(?).

Quote from: Eli on
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.

Odd AccurateRip results

Reply #16 –
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.

Odd AccurateRip results

Reply #17 –
Quote from: spoon on
>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?

Odd AccurateRip results

Reply #18 –
Quote from: greynol on
Quote from: Eli on
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.

Odd AccurateRip results

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

Seems that way.

Odd AccurateRip results

Reply #20 –
Quote from: spoon on
>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?

Odd AccurateRip results

Reply #21 –
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.

Odd AccurateRip results

Reply #22 –
Quote from: spoon on
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

Odd AccurateRip results

Reply #23 –
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.

Odd AccurateRip results

Reply #24 –
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".