AccurateRip what?
A system designed to offer true 100% accurate rips from Audio CDs, be a part of AccurateRip and help create it, visit here for full information and download:
http://forum.dbpoweramp.com/showthread.php...p?threadid=1592 (http://forum.dbpoweramp.com/showthread.php?threadid=1592)
Downloading it now... I'll try to up the ratio of heavy metal music in your database
[span style='font-size:8pt;line-height:100%'](CDex isn't even a rival huh?.. )[/span] Congratulations, haven't checked it out yet, but anoter such project sounds great!
I was asked:
And will you be charging for this service eventually?
I'm loath to help out if it evetually costs me money?
Good question, I publically state that AccurateRip will never be sold off, or charged for. It might even make it onto other Rippers (totally free and open), but that is a little too early just yet.
I have tried about 10 cds on the list, and it only recognized one of them. On that cd, it couldn't get the proper results . I guess I'll have to wait until more cd's get into the database to use it.
Edit: Somebody add some Metallica cds to the database and I'll be fine
Sure this project doesn't sound like a bad idea, but there are a couple of questions I have:
1. You are aware that a lot of CDs are reissued (with bonus tracks etc.), and then you have "Digitally Mastered" CDs (as opposed to the originals) ... wouldn't this cause some confusion regarding your CD database?
2. Also, you want this database to be big enough to store all CDs in existence? Won't that make the database awfully large (to download)? And 1 million (different) CDs? Doesn't seem like that much to me, surely there must be more CDs in the world!
Anyway, good luck with your project!
AccurateRip what?
A system designed to offer true 100% accurate rips from Audio CDs, be a part of AccurateRip and help create it, visit here for full information and download:
http://forum.dbpoweramp.com/showthread.php...p?threadid=1592 (http://forum.dbpoweramp.com/showthread.php?threadid=1592)
- every RIP should create a hash (128 bit) + a random number (16...32 bit) + RMS value (16 bit)
which gives a 160...176 bit number
- every number is used at most once, not more
- generating hashs from WAV files should be possible (WAV, APE, LPAC),
some people have hundreds of CD-DAs losslessly encoded on HD
- error propability can be computed exactly. This needs some knowledge of math
- note that there are a lot of CDs with identical track lengths, but different PCM
signal.
why not use gracenote to detect cdda tracks?
Why not change the name to AccuRip??? Sounds catchier than AccurateRip.
AccurateRip what?
A system designed to offer true 100% accurate rips from Audio CDs, be a part of AccurateRip and help create it, visit here for full information and download:
http://forum.dbpoweramp.com/showthread.php...p?threadid=1592 (http://forum.dbpoweramp.com/showthread.php?threadid=1592)
- every RIP should create a hash (128 bit) + a random number (16...32 bit) + RMS value (16 bit)
which gives a 160...176 bit number
- every number is used at most once, not more
- generating hashs from WAV files should be possible (WAV, APE, LPAC),
some people have hundreds of CD-DAs losslessly encoded on HD
- error propability can be computed exactly. This needs some knowledge of math
- note that there are a lot of CDs with identical track lengths, but different PCM
signal.
Now this sounds more interesting.
AccurateRip what?
A system designed to offer true 100% accurate rips from Audio CDs, be a part of AccurateRip and help create it, visit here for full information and download:
http://forum.dbpoweramp.com/showthread.php...p?threadid=1592 (http://forum.dbpoweramp.com/showthread.php?threadid=1592)
- every RIP should create a hash (128 bit) + a random number (16...32 bit) + RMS value (16 bit)
which gives a 160...176 bit number
- every number is used at most once, not more
- generating hashs from WAV files should be possible (WAV, APE, LPAC),
some people have hundreds of CD-DAs losslessly encoded on HD
- error propability can be computed exactly. This needs some knowledge of math
- note that there are a lot of CDs with identical track lengths, but different PCM
signal.
Agreed ! This is the way we could get much more confident in audio extraction.
However, we should really stop using md5 (128-bit) because of the collision probabilities, and replace that deprecated hash with sha-1 or tiger.
May I suggest:
1. a 160-bit (or tiger256) hash of the complete PCM signal (all tracks concatenated) => rip precision can be verified,
2. a 160-bit (or tiger256) hash of the exact track lengths, ISRC and all optional info except the audio => album can be easily looked up *before* playing it,
3. a 160-bit (or 256) random number => each rip (even by same person) is unique, and can be identified if needed
4. other info (rms value? others?)
and optionally:
5. a 1024-bit (or 2048) digital RSA signature of all the above, performed using the private key of the ripping person.
[edit]
- just out of curiosity, Frank, your incorporation of the RMS value is for informational purposes only ? good idea I think !
- the inclusion of a properly-designed, hardware cryptographic-level RNG (random nb generator) should be mandatory in every computer, PDA !
have tried about 10 cds on the list, and it only recognized one of them. On that cd, it couldn't get the proper results .
Which stage did it not yield propper results. Did it Configure? ie find the offset of your drive?
1. You are aware that a lot of CDs are reissued (with bonus tracks etc.), and then you have "Digitally Mastered" CDs (as opposed to the originals) ... wouldn't this cause some confusion regarding your CD database?
- note that there are a lot of CDs with identical track lengths, but different PCM
signal.
If in the table of contents on a CD these two different discs appear identical (to 1/75th of a second) then yes they would clash.
2. Also, you want this database to be big enough to store all CDs in existence? Won't that make the database awfully large (to download)? And 1 million (different) CDs? Doesn't seem like that much to me, surely there must be more CDs in the world!
It will move to a system like freedb, being online, but initally it is offline.
Would it be possible to get more information on the ripping process? ie when a re-read of a section is required, or if the reader came across something unreadable? Having nothing kinda weirds me out, being used to the wealth of information that EAC provides.
Edit: *sigh* After testing, it seems that the so-called "AccurateRip" can't even tell me when by CD-rom drive has littered a file with read errors (likely numbering in the hundreds, at least one or two per second for about 240 seconds), let alone get a half-decent rip from that. I recommend you try testing the program with an error-inducing CD, and making it get a half-decent rip from that before making any claims of competing with EAC. dMC is about on CDex level right now, IMO. Probably somewhat lower, as I think CDex gives an error message when it does not read properly.
For your Error CD was the track already listed in the database? this system is nothing without the database being populated, which it is not now.
It is like saying 1 day after CDDB was launched 'this system is useless, it does not contain my disc!'
I can't seem to get AccurateRip configured with my Plextor 40-TS drives. I have tried about 6 of the cd's on the list and it fails after reading the offsets. Do I need to do something else to get this to work or just wait for a future release?
it fails after reading the offsets
The error is that the drive is not Accurate Stream compatible? (even though I think it is).
For your Error CD was the track already listed in the database? this system is nothing without the database being populated, which it is not now.
It is like saying 1 day after CDDB was launched 'this system is useless, it does not contain my disc!'
No. However, no amount of external error correction is going to fix rip problems like that. At very least, the program ought to be able to extract without the database decently and inform the user when local errors occur.
To use the CDDB analogy, most programs that implement it tell you when it isn't available, and most try to make the best of that situation by reading CDPLAYER.INI et cetera.
Wow. Out of that list of CD's, I have 1, maybe 2 CD's. Guess that would make it a good cross-section.
Question I have is, if the CD needs to be in the database to get an accurate rip, and the CD first needs to be ripped to get into the database, isn't this kinda like the chicken & the egg?
Just trying to understand how it works
Take this example - a brand new CD is released 'Britney Spears - Worst Hits'
The very first person to get said CD will rip it and AccurateRip will say it is not in the database, the 2nd person has the first persons rip to go off, and so-on.
BTW If the first person with the CD was to re-rip it, AccurateRip would use his own results from the first rip, although personally I don't think it is a 100% accurate, sort of how EAC does now - you need other people with the same disc.
sorry, but it still seems you're failing to notice that you can and should give an error report of the rip. That requires absolutely no database information of any sort. You just read the CD, so you should have some data on whether or not you read it without errors. Whether or not your ripping results match other peoples' is of no concern yet, and whether or not you're getting 10 zillion read errors off the CD at the moment is of great concern. There's no sense littering your database with bad read results, now is there? If you're simply doing burst reading and relying on everyone else's results of burst reading the same cd to classify your rip as accurate or inaccurate then you need to do a bit of rethinking of the process. You should be able to do a "100% rip as far as my own equipment goes" rip before you worry about a "does my 100% local error free rip match anyone else's 100% local error free rip" rip.
Your proposing a 2nd seperate system (what EAC tries to do).
Lets put it this way, lets look forward 6 months, I rip a CD and at the end of the Rip it says that my rip has matched 5 other peoples indepant rips, then I can sleep soundly at night that it is 100% right.
If on the otherhand it says that 5 other people are telling me that my rip is wrong, I personally would remove the disc apply a restorer to the disc and try again, if it fails again I am going to find that disc from another source (borrow). I really do not think a system that re-reads each sector without knowing what the true correct result is can know if it is accurate, in my testing (of 125 discs) I have had EAC report a disc ripped accurately when clearly it did not (as verified by going out and buying a fresh unscratched CD).
And it does not matter if people submit discs to the database that have 10 zillion scratches, the system is mathamatically immune to such (as long as there are a resonable amount of submits from other people, ie more than 1).
Your proposing a 2nd seperate system (what EAC tries to do).
Still, adding a decent ripping method (something more advanced then burst mode, cdparanoia maybe?) would be a good thing. That would minimize the amount of bad rips submited.
but it should also take into account the fact that perhaps nobody else has that CD, or at the very least it hasn't been submitted to the database. You are happy with a burst mode rip, fine. "AccurateRip" doesn't seem to be a very descriptive name of the product in that case, since you're not doing anything at all to ensure that the *rip* is accurate as it is ripping. You're simply doing a check afterwards in hopes that the drive's burst mode is capable of giving correct results on the very first try. I keep saying burst mode, which may not be correct at all, but you haven't corrected me. Does it simply read in burst mode? Or do you at least have it read in some simple sync mode?
You are using very EAC specific terms, but dMC can do both, to answer your question I (myself) read in 'burst mode', for Accurate Stream drives that is the best, no point in doing synchronization.
When a scratch can return the same data for two reads is there a point in re-reading? I feel EAC has lead alot of people into a false sense of security, in many ways it operates from the oppersite direction, let me explain:
If AccurateRip says a disc is 100% then it will be 100%, if it is not in the database then AccurateRip cannot function on that Rip (yet, wait for the database to be populated) so you do not know if the Rip is accurate.
If EAC says a disc is 100% then there is that nagging chance the error returned the same data twice in its 'secure' mode, if EAC says a disc is 98% you can be sure the disc has errors.
Now imagine a system that combines both....right now I am trying my best to develop and put everything together for a new concept that has never been tried.
so what you're saying is that simply because a drive has the Accurate Stream feature it means that it reads 100% correctly? um, ok.
<edit> added 'it means'
If EAC says a disc is 100% then there is that nagging chance the error returned the same data twice in its 'secure' mode
Use Test&Copy
"Then there is that nagging chance the error returned the same data three times"
Honestly, your project is very nice
But it doesn't do much more than saying 'yes your rip is accurate' or 'no it is not' (right?)
It would allow ripping in a fast mode, and verify the result.
Note: it is important that a CD has been ripped by several people who all find the same hash (sum) before letting the database say 'only this hash is correct'
Your proposing a 2nd seperate system (what EAC tries to do).
Still, adding a decent ripping method (something more advanced then burst mode, cdparanoia maybe?) would be a good thing. That would minimize the amount of bad rips submited.
Remember that those rips will all return different hashes, so no real danger.
don't get me wrong, I think the idea of having a database of others' results to verify your own is a great idea, and I appreciate the effort. I'm only questioning the reading method. To try and illustrate my point a little better, consider that drives say that they can report C2 information too, but does that mean they report that correctly? It seems to me that you'll get a much better, bigger, and more reliable database of information, and get better results quicker, if you didn't use burst mode and rely on Accurate Stream to ensure data quality.
Remember that those rips will all return different hashes, so no real danger.
Don't you think it would help this effort to have less of these garbage rips though? Seems to me it would progress quicker and give much more reliable results to compare to if we weren't all ripping in such a hazardous fashion.
If EAC says a disc is 100% then there is that nagging chance the error returned the same data twice in its 'secure' mode
This should only be true if you have the incorrect cache settings in EAC. There is a box labeled 'drive caches audio data' in EAC. If your drive caches audio data, you put a checkmark beside this box to avoid EAC incorrectly pulling the same read error twice in a row. If your drive does not cache audio data, you can remove the checkmark.
If EAC says a disc is 98% you can be sure the disc has errors.
Yes, but the percentage level simply refers to the % of samples that were read without errors. If your settings are correct, the other 2% of samples were error corrected (read again by EAC) and the rip is perfect.
With the proper settings in EAC, the only time you have to worry is when you see 'read error' or 'synch error' after extraction.
This should only be true if you have the incorrect cache settings in EAC. There is a box labeled 'drive caches audio data' in EAC.
Nah, I have seen it myself on two seperate drives that do not cache data (I know). Think about it, why should a scratch always give out different bad results? they can easily be the same.
(http://pageperso.aol.fr/lyonpio2001/smileys/delth.jpg)
It has been reported several times already that the rip could be incorrect even with cache on, even with no errors occured (because CRC mismatch). It has even be reported twice
that with CRC matching, the rip could be wrong (BobHere and Defsiam).
I don't know if a secure mode, that may be very difficult to code, would improve the accuracy of rips very much. We have not enough data about this. Maybe most of burst mode rips are already correct.
On the other hand, CDParanoia, for example, doesn't work on my computer : it doesn't detect errors (see http://www.hydrogenaudio.org/forums/index....=ST&f=20&t=3164 (http://www.hydrogenaudio.org/forums/index.php?act=ST&f=20&t=3164) ) .
But one thing is sure, a secure mode would attract users, who otherwise would not care about suffering unsecure extractions now, hoping that in the future, they will benefit from secure ones.
The easiest to do would be a test and copy mode : it would return if errors occured.
Edit : added "maybe most of burst mode rips are already correct"
Edit : added "on the other hand"
Edit : removed "even 100% quality" (not sure to have already see this mentionned)
i did 2 cd rips test mode, went back to options offset was still at zero, any way to change if i know the offset??? tdk velo 12/10/32a, eac listing showed it as a plextor with+99 offset. il try more cd's tonite when i get home
Now imagine a system that combines both....right now I am trying my best to develop and put everything together for a new concept that has never been tried.
This is a good idea but only works better than EAC by itself once you reach a critical mass of users so that there are multiple samples for CDs outside of the top 1,000.
And if you start off with even slightly less robust ripping than EAC then I would choose EAC instead because it would give me the best rip I can get without borrowing or replacing problem CDs. Many of the CDs in my collection are imported, out of print, and / or obscure, so borrowing and replacing are not possible.
It's too bad EAC isn't open source, then you could "piggyback" your good idea on top of an existing good ripper (and user base) instead of having to build your own.
Which stage did it not yield propper results. Did it Configure? ie find the offset of your drive?
Sorry for the late reply. I have been away for a while. I don't know if these are identical versions to the cds that you have in the database, (pressing, later release, etc.) but out of the cds that I had, only one was automatically recognized by your program. Unfortunately, the disc isn't in very good shape, so I couldn't get identical results. Because of this, I am unable to setup your program to use accuraterip.
Jordan
I publically state that AccurateRip will never be sold off, or charged for. It might even make it onto other Rippers (totally free and open), but that is a little too early just yet.
Integration into EAC would be ideal (most-used audio extractor. EAC offers fast/burst read modes and secure modes. People could do a fast DAE with C2 enabled etc, and check with the accuraterip database afterwards - and switch to a more secure mode if necessary)
I hope we are not going too fast?
EDIT: I'd like to comment on the AccurateRip idea itself:
many ppl will be glad to finally find their offset
but the current software (EAC) is so good that you can know 'for sure' whether the rip is perfect or not. (not 100% for sure, but with a accuracy comparable to the AccurateRip database).
Just get the most out of EAC (not in the least the CRC comparison) and the results will be satisfying
The real weak point of EAC is DAE for DCs in bad condition. Read/Sync errors... It tells you the extraction was bad, but you cannot recover data correctly and there's nothing to do about it.
Sorry for the late reply. I have been away for a while. I don't know if these are identical versions to the cds that you have in the database, (pressing, later release, etc.) but out of the cds that I had, only one was automatically recognized by your program. Unfortunately, the disc isn't in very good shape, so I couldn't get identical results. Because of this, I am unable to setup your program to use accuraterip.
As soon as someone adds an addition to the database, I will release Test #2 - this will write log files to the disc so I can get a good feel for what is happening. Few days or a week at most.
most-used audio extractor. EAC
Perhaps around these parts, but looking at freedb it is used as much as dBpowerAMP, CDex is the clear winner:
http://freedb.org/freedb_stats.php?type=we...y&topic=clients (http://freedb.org/freedb_stats.php?type=weekly&topic=clients)
Even with dBpowerAMP alone I think the database will populate quickly (200,000 discs ripped each week).
i did 2 cd rips test mode, went back to options offset was still at zero, any way to change if i know the offset??? tdk velo 12/10/32a, eac listing showed it as a plextor with+99 offset. il try more cd's tonite when i get home
If it recognised a CD a message would appear offering to find the offsets, after which the title of Audio CD Input will no long say [AccurateRip Unconfigured]
most-used audio extractor. EAC
Perhaps around these parts, but looking at freedb it is used as much as dBpowerAMP, CDex is the clear winner (...)
Yes, of course. But let's be honest:
People who are so perfectionist that copying every single byte correctly is essential to them, well those people don't have any choice: for perfectionists EAC is the way to go (although there is other good software as well, spoon )
-EDIT1-
the reason I am not mentioning Plextools is because not everyone has a Plextor drive
-EDIT2-
to Pio's reaction on cmyden's post
I'm not sure where to post bugs, but I guess this is as good as any...
When determining my drive offset, ARip gives me a +582, where EAC and the Coaster Factory both give me +594. This was using The Cardigans - "Gran Turismo". I also have an Alanis Morissette - "Jagged Little Pill", but ARip didn't recognize it (maybe because it's a German/European version).
We can look into this one:
1, put your dMC calculated offset into EAC (sample one I think it takes).
Next Rip track 1 'The Cardigans - Gran Turismo' to wave 16bit 44.1KHz Stereo.
2, Convert that Wave file in dBpowerAMP Music Converter to a wave file (Right Click on it >> Convert To >> Wave - press CD Quality button) - EAC writes wave headers different to dMC,
3, Run this CRC calculation program, point it at your converted wave file and write
down the CRC number:
http://www.dbpoweramp.com/bin/Crc32.exe (http://www.dbpoweramp.com/bin/Crc32.exe)
40KB - will run from web
4, Rip same track 1 with dBpowerAMP Music Converter - Rip to Wave 16bit 44.1KHz Stereo
5, Run the CRC again write down the CRC number.
6, Tell me the CRC numbers.
I have that disc so I will rip track 1 with dMC AccurateRip, EAC and Plextools. We will find out which is the correct offset...
BTW Alanis Morissette - "Jagged Little Pill" is a protected CD with the TOC messed up, diffrent drives will read different disc lengths.
edit - I was wrong, was thinking of Nat Ibrullia - White lillies island.
Are you sure "Pill" is a protected CD? That was back in 1995, before Napster, MP3 proliferation and the RIAA turning into an evil monster...
Anyway, CRC values are:
EAC - 6F9EE721
DBM - 09029A97
...but I think there isn't much one can do with these numbers after all the converting. AND EAC gave me 99.9 in stead of 100% quality, though Test and Copy CRCs were the same.
And whats this about DBM writing different WAV headers than EAC? In what way?
Ah, and I have a LiteOn LTD-163 (without caching).
hehe i guess i should have read the post on the db forum a little more closer , i dont have any of those cd's lol, guess im the only one who likes metal-hard rock around here lol
The plot thickens...I ripped the first track.
ARip gives me a +582, where EAC and the Coaster Factory both give me +594
I am going out on a limb and saying that EAC and Coaster Factory are wrong on the offset, here is my reasoning.
I have a plextor 161040a, an I am 100% sure that the offset is +99 on my drive (dMC EAC and Plextools says it is). I rip that track 1 on my Plextor and the CRC 6F9EE721, same as EAC with +582, so as far as I am concerned the offset is +582, it is a shame that that track has scratches, can you do the same for track 2, or 3 until you get one with no errors and give me CRC results from the small CRC program (I want to see dMC rip right as well).
From SatCPs page Lite-On DVD 16/48 (LTD-163) VGH4N/GH4S Yes (2) No (2) Yes (2) MMC1 (2) +594 (2) two people with EAC have said 594.
BTW EAC writes an WAVEFORMAT header, dMC WAVEFORMATEX (needed for compressed wave files), it is only 2 bytes different.
One last thing, set EAC to +594 and rip track 1 and calculate the CRC please.
It is possible to get a variable offset. Test your drive with Feurio.
Also, it is possible that reading with subchannels changes the offset. It was reported once, but Andre said it was possible for burning only, not reading.
to Pio's reaction on cmyden's post
It was not just CMyden's post, but also all the rambling about the lack of instant secure mode.
By the way, this offset thing is strange. When I detected the true offset of my old drives, I found 12 samples more than SatCPs : http://pageperso.aol.fr/Lyonpio2001/offset.htm (http://pageperso.aol.fr/Lyonpio2001/offset.htm) (Yamaha 6416S, found : read from +179 to +185, write -1 ; SatCps reports for the 4416 and 8416 : read from +169 to +171, write from +9 to +13).
Remember that +12 on the read offset is -12 on the write offset.
spoon:
Your project is great, it's a cool idea. Even better if it works, which seems to be the case. But... FYI... although I will try it out, there's no way I'll use DMC as my main ripping app because of the lack of external encoder support in the free version (I bet many other people think the same - most MPC users on this board I guess, for instance). If the free version had external encoder support, the database would fill up far more rapidly which would make it more useful for all users of DMC, and would ensure that the word gets spread about AccurateRip.
No, I'm not a beggar , just stating my thoughts.
CU
Dominic
I have been pondering such for a few weeks, it is a shame that the Power Pack is needed for codecs I do not have the time, or am able to write, I will compromise - the Generic Output CLI codec will go free as of 30 minutes from now. The others will follow suit in no more than 4 months.
Thats a good thing you do Spoon, it must be hard and a bit frustrating coding these applications for no financial gain,good on you.
edit: typo's caused by beer
Talking of drive offsets, I have got a guy with a PlexWriter 12/10/32A who has a verifiable offset of -481 samples (-1924 bytes). Although I am still investigating it (perfectionist )
Update:
Now results are coming back one hiccup was found - that is one disc entered the database ripped with the wrong offset, I am still unsure why it happened, I suspect a CD drive threw a wobbler and was 1/4 of a CD sector out (it had ripped 100's correctly). Anyhow, such an entry could polute the database if others found their offsets of this disc. So the rules of the system have been changed to only recognise discs for offset detection with a Confidence of two or more. What this means is, the database will take longer to populate, so I am going to help it out a little.
Anyone who has more than 100 discs to add to accuraterip, I am willing to send out a CD (I have plenty of classical CDs I don't want), email me dbpoweramp@dbpoweramp.com
what about if we have a drive with very well-known offsets? Like the Liteon 24102B 24x burner with a +12 read offset in EAC? Are we able to just manually set the offset in dbpoweramp and start populating the database? Or will it only populate from drives it calibrates itself?
Part of the test is to make sure the correct offset is found, that is half the battle of this system, so the more tests of that the better. If you have more than 100 discs I will send a CD on.