Deleted, please remove.
2 Likes
Good to know. Iāve noticed few failed individual tracks with my Zen Mini.
Did you use some software to check the entire library?
Which begs the question of whether the re-ripped tracks sound any different to their predecessorsā¦
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.
can accurate rip be used to check naim rips?
But has the sound improved for those cd ripped again?
Deleted, please remove.
1 Like
Deleted, please remove.
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.
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.
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
Deleted, please remove.
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
Indeed itās not like us guys go to any trouble at all to ensure bit perfect playback.
.sjb
1 Like
Perhaps errors are only evident if one uses expensive ethernet cabling, or specific models of switch.
2 Likes
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
Deleted, please remove.
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.
Deleted, please remove.
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.