I've been building up my collection of online music for the home LAN, grabbing stacks of CDs from the shelves and converting them to Oggs. (This is an ongoing project of mine that became a special mini-marathon effort what with the approach of the holidays, the multi-disc changer now in storage, and the family's hankering for me to play holiday music.) To speed the process up, I've been tinkering with some of the cdda2wav options in an effort to match the software to the hardware using suggestions in the cdda2wav(1) manpage.

Before my tuning efforts, I was setting "speed=0" on the cdda2wav command line and that works well for many CDs. I interpreted the man page information as saying 0=full speed which, for my Lite-On ("iHAS324") drive is 48x when reading CDs. At times, though, I was getting messages about minor errors with some of the reads (0.1%, 0.2%, 0.3% of the reads) even for discs that had zero scratches, fingerprints, and any other visible flaws. The cdda2wav(1) page mentions that for "maximum extraction quality" that users should keep speed no higher than 8. Generating WAV files was noticeably slower at this speed (no big surprise there), but still usually just taking a few minutes.

To try and speed things up, I then tried configuring the readahead to be a better match to the drive's buffer. In the case of the Lite-On, that's 2MB which, according to the manpage, tells me that I should be using a value of "450" for each megabyte of buffer or "900". WAV creation time jumped a whopping amount: 24 minutes! Zero read errors but at a huge decrease in throughput.

Setting the drive speed back to "0" but still using the expanded readahead, got it back down to a tad over 6 minutes to read ~75 minutes of content which is better but will likely bring back some of those read errors on some discs.

Q1: Any tips on methods to speed up this read process?

Q2: Is cdda2wav really using the larger readahead setting? When starting the read, I see:
which is exactly the same startup information I get when I omit the "-paraopts=..." switch. Passing arguments to increase libparanoia's readahead buffering doesn't seem to be affecting anything. Or... does that buffer memory message in the program startup have nothing to do with the libparanoia's buffering?

Q3: Is using the "-paranoia" switch the culprit here? If so, I suspect there's an entirely different method of tuning cdd2wav for good performance when not using the "-paranoia" switch, right?

Any tips are welcomed.

TIA...

Use multiple optical drives and multiple computers. This task can be parallelized.

I don't recall using any special options when I extracted my audio CDs years ago. I do remember having to extract them twice due to a (then-expensive) 200GB hard drive failing.
Ed

Limited desk space prohibits that. As would the missus.

Ouch! That's why I've been stashing the files on a networked RAID device and backing that up daily. Even parallelized, I surely don't want to do this again. It's taken a long time to get where I am and have a lot more to go -- it's a fairly large CD collection -- and any time savings is a real boon. (I've got a similar-sized collection of LPs that I want to run through Audacity and I see absolutely no way to automate that process.)

(At first I read that as a 200MB hard disk and thought: "Wow! You did this a lo-o-ong time ago". The last time I used drives in the megabyte range on a PC was on a '486. :^D )

The generic settings work OK for the most part but the messages about problems encountered while extracting the WAVs make me wonder if I'm going to be re-extracting some of them when, upon playback, those errors turned out to be not so minor after all.

I reworked my script to, initially, run 'cdda2wav' at full speed, scraping its screen output, and producing an exception list of tracks that have to re-extracted at slow speed, dropping the speed to 1/3 of the previous pass on each following pass. I was a bit surprised to find that, during testing, there were a few tracks that weren't even successfully extracted at "-speed 1". At that point I started tinkering with the readahead buffering. The formula in the the cdda2wav manpage that I was using (450 x number of MB in drive) wasn't enough. I wound up doubling it. Those two changes seem they'll work. We'll see.

I thought all LQ'ers were surrounded by old Linux boxes.

I also have a large LP collection. After careful consideration and some testing, I concluded that music on LPs is best kept in analog form. Part of the appeal of LPs is putting them on the turntable.
Ed