Hello!

I believe the AccurateRip results are not convincing enough, their is no degree of correctness convincing to the user.
So I thought what if we could start a project were people would input hashes for rips of their collections.
Allowing people to check their rips against the DB.

AccurateRip returns hashes in CRC32 format, which is not enough for one track if the length is never the same.

I'm looking for people interested in this and have big and collections in reasonable condition for hashing.


-Nocturnal

First, I would say that having more sources to verify rips is probably not a bad thing. To clarify though, AccurateRip's values are also based off of the 32-bit DiscID, so there is more accuracy than you might be aware of.

For the record, AR hashes are not CRC32.

DiscID, it is bound to be unique to the disc itself. But comparing from the track side itself, it isn't.

AccurateRip results are not sufficient, the results returned per track is a hash and an accuracy rip. The accuracy rip is loosely based on the number of times it was ripped and the similarity between these rips, yet insufficient to provide any assurances to the user. Hashing is the best way to find the best solution/condition per track.

Track checksums are referenced by disc ID, this was patmcg's point.

Please feel free to study up on AccurateRip before continuing with this discussion, there is a wealth of information available on the topic here at this forum.

You can say AR is not sufficient until your fingers turn blue, though this does not in any way validate your concerns as actually being true. Perhaps you can provide some kind of rationale/statistics to back your assertion, so that you may be taken seriously.

Things start everytime with the work of one man/woman - go, start programming an api, a quick database (ZFS Filesystem should be "the shit" for your idea, because it's incredible secure, omg omg), python/perl scripts, a plug-in for EAC, dBpoweramp and probably foobar and you'll see: They will come and hail you.

On the other side... Does exist a database with CD releases and their technically infos? Like mastering studio, mastering technology, sound problems, emphasis, dynamic range and co. Discogs dosn´t provide such things.
That could probably attract people.

But the data itself is only contained within AccurateRip and not provided to the mass public, with the project I'm sharing such information with the mass public.


The confidence value returned is never the same and I should be assured that whomever has been ripping has a ripped from a CD in mint condition. Since the hash value is based on DiscID, I can see some truth to my words. People that are new to ripping can never understand the meaning behind the results returned by EAC, so my solution can offer them some comfort.

I'm sure you should be assured you will get a pony too.

I can see it now: "new ripping accuracy service requires webcam proof of a gun pointed at user's head while ripping"

You can't possibly know whether or not a rip is correct a priori - and moreover, you can't possibly dismiss a rip solely because it has a hash value in the minority. So many legit CD pressings have offset errors that the relativist position AccurateRip takes is the only sane position.



"Never"? You seem to be unusually elitist about what users can and cannot understand.

The beauty of the system is this is unnecessary.
Even badly scratched discs can grow the database in a healthful manner.

I think you fail to understand the collision rates at play here.

That's why I said people that are new. I imagine when you started ripping CDs you were so perfect at it.

When I started ripping CDs back in '98 I bought (because it wasn't freeware at the time) Audiograbber by Jackie Franck and began extracting audio. Now and then I'd find problems with the rips and would try on a different drive (had DVD and CD drives back then) and different computers. If the error happens at the same place in multiple rips with different machines, it must be recorded in. If the error is caused by disc damage, different drives will behave differently. Best bet then is to get the disc repaired or get another copy.

Yes, you can have discs repaired if the damage is only on the NON label side. The game store I go to has a buffing machine that will grind down the disc and remove scratches. Scratches on the label side will damage the reflective layer and are not repairable (am I wrong?).

BTW you're getting a little defensive about this.

G²

I used to make my own mp3s back in 1996 on a Pentium, WinDAC and an encoder written in VB. And I agree with your deduction about the CD states, unfortunately I live in Egypt and I have no way of repairing any of my CDs. And if I buy any CDs I have to wait for Christmas or the Summer until I get them, back in 2007 I started to make digital rips and have them stored on an external HDD. These rips were done from newly opened CDs then encoded on my computer in Apple Lossless and stored on my iPod, but since I've been collecting CDs since way before 2007. Some of the CDs have grown big scratches on them, yet EAC doesn't show errors while ripping.

However AccurateRip has a different opinion results aren't the same and if you listen to the track it skips. But if you are into the downloading of Linux distributions they can be compared against hashes. So what if a DB containing a list of hashes and the user provides a used filename output. A MD5 to check the ripped CDs could be provided and instead of having to listen to the damaged track the user can compare that straight away. I saw spoon in a thread complaining of the weakness of CRC use, but sure the small hash is easier to store in a DB especially for a large collection of CDs.

I thought of starting something similar to AccurateRip, dipped my eyes at some CD reading related code and technical stuff. But on the technical audio side I didn't know where to start and I remember pieces of audio properties since physics class. So instead of having to dip my hands deeply to get some really excellent or perfect results I thought it would be better to settle for hashing.

Of course not, it's a living database.

Nonsense. You either get a match or you don't. If you get a match then you can be sure that both you and the other people who submitted the same result (as determined by the confidence) had error-free rips. If you don't get a match because you have a different pressing then you might be able to get one using CUE Tools without any additional work. Considering that this is a native Windows program based on .NET, I see an opportunity for development for non-Windows and non-Mac platforms (XLD and I think Rip have similar functionality), though I don't see any reason for the creation of a new database. If you don't get a match because there is no other accurate data or your rip is not accurate, then there's nothing about a competing database that will help; likely just the opposite.

It uses much of the same information as the older DiscID does, but with far more precision and also has the provision for data tracks, but what does that have to do with the all the rice in China?

You're speaking for yourself, as most newbies I've seen (scores of them) don't seem to have the problems of which you speak. Still, exactly what is your solution?

I don't really want this to dive unnecessarily off-topic, but you must surely be able to buy toothpaste and car wax in Egypt. Again, feel free to search this site as this topic has been discussed to death as well:
http://www.hydrogenaudio.org/forums/index.php?showtopic=2633
http://www.hydrogenaudio.org/forums/index....showtopic=65962

Re-read the initial post and you will see that this is off-topic. Considering that we already have our hands full regarding the technical merits as they relate to the actual topic at hand, please refrain from obscuring the focus of this discussion. If you have any questions please read TOS #5. If you disagree with my assessment then refer to TOS #7. This is not negotiable.

This just seems to be a CRC (32 bit) vs MD5 discussion, whilst MD5 would have less collisions on the CRC it would not inform of a potential collision, where-as the confidence system does, example:

Rip track1 - get a crc 11111111 conf 96
Rip track2 - get a crc 22222222 conf 94
Rip track3 - get a crc bbbbbbbb conf 1
Rip track4 - get a crc 44444444 conf 96
Rip track5 - get a crc 55555555 conf 93

Now track 3 has has a ripping error and matches someone elses ripping error, in the very unlikely even of a collision in the CRC (in the billions to one) you can spot something is not right on confidence. **** in reality the conf 1 result would not be in the database it would be excluded as peoples singular bad rips do not appear, so you would need two people both having a bad rip to appear in the database (which if my grasp of odds are correct would be 2^32 * 2^32 * 2^32). In reality when only around 100 people have ripped that disc, getting collisions like this are so unlikely, as they say you have more chance by being struck by lightning....

This topic is pointless, the biggest "flaw" of accuraterip is not unreliability or collision: the database is rock stable, wicked & relentless. The database biggest flaw is "Disk not present in database." which happens around ~40% of time according to my experience. The creation of a new database will only split the market & make "Disk not present in database." even more frequent. So this idea is really stupid IMHO.

Think we have been through this before, like http://www.hydrogenaudio.org/forums/index....75&start=75

And as sauvage78 points out, the biggest problem with AccurateRip is that there are so many morons around who haven't got enough musical taste to buy & rip "my" discs before me

Back in July I ripped a Cranberries album (Stars: The Best of 1992-2002), the CD was brand new and I had just opened it. So the CD was in perfect condition and had been just inserted for ripping, so to conclude their were no scratches or any problems no suspicious positions was reported from EAC.
But after the the ripping was completed, I received this.



What would you do if you were in my position? :S

Try again later and hope that someone else has now ripped the same pressing that you have...

BTW, by submitting your results you make it possible for others that have your pressing to not have this situation when they rip theirs.

Edit: It's amazing how much time we spend defending AR when it should be a no-brainer.

I had proposed this before, but if anyone wanted to take the concept of AccurateRip to the next step, the clear choice would be implementation and storage of Reed-Solomon codes. This would allow for both verification and REPAIR! As a proof of concept I have taken songs with a few difficult to recover frames, gotten accuraterips as verified by AR, used ICE ECC to generate a ecc file, then re-ripped the disc in burst mode on a different computer, confirming that it was not accurate and used the ecc file to repair it and confirmed that the md5 of the repaired file matched the AR file

About how much bigger would the storage space for the database need to be to include this information? Are we talking double? More?

Did you see the part of the log that says, "You may have a different pressing from the one(s) in the database"?

If so, I addressed such a circumstance already:

But indulge me, how would your new and improved system handle this situation? How do you expect to generate hashes for a track that does not exist in the database, magic?

With the way hashes are calculated for AR, it is possible to get a match for a different pressing even if it doesn't exist in the database. With CRC32 or MD5 this is not possible.

It would be great if the results were returned in XML format with a webservice for retrieving/submitting results. Of course the submission process would have to be rigorous so that people wouldn't be able to poison the database but I think a more open/useable service would be an awesome idea.

greynol, I'm not proposing a new hash system, but I'm proposing a web site filled with MD5 hashes of the wav files ripped.
Supporting AccurateRip as it already has a few million tracks stored in it, but it can be used as a side reference with AccurateRip to provide further guidance on the quality of the rip.

Such a database has already been attempted:
http://www.audiograbber.com-us.net/checksums.html

I'm guessing it has failed miserably for quite a number of reasons, among them is the fact that it does not take into account the large number pressing differences.

This audiograbber database is ridiculous... it only illustrates how great is accuraterip.
If you think accuraterip is bad, then chance are high that you don't understand how it works.

The cuetools support of accuraterip was a revolution for me, it changed my life. Just as F2K, EAC & Flac did.

Up to this point I fail to see a reason why one would see the need for a secondary database, aside from ignorance/misunderstanding.

Ahhh, remember that one, yes it was a failure. But I don't understand why such a project should fail, as a project on it's own I could say it would fail. But I think with AccurateRip's data it can be a reason to succeed, today.

Build a better mousetrap and the world will beat a path to your door.
What is better about your mousetrap? So far you have not successfully argued any improvement over AR.

If you read the post about the new album I ripped in July you would understand, Audiograbber failed because it didn't have a database for drive offsets.

What if this project is able to prove the better pressings of CDs, it could decrease the size of the database if it disregards non listed pressings for certain CDs. Since those CDs would have been verified in another way, using hashes and other methods of validation.

A - I thought this was about the AccurateRip database - not the Audiograbber failed database.
B - Audiograbber wasn't part of my question.
C - Audiograbber wasn't part of your original proposal.
D - Greynol already told you (and again reminded you) of an existing tool to use the existing AR database to deal with your specific problem. Again - what is better about your proposed method which will work better than CUETools + AR for rare (or new) pressings?

We've discussed AR shortcomings for quite some time now. In terms of security the biggest one is the hash calculation itself, however it allows for offset differences and the measurement of the offset with a very small amount of additional computation.

Unfortunately it would seem that this discussion has not risen to the level of previous ones.

Please define "better pressings".


But one of the problems with any database there will always be titles or pressings of titles that don't exist in the database. You think leaving them out would be a good thing?


Could you please not be so vague? What other methods?

That's another one of the many reasons, yes. They all point to a common problem: a severe lack of understanding by the person who organized the effort. I apologize for being insolent, but it would seem that we might be facing the same sort of problem this time around as well.

Let's say if a group people have agreed to collaborate on this effort, they are aware of the current problems that face them. They have the right equipment calibrated at the right offset, they say they have CDs in good condition of the same artist. Everyone will rip a copy on his/her drive and hash a MD5 or SHA1 file for the ripped wav files, then using a system everyone can test the hash sum of the other persons. If the CDs are in good condition as they are believed to be, then the results should be the same. I have 2 drives in every machine (1 DVD and 1 CD-R) and I use the CD-R for ripping no need to use audio CDs on the DVD drive it's more precious. I ripped an album from the CD-R hashed it using MD5, since I already hash every rip that I back up on external HDD. At least with the hashes I can know if the drive has gone corrupt or has been modified. And then I did the same rip for the same album on the DVD, thanks to AccurateRip the drive offsets were retrieved or else this would be a needle in a big haystack. After the rip was done I did compare the MD5 hashes produced by the CD-R rip against the DVD rip, perfect duplicates.

I'm sure some people here cherish their CD collections, or I wouldn't have announced the topic here since this is an audio enthusiast's resource.

Yes, I know it won't be that good, but like my encounter with the Cranberries album. Their was no good pressing, but if you compare the one that was stored a good source of comparison although it was a low quality pressing and being pushed as confident. :S

Maybe at least then AccurateRip can disregard or identify the bad pressing, due to the effort provided by this project.

Are you suggesting that the two drives could produce two different rips (of the same disk) and both of these rips would be called accuratre by AR?
I sounds to me like you are.

No they were two different drives and they produced the same rip. 1 DVD Burner and 1 CD Burner

It isn't "bad" or "good" it's simply different. Before continuing to discuss your Cranberries disc, give CUE Tools a try.

Soap you have been skipping a few posts and not following the conclusions found.

Sorry, but reading your responses, it doesn't sound like you're aware of the current problems that face you


But you have not suggested anything that hasn't already been considered and addressed.

Where are you getting with this? I hate cue.

I'm not so sure about Soap, but this has been very true in your situation, nocturnal.

You don't even have the slightest idea about what you're saying, do you?
http://www.hydrogenaudio.org/forums/index....showtopic=66233

If by "hate cue" you mean cue sheets, if you have a disc where the first track starts somewhere after 00:00:00, how do you plan on identifying it?

I have to agree with some of the others, I think you are really confused about how AR works.

The problem with your cranberries cd, is that no one else has submitted that particular pressing that you have.

So, you think you want to compare your rip to other pressings by comparing track checksums with some other db, but unless these checksums were all from the same pressing, you would still have different checksums and you would be right back at the same place as you were with AR.

In this hypothetical group of yours, if everyone had the same disk (same pressing of same disk), and ripped with the same or different drives (it doesnt matter) and then submitted the results to AR, after a period of time they would then appear in the DB and you could then be confident your rip is good.

Then again, I think some people are just too paranoid for their own good.

I'm attempting to get at the root of your desire - and purposefully ignoring the jumping around you appear to be doing.
I feel that every time I ask a specific question regarding the problem you are attempting to solve the problem changes.

He could check this disc against the AR database using CUE Tools which can correct what is most likely only an offset difference due to the different pressing and be done with it. At that point, nocturnal might ascertain a higher level of appreciation of the elegance of AccurateRip and realize that md5/sha1/crc32 will not allow this to happen so effortlessly.

Still, based on the initial incorrect assumption that AR hashes were crc32, I still fail to see any legitimate argument demonstrating that AR is "not convincing enough", having "no degree of correctness convincing to the user" or "insufficient to provide any assurances to the user".

I don't understand what is a "bad pressing" or a "low quality pressing" means in the context of accuraterip. Accuraterip cannot tell anything about the quality of pressings. It's either an official CD then, bad or good, it's an official pressing or it's not. If it's an official CD then there can be a LOT of pressings because obviously record compagnie don't care at all if about if the layout of pressing A & pressing B don't match, all they care about is audible glitche.

There is nothing wrong with a track not being accurate & with your Cranberries album.
In the end accuraterip can only send you 3 kind of anwsers:
1: Your RIP is perfect
2: Your CD is not in database
3: Your CD is not in database but your CD is likely to be scratched/damaged, because a lot of other people disagree.

The case were you can be 100% sure that the track is damaged doesn't exist. It's only a matter of logic & probability. All accuraterip does is to tell you if the probability of a scratch is high (sometimes very high) or if it's low. So in the end, you should only really care about result 3 & you have the final choice if you trust accuraterip database or not.

If your CD is not accurate, but not in database it doesn't mean at all that there is anything wrong with your rip. In this case, Accuraterip is like Socrate, it knows that it knows nothing. But it can rationnaly guess.

Instead of judging the database on track/pressing that you don't know if they are accurate. A rationnal starting point is to judge the database on tracks that you know aren't accurate because there were ripping problem. Then you would realize that accuraterip is never wrong on those tracks.

The next step is to find a CD were the log is secure but not accurate. If you can hear a scratch in the "so-called secure" but not accurate track I can guaranty you that you will start trusting the accuraterip database more than any EAC secure log. It happened to me, since then my trust in accuraterip is very high. Many times I didn't understund its result at first, almost each time I found a rationnal explanation later.

nocturnal, could you post the full cuetools log of your Cranberries album plz.

Edit: nocturnal, your new posts made me realize you made me lose my time, you have no clue what your speaking about. Go learn. I LOVE cue sheets