Innous Ripping - Beware

Streaming Audio
#1

Just a heads-up to Innuos ripper users.

After a ripping session, I decided to back up all my albums to an external HD. I thought this would be a good opportunity to check all my rips against the AccurateRip database. and to my horror, 10 albums out of 150 did not pass as accurate.

Worryingly, no errors were reported by the Innuos software; they all appeared to be ripped OK.

I deleted the bad albums and re-ripped them, and all now pass as accurate.

Any users of Innuos rippers, or any hardware ripper in fact would be well advised to check their rips, as you may have some duff tracks and not know it.

2 Likes
#2

Good to know. I’ve noticed few failed individual tracks with my Zen Mini.

Did you use some software to check the entire library?

#3

Which begs the question of whether the re-ripped tracks sound any different to their predecessors…

#4

I wonder how serious these ripping errors are.

When I ripped my CD collection, about 400/500 at the time, to my then new Core in 2019, I got about 13 ‘ripping errors’ according to the Naim app. Mostly one per CD but a couple with two or three on the same CD. I have since played all the effected CDs with no problems at all & could hear nothing wrong at all with the tracks supposedly containing the ripping errors. Therefore I have left well alone based on the ‘doesn’t appear anything to be wrong so don’t try & fix it’ maxim.

#5

can accurate rip be used to check naim rips?

#6

But has the sound improved for those cd ripped again?

#7

slither I used AccurateRip part of PerfectTUNES:-

https://www.dbpoweramp.com/perfecttunes.htm

I am sure there are some free products to do the same job.

1 Like
#8

I should have checked that, next time it happens I will.

#9

There are tools which can pass any WAV or FLAC back through AccurateRip. Something like CueTools perhaps.

So you can check any file you have lying about.

#10

Due to years of careless keeping, some of my CDs are in bad condition with lots of scratches and cloudy surfaces, so bad that some are considered “total-loss”

When I bought my Uniti Core and started ripping them into WAVs, some of my ripping result in tracks with some 20s or 30s errors as per Naim app display, so bad that I thought the tracks wouldn’t be playable.

But when I play the CDs with my Uniti Star, most of them sounds fine like nothing’s wrong at all. Although I’m not sure with a more sophisticated system (500s or statement) those errors would still be unnoticeable, but at least on ordinary system they’re still fine.

#11

Not sure what the “beware” is here. I would be shocked if there were no errors and my experience this far is 1,700 rips and the only real errors have been CDs which failed to rip in the first place. The failure rate broadly equates to the stat reported above post rip.

Out of interest I have just taken one of my two portable HD back ups; attached it to our now ancient and rarely home PC; run a check and found 122 errors. I’ve then done the same with the second back up and found… 122 errors. I then played a sample of 10 tracks through the PC and after being satisfied I could hear nothing I took my life in my hands; wiped the Innuos and for the first time ever restored from the first back up. Worked beautifully. Have then played a couple of those tracks through the main system. No issues at all. Have now programmed a play list for Mrs. H. to listen to whilst wrapping presents which consists of all the tracks with errors. She’s 9 tracks in and has literally heard no issue at all.

Easy to get very worked up over these things but I doubt there’s much to be concerned about here.

1 Like
#12

“Beware” because Innuos is making rips with errors and not reporting them to users. I.e. you think you have a good rip and you do not.

#13

Given that the function of the file is to instruct the hardware to produce a given sound, as long as the file sounds as it should, any errors are irrelevant…

2 Likes
#14

Indeed it’s not like us guys go to any trouble at all to ensure bit perfect playback.

.sjb

1 Like
#15

Perhaps errors are only evident if one uses expensive ethernet cabling, or specific models of switch.

:astonished: :laughing:

2 Likes
#16

Once you’ve ripped CDs on any Innuos, go to CD Rip History (Sense 2.0) or Disc Quarantine and any detected problems such as a non ‘bit perfect’ rip or a duplicate library entry will be listed.

The problem with AccurateRip is that the database entries are user contributed and if it doesn’t have the exact same pressing or version as your CD it will report errors. Drive offset can also play a role in error generation and AccurateRip is not calibrated for the Innuos drive.

1 Like
#17

Blackmorec they are not reported as non ‘bit perfect’, but are reported by AccurateRip as non ‘bit perfect’, then you re-rip them and they pass AccurateRip…

#18

Hi Chocky,
Based on many years working with Mass Spectrometer user contributed library data bases, here’s how I believe a database like AccurateRip works:

The assumption is that a non-bit-perfect rip is statistically not reproducible. As soon as AccurateRip gets the exact same bit pattern twice its logic is that it must be perfect. Given the size of a CD rip, this is statistically a valid assumption.

When a new unique rip is searched that is not in the AR data base, its reported as an error. When the exact same rip turns up a second time, it matches the first rip, is treated as accurate and added to the data base, so any subsequent search is labelled as a bit-perfect rip.
The Innuos system doesn’t need AR to confirm a bit perfect copy as it has the original CD to compare the rip against. If the two don’t match, it makes an appropriate entry into CD Rip History or quarantines the file, depending on which version of SW is used.

So here’s the question….if the Innuos ripper is producing non-accurate rips, how come it always gets it right the second time? Following the above logic the second rip is seen as correct because it matches the first rip and not because something about the rip has changed.

Here’s how you can test the above. Instead of deleting the first copy of the Innuos rip, leave it, rip the cd again and if you get a ‘duplicate’ error, it means that the Innuos SW is seeing the exact same rip twice i.e 2 bit perfect rips. If AR initially shows an error but passes the 2nd rip as bit-perfect it means that the AR database has now found a confirmation for the first rip (to which it assigned an error), added it to its data base and assigned a ‘pass’ .

In summary, Innuos compares its rip to the original while AR compares a new rip to the existing, user contributed library.

In a mass spectrometer, users can make their own spectral libraries using standards, or they can search user contributed libraries, produced on a variety of different instruments. The users own standards-based library is ALWAYS most accurate as it goes back to a certified standard and both standard and unknown are analysed on the same instrument. In essence Innuos use the same approach of comparing a rip to the original CD, so by definition the Innuos comparison is going to be more accurate.

#19

I think AccurateRip uses CRC (Cyclic redundancy check) data for each track, the same method I use to identify corrupt data on my hard drives.

#20

This is actually the strength of AccurateRip not a problem. It only takes two people independently ripping a CD with known offset to generate a 100% confidence CRC.

Anyone with even a single bit error in their rip simply won’t match this CRC and so knows they have an error.

AccurateRip does not identify the physical CD.

The AccurateRip database is just a list of unique CD IDs with associated track CRCs.

If you are having problems with a ripper (physical or software) getting confused by original/remaster/reissue pressings of a CD then the problem is the ripper software is poorly implemented or buggy. Each CD should be uniquely identified.

It’s then up to the ripping software to submit the CD ID plus track CRCs against the AccurateRip database. If the ripper incorrectly identifies the source physical CD then of course an “error” will show up as you’re comparing apples and oranges.

AccurateRip v2 includes cross pressing checks where the same CD content have different IDs so these are not an issue if the ripper correctly identifies CD.

AccurateRip provides a mechanism to compare the audio content in a rip independent of drive offset.

Drive offset will only introduce “errors” if the software which calculates and submits the track CRCs does not correctly take offset into account.

All major ripping packages, such as dbPowerAmp, handle offset via the AccurateRip transport database (1200+ physical devices) confirmed by ripping minimum of 3 key (common) CDs and confirming the expected drive offset generates matching track CRCs.

Which CD transport does Innuos use? Do they manufacture their own or use a third party transport? It might well be on the transport offset database under the manufacturer.

If Innuos use AccurateRip to verify rips then they know the offset of the drive and it’s part of the firmware performing checks.

The offset could be found by taking any Innuos ripped FLAC or WAV and running it through one of the tools which perform reverification against AccurateRip. These tools try common offsets or can be given an offset via config/parameter. Either way AccurateRip can be used to check Innuos rips successfully.