Feature req: Accuraterip style verification (www query of checksum of rips)

[GoogleCodeExporter]

Accuraterip is a database product that lets users verify the md5sum of 
their rips against a "public" database.  Unfortunately it is no longer 
maintained.

I would like to get an open database going of checksums of ripped wav 
files so that the FOSS audiophile community can have something to see how 
their rips compare with others.

Does such a database exist already?  I've posted on the forum at 
freedb.org to check with them on this also.

If it doesn't exist, I would be happy to start it!  This would compliment 
rubyripper more than any other software out there now and I think most 
users would enjoy it.

Matt

Original issue reported on code.google.com by geniuswe...@gmail.com on 12 Aug 2007 at 10:22

• Blocking: #528

[GoogleCodeExporter]

An interesting and tempting idea indeed. I do see some problems though.

1. How can one assure that users will set their offset value correctly? 
Different 
offsets lead to different checksums with the same drive. I know Exact Audio 
Copy 
uses some popular cd's to get the offset right.

2. You would have to setup a server with a public API to read and write to a 
database. You probably want to restrict the latter to certain certified 
programs. 
Implementing such a thing is not an easy task at all if you ask me. Also a 
reliable 
hosting adress seems to be desirable.

I'm open to ideas how to solve those.

Original comment by rubyripp...@gmail.com on 14 Aug 2007 at 9:20

[GoogleCodeExporter]

I would suggest a vote system (one vote per submitted checksum) on the 
assumption
that people with bad offsets will tend to give fairly random checksums when they
submit them.  Very much like rubyripper works when ripping. 

I see the process as
a) client app submits checksum / cdid# / track# to the server
b) server stores the checksum as a vote
c) server returns pass/fail depending on whether the submitted checksum is in 
accord
with the majority of votes received in the past.  In the case where the number 
of
votes is 1 (first submit of that cd/track) it will return pass.  Otherwise it 
will
return pass/fail depending on the vote tally so far for that checksum relative 
to
others.  A "degree of confidence" number from 1-100 that is directly related to 
the
number of votes for that track could also be worked in to give clients some
flexibility in handling the result.  It's pretty good odds at 100 that the 
checksum
is the right one.

There are a number of other anti-pollution measures I would add to the 
submission
acceptance process but I think this could work.

Hosting it is not a problem, I have a number of well connected servers.  I 
think the
protocol will be very lightweight given my description so far, much lighter than
freedb for example.

Original comment by geniuswe...@gmail.com on 17 Aug 2007 at 3:58

[GoogleCodeExporter]

I'm not sure why the parent thinks that AccurateRip is no longer maintained.  
It's
thriving, in fact:  the latest releases of Exact Audio Copy have improved 
support for
it by leaps and bounds.

http://www.accuraterip.com/

I think that the masterminds behind AccurateRip are Illustrate (makers of
dbPowerAmp).  The lead (only?) developer, Spoon, is a frequent poster at
HydrogenAudio, so it'd be easy to get ahold of him there.

Original comment by heliolo...@gmail.com on 21 Aug 2007 at 2:48

[GoogleCodeExporter]

In any case the database is held in a private copyright and is not published 
without
restrictions, so it couldn't be used effectively by open source programs.

Since it wouldn't be much of a job, I propose building an independent database
without getting involved with Accuraterip at all, and release it under a 
creative
commons license or similar.  The optimal solution would be for Spoon to do this 
but
from a reading of the forums for the product it doesn't seem likely to happen.

I'll see if I can get a proof of concept coded up and I can then repost later.

Original comment by geniuswe...@gmail.com on 21 Aug 2007 at 10:03

[GoogleCodeExporter]

Would communication with a private database on the web really have any impact 
on the
distribution of an open-source program?  IANAL, but that seems dubious to me.  
The
problem with starting a CC (or more likely GPL) database on the web is that such
databases are only valid insofar as they are used.  The proposed database would
initially be used only by.... RubyRipper.  And possibly other libparanoia-based
rippers, should they elect to use it.  But there would be no reason to trust the
submissions from said rippers anyway, since libparanoia is known to be buggy 
and not
particularly accurate.

As far as I'm concerned, the best approach is to get RubyRipper to talk to
AccurateRip, proprietary or not, provided Spoon is able to provide an API to 
talk to
the database---both dBpoweramp and EAC seem to use a drop-in DLL file which is 
of no
particular use on a POSIX system.

Original comment by heliolo...@gmail.com on 26 Aug 2007 at 3:30

[GoogleCodeExporter]

Ah, I should have looked a bit first.  Basically, Spoon needs to approve the 
software.

Third-party access to AR: http://www.accuraterip.com/3rdparty-access.htm

Perl script as proof of concept for access to AR:
http://www.srcf.ucam.org/~cjk32/ARCue/ARCue.pl

Original comment by heliolo...@gmail.com on 26 Aug 2007 at 3:35

[GoogleCodeExporter]

An existing database with a lot of data in it should indeed be preferred. But 
since 
Accuraterip doesn't have a public API, is it allowed to use it in an opensource 
program?

Original comment by rubyripp...@gmail.com on 26 Aug 2007 at 8:27

[GoogleCodeExporter]

>An existing database with a lot of data in it should indeed be preferred. But 
since 
>Accuraterip doesn't have a public API, is it allowed to use it in an 
opensource 
>program?

Quote from their website:
"AccurateRip is open for anyone and everyone**, the benefit of such a system 
should
not be limited to one program."

I am not convinced of the quality of AR though. I know a couple of people who 
submit
rips of burned CD's, just because they do not know that they shouldn't...

Heinz

Original comment by heinz.weigand@gmail.com on 29 Sep 2007 at 11:55

[GoogleCodeExporter]

Are people getting favorable results from using it with EAC?  I've only ripped 
about
20 discs with EAC using AccurateRip, but none of them have matched the 
checksum.  It
might be my drive, which is a Plextor PX-755SA, but the db doesn't seem very 
reliable
to me.

By the way, heliologue, you mention bugs and a lack of accuracy with 
libparanoia. 
Can you back that up a bit, I'm curious if I should feel as safe as I do using 
RR.

Original comment by mfsali...@gmail.com on 12 Oct 2007 at 12:58

[GoogleCodeExporter]

As noted before, when you're offset is not set correctly, you will have 
problems to 
match the results of others.

As of bugs and lack of accuracy with libparanoia. All rippers have problems 
reading 
damaged sectors. It's the primary reason why rubyripper is written.

Original comment by rubyripp...@gmail.com on 12 Oct 2007 at 2:45

[GoogleCodeExporter]

I don't know if this type of implementation will bring any improvement to the 
ripping
process. Today I've ripped the same CD from two different computers, and 
everything
was OK. The sound was perfect, but the md5sums not. Sometimes errors can occur, 
but
they have so little impact on the entire procedure that it can mean only
0.0000something'' of difference. Sometimes erros like that can occur even in the
manufacturing process. So It's very difficult to have two identical waves from 
two
different CDs.

Original comment by alsamp...@gmail.com on 26 Nov 2007 at 1:01

[GoogleCodeExporter]

I am using dbpoweramp for ripping. I used to rip also with EAC.
Unfortunately nothing similar under Linux yet.

Accourate Rip is becoming a key feature to me.

The great thing with accurate rip is that you can usually rip at a much higher 
speed
and you're also getting perfect results.
You don't have to run insane slow rips.
I'd be really happy to have Accourate in.

The offset issue is not an issue. The drive database is pretty reliable. 

Original comment by kls.schlz@gmail.com on 5 Jan 2008 at 11:20

[GoogleCodeExporter]

In fact there are a couple of issues that play here:
* is an opensource program allowed to have access on the accuraterip database
* and if so, read-only or also send info
* what are the prerequisites of having support of accuraterip? Does rubyripper 
need 
to offer a dialog to match one of the 'known' discs against the database to 
verify 
the offset? In general, what does rubyripper need to take for measures to 
ensure 
that sending checksums do have a correct offset on their drive?
* how are gaps between tracks handled? Do they belong to the track or not?

I feel that to implement support for such a feature demands quite a lot of 
developer time. But after next release this will have my full attention. Anyone 
who 
can help with details about the above, say so...

Original comment by rubyripp...@gmail.com on 5 Jan 2008 at 11:45

• Changed state: Accepted

[GoogleCodeExporter]

* is an opensource program allowed to have access on the accuraterip database

it was posted previously, but:
http://www.accuraterip.com/3rdparty-access.htm
http://www.srcf.ucam.org/~cjk32/ARCue/ARCue.pl

Original comment by asdfasdf...@freemail.hu on 6 Jan 2008 at 1:28

[GoogleCodeExporter]

Hi .

Following Up on comment 13.

Did you get any further here?
Did you get any support?

I have no idea how they calculate the checksums and how you compare the AR 
database
with the actuals. I guess AR guys will be open to tell you.

Some thoughts: 

1. You could first implement a checkbox within settings for enabling it.
   You could also add a selectable function to cancel the rip if AR check fails.   
2. EAC is using just a log entry at the end of the rip  to tell you that the 
checksum
is correct. That would be very easy to implement I guess. You can decide by 
yourself
if you want to try it again. 
3. I, and I guess many others, know and proved the drive offset from playing 
with
EAC. The offset issue shouldn't be a Rubyripper priority issue.

Cheers

Original comment by kls.schlz@gmail.com on 21 Feb 2008 at 1:02

[GoogleCodeExporter]

Reading in this thread thread, "AccurateRip - Future Direction" in the 
dBpoweramp
forums, it seems that they are using CRCs and doing "offset calculations" in the
client using known commercial discs (so-called "key discs") to calibrate your 
drive's
offset by checking against the "key disc" on-line in the database.  Perhaps 
opening a
dialog with these folks would answer many of the questions you may have.  Check 
the
thread, it is an interesting read.  Here is the url:

http://forum.dbpoweramp.com/showthread.php?t=16463

Peace,
Tim LePes

Original comment by luvdownb...@gmail.com on 30 Apr 2008 at 2:26

[GoogleCodeExporter]

Oh yeah...  bump +1 for this feature!!!  :D

Tim

Original comment by luvdownb...@gmail.com on 30 Apr 2008 at 2:27

[GoogleCodeExporter]

I tried testing a rip I made with RubyRipper using the AR database, and the 
result
was positive (see attachment).
ARCue works only on single wav file and, in order to create it, I needed a
non-compliant cuesheet (I made it with EAC) and a Win utility called CueTools.

Maybe it would be a good idea to create a RubyRipper feature which can do the 
same
thing: creating a proper cuesheet and a single wav file, submitting them to AR
database and writing a separate log. This way there's no need to submit rip 
results
to AR: you'll only compare them with the ones on the AR database.

Please note: on the logs I deleted infos about Drives used.

Original comment by upgrade2...@gmail.com on 30 Apr 2008 at 11:11

Attachments:

• RR-AR-EAC.7z

[GoogleCodeExporter]

I think you would find a much increased user base if you added Accuratrip to 
your 
program.  This is one of the features of dBpoweramp that keeps me running a 
windows 
machine.  Hope all is going well on this project!

Original comment by JGordon...@gmail.com on 5 May 2008 at 12:24

[GoogleCodeExporter]

that would really be a cool feature for a cool ripping program!
i'd also love to see  that feature in rubyripper.

regards,
harald

Original comment by harald.g...@gmail.com on 20 May 2008 at 5:21

[GoogleCodeExporter]

And yes, again a vote for this feature! I read the whole bug report and believe 
there
are some good ideas. Maybe an independent plugin mentioned in comment 18 is a 
good
idea. Maybe we will get a plugin system (like firefox?) in rubyripper: one 
plugin for
AR, one to find out the offset, ... only an idea which just comes up. :-)

greets
Jan

Original comment by jbuec...@gmail.com on 6 Aug 2008 at 2:41

[GoogleCodeExporter]

issue 224 is marked as a duplicate.

Original comment by rubyripp...@gmail.com on 6 Aug 2008 at 2:48

[GoogleCodeExporter]

AccurateRip is made for dbPowerAmp, but it wins that most of people use EAC and 
submit results. RubyRipper should not only rip using DB, but also submit 
results.

Comment 18 about noncompliant cue is a needed feature - other way all rips from 
CDs 
with gaps are not proper to restore the original CD from rip, even if they 
don't 
influence on rip itself (not the gap before first track).

Original comment by studio3...@gmail.com on 11 Aug 2008 at 11:14

[GoogleCodeExporter]

i'm curious whether any progress has been made. has there been any kind of
communication with the AR staff, or anything?

Original comment by asdfasdf...@freemail.hu on 19 Aug 2008 at 6:41

[GoogleCodeExporter]

rr should definitely have the ability to compare its rip results to those of 
accurate
rip DB and also to submit them to it. 

More cuesheet options would be very welcome also. 

Original comment by FlacMonk...@gmail.com on 27 Sep 2008 at 9:41

[GoogleCodeExporter]

Just wanted to let you know, it's not that difficult to verify a rip against AR
database, and i recently found that you don't even have to know the drive offset
(unless you want to submit results). I implemented this functionality in 
windows app
CUETools (http://www.hydrogenaudio.org/forums/index.php?showtopic=66233). It's 
not
portable, but it is opensource, so you can take a look at the code to see how it
works. It calculates track CRCs for a range of possible ofsets simultaniously, 
then
it presents a log, which displays various offsets matching the database. Usualy 
there
are more than one, and not because people got their read offsets wrong and 
submitted
wrong results to the database, but because usually there are several pressings 
of the
same CD, different only in offset.

Original comment by gchu...@gmail.com on 23 Oct 2008 at 2:35

[GoogleCodeExporter]

XLD is a an open-source ripper for Mac using AccurateRip. In some way it's even 
better than EAC, though only EAC and dbPowerAmp are proved to send ripping 
results 
to database (for now). But there's enough software already that can access DB 
without problems.
Let's count: ARCue, Cue Tools (above), fooAccRip (an ARCue modification for use 
with 
foobar2000), TripleFLAC and lots of ARCue mods (ARFLAC, ARCue with offset 
searching, 
etc.).

Original comment by studio3...@gmail.com on 28 Nov 2008 at 5:08

[GoogleCodeExporter]

Slightly tangential, but why not compare against MusicBrainz.org's acoustic
fingerprints--which works regardless of codec?  I believe it's open source.

Original comment by iain.dal...@gmail.com on 4 Dec 2008 at 7:52

[GoogleCodeExporter]

AccurateRip has 40 mln. rips in db already. MusicBrainz won't even be close.

Original comment by studio3...@gmail.com on 24 Dec 2008 at 7:38

[GoogleCodeExporter]

[quote=accuraterip]AccurateRip's database in it's final state, is copyrighted
Illustrate, access is restricted to approved programs.

Commercial Access

Commercial usage of AccurateRip requires an AccurateRip commercial license, 
please
email for details:[/quote]

I dont want to contribute to something that doesnt share the data I submit 
freely.

Original comment by ComradeK...@gmail.com on 31 Mar 2009 at 10:32

[GoogleCodeExporter]

Please help fill the wiki page I've created to research this feature:
AccurateRip_Research.

Original comment by rubyripp...@gmail.com on 6 Apr 2009 at 9:08

[GoogleCodeExporter]

After issue 207 is fixed, this should be my next target. So please rejoice, your
voices are heard :)

Original comment by rubyripp...@gmail.com on 11 Jul 2009 at 9:49

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

It would be nice to hear about this project is still to be counted for. 
AccurateRip
is fine indeed, and actually it fulfills all that I desire after ripping my 
discs.
However, the downside is that it's not under GPL license, therefor could prolly 
at
any given time be subjected to a fully being-charged-for system (not very 
likely,
however). So, An open-source project with the same idea as AccurateRip would be
really nice. I've given the same idea lots of thoughts, and then I ran across 
this
topic. Interesting, indeed. The obstacles no. 1-2 stated high above is not to
consider even remotely hard to overcome, right? It should all be in the hands of
great minds and some efforts here, right? ;) Please, keep it up!

Original comment by skogsw...@gmail.com on 10 Jan 2010 at 10:32

[GoogleCodeExporter]

In fact, there is an open-source project with the same idea as AccurateRip.
http://db.cuetools.net/

Original comment by gchu...@gmail.com on 6 May 2010 at 2:00

[GoogleCodeExporter]

I'd be remiss not to mention this fine project which implements AccurateRip as 
well:
http://thomas.apestaart.org/morituri/trac/wiki

Original comment by mordbr...@gmail.com on 6 May 2010 at 2:57

[GoogleCodeExporter]

It seems to me that the restriction on commercial use would make AccurateRip 
incompatible with the GPL3 used in RubyRipper (See Section 10 and Section 12 of 
the GPL3).  However, it seems to me that that MIGHT not preclude adding some 
glue to ALLOW the user to use their own AccurateRip app such as ARFlac or 
ARCue, as mentioned above, provided that RubyRipper was not 
conveyed/distributed together with the AccurateRip application.

Admittedly, this is a bit fuzzy with respect to my interpretation of the GPL3, 
as it assumes that the Commercial License for AccurateRip would ONLY be 
required once access to the AccurateRip database was made possible (i.e. when 
ARFlac/ARCue was added to the system with RubyRipper).  In some legal 
jurisdictions, however, this assumption may not hold (e.g. if the license 
applied due to the fact that the intent of the glue code was to permit use of 
AccurateRip), and even in those jurisdictions where it does, this likely 
violates the spirit, if not the explicit wording, of the GPL3, and it would 
raise concerns with respect to even simply giving someone a computer on which 
you had installed both Rubyripper and ARCue/ARFlac (whether or not doing so was 
intentional).

Furthermore, another downside to this approach is that there are no external 
apps that I'm aware of which support track-by-track AccurateRip calculation 
using wave files.  All of them require either an image rip or that the audio be 
in FLAC format.

Of course this is all a moot point should spoon grant access to rubyripper 
under a license which is compatible with the GPL3.  Given his intent to charge 
for Commercial Use however, I doubt this is possible.  I suspect this would 
require getting in contact with spoon directly to get clarification.

Original comment by comradec...@gmail.com on 20 Nov 2011 at 4:09

[GoogleCodeExporter]

maybe you can check this similar project Morituri that has already an 
implemented support for AccurateRip verification and also for other things, so 
maybe you can check out how they are solved there.
http://thomas.apestaart.org/morituri/trac/wiki

Original comment by pyroping...@gmail.com on 22 Nov 2011 at 7:34

[GoogleCodeExporter]

It's not technical issues which would prevent this from working (Morituri, 
ARCue and ARFlac provide more than enough code to base on).  It's legal issues 
(license incompatibilities) that would be the killer on this feature.  That 
said, I am doubtful that there would be an issue if there were hooks for 
ARBITRARY programs to test for track quality (e.g. a return code of 1 from the 
external application means a bad rip, a return code of 0 means a good rip, and 
pipe stdout direct to the log file without any post-processing), like how we 
allow arbitrary "other" encoders.

This approach would have the advantage of not breaking the spirit or the word 
of the GPL (the AccurateRip application is at arms-length and is invoked as a 
shell, and there is no assumption that AccurateRip is the verification engine 
used), as well as allowing for future flexibility (if with the disadvantage of 
not necessarily playing well with rubyripper).

However, Morituri IS GPL3, so it is possible that they have figured out a 
solution to the license incompatibilities, and it may be worth talking to them 
for that at the very least.

Original comment by comradec...@gmail.com on 23 Nov 2011 at 4:50

[GoogleCodeExporter]

So how about supporting an open source alternative to AccurateRip? I mean CTDB 
of course, i mentioned it earlier. EAC already does.

Original comment by gchu...@gmail.com on 23 Nov 2011 at 5:02

[GoogleCodeExporter]

Rest assured that I am fully in favor of supporting CTDB and will see what I 
can do about it.  The above statement was mostly to make clear my concerns 
about the legal implications of including AccurateRip support directly.

Original comment by comradec...@gmail.com on 23 Nov 2011 at 6:48

[GoogleCodeExporter]

Original comment by comradec...@gmail.com on 25 Aug 2012 at 9:58

• Now blocking: #528

[GoogleCodeExporter]

Any word on progress with AccurateRip and GPL3?  

Original comment by snails...@gmail.com on 3 Oct 2012 at 2:44

[GoogleCodeExporter]

Any update?  I have recently fallen in love with Rubyripper and think this 
capability would be great.

Original comment by David.H....@gmail.com on 15 Jan 2013 at 5:13