Slow CD ripping (Sound Juicer)

Found out package name.

Some more notes: Ripping in MP3/OGG is much slower than WAV or FLAC (2x slower).

wav and flac rip at 2.8x vs ogg at 1.5x, Perhaps the part of the problem is in the encoding phase.

Note that ripping with k3b does no better (a common dependency?). But 3x on a machine that can do 20x is a problem.

I can confirm this problem. I always get 1.5x ripping speed with soundjuicer.

More info:

Yes, DMA is enabled on both the hard drive and CDROM.

Yet more Info:

Processor speed seems to be the bottleneck with Ripping. Some experiments. All Files encoded as OGG.
(forgive me if columns don't line up correct due to different fonts, i have put commas between fields, it may help)

Processor RAM Ripping Speed
Celeron 533mhz, 384mb, 1.5x *
Celeron M 700 mhz, 256mb, 2.5x
P3 933mhz, 384mb, 2.7x *
Sempron 3800+, 2048MB, 11.5x

*These 2 are in fact the same machine, processor changed between tests

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with development version of Ubuntu, Hardy Heron?

Thanks in advance.

Basilio Kublik wrote:
> Thank you for taking the time to report this bug and helping to make
> Ubuntu better. You reported this bug a while ago and there hasn't been
> any activity in it recently. We were wondering is this still an issue
> for you? Can you try with development version of Ubuntu, Hardy Heron?
>
> Thanks in advance.
>
> ** Changed in: gstreamer0.10 (Ubuntu)
> Importance: Undecided => Low
> Assignee: (unassigned) => Basilio Kublik (sourcercito)
> Status: New => Incomplete
>
>

I'm sorry, I can't test it. For a variety of reasons, I've gone back to
Windows.

I can tell you that I think the bottleneck is in the encoding.

Hi Nuno
Could you confirm if this is still an issue under Hardy Heron?

Thanks

I'm not sure if this is related, but I've had the same issues on my machine. I'm using a Gateway Solo 5300 with 512 MB of RAM (the maximum it supports). At one point in time, when this laptop was brand new from the factory, it had Windows ME on it. I used this laptop to rip CDs all the time during that time period. It had only 256 MB of RAM at the time. A CD would take something like five minutes from start to finish, regardless of which ripping program I'd use (Windows Media Player, Winamp, et al).

Now, a CD rip takes between a half hour and an hour. It happened with Sound Juicer under Ubuntu Gutsy, and it's happening with KAudioCreator under Kubuntu Hardy. With KAudioCreator, the ripping and encoding processes are performed separately, so I can see when it's ripping vs. when it's encoding. The ripping process for one 10-minute-long track is somewhere around five minutes. Encoding is just as long.

I've seen a bunch of people on the Internets suggest that it's a DMA issue. Below is the output of the command hdparm -i /dev/scd0. Based on how everything's responding, it seems like there are bottlenecks on both the hardware end of things and the encoding end.

/dev/scd0:

 Model=DV-28E-A , FwRev=1.0A , SerialNo=
 Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
 RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=DualPortCache, BuffSize=512kB, MaxMultSect=0
 (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 *udma2
 AdvancedPM=no
 Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4

 * signifies the current active mode

I almost forgot: If it would help developers to have SSH and/or VNC access to my machine for testing purposes, I'd be more than willing to provide access.

Same problem here. Ripping a cd with ruby-ripper and sound-juicer takes about an hour. However encoding is fast and regular reading shows no problems. E.g.:

~$ sudo hdparm -tT /dev/dvd

/dev/dvd:
 Timing cached reads: 556 MB in 2.00 seconds = 277.78 MB/sec
 Timing buffered disk reads: 10 MB in 3.64 seconds = 2.75 MB/sec

------------------------------------------------------------------------

~$ sudo hdparm -i /dev/dvd

/dev/dvd:

 Model=TSSTcorpCD/DVDW TS-H552U , FwRev=US03 , SerialNo=
 Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
 RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=unknown, BuffSize=0kB, MaxMultSect=0
 (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
 IORDY=yes, tPIO={min:227,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 *udma2
 AdvancedPM=no

------------------------------------------------------------------------

~$ uname -r
2.6.24-17-generic

------------------------------------------------------------------------

What further debugging info do the devs need.. please speak up.

may someone experiencing the issue forward this upstream? For forwarding instructions please have a look to https://wiki.ubuntu.com/Bugs/Upstream/GNOME ; leaving this as incomplete until that, thanks.

Tried searchingGoogle and Fedora bugzilla. The bug doesn't seem to affect anything but Ubuntu. Can someone experiencing the problem please confirm if it's also a problem on other distros? Otherwise why forward it upstream?

I'm experiencing the same issue. However, I didn't have this same problem under Gutsy 32-bit. I'm now running Hardy 64-bit, and have noticed my ripping speeds drop from about 12-14x down to about 5x or so. Here's the hdparm output info:

 Model=TSSTcorp DVD+/-RW TS-L632H , FwRev=D300 , SerialNo=
 Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
 RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=unknown, BuffSize=0kB, MaxMultSect=0
 (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
 IORDY=on/off, tPIO={min:383,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 *udma2
 AdvancedPM=no
 Drive conforms to: unknown:

 * signifies the current active mode

I notice that my processor rarely seems to exceed the 50% mark on either of the two CPUs unless I'm doing something else in another application at the same time. It's not a showstopper but, but it is unfortunate. Thanks for looking into this,

All the best!

As an additional note, it seems to vary quite dramatically depending on the disc. Some discs rip at an almost normal rate, whereas others seem to go much more slowly. Yet some of the discs that rip slowly don't appear to have any damage, etc. Very odd, but there we go!

Since it's been a very long time since any additional info was added to this bug, I'm just checking to see if this is still an issue, and find out what additional work should be done on this bug.

It seems to be largely up to speed for me now on Intrepid 64. However, Rhythmbox is now quite slow. I guess a separate bug should be started for that?

Marking this bug invalid and recommending that CTenorman file a new bug for the Rhythmbox issue