search

caveman-dick / rubyripper

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

Last track not ripping #335

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
 sytem: debian 5.0.2 kernel 2.6.26-2-686
 I have this package installed using gtk2: 
http://www.debian-multimedia.org/dists/unstable/main/binary-sparc/package/rubyri
pper.php
No matter what CD i use for ripping there's always and error that appears
on the very last song: ''Starting to rip track 17, trial #1
Filesize is not correct! Trying another time''
I've set 'max_tries=6'' but it keeps showing up forever. I didn't have this
problem when using the 0.55 version. I've tested the CDs with EAC and
everything goes smoothly without any errors.

Original issue reported on code.google.com by aleximil...@gmail.com on 31 Jul 2009 at 10:10

Attachments:

GoogleCodeExporter commented 8 years ago 
Same here 
i hae an ubuntu 9.04,using the git veseon from last night treyed ...reinstall
cdparanpia , cdrdao , compiling it from src just to be shure but nothig even 
with the
0.57 ver of ruby ripper

obs: sory the poor english

Original comment by dalton.brisola@gmail.com on 31 Jul 2009 at 2:48

Attachments:

GoogleCodeExporter commented 8 years ago 
Could you please retry this with latest git? See commit
http://github.com/rubyripperdev/rubyripper/commit/eeb5b1dd0c09adf047301d58d8d431
9556242951

Please report if this solves your problems.

Original comment by rubyripp...@gmail.com on 31 Jul 2009 at 5:23

GoogleCodeExporter commented 8 years ago 
Sorry, not working with me.
I tested *.deb of
http://linux.softpedia.com/progDownload/Rubyripper-Download-20741.html, but 
same result.
Tomorrow I will try RR_0.55 again to see results :)
:beer:

Original comment by aleximil...@gmail.com on 31 Jul 2009 at 10:34

GoogleCodeExporter commented 8 years ago 
I am not asking to test 0.5.7, I'm asking to test git. See the Git wiki page on 
this
site.

Original comment by rubyripp...@gmail.com on 1 Aug 2009 at 7:50

GoogleCodeExporter commented 8 years ago 
It worked some way ... since by the code i could see my cdpaaranoia + drive are 
the
real source of the problem ...as i acknowlege* it  identify the error and work 
around
... (after all its for cdparanoia developers to deal with it.) any away here 
are more
info on an OK rip with the so caled bug wrkaround with some paranoia logs to 
confirm
(or not) my asumptions...
::ver used git from commit indicate in ::
http://github.com/rubyripperdev/rubyripper/commit/eeb5b1dd0c09adf047301d58d8d431
9556242951

thanks ... good work keep it going :)
ps: sory the poor english

Original comment by dalton.brisola@gmail.com on 1 Aug 2009 at 3:04

Attachments:

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
I did some tests, the problem may be in the CDROM-e model: HL-DT-ST DVDRAM 
GSA-H12N
UL01, switched it ATAPI DVD A  DH20A4P 9P53 and things were perfect. 
Windows+EAC with
no problem, seen from the log.
The new git very good function included TOC & Pregap detected. :beer:

This will be the new version, it comes to translating.

Alternative Download link for test: http://linux-al.hit.bg/test.zip

ps: sorry for my bad English

Original comment by aleximil...@gmail.com on 1 Aug 2009 at 8:21

Attachments:

GoogleCodeExporter commented 8 years ago 
I am also having these issues, therefore I don't believe it's cdparanoia or the 
drive
(I have been able to rip plenty of CDs before). I'll try my git version on it.

Original comment by fergof...@gmail.com on 2 Aug 2009 at 11:15

GoogleCodeExporter commented 8 years ago 
The latest commit is doing the same, the temporary is increasing in size 
however it
is simply going excruciatingly slow.

Original comment by fergof...@gmail.com on 2 Aug 2009 at 12:23

GoogleCodeExporter commented 8 years ago 
I don't expect cdparanoia usually has read errors like shown in the
cdparanoia-output-error.log above. It might be related to the offset setting. 
Perhaps
some drives don't allow to overread (to apply the correction).

So cdparanoia does skip a few sectors at the end of some drives. Based on the 
TOC of
the disc, the expected filesize is calculated. When there is a mismatch for last
track, the number of sectors missing are reported.

Changing the ripping drive can solve the problem completely. Rubyripper 
shouldn't
just keep looping on those other drives though. But a warning to report how much
sectors are missing should be in place I think.

@all: Does anyone still have endless loops with mismatching filesize?
@all: Please confirm that the messages are solved when resetting the offset 
value to 0.

Original comment by rubyripp...@gmail.com on 2 Aug 2009 at 3:28

GoogleCodeExporter commented 8 years ago 
It is not an issue with filesize or offset value for me. It could simply be an 
issue
with the disk I was trying. I can deduce this because:
Filesize: it rips fully (after a very very long time) with no errors
Offset Value: I have used this same offset value for years (including a couple 
of
months with rr)
Disk: this is the first time I have encountered it, and I am yet to try another 
disk

Additionally after leaving it for a while and after it finishes ripping twice 
it had
>200 sector mismatches, which leads me to believe it's an issue with the outer
sectors of the disk and that cdparanoia it giving its :-O and :-( errors (I 
simply
can't see them). Later today (it's 0135 here) I'll give the disk a try with
cdparanoia and see whether I get unhappy faces, and I'll also give another disk 
a try.

Original comment by fergof...@gmail.com on 2 Aug 2009 at 3:35

GoogleCodeExporter commented 8 years ago 
It indeed might be a problem with some sectors on the last disk. I'll see if I 
can
catch those and report them in the logfile.

Original comment by rubyripp...@gmail.com on 2 Aug 2009 at 3:47

GoogleCodeExporter commented 8 years ago 
Test again. With the value of ofset: 0 ripping runs without error.
Rr 0.5.5 and tested with the value of ofset: 667, also passed without error.
But to try other CD's ...?

Original comment by aleximil...@gmail.com on 3 Aug 2009 at 1:36

Attachments:

GoogleCodeExporter commented 8 years ago 
@aleximilian: There is something strange about your bug report in that 
rubyripper
reports a negitive amount of sectors missing. This is indeed changed with last
version, it now rips till the end of the disc for last track.

I suppose extra sectors can't hurt. Please update your git to:
http://github.com/rubyripperdev/rubyripper/commit/87e37260b0b0b84c2e7cb5119f39a6
a52c6fe593

Original comment by rubyripp...@gmail.com on 3 Aug 2009 at 4:13

GoogleCodeExporter commented 8 years ago 
I've tried the git you gave but when it started the program it runs for awhile 
and
stops by itself.

Original comment by aleximil...@gmail.com on 3 Aug 2009 at 5:59

Attachments:

GoogleCodeExporter commented 8 years ago 
Next commit should fix your trouble with manual freedb string generation:
http://github.com/rubyripperdev/rubyripper/commit/a63caab6ec13aad7cc8da53b86acbd
8bdc55d0fe

I forgot it after refactoring all arrays to hashes. So when startSector[0] was
mentioned it was looking for track 0 instead of the first item in the array.

Original comment by rubyripp...@gmail.com on 3 Aug 2009 at 6:42

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Very good job.
:beer:

Original comment by aleximil...@gmail.com on 3 Aug 2009 at 10:47

Attachments:

GoogleCodeExporter commented 8 years ago 
Then I guess I can close this one :)

Original comment by rubyripp...@gmail.com on 4 Aug 2009 at 5:59