----

>We don't have a consistent "standard" on how to consider EAC to have ripped a CD perfectly

You do, it is called AccurateRip.

no we don't.
AccurateRip reports just 2 correct rips out of 10 pressings I have, at least here. I have seen other people complaining that it is never the same pressing of that CD, thus all "incorrectly ripped" tracks.

But you understood what I said.

If a track is not in the database, there is little AccurateRip can do. The new AccurateRip dll (soon to be in EAC) allows accuraterip identification details to be written to an idtag, not sure if Andre is going to implement this, but if he did it would allow files to be looked up at a later date.

Encourage more people to use it. Encourage more programs to use it. The CDs cant get in the database if no one puts them in there.

BTW, the vast majority of the CDs I rip anymore are in the database.

> I have seen other people complaining that it is never the same pressing of that CD, thus all "incorrectly ripped" tracks.

It is funny, most people only write something when they want to complain, they do not write to say it is working. See reports from 20 people is not representive of the 18,000 who use it. Sure there are discs missing, nothing is perfect.

There are over 1 million unique tracks in the database. Who knows how many unique tracks are in existance.

If you have a pressing that is not in the database, re-rip the disc in a separate drive. This will allow the database to grow faster and more fully represent pressings available. Some people may advise against this practice as its possible the disc may have consistent errors.

but you know, I am NOT talking about ripping cds here, you guys didn't catch the point... the point is... whenever music becomes completely digital** what use will AccurateRip be of? Shouldn't we start by right now a WAV implementation to check against a major database? I personally have hundreds of WAV data that were ripped from CD, but never took a log of it. AccurateRip-WAV could save me the time to go after a certain CD pressing and re-ripping the thing again. Please get the point...



**(not guessing in which age this is going to happen but we're getting there soon),

But how are you to know that your wav file is accurte without coming directly from the source. AccurateRip can be used to check against lossless files as long as there is an AR ID in the tags.

spoon, could you calculate the AR ID from a .wav (or other lossless) file? Or do a reverse look up in the database? (e.g. Here's the track - does it match any CD). Or is the point that the data lost/added by unknown/uncorrected offsets is now gone, so it just won't work?

Bourne, I hope the 3 unreadable tracks weren't the 3 which are actually worth listening to on that album? ;-D PM me if you're really stuck for parts of them (not wishing to go against HA's 30 second rule).

Cheers,
David.

The main problem I see with 'accuraterip for wave' is there is no consistent way of validating a file against a common standard... IE the disc TOC.

ToC is the reference by which all accurate rip tracks are compared to.

That said, if some program were able to generate the applicable crc/signature that accurate rip uses for each track, can then look up that CRC and compare how many toc/tracks/etc match that crc, and then show you the 'confidence' level of that wave, that might be useful...

The key question then is, is the CRC/Signature that accurate rip uses for each track, unique enough to identify a specific rip without the associated TOC.

You could lookup wavefiles if you have a cue sheet.

I'll say this: a freedb-style lookup, built into Foobar2000 that looks up my FLAC albums in the accuraterip database, would be absolutely awesome and would save me TONS of grief.

if we had something like, let's say, a foobar plugin just like Borisz said.

"Song.flac"
Entries 450
Matching 310 (Sane)
Mis-matching 140 (Corrupted)

OK Your FLAC file is SANE (it is matching the majority of rips).
or
NO Your FLAC file is corrupted (probably offset issue).

Considering how files get distributed over the internet, there could be dozens (hundreds?) of copies of the same defective rip, making it look legitimate. How do you make sure that only the original rip gets into the database?

How VERY true.

I actually do check images that I've ripped previously (as a single file or as seperate tracks, it doesn't matter) against the AR database but will not share how for this very reason. I make sure to never submit results from previously ripped tracks but I have no way of keeping someone else from doing this.

i just figured that AccurateRip can tell you if a rip is accurate even from a CD-R that wasn't burned with cuesheet, just fill the proper song names, artist and title... I just ripped 3 CD-Rs I made off the net and gave me accurate rips in secure mode test and copy with confidences over 20.

am i just facing a BUG or now I went to be real lucky???

@greynol:

You said - "I actually do check images that I've ripped previously (as a single file or as seperate tracks, it doesn't matter) against the AR database but will not share how for this very reason."


Someone asked:
Originally Posted by gbarrios
"I've already ripped over 900 CD's to WMA Lossless. Is there a way to run AccurateRip against my exisitng digital files to see how many have errors?"


Spoon (devel) replied:

"No, AccurateRip requires the CD Table of Contents to identify a track, your wma lossless possibly does not have that."

Greynol, would you be lying to us or spreading FUD?

I'm not spreading any FEAR since contamination of the AccurateRip database is indeed a reality. You ripped those CD-Rs, right? Did you make sure to blow away the bin files that they generated before you uploaded your rip results? If so that's great, but you can see how easy it is...

I'm not UNCERTAIN: I definitely can check waves against the database, and it seems that you did also.

Regarding DOUBT, it's in my nature to always challenge what I read so I try to stay on the other side of that coin.

Am I missing something or is what's being discussed and asked about here exactly what was created and mentioned in this thread? I ask because I'm rather surprised that thread has gone without a response. Well, except for mine. heh

Greynol - I think that the accuraterip database is mostly pollution-resistant by design. Even with your method, assuming you don't artificially rotate the drive "manufacturer"/"serial" information on purpose (which can be done by your method), the database should remain somewhat resistant. The only problem I can think of is if someone designed a coordinated attack that would submit a large number of records for rips that simulate common tool configuration mistakes (e.g. after AccurateRIP begins to allow submissions, how does it know that the confidence it had in the calling tool remains in place if the user can change settings after the fact?). Also, for simplicity, the above assumes we're talking about commercial CDs.

Bourne - On a related topic, the database doesn't care if the disc you are ripping is a CD or CD-R, a commercial release or a home-brew compilation . If someone is distributing a flawed/glitched rip that people are burning to CD-Rs and then distributing, at some point...users who have their ripping/burning engines properly configured are going to get positive accuraterip results, even if there are audible artifacts of the original flawed rip. On the other hand, I don't see why that's a problem, the system is working as designed. In most cases you trust the recording/mastering engineers and plant to create a nearly flawless CD that you rip from. In this case, you added another middleman, the one who ripped (or compiled, don't want to assume we're talking about piracy here) the WAVs into the bin/cue that you downloaded. He's now part of the group you (and the other downloaders who use AR - all 20 of them) implicitly trusted by receiving the bin/cue instead of a CD.

-brendan

There is nothing keeping someone from uploading a CD-R (just one example) burned from something he or she downloaded from the internet.

I can assure you that there are many people who share read-offset corrected lossless rips and there are many people who burn them to CD-R using an appropriate write samples offset. This has been going on for several years now and those CD-Rs do get ripped again.

AccurateRip has absolutlely no resistance against this.

greynol...

i did not uploaded any CD-R to the accuraterip database. to be honest i did not even uploaded the commercial ones I have (because they are like 40 confidences already) and I was too lazy to submit (being that I tried once and the results did not go through because of server issues).

i do not know how to check WAV, FLACS, WVs, MP3 or whatever to the AccurateRip database, but surely got curious on how you did it. To be truthful I wanted to know this, just for educational purposes and not to spread this all over internet like I would have enough time to sit here and make a plan to destroy the entire AR database, plus I always like to know if a rip is accurate or not, if i grab anything from the net which in the EAC log says "Read Offset Correction = 0" I get mad, so I wouldn't be the one to pollute accurate rip db just for the fun out of it.

But you know, you are right, I could have done that, couldn't I? So could any person! That is why AccurateRip is not 100% trustful.

I don't think anyone is intentionally trying to "destroy" the database, at least I certainly hope not. Furthermore, I don't believe pollution from questionable uploads is wide-spread; I simply feel that it's naive to think such uploads don't or can't exist.

Regarding your "trustful" comment, positive AccurateRip results are trustworthy so long as you're checking an original CD and so long as the data that's being used to verify your rip didn't all come from this same CD. Positive results are also trustworthy when checking lossless files so long as you are certain that the data used to verify them did not all come from the same source used to create them. If you didn't create those lossless files yourself, how can you be sure?

As for negative results, I don't trust them implicitly since you can't be certain that the database has your pressing besides the fact that multiple entries can be from the exact same source.

Why does it need resistance against this? What problem would that lead to for a regular bought-from-store/amazon/used CD ripping person?

-brendan

Brendan,

I'm simply explaining why I won't publicly share how to use AccurateRip to check previously ripped tracks. Please don't make my statements to mean anything more than this.

For the most part I think the database is a wonderful thing and rely on it heavily. I cannot think of any way to make it more resistant to corruption nor would I want it to be if it meant that I could no longer use it to check rips I've previously made or if it had a negative effect on someone trying to upload a legitimate disc just as you suggested.

greynol has a point...
let's say someone just download and burns an album off the net (image + no cue file) and burn to CD-R then after that, this person submits the results. Then another Joe goes for the same album on the net and uses Accurate Rip and finds out that the disc is in the database and uploads the info.

Let's say that 5 persons do this. You end up with 5 false-positive right?

It would be a passive plugin. It could take data from accuraterip to check files, but could not submit any data. Submitting would still work only with EAC/dbpa, when ripping physical compact discs.

I'm sorry, there was a disconnect in my understanding of your point. I'll leave it be.

-brendan

I'm sure that would generate 5 different CRC's, because people are careless about read/write offsets. But if a single-wav checker was also able to determine a missing/incorrect offset, it should still verify against a original CD submission.

You'd be surprised how many people do in fact pay attention to read and write offsets. There are some pretty obsessive people when it comes to DAE.

Think about how many posts have been made regarding offsets and people refusing to buy drives that can't overread just to this forum in the last year.

These "someone" are indeed careless when it comes to offsets, as they don't even care about a cue file. People inhere are of course of another oppinion, but this is a relative small small community compared to the average user (also discussed several times before)

Is there any sort of expected release date for this functionality?

Ask andre, the DLL was completed 3 months ago (and ships with dBpoweramp R12).

Guys, I do agree!!!

I'd be very happy to check every now and then my accurately ripped files just to be sure the medium they're on is not damaged (even hard disks, I think, could deteriorate over the years!)

One thing that I think goes with this discussion, is that you have no choice whether it uploads or not.

I mean, every time you rip a CD it uploads to the AccurateRip database, which means the next time people rip their CDs it will check against what I just ripped. Well I just ripped about 50 CDs that are all scratched to hell, some of them were not in the database before.

The idea of AccurateRip is great, but I think there were a few things that were overlooked in the development. They're not impossible to fix, however.

EDIT:

I can confirm this as well, although I can't for the life of me remember which exact disc I ripped.

-Me

Scratched cds will not affect accuraterip, in that the system is a confidence system, your 1 bad result would never make it into the final database for a cd with many submissions.

What if the "scratched" CD was actually a different and legitimate pressing?

You need 2 matching submissions for it to appear in the database in that instance.