6 ms·

> some people buy mats to put onto your CDs before putting the CD in a player An 80-minute, 700 MB CD-R fits 80 * 60 * 44100 * 2 * 2 / 2^20 ~= 807 MB of audio.

by Wicher 12y ago

> some people buy mats to put onto your CDs before putting the CD in a player An 80-minute, 700 MB CD-R fits 80 * 60 * 44100 * 2 * 2 / 2^20 ~= 807 MB of audio. Why is that? The 100MB difference is not just due to the audio TOC being of smaller size than the ISO9660 or UDF file system metadata. It's also because of differences in error correction. I don't have the spec on hand but I recall from when I was investigating this that CD-ROMs use more bits for error correction than audio CDs. That's why you can fit more audio data than "filesystem data" on a CD-R. Reading (ripping, digitally) an audio CD will likely result in different digital audio files every time, since the error correction is not that good, but good enough, for audio. I read into this when I was wondering why my CD-DA extracted .wavs came out with a different checksum every time. 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. CD-ROMs however, which store digital data, need better correction - you definately don't want a bitflip in your .exe, while a minor amplitude diff — an uncorrected bitflip in the upper bits of a 16-bit PCM signal — is no biggie. So… I'm not saying that the people using CD mats are informed (or have tested whether the mat makes a difference, or would even know how to go on about testing this, scientifically), but there's more to it than what I originally thought — which was "it's digital so it's never degraded". I wouldn't have known without checking the md5sum of my .wav, though.

aidenn0 12y ago
On a decent drive, cdparanoia should successfully rip with no errors on a clean disc. I have done the md5sum test before.
- Wicher 12y ago
  Background here: http://www.xiph.org/paranoia/faq.html#play http://www.xiph.org/paranoia/faq.html#play
  - X-Istence 12y ago
    "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 ...
  - makomk 12y ago
    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.
gumby 12y ago
> 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.
- vegedor 12y ago
  > 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. Well, the isochronous stream is picked up by an analogue transducer, isn't it? > 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. Well, at least you allow some doubt. With extreme warping, e.g. hitting the player slightly, you could easily bring the playback to a stop. Now, I don't know how weak a vibration we are talking, nevertheless it's clear the ECC in Audio-CDs is weak (e.g. ignoring the byte of lower significance? I did read about this somewhere, also related to an HN comment), but you barely addressed that.
- mark-r 12y ago
  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.
- Wicher 12y ago
  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 https://en.wikipedia.org/wiki/CD-ROM#CD-ROM_format .
Lazlo_Nibble 12y ago
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.
- Stratoscope 12y ago
  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?
  - jboggan 12y ago
    We've discovered digital homeopathy.
    - oaktowner 12y ago
      Funniest reply I've read all day.
  - psychometry 12y ago
    Flawless satire.
    - hueving 12y ago
crazy1van 12y ago
> 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"....
- Wicher 12y ago
  I did check by diffing the RIFF headers. Here's some info on the metadata: https://ccrma.stanford.edu/courses/422/projects/WaveFormat/ https://ccrma.stanford.edu/courses/422/projects/WaveFormat/ . There's little to no room for variance.
  - aidenn0 12y ago
    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).
lobster_johnson 12y ago
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.

by Wicher 12y ago

aidenn0 12y ago

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

Wicher 12y ago
Background here: http://www.xiph.org/paranoia/faq.html#play http://www.xiph.org/paranoia/faq.html#play
- X-Istence 12y ago
  "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 ...
- makomk 12y ago
  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.

gumby 12y ago

> 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.

vegedor 12y ago
> 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. Well, the isochronous stream is picked up by an analogue transducer, isn't it? > 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. Well, at least you allow some doubt. With extreme warping, e.g. hitting the player slightly, you could easily bring the playback to a stop. Now, I don't know how weak a vibration we are talking, nevertheless it's clear the ECC in Audio-CDs is weak (e.g. ignoring the byte of lower significance? I did read about this somewhere, also related to an HN comment), but you barely addressed that.
mark-r 12y ago
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.
Wicher 12y ago
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 https://en.wikipedia.org/wiki/CD-ROM#CD-ROM_format .

Lazlo_Nibble 12y ago

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.

Stratoscope 12y ago
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?
- jboggan 12y ago
  We've discovered digital homeopathy.
  - oaktowner 12y ago
    Funniest reply I've read all day.
- psychometry 12y ago
  Flawless satire.
  - hueving 12y ago

crazy1van 12y ago

> 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"....

Wicher 12y ago
I did check by diffing the RIFF headers. Here's some info on the metadata: https://ccrma.stanford.edu/courses/422/projects/WaveFormat/ https://ccrma.stanford.edu/courses/422/projects/WaveFormat/ . There's little to no room for variance.
- aidenn0 12y ago
  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).

lobster_johnson 12y ago

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.