sound-juicer should expose paranoia option

Bug #941670 reported by Phillip Susi
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Sound Juicer
New
Wishlist
sound-juicer (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

sound-juicer reads the disc in paranoia mode by default, causing ripping speed to be VERY slow ( on the order of 2x ). It has a "paranoia" gconf setting you can change to zero to disable this behavior and extract at full speed. This setting should be exposed in the preferences dialog so users can easily find it.

Related branches

Phillip Susi (psusi)
Changed in sound-juicer (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Changed in sound-juicer:
importance: Unknown → Medium
status: Unknown → New
Changed in sound-juicer:
importance: Medium → Wishlist
Revision history for this message
dukat (dukat) wrote :

This does not make any sense for a beginner's program. An option to trade in ripping accuracy for speed is something that a regular user should even have to consider. I vote against adding this option.

Revision history for this message
Phillip Susi (psusi) wrote :

In a perfect world, they would not have to consider it. Unfortunately, the world is not perfect. Users who buy a 52x drive are rightly confused when it apparently can only rip at 2x. This is not really acceptable if there is any way around it. You could disable paranoia by default, but then you could be left with users of older/bad drives getting poor quality rips, which again is not acceptable.

Users are not so stupid that they are frightened by options. Most can be happy never noticing it, but those that do wonder why their ripping experience is bad will take a closer look and find an option that can help them.

Revision history for this message
Jan Claeys (janc) wrote :

@Phillip: using paranoia should only slow it down to half speed or so as it reads everything (at least) twice, which would still be 25× standard audio CD speed.

Revision history for this message
Phillip Susi (psusi) wrote :

It slows it down much more than by a factor of two because it only reads short 64k bursts, then seeks back to re-read. While transfer rates have improved significantly on drives, seek times have not, so all that seeking kills the performance.

Revision history for this message
Iain Lane (laney) wrote :

Thanks; I'm reluctant to upload this without upstream's approval but I've subscribed to upstream and this bug now so when it comes I'll upload to Ubuntu.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.