search

fongecore / rubyripper

Automatically exported from code.google.com/p/rubyripper
0 stars 0 forks source link

cdparanoia not outputting wav files #211

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1.  Put cd in drive 
2. Type rrip_cli
3.

What is the expected output? What do you see instead?
Expected output: cd ripping. Actual output:  
[quote]:~/temp/rrip/rubyripper-0.5.1$ rrip_cli
Use config file ~/.rubyripper/settings
/usr/bin/rrip_cli:262:in `get_cd_info': undefined method `cd_playtime' for
#<Disc:0x7f5686a945c8> (NoMethodError)
    from /usr/bin/rrip_cli:48:in `initialize'
    from /usr/bin/rrip_cli:403:in `new'
    from /usr/bin/rrip_cli:403
[/quote]

What version of rubyripper are you using? On what operating system? Are you
using the gtk2 or the commandline interface?
0.5.1, on an amd64 kernel for ubuntu linux.
Please provide any additional information below.
   I have tried the gui interface, but it gives me an error that cdparanoia
doesn't output wav files.  I don't know how else it would store them but I
tried changing output to wav, to flac, to ogg, etc.  Nothing worked.  Back
to abcde.  I liked rubyripper when it first worked for me a few years ago
though!

Original issue reported on code.google.com by creepst...@gmail.com on 17 Jul 2008 at 8:38

GoogleCodeExporter commented 8 years ago 
Your problems with the cli frontend are fixed in svn r247 already.

If cdparanoia doesn't output wav files this usually means that your manual 
switches
in cdparanoia result in cdparanoia crashing.

Please show your $HOME/.rubyripper/settings for more analysis.

Original comment by rubyripp...@gmail.com on 17 Jul 2008 at 4:20

GoogleCodeExporter commented 8 years ago 
vorbissettings=-q 5
flacsettings=--best
naming_normal=%f/%a (%y) %b/%n - %t
max_tries=3
wav=true
vorbis=false
flac=true
gain=album
req_matches_all=2
req_matches_errors=2
naming_various=%f/%a (%y) %b/%n - %va - %t
edit=false
freedb=true
tracksToRip=123456789101112123456789101112
username=anonymous
create_cue=false
maxThreads=1
mp3=false
normalize=false
no_log=false
editor=mousepad
eject=true
verbose=true
basedir=/home/bjorn/audio
site=http://freedb2.org:80/~cddb/cddb.cgi
rippersettings=-Z
playlist=true
first_hit=true
hostname=my_secret.com
debug=false
naming_image=%f/%a (%y) %b/%a - %b (%y)
offset=0
cdrom=/dev/scd0
othersettings=
mp3settings=-V 3
image=true
other=false
filemanager=thunar
instance=main

In the gui version it said that cdparanoia doesn't output wav files so I tried
changing wav to false, nothing changed.

Original comment by creepst...@gmail.com on 18 Jul 2008 at 4:38

GoogleCodeExporter commented 8 years ago 
I feel this one is related to issue 212. There seems to be a problem with 
ripping
image files. Can you confirm the problem is gone, when you disable image 
ripping?

Original comment by rubyripp...@gmail.com on 18 Jul 2008 at 4:59

GoogleCodeExporter commented 8 years ago 
Please set debug to true, restart and rerun. See if it spits any info when 
launched
from a terminal.

Original comment by rubyripp...@gmail.com on 22 Jul 2008 at 5:26

GoogleCodeExporter commented 8 years ago 
I too am having the gtk cdparanoia doesn't output wav error message issue.  I 
am not,
however, using image ripping.  I am running Debian Lenny and rubyripper .5.2 .  
I
tried running in debug but nothing unusual pops out on the terminal.  One 
interesting
tidbit I discovered is that if I specify the "-d /dev/hdc" option directly in 
the
"Pass cdparanoia options" preference the process gets further along.  My ripping
drive is not found automatically by cdparanoia, but this never used to be a 
problem
in rubyripper if I specified the drive in the "cdrom device" preference field - 
now
it is.  It seems like somehow rubyripper isn't passing options properly to its
dependent programs.  Though using the pass cdparanoia options trick does get the
ripping working, the overall process still fails.  The gtk interface hangs 
after the
first track, the ripping continues to take place, outputting wav files to the 
temp
folder, but no compressed files are created in the final album folder.  Here 
are my
settings:

req_matches_all=3
naming_various=%g/%a/%b/%n - %va - %t
vorbissettings=-q 7
flacsettings=--best
edit=false
freedb=true
naming_normal=%g/%a/%b/%n - %t
max_tries=8
wav=false
gain=album
req_matches_errors=4
editor=gedit
username=anonymous
verbose=true
maxThreads=1
mp3=false
normalize=replaygain
first_hit=true
cdrom=/dev/hdc
create_cue=false
site=http://freedb2.org:80/~cddb/cddb.cgi
playlist=false
other=false
no_log=true
filemanager=nautilus --no-desktop
hostname=my_secret.com
eject=true
instance=main
debug=true
naming_image=%f/%a (%y) %b/%a - %b (%y)
basedir=/home/music
othersettings=
mp3settings=-V 3
image=false
rippersettings=-Z
offset=0
vorbis=true
flac=false

Original comment by jbfun...@gmail.com on 23 Jul 2008 at 6:57

GoogleCodeExporter commented 8 years ago 
What you both have in common is that you don't use the default of /dev/cdrom.

Can you please test if r262 fixes your problems? You can see how to use 
subversion on
the source tab above on this page.

Original comment by rubyripp...@gmail.com on 23 Jul 2008 at 5:58

GoogleCodeExporter commented 8 years ago 
I just tried r262 and the issue remains.  The behavior is exactly the same as 
.5.2.

Original comment by jbfun...@gmail.com on 23 Jul 2008 at 6:45

GoogleCodeExporter commented 8 years ago 
In reference to issue 212, I am also beginning to wonder if this is somehow 
born of a
Debian Testing ruby update...

Original comment by jbfun...@gmail.com on 23 Jul 2008 at 6:46

GoogleCodeExporter commented 8 years ago 
That would be unlikely. It would be more likely that an update to cdparanoia is
giving problems. Isn't debian using a BSD version of cdparanoia because of 
licensing
issues? Can you please check if cdparanoia has been updated lately? Perhaps 
reverse
the upgrade if possible and see if it changes anything...

Also please test if older versions of rubyripper (say 0.5.0) do still work... 
You
don't have to install them. Just run (after unpacking) ./rubyripper_gtk2.rb

Original comment by rubyripp...@gmail.com on 23 Jul 2008 at 9:19

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
The version is:
cdparanoia III release 10.0 (June 10, 2008)

.5.0 has the same issue.

I'll try and see if I can find the deb for the old version of cdparanoia and 
check if
that fixes it.

Original comment by jbfun...@gmail.com on 24 Jul 2008 at 12:04

GoogleCodeExporter commented 8 years ago 
I downgraded to:

cdparanoia III release 10pre0 (August 29, 2006)

The problem is still there.

Original comment by jbfun...@gmail.com on 24 Jul 2008 at 12:17

GoogleCodeExporter commented 8 years ago 
Also, the .5.0 problem is slightly different.  Directly after clicking the "Rip 
CD
Now!" button the program crashes and outputs this on the console:

/usr/src/rubyripper-0.5.0/rr_lib.rb:1139:in `prepare_dirs': undefined method 
`update'
for "main":String (NoMethodError)
    from /usr/src/rubyripper-0.5.0/rr_lib.rb:1137:in `each'
    from /usr/src/rubyripper-0.5.0/rr_lib.rb:1137:in `prepare_dirs'
    from /usr/src/rubyripper-0.5.0/rr_lib.rb:1063:in `settings_ok'
    from ./rubyripper_gtk2.rb:222:in `start_rip'
    from ./rubyripper_gtk2.rb:221:in `initialize'
    from ./rubyripper_gtk2.rb:221:in `new'
    from ./rubyripper_gtk2.rb:221:in `start_rip'
    from ./rubyripper_gtk2.rb:96:in `create_signals'
    from ./rubyripper_gtk2.rb:1083:in `call'
    from ./rubyripper_gtk2.rb:1083:in `main'
    from ./rubyripper_gtk2.rb:1083

Original comment by jbfun...@gmail.com on 24 Jul 2008 at 12:22

GoogleCodeExporter commented 8 years ago 
I did find an error which seems to affect both of you. The trackToRip variable
contains the album tracks twice. I've fixed this in r264. I don't know if this 
fixes
anything for you, but it won't hurt at least.

I've also added a debug line in r265 that prints the command that is send to
cdparanoia. Please verify that the query of the disc is succesfull when done 
manually.

Original comment by rubyripp...@gmail.com on 24 Jul 2008 at 5:22

GoogleCodeExporter commented 8 years ago 
This is the rrip_gui output:

This command will be used to query cdparanoia:
cdparanoia -d /dev/hdc -vQ 2>&1
Ripping track 1
cdparanoia III release 10.0 (June 10, 2008)

003: CDROM reporting illegal number of tracks

Unable to open disc.  Is there an audio CD in the drive?

When that command is run directly in cdparanoia, the CD IS properly found, 
however.

Original comment by jbfun...@gmail.com on 24 Jul 2008 at 8:14

GoogleCodeExporter commented 8 years ago 
Question: What shell are you using? Bash, or something else?

Original comment by rubyripp...@gmail.com on 24 Jul 2008 at 8:57

GoogleCodeExporter commented 8 years ago 
I guess you used the command except the 2>&1 bit. This last part is redirecting 
the
error messages to the normal output stream. Please confirm this is the case.

I somehow think it has something to do with:
https://bugs.launchpad.net/ubuntu/+source/dash/+bug/141481

I'll see if I can somehow redirect the output in a different way.

Original comment by rubyripp...@gmail.com on 24 Jul 2008 at 9:15

GoogleCodeExporter commented 8 years ago 
I am using Bash.
I used the cdparanoia command both with and without the 2>&1 bit.  The output 
was the
same either way (it read the drive information and then the TOC of the CD in 
the drive).

Original comment by jbfun...@gmail.com on 24 Jul 2008 at 11:05

GoogleCodeExporter commented 8 years ago 
Also, /bin/sh on Debian Lenny points to bash.

Original comment by jbfun...@gmail.com on 24 Jul 2008 at 11:09

GoogleCodeExporter commented 8 years ago 
I get the same error.

I ripped a CD a few hours ago and then canceled it half way through.

Now I try it gives me this annoying error.

:-S.

Original comment by joshuase...@gmail.com on 25 Jul 2008 at 2:53

GoogleCodeExporter commented 8 years ago 
Hey, this might give some clue. Can anyone confirm the issue is still there when
deleting any leftover "temp" dir? It should be created (and deleted) in the dir 
above
the destination dir.

Original comment by rubyripp...@gmail.com on 25 Jul 2008 at 3:23

GoogleCodeExporter commented 8 years ago 
The problem is still there when I delete the album folder and try again if 
that's
what you mean.  

Settings: 
vorbissettings=-q 4
flacsettings=--best
cd=#<Disc:0xb7a30ec8>
naming_normal=%a -  %b (%y)/%n - %t
max_tries=5
wav=false
vorbis=false
flac=false
gain=album
req_matches_all=2
req_matches_errors=3
naming_various=%f/%a - %b (%y)/%n - %va - %t
edit=false
freedb=true
tracksToRip=12345678910
username=anonymous
create_cue=true
maxThreads=1
mp3=true
normalize=false
no_log=false
editor=gedit
eject=true
verbose=false
basedir=~/
site=http://freedb2.org:80/~cddb/cddb.cgi
rippersettings=-Z
playlist=true
first_hit=true
hostname=my_secret.com
debug=false
naming_image=%f/%a (%y) %b/%a - %b (%y)
offset=0
cdrom=/dev/scd1
othersettings=
mp3settings=-V 0
image=false
other=false
filemanager=nautilus --no-desktop
instance=main

Sorry if I can't really help you i'm a bit of a linux n00b atm.

Original comment by joshuase...@gmail.com on 25 Jul 2008 at 3:30

GoogleCodeExporter commented 8 years ago 
Please check out r266 and see if it solves your problems. This is as close to 
the
code in question as it gets. Perhaps it was a ruby update after all that caused 
you
problems.

Original comment by rubyripp...@gmail.com on 25 Jul 2008 at 6:51

GoogleCodeExporter commented 8 years ago 
Sorry but i'm a n00b.

What do I have to do?

I went to that link but all it was, was code.

Original comment by joshuase...@gmail.com on 25 Jul 2008 at 8:06

GoogleCodeExporter commented 8 years ago 
1. make sure you've installed subversion
2. follow the directions of the source tab above on this page

When you want to update an existing version (after the first svn checkout):
3. type in a terminal in the directory -> svn update

Original comment by rubyripp...@gmail.com on 25 Jul 2008 at 9:04

GoogleCodeExporter commented 8 years ago 
joshua@joshua-desktop:~$ svn checkout 
http://rubyripper.googlecode.com/svn/trunk/
rubyripper-read-only
A    rubyripper-read-only/locale
A    rubyripper-read-only/locale/po
A    rubyripper-read-only/locale/po/rubyripper.pot
A    rubyripper-read-only/locale/po/ru
A    rubyripper-read-only/locale/po/ru/rubyripper.po
A    rubyripper-read-only/locale/po/es
A    rubyripper-read-only/locale/po/es/rubyripper.po
A    rubyripper-read-only/locale/po/de
A    rubyripper-read-only/locale/po/de/rubyripper.po
A    rubyripper-read-only/locale/po/nl
A    rubyripper-read-only/locale/po/nl/rubyripper.po
A    rubyripper-read-only/locale/po/hu
A    rubyripper-read-only/locale/po/hu/rubyripper.po
A    rubyripper-read-only/GPL-3.txt
A    rubyripper-read-only/configure
A    rubyripper-read-only/rubyripper.png
A    rubyripper-read-only/rr_lib.rb
A    rubyripper-read-only/rubyripper.desktop
A    rubyripper-read-only/rubyripper_cli.rb
A    rubyripper-read-only/rubyripper_gtk2.rb
A    rubyripper-read-only/README
Checked out revision 266.
joshua@joshua-desktop:~$ svn update
Skipped '.'

????

I did stages 1+2....When you say "in the directory" what do you mean?  What
directory?  Sorry mate...thanks in advanced also.

Original comment by joshuase...@gmail.com on 25 Jul 2008 at 9:57

GoogleCodeExporter commented 8 years ago 
I just checked out r266 and the problem still exists.  The exact same error 
still occurs.

Original comment by jbfun...@gmail.com on 25 Jul 2008 at 11:34

GoogleCodeExporter commented 8 years ago 
Also, regardless of the existence of the temp folder the issue still persists.

Original comment by jbfun...@gmail.com on 25 Jul 2008 at 11:38

GoogleCodeExporter commented 8 years ago 
I've added a wiki page ( Subversion ) to explain the use of subversion.

Original comment by rubyripp...@gmail.com on 26 Jul 2008 at 8:55

GoogleCodeExporter commented 8 years ago 
I have to delay solving this due to the 3 weeks of holiday I have. The first 
week I
will be in Wacken, Germany and the second two weeks in Sarre, Italy. After this 
my
attempts at solving this will start again :)

Original comment by rubyripp...@gmail.com on 26 Jul 2008 at 1:30

GoogleCodeExporter commented 8 years ago 
That's pretty damn annonying.

Well have a good holiday mate.

Original comment by joshuase...@gmail.com on 26 Jul 2008 at 2:15

GoogleCodeExporter commented 8 years ago 
I also get this error message with the GTK+ GUI. If I change 
"@multipleDriveSupport =
false" to "@multipleDriveSupport = true" in the method audioDisc in rr_lib.rb, 
it works.

Original comment by pizzap...@gmail.com on 26 Jul 2008 at 10:55

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Thanks pizzapunk, this at least points me to the place where the trouble 
starts. Can
anyone please confirm r273 fixed the problems?

Original comment by rubyripp...@gmail.com on 4 Aug 2008 at 4:43

GoogleCodeExporter commented 8 years ago 
I think this is definitely a multiple drive issue.  I had this problem myself 
before
I did what pizzapunk suggested.  I think if /dev/cdrom points to something 
other than
the drive you will be using you have this problem.  I noticed that if I used the
drive /dev/cdrom actually pointed to I did not have this problem without having 
to
change any coding.

Original comment by tdto...@gmail.com on 4 Aug 2008 at 7:35

GoogleCodeExporter commented 8 years ago 
The detection of cdparanoia not supporting the -d switch (multipleDriveSupport) 
is
not for nothing. In MacOS there are cdparanoia binarys which error if you try 
to add
-d /dev/cdrom into the commandline. Apparently with the recent changes of code, 
the
logic was not working anymore. So disabling the logic was only a workaround.

The real solution is probably to be found in r273.

Original comment by rubyripp...@gmail.com on 4 Aug 2008 at 9:16

GoogleCodeExporter commented 8 years ago 
since you think this is related... just tried r274 and it didn't fix thing.  I 
think,
now, two temp dirs are being created (one subdirectory in the album dir and one 
in
the ripping directory).  Still get the empty wav file in the album dir.  At the 
end
rr hangs and CPU usage spikes to 100%.  Disc is ejected, however.

Original comment by mordbr...@gmail.com on 4 Aug 2008 at 9:17

GoogleCodeExporter commented 8 years ago 
I've changed my mind about that. There seems to be two different things going on
here. But thanks for reporting anyway.

Original comment by rubyripp...@gmail.com on 4 Aug 2008 at 9:30

GoogleCodeExporter commented 8 years ago 
Another attempt goes in to solve this issue. See issue r276.

Before this commit I could reproduce the cdparanoia not outputting wav files 
message.
When ripping the same disc another time, I'd get a dialog to ask me if I want to
overwrite etcetera. I chose cancel. Then start again. After the selected tracks 
were
ripped cdparanoia wanted to rip it another time. But then the thread was killed 
by
the ruby garbage collector I suspect.

After this commit this problem no longer occurs. Please give it a spin :)

Original comment by rubyripp...@gmail.com on 4 Aug 2008 at 10:34

GoogleCodeExporter commented 8 years ago 
I can only speak for myself, but everything is working fine now on my end.

Original comment by tdto...@gmail.com on 5 Aug 2008 at 12:42

GoogleCodeExporter commented 8 years ago 
So long nobody want to re-open this, I'll mark this as fixed. Thanks for all the
ideas leading to the solution :)

Original comment by rubyripp...@gmail.com on 5 Aug 2008 at 1:49

GoogleCodeExporter commented 8 years ago 
This is probably a second issue that was just masked by the not outputting wav 
issue:
 r276 does make cdparanoia function properly again, however rrip_gui seems to freeze.
 All the trials for the first track are reported properly in the status screen in
rrip_gui.  After that first track, however, nothing more is reported.  The 
program
continues on ripping all the remaining tracks and seems to evaluate the various
trials for differences (after all trials for a track it deletes all but one) 
BUT it
does not encode them (the first track DOES get encoded - in this case to 
vorbis).  If
you let the whole CD go through cdparanoia will stop ripping and you will have 
the
whole CD in untouched wav files in the temp folder but rrip_gui will just sit 
there,
not having reported anything since the first track and not having encoded 
anything
but the first track, until you kill the program.  Neither status bar ever moves 
from 0%.

Original comment by jbfun...@gmail.com on 5 Aug 2008 at 5:15

GoogleCodeExporter commented 8 years ago 
Please open up a new issue. This one is getting a bit long ;) Just copy / paste 
your
post... But first make sure r281 hasn't fixed your problem already.

Original comment by rubyripp...@gmail.com on 5 Aug 2008 at 5:41