![]() ![]() Note that the "errors" did not trigger quitting the rip as requested by the -X) (note that the speed command was ignored and the device is /dev/sg1)Ĭdparanoia -v -d /dev/sg1 -w -B -X 9 -S 1 How could I force the reading speed to 1x?Ĭdda2wav -t9+9 -B -D2,0,0 -O wav -S1 -paranoia -I generic_scsi -paraopts=retries=999 Two successive rips do not give identical files (checked with cmp)Īlso, the speed setting command seems to be completely ignored. Unfortunately, it does not say if the error or problem was corrected. During the rip, the smiley was ":-P", which means "Unreported loss of streaming in atomic read operation". On the other hand, if ripping with cdparanoia, I only get some "+" progress indicators, which according to the manual are "Unreported loss of streaming/other error in read". Recording 367.5733 seconds stereo with 16 bits 44100.0 Hz ->'audio'.ġ00% track 9 recorded with medium problems (2.0% problem sectors)ġ00% 0 rderr, 0 skip, 552 atom, 0 edge, 0 drop, 0 dup, 0 driftĭo you know what are these atom errors? I googled and somebody suggested that it was related to copy protection, but it does not sound like it would be the case here. It seems that my drive caches audio, so I'm trying cdda2wav with libparanoia, as suggested above. I'm using a Plextor Px-230A through an external case, so it goes through the SCSI emulation layer. (my dvd burner doesn't cache audio, my cd burner does) I wrote myself a script that just rips the cd twice and md5's them. Make sure your drive doesn't cache audio, it produces incredibly inconsistent results.(cdparanoia just rereads the audio cache several times and thinks it's ok) Cdda2wav with libparanoia is a better choice for drives that cache audio, but on bad cd's it doesn't stop/freeze/give a fatal error. Even if you rip the same track with different drives the md5 sums match when you use offset correction. When I rip one track twice, using the same reader, I get the same md5 sums (in case the cd is not badly scratched). ![]() Not much, if the drive itself is very good, but certainly enough to fail md5 check. This means every time you read it with a CD drive the result is going to be a little different. I hope my burner really has a write offset of 0 and I think maybe the problem is related to the toc reading process of cdrdao that doesn't include offset correction.ĭo you guys know how to do this properly?ĪFAIK the correction used for audio CD's is not absolute. So I just extracted one track on both the original and the copy disc and checked the md5 sums:īut the md5 sums didn't match so the copy isn't exact. Then I wanted to check if the copy is bitperfect. Finally I burned:Ĭdrdao -driver generic-mmc-raw -device ATAPI:0,0,0 project.toc I tried like this:Ĭdrdao read-toc -device ATAPI:0,0,0 project.tocĪfterwards I renamed cdparanoia's cdda.wav to data.wav as the project.toc file uses this filename. So I thought I'd just have to rip the wav to disk with cdparanoia, extract the toc info with cdrdao and burn the results. The drive seems to have a write offset of 0. My drive (dvd-writer) has a read offset which I can correct using the '-O' parameter in cdparanoia. I'm trying to make a perfect copy of an audio cd, but until now I didn't succeed. Posted: Tue 10:35 pm Post subject: Bitperfect CDDA copy? Gentoo Forums :: View topic - Bitperfect CDDA copy?
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |