rip fails after Cdparanoia doesn't output wav files while cdparanoia -B 1- finishes succesfully

[GoogleCodeExporter]

1) Please describe the steps to reproduce the situation:
a. Insert any cd.
b. rrip_cli
c. rip entire cd

2) What is the expected output? What do you see instead?
successful rip of the entire cd

3) What version of rubyripper are you using? On what operating system? The
gtk2 of commandline interface?
rrip_cli, 
Rubyripper version 0.6.0., 
Arch linux x64, 
cdparanoia III release 10.3pre (September 16, 2008)

4) Is this not already fixed with the latest & greatest code? See for
instructions the Source tab above.
In trying to resolve this issue I have already upgraded both rubyripper and 
cdparanoia to the lastest available sources

5) Does the problem happen with all discs? If not, please attach
the output of cdparanoia -Q with a disc that gives trouble.
The problem occurs with all discs.

6) Please explain why this change is important for you. Also, how many
users would benefit from this change?
There is no viable alternative for ripping cd's on linux as far as I'm 
concerned.

Please provide any additional information below. The more usefull
information provided, the sooner the issue will be fixed.

Attached you find the rubyripper config and the output of the cdparanoia run. 
Note that I have tried to run rubyripper and cdparanoia with an offset of 0 and 
the offset known for my hardware which is 102

Original issue reported on code.google.com by bas.bossink@gmail.com on 29 Aug 2010 at 12:56

Attachments:

• cdparanoia_output.txt
• settings

[GoogleCodeExporter]

I would expect rubyripper to fail somewhere if the cdparanoia command includes 
extra settings that would impact the output size. You might want to try the 
option to make an image rip instead? Otherwise the expected size wouldn't match 
anyway.

Original comment by boukewou...@gmail.com on 29 Aug 2010 at 9:45

[GoogleCodeExporter]

As can be seen from the settings no special cdparanoia settings are active. The 
suggested image rip works but has the downside of not being able to distinguish 
the individual tracks when the rip process finishes. While this would be 
preferred. Is there a configuration setting that can fix the behavior but still 
extracts the individual tracks?

Original comment by bas.bossink@gmail.com on 30 Aug 2010 at 9:35

[GoogleCodeExporter]

It appears that unchecking the cuesheet creation in the gui, which apperantly 
influences the settings for the cli as well, 'fixes' the problem.

Original comment by bas.bossink@gmail.com on 31 Aug 2010 at 2:07

[GoogleCodeExporter]

I just had this same issue. When ripping a CD the first 8 tracks went nicely 
but RubyRipper stopped on the 9th track with error: "Cdparanoia doesn't output 
wav files". I was also able to repeat (several times over) the error by trying 
to rip only the 9th track.

I followed the advice above and unchecked "the cuesheet creation" from the gui. 
And Voila! Now things work and I'm able to rip the entire CD, including the 
track 9.

I am using: 
- Ruburipper 0.6.0 GUI from here: 
http://code.google.com/p/rubyripper/downloads/list
- Ubuntu 10.10, 64bit, all updates
- All dependencies are met, except: wavgain and normalize (although I've 
normalize-audio package installed, if it's the same) which I wasn't able to 
find thru Synaptic

Additionally:
- I did install Rubyripper with this option: "./configure --enable-lang-all 
--enable-gtk2 --enable-cli --prefix=/usr"

Original comment by ju...@niiranen.fi on 16 Aug 2011 at 5:16

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Happens with 0.6.2 too. Can be ”fixed” by disabling cuesheet creation from 
settings by setting create_cue=false.

Somehow this always happens for track 8... I guess cuesheet creation somehow 
messes up for that track. 

It works properly if disk has less than 8 tracks.

Original comment by samu.vou...@gmail.com on 24 Feb 2012 at 11:54

[GoogleCodeExporter]

I can also verify this problem and workaround are still valid.  It is still 
happening in 0.62 on Ubuntu 12.10 / Linux Mint 14.

Original comment by hydr...@gmail.com on 12 May 2013 at 2:53

[GoogleCodeExporter]

Bug (and gimparound) is still in effect, Ubuntu Studio 13.10 Saucy Salamander.

Original comment by edwardoc...@gmail.com on 9 Dec 2013 at 6:25

[GoogleCodeExporter]

Observation - I do not have the cuesheet option checked (entire area greyed 
out) and I also get this same error. I am ripping to a NAS location mounted as 
a local directory. (Ubuntu v. 13.04, Rubyripper v. 0.6.2.1-getdeb1)

I have four computers ripping at once and only the computers using external 
CDROM RW devices work without this crash. Using internal CD drives on my Lenovo 
T61 laptops seems to cause this problem to occur. UNLESS - I rip to a local 
drive that is on the computer.

My guess is that if the write location is unable to take the data at the rate 
Rubyripper wants to spit it out, this is where the problem is. The slower CDROM 
devices allow the data to come in slowly therefore data gets written more 
slowly, the use of a local drive allows faster access than the network and so 
the data gets out from rubyripper more quickly.

Original comment by jerry.ko...@gmail.com on 25 Dec 2013 at 9:02

[GoogleCodeExporter]

Sorry for over posting - enabled local file caching (to local drive) when 
accessing NAS according to these instructions:

http://xmodulo.com/2013/06/how-to-enable-local-file-caching-for-nfs-share-on-lin
ux.html

And I am now ripping happily to my NAS (via local disk writes). 

For those of you ripping locally AND getting this error - suggest methods to 
allow faster writing (local RAM disk? SSD or cache for local drive - if this 
isn't already done by default).

Original comment by jerry.ko...@gmail.com on 25 Dec 2013 at 9:31