3

I'm shocked at how slow Sound Juicer rips audio CD's. My machine is an Intel i7 with 4Gb RAM, so I thought that ripping would take just a couple of minutes. But the program takes it's time and lasts about 20' for each CD.

Is there a way to configure Sound Juicer to make better use of the available hardware?

Is there another program available for faster ripping?

The DVD is a Super Multi DL Drive. I guess it's faster than single speed. No serious errors on the command line after the extraction starts. Before that, gtk errors and glib errors. Running it from the command line is much faster.

Warnings on command line:

(sound-juicer:1285): WARNING **: Widget (GtkEntry) has more than one label 
(sound-juicer:1285): GLib-GObject-WARNING **: invalid cast from GdkX11Window' to GtkWidget' 
(sound-juicer:1285): Gtk-CRITICAL **: gtk_widget_get_display: assertion GTK_IS_WIDGET (widget)' failed 
(sound-juicer:1285): Gdk-CRITICAL **: gdk_cursor_new_for_display: assertion GDK_IS_DISPLAY (display)' failed 
(sound-juicer:1285): Gdk-CRITICAL **: gdk_cursor_unref: assertion `cursor != NULL' failed

I've monitored the system, and the memory use stays below 800Mb, also, the processors stay mostly below 20%.

Now, if a CD has 700Mb max, wouldn't it be possible to read the smallest song (in bytes) into memory, start processing that with one thread, read the next smallest song into memory and spawn the next process, etc?

With 4Gb RAM, and 8 processors, the computer should not have any problem ripping and encoding 4 CD's in memory at the same time. Or should it?

dd: reading `/dev/cdrom': Input/output error
0+0 records in
0+0 records out
0 bytes (0 B) copied, 0.0258942 s, 0.0 kB/s

real    0m12.087s
user    0m0.000s
sys 0m0.004s
Jorge Castro
  • 71,754
GUI Junkie
  • 1,936
  • It also depends on the specs of your cd/dvd drive: if you got a single speed it will take some time ;) Did you try to start soundjuicer from commandline and see if you get any errors in the console? – Rinzwind Feb 23 '12 at 22:09
  • The DVD is a Super Multi DL Drive. I guess it's faster than single speed. No serious errors on the command line after the extraction starts. Before that, gtk errors and glib errors. – GUI Junkie Feb 23 '12 at 23:53
  • @Rinzwind: ** (sound-juicer:1285): WARNING **: Widget (GtkEntry) has more than one label

    (sound-juicer:1285): GLib-GObject-WARNING **: invalid cast from GdkX11Window' toGtkWidget'

    (sound-juicer:1285): Gtk-CRITICAL **: gtk_widget_get_display: assertion `GTK_IS_WIDGET (widget)' failed

    (sound-juicer:1285): Gdk-CRITICAL **: gdk_cursor_new_for_display: assertion `GDK_IS_DISPLAY (display)' failed

    (sound-juicer:1285): Gdk-CRITICAL **: gdk_cursor_unref: assertion `cursor != NULL' failed

     – GUI Junkie Feb 23 '12 at 23:55
  • @Rinzwind, wait, from the command line it was much faster. Can it be? – GUI Junkie Feb 23 '12 at 23:57
  • Those warnings are worth investigating ;) – Rinzwind Feb 24 '12 at 08:06
  • @GUIJunkie - can you expand your question as to the ripping software you have used and discounted? Personally I use asunder which I find very fast and reliable. – fossfreedom Feb 26 '12 at 10:59
  • @fossfreedom, the question is about Sound Juicer. I'll try Asunder and if that works for me, the +50 are yours. – GUI Junkie Feb 26 '12 at 13:49
  • @fossfreedom, I'm trying Asunder now and it's 20' for a CD with 12 songs. I'm not impressed. At first I had gdk-warnings, but with this answer, these went away. Still, the ripping goes slow. I'm ripping to MP3, bye the way. – GUI Junkie Feb 28 '12 at 09:16
  • @GUIJunkie - I'm utterly amazed at the slow speed you are achieving. If you have another computer, can you try sound-juicer and asunder with that computer. Maybe you really have a hardware issue. – fossfreedom Feb 28 '12 at 09:49
  • I use k3b for all my cd/dvd stuff...but I'm patient on speed issues, so I couldn't say it would be any faster. It's just horribly STABLE. Which is key for me. – RobotHumans Feb 28 '12 at 12:23
  • @fossfreedom, on the other computer it ripped a CD in just about 3'. The hardware is far older: Core2 Duo at 2.33Ghz and 2Gb RAM. – GUI Junkie Feb 29 '12 at 00:39
  • @GUIJunkie - that sounds like the correct rip time - if you can - substitute your new computer CD drive with your old computer CD drive - do you get the same fast speed (or faster!)? – fossfreedom Feb 29 '12 at 09:54
  • Let's try your CD drive's speed, shall we? Write the following in your terminal: time dd if=/dev/cdrom of=/tmp/cd.iso -- that creates an ISO of the CD that is in your drive. Report back how long it took in your question. – Lakritsbollar Mar 01 '12 at 19:00
  • @Lakritsbollar, just tried, I'm not sure the results are correct, but I copied them in the question. The cd.iso is 0 bits sized. – GUI Junkie Mar 01 '12 at 20:05

3 Answers3

3

The reason extraction is so slow is because sound juicer uses cdparanoia, which was designed to read the disc multiple times in a very low level mode and perform complex software error correction to work around bugs that many drives commonly had, and any physical scratches on the disc. I think these days most drives manage to do it correctly themselves, and so cdparanoia is no longer really needed. There appears to be an open bug to have sound juicer stop using cdparanoia here:

https://bugzilla.gnome.org/show_bug.cgi?id=313302

It appears that sound-juicer has a gconf setting named paranoia where you can configure the paranoia settings. Open gconf-editor and change the value to 0 and things go MUCH faster.

psusi
  • 37,551
  • Thanks for the info. Is there another program out there that does the job without getting paranoid? – GUI Junkie Feb 24 '12 at 23:39
  • @psusi - that bug report was from 2005 - I dont see any link to cdparanoia in the package lists for sound-juicer in oneiric. – fossfreedom Feb 26 '12 at 10:52
  • @fossfreedom, what do you mean "link to cdparanoia in the package lists"? apt-cache show cdparanoia. It does appear that sound-juicer does not depend on it though. It looks like the functionality was integrated into a gstreamer plugin that sound-juicer uses. – psusi Feb 26 '12 at 16:21
  • 1
    @GUIJunkie, it looks like there is a gconf setting to configure the paranoia behavior. I really wish the gnome developers would get this stupid idea out of their heads that exposing such settings in the preferences dialog of the app is a bad thing. – psusi Feb 26 '12 at 16:22
  • @psusi - yeah, that's why all the custom little bits I use myself install to opt and completely disregard gconf as much as possible... – RobotHumans Feb 28 '12 at 12:22
0

I'd say no, your ripping speed is based on your hardware for the most part. The only thing your software is doing is reading, arranging, and checking the data that the cd/dvd drive is scanning.

PyroSamurai
  • 17
  • As the question states, I have excellent hardware, it should be blazing fast. The whole process shouldn't last more than a couple of minutes, five at most. – GUI Junkie Feb 24 '12 at 08:45
  • -1: obviously good quality hardware should be faster than 2x. – psusi Feb 24 '12 at 19:14
  • The question does not state make and model of the disc drive and I am not going to assume that 1. Just because you have a good processor and ram that everything else is just dandy and 2. That putting "Super" in front of any product's name makes it good hardware. Here is my suggestion. Take the disc drive out and hook it up to another computer and see if you still have the same issue. If you do, the disc drive may be broke or in need of maintenance. – PyroSamurai Dec 26 '12 at 16:18
-2

DVD write speed is a function of the drive and of the actual media. The media write speed for that particular media will be on the packaging, you can't do better than that. The achieved write speed is usually reported by the writing software so you can see if the advertised speed is achieved. Your drive is likely SATA which is capable of speeds faster than your drive can handle.

fragos
  • 3,503
  • Question is about reading, not writing. – psusi Feb 24 '12 at 19:13
  • @PSIU Ripping a CD/DVD is writing and not reading. What I said about writing speed is correct. An I7 processor won't make inherently slow hardware faster. – fragos Feb 24 '12 at 20:48
  • No, ripping means reading ( and typically encoding ). – psusi Feb 24 '12 at 22:56
  • Right you are. My confusion comes from associating ripping with what was always my end result -- a digital CD copy of music. – fragos Feb 25 '12 at 02:11