OT: RE: Pulled out an old song..
snip, snip 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. Or you could find a drive with a good implementation of C2 error correction. Reed-Solomon code used for storing raw CD data is almost capable of miracles. 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. Enter EAC (as I said it's Windows only but it allows bit-perfect rips). I'll quote some things from the EAC's website[1]: In secure mode, this program reads every audio sector at least twice. That is one reason why the program is so slow. But by using this technique non-identical sectors are detected. If an error occurs (read or sync error), the program keeps on reading this sector, until eight of 16 retries are identical, but at maximum one, three or five times (according to the error recovery quality) these 16 retries are read. So, in the worst case, bad sectors are read up to 82 times! But this will help the program to obtain best result by comparing all of the retries. If it is not sure that the stream is correct (at least it can be said at approx. 99.5%) the program will tell the user where the (possible) read error occurred. The program also tries to adjust the jitter artefacts that occur on the first block of a track, so that each extraction should be exactly the same. On drives found to have the accurate stream feature, this is guaranteed. And in order to get the same hash on different drive models or even a bit identical CD-R copy of the pressed CD it supports read/write offsets: 'Sample Offset' is another new feature of EAC, it will help to always get the same WAVs compared to a different reader and to prevent generation losses. Nearly all drives can not position the head correctly. That means if the program tells the drive to read block 1 it will probably read data somewhere in block 9998 instead. But this is not visible to the reading program, it won't know if it is really the data it wanted. Usually the head will be set always to a fixed offset before or after the correct read position. So it is possible to detect this offset once and use it for all CDs coming afterwards. [1] http://www.exactaudiocopy.de/
Re: Pulled out an old song..
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
Re: Pulled out an old song..
On Fri, Jun 16, 2006 at 12:01:35PM +0900, Jason Stubbs wrote: Unless the quality of the CD has deterioated, where does the random element come from? http://www.stereophile.com/features/827/ If you start reading about the low-level details of C/DVDs and you don't have a lot of faith in math, you'll be scared to death you ever put data on an optical disc.
Re: Pulled out an old song..
On 16/06/06, Michael Coulter [EMAIL PROTECTED] wrote: On Fri, Jun 16, 2006 at 12:01:35PM +0900, Jason Stubbs wrote: Unless the quality of the CD has deterioated, where does the random element come from? http://www.stereophile.com/features/827/ If you start reading about the low-level details of C/DVDs and you don't have a lot of faith in math, you'll be scared to death you ever put data on an optical disc. Jason, Thank you for the link!
Re: Pulled out an old song..
On 16/06/06, Michael Coulter [EMAIL PROTECTED] wrote: On Fri, Jun 16, 2006 at 12:01:35PM +0900, Jason Stubbs wrote: Unless the quality of the CD has deterioated, where does the random element come from? http://www.stereophile.com/features/827/ If you start reading about the low-level details of C/DVDs and you don't have a lot of faith in math, you'll be scared to death you ever put data on an optical disc. Very interesting article. However, I still don't see how ripped audio might change on each ripping. The article states that E11 and E12 errors are common but that the original data is fully inferrable(sp?) and that E22 errors are usually caused by damage. I can see how audibal changes could occur if CD players use the amplitude obtained from the CD directly without first going fully digital, but otherwise... Anyway, enough idle conjecture. When I get home I'll give it a try myself and then do further research. :) vladas wrote: Jason, Thank you for the link! Thank Michael. ;) -- Jason Stubbs
Re: Pulled out an old song..
On 16/06/06, Jason Stubbs [EMAIL PROTECTED] wrote: On 16/06/06, Michael Coulter [EMAIL PROTECTED] wrote: On Fri, Jun 16, 2006 at 12:01:35PM +0900, Jason Stubbs wrote: Unless the quality of the CD has deterioated, where does the random element come from? http://www.stereophile.com/features/827/ If you start reading about the low-level details of C/DVDs and you don't have a lot of faith in math, you'll be scared to death you ever put data on an optical disc. Very interesting article. However, I still don't see how ripped audio might change on each ripping. The article states that E11 and E12 errors are common but that the original data is fully inferrable(sp?) and that E22 errors are usually caused by damage. I can see how audibal changes could occur if CD players use the amplitude obtained from the CD directly without first going fully digital, but otherwise... Anyway, enough idle conjecture. When I get home I'll give it a try myself and then do further research. :) vladas wrote: Jason, Thank you for the link! Thank Michael. ;) Oh. Sorry: Thank you, Michael. -- Jason Stubbs vladas
Re: Pulled out an old song..
On Behalf Of Jason Stubbs Sent: Friday, June 16, 2006 10:06 AM On 16/06/06, Michael Coulter [EMAIL PROTECTED] wrote: On Fri, Jun 16, 2006 at 12:01:35PM +0900, Jason Stubbs wrote: Unless the quality of the CD has deterioated, where does the random element come from? http://www.stereophile.com/features/827/ If you start reading about the low-level details of C/DVDs and you don't have a lot of faith in math, you'll be scared to death you ever put data on an optical disc. Very interesting article. However, I still don't see how ripped audio might change on each ripping. The article states that E11 and E12 errors are common but that the original data is fully inferrable(sp?) and that E22 errors are usually caused by damage. I can see how audibal changes could occur if CD players use the amplitude obtained from the CD directly without first going fully digital, but otherwise... Anyway, enough idle conjecture. When I get home I'll give it a try myself and then do further research. :) You can get bit identical rips of audio CDs, meaning you can compare the track's CRC, hash or anything else. EAC (www.exactaudiocopy.de) is one solution but it's Windows only. I haven't ripped under OpenBSD so I have no recommendation for it. www.hydrogenaudio.org is my source of authoritative information regarding digital audio. Check it out. Regards, Daniel.
Re: Pulled out an old song..
Peter Philipp wrote: I was just going through my OpenBSD cd's and came across the first cd with a song... Interestingly enough I didn't find an mp3 with it as combined with newer releases. Anyhow can anyone confirm this rmd160 checksum after the song is cdparanoia'd? # rmd160 track02.cdda.wav RMD160 (track02.cdda.wav) = 1053805b53962e22028768516285da1cba5e4454 CD-tracks don't work that way. Rip it again and you'll probably find another checksum. # Han
Re: Pulled out an old song..
Han Boetes wrote: Peter Philipp wrote: I was just going through my OpenBSD cd's and came across the first cd with a song... Interestingly enough I didn't find an mp3 with it as combined with newer releases. Anyhow can anyone confirm this rmd160 checksum after the song is cdparanoia'd? # rmd160 track02.cdda.wav RMD160 (track02.cdda.wav) = 1053805b53962e22028768516285da1cba5e4454 CD-tracks don't work that way. Rip it again and you'll probably find another checksum. Forgive my ignorance but how could CD-tracks not work that way? As far as I understand it, the only difference between a data track and an audio track is that a data track divides a sector into a data portion and a checksum portion whereas an audio track uses the entire sector for data. Unless the quality of the CD has deterioated, where does the random element come from? -- Jason Stubbs
Pulled out an old song..
Hi all, I was just going through my OpenBSD cd's and came across the first cd with a song... Interestingly enough I didn't find an mp3 with it as combined with newer releases. Anyhow can anyone confirm this rmd160 checksum after the song is cdparanoia'd? # rmd160 track02.cdda.wav RMD160 (track02.cdda.wav) = 1053805b53962e22028768516285da1cba5e4454 Thanks OpenBSD; keep up the great work! -peter
