Hi Jason, On 2006.06.16, at 6:05 PM, Jason Stubbs wrote:
Very interesting article. However, I still don't see how ripped audio might change on each ripping.
CD audio data was designed to be constantly streamed. Read into a FIFO buffer, which in turn is read from a DAC with quartz precision. The disc spinning speed does not need to be constantly accurate since the FIFO employs low and high watermarks. This causes the disc to be constantly sped up and slowed down with the result being a duty cycle of slower and faster spinning which averages out to the correct spin speed. This is to keep data in the FIFO, but never completely filled or allowed to empty.
Without the FIFO, this would not be acceptable since the sound would speed up and slow down and pitch would suffer. As a result CD's would need to spin very accurately and this would be a lot harder and more expensive to do and not be able to match the accuracy allowed with a FIFO. These particular FIFO's can be written to, read from and provide watermark signals independently at differing speeds, without either blocking any other.
This constant streaming design is perfect for what CD audio was designed for: to play audio CD's in audio CD players. ; )
CD audio data was not designed to allow stopping and starting with the expectation that the data will marry bit perfect without any redundancy or loss. When you press pause/play on a CD player, it is unlikely that you are going to notice a small portion of data loss or a small portion of music which already played, so the limited addressing (not block perfect) is acceptable in the intended application. However, if you could capture each portion and then play them one after the other without the pause, you are likely to notice a stutter (redundancy occurs) and/or a click/pop (redundancy or loss occurs).
Since computers like to work in portions, ripping audio from a CD can cause the requests to start and stop, instead of constantly stream. But the format is not designed to gracefully handle that. This can cause errors (repeated data or lost data) which differ with each rip, due to conditions not necessarily being the same each time (and of course a single bit error will cause a different hash).
This is why CD paranoia exists. CD paranoia reads back a little with each new portion of the stream read and then tries to find where the overlapping data at the end of the previous stream matches the beginning of the new stream. It then joins them so that there should hopefully be no repeated or lost data, discarding the redundant data in the process. The use of CD paranoia will increase the chances of getting the same hash from a rip, but it can only do the best with what it is given from the drive under variable conditions.
Also, CD audio data has weaker error detection/correction than CDROM data, so marginal reads have a greater chance of giving differing results. Combine the random nature of noise with marginal data and weak error detection and that noise can colour the output in an unpredictable fashion which is not constantly repeatable.
It would not surprise me if you could get exact same hashes on subsequent rips, but it also would not surprise me if you did not.
Shane
