Hacker News Reader

Uh, no. Bit-perfect ripping is trivial and routine, and tools like the AccurateRip DB (which has checksums for around three million different titles you can use to verify the checksums on your own rips) and the CUEtools database (which has recovery records you can use to correct bit errors on your own rips) prove it. I routinely get bit-accurate single-pass high-speed rips--no "paranoid" settings or re-reads--of discs dating back thirty years or more, and so do hundreds of thousands of other people. If you get different checksums on successive rips of the same CD, either the disc is damaged or the drive you're using is failing.

Oh sure, your rips may be perfect at the bit level, but how do you know that they're free of sub-bit quantization that isn't detectable by electronic circuits but can be heard by the human ear?

This sub-bit jitter and interference can travel along with a digital file and sneak right past your ordinary bit-level error detection and correction, no matter how lossless you make it. That's because these errors aren't visible in the bits. They occur at a deeper and more subtle level, in between the bits.

Even if you prove mathematically that two files contain the exact same bits, you can't prove that the human ear won't hear any difference, can you?

We've discovered digital homeopathy.

Funniest reply I've read all day.

The decoder/player doesn't know how to read between the bits.

Same file -> same playback.

If you hear the same sound file twice (or two identical files) and hear something different, you software is broken or you're imagining things.

Ah, well, the human ear is a much more finely tuned instrument than your decoders and players. Think of the feelings you get when you hear the ocean waves, the birds sing, a thunderclap!

Can you turn this into mere "bits"? Of course not!

That's why it is so important to protect against sub-bit quantization errors, and this can only be done with proper interconnects. Ordinary cables allow the bits to travel willy-nilly until they jam up against each other creating a brittle, edgy soundstage. Quality interconnects are tuned, aligned, and harmonically shielded to keep those precious bits - and the all-important spaces between them - in a smooth flow.

And then, we can hear all of the things that make us human.

I'm very glad you stuck with the bit (har har) and didn't resort to just telling him he missed the joke. Well done.

Whooosh.

For a second I was terrified at the thought that you're being serious.

That comment is just perfect.

Flawless satire.

Something about it being on HN also makes you assume a post isn't a joke starting out so I read for a lot longer before I realized what was happening.

That's also between the bits. See?

Thank you so muuuuuuuch for the uncontrollably laugh i'm having now

Interesting. I'll have to check those projects out. I have the same problem as the GP -- I have a script that rips CDs, taking multiple reads until it gets two bit-for-bit identical copies. And just about every time at least one track is silently "corrupted."

(I put the scare quotes on because I haven't actually bothered to check if there is an audible difference. But it does confirm the GP's experience.)

> bit-accurate single-pass high-speed rips

"military-grade encryption"

CD-audio "Red Book" data does have error correction (Cross-Interleaved Reed-Solomon Code). Whether you get a bit-perfect audio rip depends on how much error correction and retrying you do.

I remember experimenting with writing a CD ripping program in the 90s, using Windows APIs, and I found, like you, that I got different data each time. But modern rippers such as EAC does this stuff much better and will for the most part give you bit-perfect rips.

That mat does nothing. And if you read that linked page, you will see that he claims it drastically improves audio quality (bass, etc.), which is pure nonsense.

> Vibration is one of the factors that would make the same audio CD, read with the same CD player, produce different digital signals some of the time or even every time.

Err, no.

That makes sense when you have an analog version of the audio picked up by an analog transducer (i.e. a vinyl record) but makes no sense with an isochronous stream of quantized samples.

I suppose a vibration could cause a small phase shift in when the sample physically appears under the LED, but but since the D->A conversion is clocked by a PLL it is irrelevant.

If you have extreme warping or shaking (e.g fling your discman onto the floor or stick your finger on the disk while it's spinning) then a sample might not appear at all, but that's something different than you are talking about.

I suppose it's theoretically possible that some extreme warping or vibration could cause a bit flip, but that's what the ECC is for.

From Wikipedia (Compact_disc lemma):

"[…] The change in height between pits and lands results in a difference in the way the light is reflected. By measuring the intensity change with a photodiode […]"

I'm no signals expert. Are you saying that there is no quantization in that intensity change measurement?

Regardless of quantization, maybe you're right on vibration not being a major source of errors (I know little about electronics and PLLs).

But then, what are the error sources that made the engineers put an extra 276 bytes of Reed-Solomon error correction per 2352-byte sector on a mode-1 data CD-ROM (vs none on an audio CD, which has just has the frame ECC and nothing extra). See https://en.wikipedia.org/wiki/CD-ROM#CD-ROM_format .

There was a day when the clock going in to the D/A converter could be affected by the bitstream coming off the CD. Those days are long gone I'm sure. Everything is buffered in RAM, overclocked, and digitally processed before it hits the D/A.

On a decent drive, cdparanoia should successfully rip with no errors on a clean disc. I have done the md5sum test before.

Background here:

http://www.xiph.org/paranoia/faq.html#play

"Oh, and virtually no PC on earth has that kind of I/O throughput; a Sun Enterprise server might, but a PC does not. Most don't come within a factor of five, assuming perfect realtime behavior."

Some statements just don't age well ...

It's generally the lack of synchronization and positioning information compared to data CDs that gets you. In particular, on many older drives you can't reliably start the rip at the same place each time, so even if all the corrections and fixups work perfectly and you get a bit-exact rip (which isn't hard) you still won't get the same file twice.

> I read into this when I was wondering why my CD-DA extracted .wavs came out with a different checksum every time.

You sure there isn't something in the wavs like a creation date field that would always cause the checksum to be different? That would make way more sense than "vibration"....

I did check by diffing the RIFF headers. Here's some info on the metadata: https://ccrma.stanford.edu/courses/422/projects/WaveFormat/ . There's little to no room for variance.

FYI the difference is almost certainly due to the seeks not being sample-accurate, so your rips are bit identical for each sample, but you are starting in very slightly different places. Either that or you have a really broken CD-ROM drive (which is also possible).