They could have made a fortune in the 90ies by providing a CD fluid that makes Windows and Office not crash when installed from a treated CD
1 Like
How did you manage to compare the two rips? If you rip the same CD twice on a US, I seem to recall that it replaces the first rip with the second, and you need to do a bit of jiggerypokery to get around this.
Let’s consider two scenarios.
Data is copied from a CD in such a way that there is no error in reading the data, it is read perfectly from the CD.
Would the data be written to a particular single part of the hard drive, which when read would produce only a little electrical noise.
Data is copied from a CD in such a way that there is error in reading the data, and error correction is performed during the rip.
Would the data be written to various parts of the hard drive, which when read would produce more electrical noise.
I always rip to my PC then copy to a NAS, then stream from the NAS. So I wouldn’t have this problem, if it actually exists. 
I think that allowing too much room for hypotheticals, without clear ways of testing and verifying any provided claims, is what leads to Audio Myths being created and perpetuated. Any difference in sound that is large enough to be audible by human ears, should in principle be more than large enough to be verifiable in objective tests. If it isn’t and we are stuck in the magical / unexplained realm, then we risk perpetuating ambiguous truths that in the long run will hurt our collective goal of reaching the best possible sound reproduction using objectively effective tools and methods.
1 Like
Maybe Tobyjug ripped the cds again, after the cleaning, and found they sounded better than before ?
They both came out as unknown. The first had me writing in the metadata. The second rip didn’t transfer to the first but came out as another unknown. As far as I could tell they were both unknowned by the same look up.
Unknowns do pop up every now and again when ripping new discs, this is when I’ll take the opportunity to try this scenario.
So no AccurateRip check, as that only possible if known.
So could rips “authenticated” by different look ups sound like something other than what’s on the disc ?
If so how should I know which is the most accurate ?
Yes the first test would be an md5sum check as @Suedkiez suggested, this would tell if the rips are identical. On a mac you could do this from a terminal window:
md5 [file1.ext]
md5 [file2.ext]
Both should give back the same result (hash).
If there is a difference, it could be interesting to open both files in an audio program to compare the waveforms. An option could be to install a trial version of a paid program like ReSample:
It is beyond me.
I rip on a computer using dBPoweramp, which links with AccurateRip to compare with a database of rips, and if not identical then re-ripping more intensively often achieves it. They have rip data on something like 400 million CDs, and it is rate to find one not in their database.
So are bits just bits then….?
Dives for cover….
2 Likes
However, Toby edited the metadata. If it’s flac rips (where the metadata is embedded in the file), and changes caused by this have to be controlled for.
About the waveform comparisons: It should be noted for the less technically inclined that these programs can typically subtract one waveform from the other. If the two waveforms are identical, the result would be zero
Rovi (which I think the US uses for metadata?) and the AccurateRip DB are different though. AccurateRip saves the CD signatures based on the checksums of the data structure. It has no idea, nor does it need to, which CD title (etc.) it is - the tags in dbPoweramp come from different sources
Yes they are. This does not mean that the way these bits are transmitted to a player (and the effects of this transport) and the way they converted into analog wave forms is always the same.
In the current case however, we have either two 100% identical files (as they would be created by the same ripper on the same hardware if the rip is faultless, which is the technical normality), for which there is no way known to humans to differentiate them, which are played back through the same device.
Or we don’t have two identical files and Toby’s US is producing crap rips
Yes. Maybe. But that’s not helping me understand what’s happening here.
Why would the serve do a crap rip ?
I don’t know exactly the procedures of the US, but a competent ripper really shouldn’t do crap crips without noticing, at least as far as the CD reading goes. An AccurateRip check (or whatever equivalent) should at least catch it if the hardware is broken And I suppose the US is competent.
What goes on after the reading, well errors might be possible. A member on the beta group is currently tracking down an issue where data is missing in the flac files. But it’s difficult to imagine how stuff like this would lead to the SQ differences you describe. In the other member’s case it’s simply dropouts where the data got lost. I would expect any such errors to result in similarly severe issues
The same way nobody knows why Melco D100 ripper gives better sounding rips which are bit perfect as Dbpoweramp rips.
The common thing must be noise. I suspect tools can see all.
We have done this a few times on the forum… more so back in the days of the ripper wars… but from memory we also did when the unitiserve first came out … and every single time time we saw the pcm data of the files from rippers were identical (data chunk) … with two considerations
A) The offset was different on some CD ROMs with iTunes… so the rip was a milliseconds late to start and finish…
B) the wave file produced varied depending on the ripper. It was either the cananocal version or the extendable version… both are valid, and involve the header constructs, and additional information chunks… but the data chunk was identical.
It stands to reason of course, or you would not be able to archive to and from optical media!.. but some people need to see it with their own eyes…
Of course the other point, you can’t just slightly change the audio when ripping… that would involve digital signal processing to modify the PCM such that the encoded audio somehow changed . An actual error sounds like a static tick or a tiny gap of silence.
4 Likes
CDPs definitely interpolate if an read error is unrecoverable and as long as data is sufficient. When ripping in burst mode, ripping software might too, I guess
But not the actual PCM… remember CD has several layers of encoding… and it it uses hamming code to fully recover the data… that is it has low entropy.
If there is an unrecoverable error then some transports will insert silence or interpolate… others provide a static click … you might expect one such error every few discs unless the disc is damaged.
Yes, but there comes a point where despite the encoding the original data is uncorrectable. That’s when it interpolates before it is forced to glitch out if it gets too bad. Was always my understanding at least