I looked at AccurateRip a long, long time ago when there was discussion on the Naim HDX and Naims claim on the rip-quality in the white-paper.
First a short word on what is stored on a CD. There are no files not even 1s and 0s. Instead there is a spiral of “pits” and “lands” and for each clock-cycle a transition is a “1” and no transition is a “0”. In order to slow down this for a bit for the encoder/decoder each 8-bit byte is stretched to 14-bits using 8-to-14-modulation (EFM modulator) and … well there is a lot more to it, just to give you an idea of the importance of clocks and the firmware on the drive unit.
There are only 2-3 apps on Windows that actually update the AccurateRip database (no apps for Linux or Mac). And with fewer CDs sold today the AccurateRip database becomes weaker.
They create two (they still cover the first buggy variant) 32-bit checksums with the CRC32 algorithm designed for short datablocks at low level not long music documents with millions of bits. Not a problem, just weakening the service.
There is a unique song-id on every CD - ISRC (you buy these codes when you want to manufacture a CD) - but you can correct the mix/content when you order a new batch of CD:s and still use the same ISRC for the song. So there are never just one (or two in the case of AccurateRip) checksum for each song.
And on top of this you have the offsets on cd-drives and so on.
My guess AccurateRip looks up the ISRC in their database and gets the checksums above a certain number of updates, deal with offsets and stir-it-all-up to calculate some kind of accuracy figure then used to say YES or NO.
All the above is just an extremely long-winded way of saying the answer to the original question is hard to give given the number of layers involved and the closed-box called AccurateRip. It sounds like an initialization error on the Innous side as it gets fixed the second time. Submit an error report to the manufacturer?
Life irony alert. 4 CDs for Christmas. Not ripped anything since October. Innuos starts to rip and stops before it’s completed the first track. A reboot hasn’t fixed it and… it’s six days out of guarantee. Deep joy.
@mikehughescq Quite a few reporting similar issues on the Innuos FB site, seemingly Innuos aware of it and building a fix into next update, I think you can find info on the Innuos site flagged under known issues.
Good luck and Merry Christmas.
Hi IanO,
I agree that when AR says you have a good match, then you have, as your rip matches the stored CRCs.
But the problem isn’t false positives, its false negatives, which is the reason Innuos didn’t use AR in the first place and is very likely the problem we have here.
From an Innuos perspective, at the same time you have a new rip you want to check for accuracy you have the original CD in the drive, so there’d be absolutely no point whatsoever in using a user contributed library when you have the original to compare to.
How can you compare a rip you’ve just completed with errors to the original CD in the drive, which you’ve just read (with errors)?
Do you try again, read the same error and think you’ve got a bit perfect rip (when you haven’t). Because you got the same result as your first rip.
Or do you try again and get a different result, then assume you’ve now ripped without error because it’s been “fixed” (which you might not have).
The whole point is a single device CANNOT know it has read a CD bitstream perfectly.
This is why AccurateRips works. It compares independent rips from different physical devices. The odds of two rips matching on CRC, unless they are both bit perfect, is astronomical as indicated above in the post about statistics.
@dayjay@glasnaim thank you both. One of the few disadvantages of not being on Facebook. Just checked in on the feedback site and there it is. Shifted to automatic mode and we’re in business.
I’m not sure why you’ve pointed me at a Linux library which has documentation which backs up what I said above.
If you read the cdparanoia page:
It is also possible to get different reads if the media is damaged and cdparanoia is unable to deterministically repair the error.
So as I said above,
Thankyou for providing documentary evidence supporting my viewpoint.
@Blackmorec Can you then explain why the OP @Chocky found 10 albums with ripping errors on tracks which failed AccurateRip, but with no errors indicated by his Innuos software?
I’ve used Whipper on Ubuntu which uses this cdparanoia library. However Whipper recognises that cdparanoia cannot guarantee bit perfect reads and so Whipper does post rip verification against -you guessed it- the AccurateRip database.
Hi IainO
We can postulate and hypothesize all we like but a definitive answer would require a copy of the 2 innuos rips and the AccurateRip report….Then you could see what changed and how the changes relate to AR’s findings
CDParanoia is 20 years old now and it really depend on the drive used and if that drive is supported, not only for offsets. Writers of ripping software don’t like it as its demand on quality slows down the ripping process considerably.
As have been told many times CD-mechanisms designed for audio CD:s are hardly made anymore (a problem Naim have as an example). What is used when you rip a CD is a data-mechanism were the redbook-book support is an add-on. Not the main-function. The stream of pits and landing you get from a CD needs to be interpreted to get the actual 1s and 0s. And that stream is full of special cases that many data-mechanisms do not support och simply buggy support…
This problems expanded in the late 90s when people used CDR:s as masters for CD-manufacturing - still with buggy software. And then we have the various attempts at copy protecting CD:s by using redbook-tricks not implemented in most software in data-mechanisms.
Personally I use Pioneer blu-ray writer drives which have very good firmware and not only support secure-mode but can be set to special HighQuality and PureRead+ modes. Unfortunately these drives are more expensive. Make sure they are level and vibration isolated and put a John-Darko-doorstop on top if you want. I also clean the cD:s with a cheap ultrasonic cleaner.
Then just make sure to use a version of XLD that enables the features. And forget AR.
Over the past 4 years I’ve ripped some 3000+ CDs using the Innuos ripping procedure and have had absolutely zero problems. A few CDs with damaged tracks were reported and repaired prior to library entry and any missing meta data like album artwork was very easily restored via the inbuilt internet search or camera download capability.
I did rerip some albums after I found that the Innuos rips sounded superior to the PC based rips I’d done prior to obtaining the Innuos system.
So I really don’t see what the problem is. Each CD takes less than 5 minutes to rip, which includes automatically obtaining all meta data from various on-line data bases and loading into the internal library. The drive is the very reliable TEAC unit and the SW is designed to achieve bit perfect rips by rereading and comparing each segment several times to ensure a perfect match. The ONLY disturbances to listening I’ve ever had were a few very loud ‘cracks’ that nearly gave me a heart attack that I initially thought to be a rip error that turned out to be caused when the 2 litre plastic spring water bottle I had been drinking from suddenly and very loudly regained its shape.