cdparanoia is slow

There is an upstream thread on gnome bugzilla that talks about earlier numbers
(the ones in the 4x range) here: http://bugzilla.gnome.org/show_bug.cgi?id=116882

I've now had two other confirms that rip speeds are in the 1.3-1.7x range now,
for some reason. Also, on my main computer the rip takes a very small cpu
percentage.

This is probably a consequence of DMA being disabled on the CD-ROM drive; check
with hdparm.

If so, this is a duplicate of bug #36185

(In reply to comment #2)
> This is probably a consequence of DMA being disabled on the CD-ROM drive; check
> with hdparm.
>
> If so, this is a duplicate of bug #36185

Please see original comment, turning DMA on and off does not make a difference.
 The only thing that has so far is setting the gconf key
apps/sound-juicer/paranoia to 0, but this isn't discoverable and I'm not sure
turning of all paranoia is a wise thing.

Jonathan

I doubt that's a sound-juicer issue, probably a cdparanoia one.

I've a 3.4x speed now with sound-juicer for an ogg encoding. Do you still get
the issue with the current versions ?

(In reply to comment #5)
> I've a 3.4x speed now with sound-juicer for an ogg encoding. Do you still get
> the issue with the current versions ?

Looks like the latest batch of updates definitely brought improvements. My two
computers are now in the 2.6x-3.1x range now, which is certainly better.

Too bad there isn't a slider in sound-juicer for faster<->more accurate, so for
those of us who want to risk it, we can rip faster. I'm not worried, though,
the improvement definitely makes it easier to rip a couple cds.

do you consider that this bug is fixed ?

(In reply to comment #7)
> do you consider that this bug is fixed ?

Sure, let's close it. Ripping in general could use some speeding up, but I'd
consider that more of an enhancement.

I would like to re-open this. Ripping audio CDs appears to be unreasonably slow
on Ubuntu. I have tried on different machines and all seem to have this problem,
with both Warty and Hoary - and since I found this bug report about it I guess
it is normal Ubuntu behaviour that everyone experiences (though I've not been
able to verify this for sure, despite asking on forums, mailing lists and irc
repeatedly). To rip a music CD will take around an hour. I have searched long
and hard for a solution. By playing with paranoia and error checking settings I
got it down to around 15-20mins, on a laptop that would rip a CD in a couple of
minutes under Windows or say, SuSE. the best speed I have seen was arond 9x
using Grip with all error checking turned off.

It's not a SoundJuicer issue, Goobox is just as slow, as is Grip, as is
KAudioCreator. Maybe a cdparanoia issue, or maybe cdparanoia is just a slow
ripper (in which case something else should be used by default).

Anyway it's a serious issue - my windows converts are not impressed when it
takes an hour to rip CDs. They are used to ripping piles of CDs without thinking
about it, because it only takes a minute or two. SoundJuicer and Goobox are such
nice interfaces for ripping, but they're no good if they don't work at a decent
speed.

updating the title. I've no idea if there is something else than cdparanoia to
do this job. What do you use with Suse? How fast does it go?

upstream indicated there were some improvements - did this get any better?

Hi all,
Is there any update on this? I've recently changed my sarge box to a breezy box and encountered this problem. I consider this very much to be a bug. My box (celeron 2.4GHz) used to rip *and* encode CDs at better than 6x speed with sarge. Now I'm lucky if I get 3x rip and 1.5x encode. The 1.5x encode is downright emabrrasing and it seems to be because the CPU/bus is taken up with some sort of system activity.
"top" reveals the following:
Cpu(s): 14.3% us, 4.6% sy, 0.0% ni, 29.7% id, 1.1% wa, 49.7% hi, 0.6% si
Mem: 775536k total, 378572k used, 396964k free, 15344k buffers
Swap: 2040212k total, 0k used, 2040212k free, 221556k cached

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 8185 rwayth 17 0 6352 4880 484 R 6.3 0.6 0:00.42 cdparanoia
 8107 rwayth 16 0 29632 16m 12m S 1.7 2.2 0:02.66 konsole

Note "49.7% hi". I'm guessing this is "hardware interrupts"? So it does not seem to be cdparanoia that is slow, rather something closer to the hardware.

Thank you for your comment randallw. What application were you using on your sarge box? sound-juicer? that would be interesting to compare on both with the same application and settings for it. Is the dma activated for your drive (hdparm -d /dev/hd...)?

This may relate to the improvement bug I raised in #42758 - using the SG-IO interface in the 2.6 kernels can offer massive benefits to cdparanoia in ripping speeds. It requires a patch to cdparanoia developed by Red Hat.

Do you have a link to that patch?

I am also experiencing problems with very slow CD ripping by CDParanoia. What information is needed to fix this bug/issue?

no sure, it's probably requiring somebody have the issue and knowing the code enough to debug it

For me this did indeed turn out to be the DMA problem. You can check/set your CDROM's status using hdparm. If hdparm works for your cdrom, then you can enable DMA permanently by editing the /etc/hdparm.conf file.

The was a note in the breezy documentation about this, but I haven't been able to find anything in the dapper docs.

DMA is already on for my drive.
Thanks though.

On 7/31/06, randallw <email address hidden> wrote:
>
>
> For me this did indeed turn out to be the DMA problem. You can check/set
> your CDROM's status using hdparm. If hdparm works for your cdrom, then you
> can enable DMA permanently by editing the /etc/hdparm.conf file.
>
> The was a note in the breezy documentation about this, but I haven't
> been able to find anything in the dapper docs.
>
> --
> cdparanoia is slow
> https://launchpad.net/bugs/13823
>

the patches mentioned in bug 42758 might solve this issue