Closed GoogleCodeExporter closed 9 years ago
It will try to reread the file forever it seems
Original comment by marcinp...@gmail.com
on 31 Mar 2009 at 12:31
Sorry should be a defect not enhancement
Original comment by marcinp...@gmail.com
on 31 Mar 2009 at 12:32
Does it also have problems when disabling the offset?
Original comment by rubyripp...@gmail.com
on 5 Apr 2009 at 2:25
Original comment by rubyripp...@gmail.com
on 5 Apr 2009 at 2:25
Tried your suggestion with offest 0 and the same thing. No change.
Sorry I tried again and it seemed to even crash grip completely. I'm thinking
it's a
defective disc. A small scratch on a new CD probably. I tried claning the CD
with
various techniques on the web and it did not help. I booted into Vista and
tried
Exact Audio Copy freeware and it worked. First it ripped it with a blank no
music
section but then I tired it again and it ripped it fine.
Thankfully I got the CD ripped into flac as this CD would be extremely
difficult to
replace as it is not popular and only sold in foreign country with even hard to
get
from the muscians who made the CD running out of stock. Ironically it's my
favorite
CD from my favorite band.
Anyway back to troubleshooting. I tried with offset 0 and it did not change
anything. In fact the first time I tired it was with offset 0 and then setting
offset to 6 was my way of trying to trouble shoot it. I did not mention that
before.
Would be curious why exact audio copy got it copied eventually.
Would you like me to try something else or do you think that a defective disc
is not
worth pursuing to find out why EAC can rip it but rubyripper can't? If you
could
please let me know.
Just wanted to say rubyripper is my favorite ripping program but EAC seemed to
handle
this one special case better.
Thanks
Martin
Original comment by marcinp...@gmail.com
on 6 Apr 2009 at 3:21
Please add the output of cdparanoia -Q (with the disc in)
Original comment by bouke.wo...@snsreaal.nl
on 6 Apr 2009 at 6:34
Output of cdparania -Q is:
cdparanoia III release 10.0 (June 10, 2008)
Table of contents (audio tracks only):
track length begin copy pre ch
===========================================================
1. 16915 [03:45.40] 0 [00:00.00] OK no 2
2. 13951 [03:06.01] 16915 [03:45.40] OK no 2
3. 15696 [03:29.21] 30866 [06:51.41] OK no 2
4. 17269 [03:50.19] 46562 [10:20.62] OK no 2
5. 15186 [03:22.36] 63831 [14:11.06] OK no 2
6. 17571 [03:54.21] 79017 [17:33.42] OK no 2
7. 15647 [03:28.47] 96588 [21:27.63] OK no 2
8. 12282 [02:43.57] 112235 [24:56.35] OK no 2
9. 16123 [03:34.73] 124517 [27:40.17] OK no 2
10. 12828 [02:51.03] 140640 [31:15.15] OK no 2
11. 12394 [02:45.19] 153468 [34:06.18] OK no 2
12. 16119 [03:34.69] 165862 [36:51.37] OK no 2
13. 16283 [03:37.08] 181981 [40:26.31] OK no 2
14. 29811 [06:37.36] 198264 [44:03.39] OK no 2
TOTAL 228075 [50:41.00] (audio only)
Original comment by marcinp...@gmail.com
on 7 Apr 2009 at 1:34
I'd be interesting in what the cli output from ripping with cdparanoia is.
Perhaps
you can try with -Z option as well.
Original comment by mordbr...@gmail.com
on 10 Apr 2009 at 12:49
I think these problems arise because of an inaccurate TOC (Table of Contents)
of the
audio disc. Then it's in effect a broken disc. Currently rubyripper doesn't
support
detecting the actual TOC, but trusts on the accuracy of the TOC provided by the
audio
disc.
I guess cdparanoia handles this error simply by stopping when it can't read any
extra
sectors. Rubyripper however, is still expecting these sectors in the amount of
bytes
it checks. Disabling this check doesn't seem like a good idea to me.
As long this doesn't happen to too many discs I can't see this as a fault of
rubyripper.
Original comment by rubyripp...@gmail.com
on 23 May 2009 at 12:31
Original issue reported on code.google.com by
marcinp...@gmail.com
on 31 Mar 2009 at 12:30Attachments: