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
Possibly you yourself had submitted the erroneous CRC twice and that's what is being reported?
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.
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?
Could be one pressing with a manufacturing defect.
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.
I am using version 12.4 (Reference).
I don't know if this is all the log information you need...
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
Sorry it is R13 which add the AccurateRip CRC to the log file, are you able to try the R13 alpha version?
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.
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.
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.
For CDs with a confidence of > 2, erronous submitted results (ie bad rips) do not make it tot the database.
Spoon, could you elaborate on what you mean by this? How are you able to distinguish a bad rip from a different pressing?
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).
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.
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.
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.
>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?
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.
>which indicates that this is a consistent problem between different user IDs, no?
Seems that way.
>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?
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.
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
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.
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".
@Fandango: The only thing which could help here is a distinction if it is a pressed CD or a CD-R/RW while ripping. I don't know if this is possible.
@spoon: Are you the only developer of AR? Or are there also some "freelancers"?
I am.
>What are the chances that this user is, inadvertently, polluting the results data from time to time?
There are effectively 4 billion 'slots' to fill with eronous data, and it takes a fair effort to fill one of those slots.
The worst thing that can happen is that CRCs of an erranous lossless rip are uploaded en masse (maybe with correct offsets!).
Yet, all it takes is just one upload or two uploads (in the case that bad data was there first) of non-erroneous data and and then it doesn't matter anymore. I don't care one iota about people getting false positives because from CD-Rs that were created from discs they did not rip themselves. If they were legal downloads then so be it; know that you can only prove that your download wasn't corrupt.
>What are the chances that this user is, inadvertently, polluting the results data from time to time?
There are effectively 4 billion 'slots' to fill with eronous data, and it takes a fair effort to fill one of those slots.
Ok...so the only person likely suffer false positives would be the person in that scenario (since they'd be the source of the multiple positive matches)...got it.
-brendan
So that nobody comes away from this thread thinking that this 1 in 4 billion figure is valid, it assumes that equal coverage of all data and that any checksum is just as likely as any other. History will show this to be false:
http://www.hydrogenaudio.org/forums/index....mp;#entry756260 (http://www.hydrogenaudio.org/forums/index.php?showtopic=66233&st=1350&p=756260&#entry756260)
EagleScout1998,
Do you have anything new to report?
Any results from a sample by sample comparison of the two versions?
Is it possible that you've uploaded AR results with more than one PC or between reinstalling your OS?
Nothing new to report.
At the time I wrote my first post, the drive in question was connected to the mobo's onboard SATA controllers. I have since connected the drive to a PCI SATA add-on (I needed another channel for another hard disk). I have not yet been able to reproduce the second CRC.
I never got around to performing a sample by sample comparison.
Accurate (2) - 25BD6EF2
Are you able to rule out the possibility that the two submissions for this particular version of the rip came from you through the use of two different computers or reinstalled OS on one computer between submissions?
Are you able to rule out the possibility that the two submissions for this particular version of the rip came from you through the use of two different computers or reinstalled OS on one computer between submissions?
No, I can't rule that out that possibility.
Here is another occurance, just like this (here 4 different drives fall into 2 camps of results ripping the same disk):
http://forum.dbpoweramp.com/showthread.php?t=16417 (http://forum.dbpoweramp.com/showthread.php?t=16417)
I've been following along as well, though it appears that two drives give one AR result with a confidence of 4 while one drive gives a different AR result with a confidence of 10. The fourth drive wasn't able to get an AR match and delivered inconsistent results in two attempts.
Used drive : LITE-ON DVDRW LH-20A1P
Make use of C2 pointers : Yes
Track 17
Track quality 100.0 %
Copy CRC 6CC43F51
Accurately ripped (confidence 4) [FC233DE5]
Copy OK
Used drive : HP DVD Writer 400c
Make use of C2 pointers : No
Track 17
Track quality 99.9 %
Copy CRC 6CC43F51
Accurately ripped (confidence 4) [FC233DE5]
Copy OK
Used drive : PLEXTOR CD-R PX-230A
Read mode : Burst
Track 17
Copy CRC 9EF72F6E
Cannot be verified as accurate (confidence 4) [03739B0E], AccurateRip returned [FC233DE5]
Copy finished
Track 17
Copy CRC 896C151F
Accurately ripped (confidence 10) [FD203DE5]
Copy finished
Track 17
Test CRC 896C151F
Accurately ripped (confidence 10) [FD203DE5]
Copy OK
Used drive : TSSTcorpCD/DVDW SH-S162L
Make use of C2 pointers : Yes
Track 17
Track quality 98.0 %
Copy CRC BD682A8F
Cannot be verified as accurate (confidence 4) [FA2D182F], AccurateRip returned [FC233DE5]
Copy finished
Track 17
Track quality 99.4 %
Copy CRC D5A6E456
Cannot be verified as accurate (confidence 4) [EAF48E86], AccurateRip returned [FC233DE5]
Copy finished