Finding offset fails for one drive "file size 0 did not match expected size"

[simpz]

I have been setting up Whipper on all the machines I use. All Fedora 27, and 2 of the 3 machines everything works fine. On one machine with a drive:

HL-DT-ST Model: DVD+-RW GHA2N Rev: A103

Finding the offsets fails with:
% whipper offset find -o 667
/usr/lib/python2.7/site-packages/urllib3/contrib/pyopenssl.py:46: DeprecationWarning: OpenSSL.rand is deprecated - you should use os.urandom instead
import OpenSSL.SSL
Checking device /dev/sr0
Trying read offset 667 ...
WARNING:whipper.program.cdparanoia:file size 0 did not match expected size 52209740
WARNING:whipper.program.cdparanoia:non-integral amount of frames difference
WARNING: cannot rip with offset 667...
No matching offset found.
Consider trying again with a different disc.

I know the offset is 667 for this drive from the database and strangely Morituri can correctly pickup the offset:
% rip offset find -o 667
Checking device /dev/cdrom
Trying read offset 667 ...
** Message: pygobject_register_sinkfunc is deprecated (GstObject)
Offset of device is likely 667, confirming ...

Read offset of device is: 667.
Adding read offset to configuration file.

If I set this as an offset in the config file ripping fails with this error too.

[simpz]

whipper.log

[Germano0]

Drive PIONEER BDC-207D on Fedora 27 and whipper-0.6.0-6.fc27.x86_64

$ whipper drive analyze
/usr/lib/python2.7/site-packages/urllib3/contrib/pyopenssl.py:46: DeprecationWarning: OpenSSL.rand is deprecated - you should use os.urandom instead
  import OpenSSL.SSL
cdparanoia can defeat the audio cache on this drive.
Adding drive cache behaviour to configuration file.

$ whipper offset find -o +667
/usr/lib/python2.7/site-packages/urllib3/contrib/pyopenssl.py:46: DeprecationWarning: OpenSSL.rand is deprecated - you should use os.urandom instead
  import OpenSSL.SSL
Checking device /dev/sr0
Trying read offset 667 ...
WARNING:whipper.program.cdparanoia:file size 0 did not match expected size 53119964
WARNING:whipper.program.cdparanoia:non-integral amount of frames difference
WARNING: cannot rip with offset 667...    
No matching offset found.
Consider trying again with a different disc.

I tried also to not to put + before 667

$ whipper offset find -o 667
/usr/lib/python2.7/site-packages/urllib3/contrib/pyopenssl.py:46: DeprecationWarning: OpenSSL.rand is deprecated - you should use os.urandom instead
  import OpenSSL.SSL
Checking device /dev/sr0
Trying read offset 667 ...
WARNING:whipper.program.cdparanoia:file size 0 did not match expected size 53119964
WARNING:whipper.program.cdparanoia:non-integral amount of frames difference
WARNING: cannot rip with offset 667...    
No matching offset found.
Consider trying again with a different disc.

[PascalMinder]

I have a similar problem with the BH10LS38 drive. According to the DB it should be +667.

But whipper always ends in an error:

whipper offset find -o +667
Checking device /dev/sr0
Trying read offset 667 ...
WARNING:whipper.program.cdparanoia:file size 0 did not match expected size 27217388
WARNING:whipper.program.cdparanoia:non-integral amount of frames difference
WARNING: cannot rip with offset 667...    
No matching offset found.
Consider trying again with a different disc.

[rry1983]

I can confirm both my TSSTcorp DVDWBD SH-B123L and a PLDS DVD+/-RW DH-16AES encounter the same error.

A workaround I found was booting a kernel version earlier than 4.15. In Fedora 4.13.9-300 I am able to rip with no errors.

[RecursiveForest]

If you run the cd-paranoia command provided in the debug log* that supposedly returns a 0 length file manually, is the file still 0? Try replacing the 1[00:00:00.00]-1[...] with 1 if the command fails, and report back at least the lines containing the track offsets in HH:MM:SS.FF notation.

for example (from a cd that happens to be in my drive):

Ripping from sector       0 (track  1 [0:00.00])
          to sector   22364 (track  1 [4:58.14])

does the "to sector ..." track 1 match the offset that whipper is trying?

(*) DEBUG:whipper.program.cdparanoia:Running cd-paranoia --stderr-progress --sample-offset=667 --force-cdrom-device /dev/sr0 1[00:00:00.00]-1[00:04:55.72] /tmp/tmpjLoljc.track01.offset667.whipper.wav in @simpz 's case.

[rry1983]

Tested a disc that refuses to rip no matter what I try. Received the same error.

"WARNING:whipper.program.cdparanoia:non-integral amount of frames difference"
"WARNING:whipper.program.cdparanoia:file size 0 did not match expected size 42444236"
The debug file in /tmp/tmp3CF3Lo.whipper.wav is a 0 byte file.  Tested another disc which refuses to rip and its debug file in /tmp/tmphrk67w.whipper.wav is also an empty 0 byte file.

[RecursiveForest]

Can you explain what "The debug file in /tmp/..." means-- I can't tell if you're referring to log messages that say "file size 0 did not match ...", the /tmp file as ripped by whipper, or files you ripped with cd-paranoia by hand that you've named the same as the files whipper tried.

If you rip the file with no offset passed to cd-paranoia, does it still return an empty file?

[rry1983]

Sorry for being vague in my last response. I think I was describing the output files themselves being created as 0 byte files. This is the output I receive if I run whipper in Debug with the offset of my drive forced (6).

DEBUG:whipper.program.cdparanoia:Ripping from 0 to 18045 (inclusive)
DEBUG:whipper.program.cdparanoia:Starting at track 1, offset 0
DEBUG:whipper.program.cdparanoia:Stopping at track 1, offset 18045
DEBUG:whipper.program.cdparanoia:Running cd-paranoia --stderr-progress --sample-offset=6 --force-cdrom-device /dev/sr0 1[00:00:00.00]-1[00:04:00.45] /tmp/tmp9VJMBH.whipper.wav
WARNING:whipper.program.cdparanoia:file size 0 did not match expected size 42444236
WARNING:whipper.program.cdparanoia:non-integral amount of frames difference
DEBUG:whipper.program.cdparanoia:getTrackQuality: frames 18046, reads 0
DEBUG:whipper.program.cdparanoia:stop: exception FileSizeError(u'/tmp/tmp9VJMBH.whipper.wav', 'File size 0 did not match expected size 42444236')
DEBUG:whipper.command.cd:Got exception TaskException(FileSizeError(u'/tmp/tmp9VJMBH.whipper.wav', 'File size 0 did not match expected size 42444236'), 'exception %(exc)s at %(filename)s:%(line)s: ') on try 1

---

I next ran a wrong command to test your suggestion. The results may be useful.

I run cdparanoia manually it does rip the disc to .wav files with no problem. Here is output it gives for track 1.

cdparanoia III release 10.2 (September 11, 2008)
 
Ripping from sector       0 (track  1 [0:00.00])
	  to sector  251591 (track 12 [8:46.73])

outputting to track01.cdda.wav

 (== PROGRESS == [                              | 018045 00 ] == :^D * ==)

If I run cd-paranoia I get an error.

cdparanoia III release 10.2 libcdio 0.94
(C) 2001 Monty <[email protected]> and Xiphophorus
(C) 2004, 2005, 2008 Rocky Bernstein <[email protected]>
(C) 2014 Robert Kausch <[email protected]>

Report bugs to [email protected]

++ WARN: error in ioctl CDROMREADTOCHDR: No medium found

Selected span contains non audio track at track 13.  Aborting.

I am hoping this information is helpful in solving this issue.

[RecursiveForest]

Thank you. If you could please use triple-backticks to quote large sections of console text it would make your reports easier to read.

Can you also please post the full command line you used with cdparanoia and cd-paranoia to rip the discs? I'm not sure if you ran them with a specific (correct? incorrect?) offset, or no offset at all.

It'd also be helpful to paste the musicbrainz URL for the CD in question.

Interesting that this is looking to be a divergence in behaviour between cdparanoia and libcdio's cd-paranoia.

[rry1983]

If I run cd-paranoia with forced offset I get this:

$ cd-paranoia -B -d /dev/sr0 -o 6
cdparanoia III release 10.2 libcdio 0.94
(C) 2001 Monty <[email protected]> and Xiphophorus
(C) 2004, 2005, 2008 Rocky Bernstein <[email protected]>
(C) 2014 Robert Kausch <[email protected]>

Report bugs to [email protected]

Forcing search overlap to 6 sectors; ignoring autosense
Selected span contains non audio track at track 13.  Aborting.

If I run cdparanoid with same forced offset I get this:

cdparanoia -B -d /dev/sr0 -o 6
cdparanoia III release 10.2 (September 11, 2008)

Forcing search overlap to 6 sectors; ignoring autosense
Ripping from sector       0 (track  1 [0:00.00])
	  to sector  251591 (track 12 [8:46.73])

outputting to track01.cdda.wav

 (== PROGRESS == [                              | 018045 00 ] == :^D * ==)

The musicbrainz URL is: https://musicbrainz.org/cdtoc/attach?toc=1+12+251742+150+18196+35827+49678+67595+94386+115802+132031+153418+174992+196843+212218&tracks=12&id=DdgxjFT7gVEdHxKuxi5SdDK9kJg-

I am also going to attach the whole debug log file to this posting.

whipper.log

[simpz]

Sorry not been repsonding quickly, the machine with this issue wasn't nearby.

But stealing the more cd-paranoia command from the log file:

DEBUG:whipper.program.cdparanoia:Running cd-paranoia --stderr-progress --sample-offset=667 --force-cdrom-device /dev/sr0 1[00:00:00.00]-1[00:04:55.72] /tmp/tmpMaZjhE.track01.offset667.whipper.wav
WARNING:whipper.program.cdparanoia:file size 0 did not match expected size 52209740
WARNING:whipper.program.cdparanoia:non-integral amount of frames difference
DEBUG:whipper.program.cdparanoia:getTrackQuality: frames 22198, reads 0

I get the following output:

% grep cd-paranoia whipper.log 
DEBUG:whipper.program.cdparanoia:Running cd-paranoia --stderr-progress --sample-offset=667 --force-cdrom-device /dev/sr0 1[00:00:00.00]-1[00:04:55.72] /tmp/tmpMaZjhE.track01.offset667.whipper.wav

% cd-paranoia --stderr-progress --sample-offset=667 --force-cdrom-device /dev/sr0 '1[00:00:00.00]-1[00:04:55.72]' /tmp/tmpMaZjhE.track01.offset667.whipper.wav
Sending all callback output to stderr for wrapper script
cdparanoia III release 10.2 libcdio 0.94
(C) 2001 Monty <[email protected]> and Xiphophorus
(C) 2004, 2005, 2008 Rocky Bernstein <[email protected]>
(C) 2014 Robert Kausch <[email protected]>

Report bugs to [email protected]

Time/sector offset goes beyond end of specified track.

The generated wav file is zero length.

[ghost]

@simpz: Could you try adding --force-overread to the arguments of the cd-paranoia command you executed? I think this issue might be related to the fact that your offset is quite large. (You need to be on cd-paranoia version 10.2+0.94+2 for this argument to be added.)

I think @rry1983's problem is a different problem from the others in this issue, not sure what the problem is there (especially because changing kernel versions fixed it), but it's probably related to the fact that cd-paranoia uses libcdio to communicate with the drive, while cdparanoia implemented the communication itself, AFAIK.

@rry1983: This probably won't matter, but you didn't force offset on the commands you executed. You used -o which forces the overlap search window size. To force the offset you need to use -O. (This is true for both cdparanoia and cd-paranoia.)

[simpz]

Maybe my cd-paranoia isn't new enough (even though this is the one shipped in the Fedora 27 repo which is usually pretty bleeding edge):

% cd-paranoia  -V
cdparanoia III release 10.2 libcdio 0.94
(C) 2001 Monty <[email protected]> and Xiphophorus
(C) 2004, 2005, 2008 Rocky Bernstein <[email protected]>
(C) 2014 Robert Kausch <[email protected]>

Report bugs to [email protected]

As I get
cd-paranoia: unrecognized option '--force-overread'

[ghost]

As far as I can tell, Fedora 27 branched off from rawhide on the 15th of august last year. cd-paranoia 10.2+0.94+2 was released on the 23rd of august last year, so I guess it makes sense that that version is not in Fedora 27.

[mruszczyk]

The maintainer of libcdio didn’t realize cd-paranoia had been updated or he would have pushed it to f27. As it stands he built the update with cdio 2.0 so he doesn’t want to push anything to f27 to prevent breakage. 10.2+0.94+2 is coming with F28 in May. I would test it but right now the F28 branch is hosed completely. I am curious if the version of cd-paranoia in f27 is causing a lot of these issues. I'm seeing some offset issues myself that I can't seem to track down, just haven't submitted an issue yet.

[Germano0]

@mruszczyk we could help him in making the needed updates in F27, since F27 is a supported version and bugs should be fixed

[mruszczyk]

@Germano0 I spoke with him via email. He grouped the update in with his 2.0 update builds and didn't want to push it to f27. I didn't really know what to do past that point. At the time 0.5.1 was working with xiph cdparanoia so I figured the swap to cd-paranoia would be fine but it looks like it's causing issues. Let me see if I can get a spare pc up to test 10.2+0.94+2 using dnf system upgrade. Anaconda hasn't worked for rawhide for a month or so.

EDIT: I am seeing this same behavior when attempting to offset find large numbers with libcdio 2.0.0 and the latest cd-paranoia.

whipper2.log.gz

[rry1983]

@a10footsquirrel Sorry for not mentioning it earlier. With an older kernel 2 of the 6 discs I have are able to be ripped. The other 4 still refuse to allow me to rip with the same file size 0 error no matter which of the 3 kernels I try from my grub menu.

[38github]

I have a similar problem that I have created an issue for.

[mtdcr]

I have the same issue as @simpz with a new drive with an offset of 667. I rebuilt latest libcdio and libcdio-paranoia from git and added --force-overread, but it didn't help:

$ cd-paranoia --force-overread --stderr-progress --sample-offset=667 --force-cdrom-device /dev/sr0 1[00:00:00.00]-1[00:04:50.12] /tmp/tmpYsAlCI.track01.offset667.whipper.wav
Sending all callback output to stderr for wrapper script
cdparanoia III release 10.2 libcdio 2.0.0 x86_64-pc-linux-gnu
(C) 2001 Monty <[email protected]> and Xiphophorus
(C) 2004, 2005, 2008 Rocky Bernstein <[email protected]>
(C) 2014 Robert Kausch <[email protected]>

Report bugs to [email protected]

Time/sector offset goes beyond end of specified track.

[mtdcr]

It works for me now. I patched cd-paranoia to just go ahead when this condition occurs.

diff --git a/src/cd-paranoia.c b/src/cd-paranoia.c
index 9443b62..68274db 100644
--- a/src/cd-paranoia.c
+++ b/src/cd-paranoia.c
@@ -227,7 +227,6 @@ parse_offset(cdrom_drive_t *d, char *offset, int begin)
   if( i_track != CDIO_INVALID_TRACK ){
     if (cdda_sector_gettrack(d,ret) != i_track) {
       report("Time/sector offset goes beyond end of specified track.");
-      exit(1);
     }
   }
 
@@ -1197,7 +1196,6 @@ main(int argc,char *argv[])
       for( i=track1; i<=track2; i++ )
         if(i != 0 && !cdda_track_audiop(d,i)){
          report("Selected span contains non audio track at track %02d.  Aborting.\n\n", i);
-          exit(1);
         }
 
       report("Ripping from sector %7ld (track %2d [%d:%02d.%02d])\n"

The first hunk was needed to rip any track. The second hunk was needed to rip the last track. Furthermore, I needed to run whipper with option -x to enable --force-overread for cd-paranoia, in order to rip the last two tracks. The disc I used was: https://musicbrainz.org/release/ab5d678d-361f-3d5a-8f18-7736a89eb88d

[ooglyhLL]

“I can confirm this patch helps. Thanks!”
Turns out that I spoke too soon. The last track still can't be ripped.

[mtdcr]

@ooglyhLL: Sorry, I forgot to update this patch after I had removed another line locally:

diff --git a/src/cd-paranoia.c b/src/cd-paranoia.c
index 9443b62..fbcf55d 100644
--- a/src/cd-paranoia.c
+++ b/src/cd-paranoia.c
@@ -227,7 +227,6 @@ parse_offset(cdrom_drive_t *d, char *offset, int begin)
   if( i_track != CDIO_INVALID_TRACK ){
     if (cdda_sector_gettrack(d,ret) != i_track) {
       report("Time/sector offset goes beyond end of specified track.");
-      exit(1);
     }
   }
 
@@ -235,7 +234,6 @@ parse_offset(cdrom_drive_t *d, char *offset, int begin)
 
   if( ret>cdda_disc_lastsector(d) ) {
     report("Time/sector offset goes beyond end of disc.");
-    exit(1);
   }
 
   return(ret);
@@ -1197,7 +1195,6 @@ main(int argc,char *argv[])
       for( i=track1; i<=track2; i++ )
         if(i != 0 && !cdda_track_audiop(d,i)){
          report("Selected span contains non audio track at track %02d.  Aborting.\n\n", i);
-          exit(1);
         }
 
       report("Ripping from sector %7ld (track %2d [%d:%02d.%02d])\n"

[ooglyhLL]

Brilliant! That did it. Thanks again.

[ferk6a]

@RecursiveForest I ran into the same issue and followed what you said. The result is quite weird.

$ cd-paranoia --stderr-progress --sample-offset=667 --force-cdrom-device /dev/sr0 1[00:00:00.00]-1[00:03:13.44] /tmp/tmpoEuyVd.track01.offset667.whipper.wav
Sending all callback output to stderr for wrapper script
cdparanoia III release 10.2 libcdio 2.0.0 x86_64-pc-linux-gnu
(C) 2001 Monty <[email protected]> and Xiphophorus
(C) 2004, 2005, 2008 Rocky Bernstein <[email protected]>
(C) 2014 Robert Kausch <[email protected]>

Report bugs to [email protected]

Time/sector offset goes beyond end of specified track.

And here it is... working?!

$ cd-paranoia --stderr-progress --sample-offset=667 --force-cdrom-device /dev/sr0 1 /tmp/tmpoEuyVd.track01.offset667.whipper.wav
Sending all callback output to stderr for wrapper script
cdparanoia III release 10.2 libcdio 2.0.0 x86_64-pc-linux-gnu
(C) 2001 Monty <[email protected]> and Xiphophorus
(C) 2004, 2005, 2008 Rocky Bernstein <[email protected]>
(C) 2014 Robert Kausch <[email protected]>

Report bugs to [email protected]

Ripping from sector       1 (track  1 [0:00.00])
          to sector   14520 (track  2 [0:00.-1])

outputting to /tmp/tmpoEuyVd.track01.offset667.whipper.wav

##: 0 [read] @ 21168
 (== PROGRESS == [>                             | ...... 00 ] == :^D . ==)   ##: 0 [read] @ 50568
 (== PROGRESS == [>                             | ...... 00 ] == :^D o ==)   ##: 0 [read] @ 79968
 (== PROGRESS == [>                             | ...... 00 ] == :^D 0 ==)   ##: 0 [read] @ 109368
##: 0 [read] @ 138768
 (== PROGRESS == [>                             | ...... 00 ] == :^D O ==)   ##: 0 [read] @ 168168
 (== PROGRESS == [>                             | ...... 00 ] == :^D 0 ==)   ##: 0 [read] @ 197568
 (== PROGRESS == [>                             | ...... 00 ] == :^D o ==)   ##: 0 [read] @ 226968
 (== PROGRESS == [>                             | ...... 00 ] == :^D . ==)   ##: 0 [read] @ 256368
...

The track ripped as a wav in the last command is perfect as far as I can see.

--force-overread makes no difference at all in the output, but I hope I brought some light to this issue.

[ferk6a]

Since the issue is found in GNU's implementation of cd-paranoia which uses libcdio, another "fix" is using Xiph's cdparanoia instead of cd-paranoia like the original morituri (https://github.com/thomasvs/morituri/blob/135b2f7bf27721177e3aeb1d26403f1b29116599/morituri/program/cdparanoia.py#L281-L282) (which is why it appears the work):

https://github.com/JoeLametta/whipper/blob/542e07144385638e5813148c25cf2d5e9e772412/whipper/program/cdparanoia.py#L286-L287

(by replacing the above and other lines with cdparanoia)

$ whipper offset find -o 667
Checking device /dev/sr0
Trying read offset 667 ...
Offset of device is likely 667, confirming ...
                                           
Read offset of device is: 667.
Adding read offset to configuration file.

[samliddicott]

[Commenting here as @JoeLametta suggests, as #203 is closed]

I'm not able to rip the last track of any of the CD's I have tried on any of the drives I have, whether using cdparanoia or cd-paranoia (symlink trick), and whether or not I use --force-overread

I also tried building libcdio-paranoia and libcdio from source of latest git head and cdparanoia from latest svnhead.

[My drive offset is 6 on all my drives]

abcde can rip all tracks (and much faster) but I want this to be the last time I rip my CD's, hence using whipper to do a good job (and I don't just mean adding the musicbrainz tags to the ripped tracks).

It seems a shame that the best tool has been broken for over two years because of the upstream bug. (Maybe it's only breakage for a few unlucky users)

Is handling of offsets generally broken for all tracks? I mean are they all ripping slightly wrong but it only causes a failure when there isn't enough data to read-into? libcdio/libcdio-paranoia#14 (comment) makes me wonder, as does #175

Otherwise, can't whipper detect the failure to rip, and cause, and try again without specifying the track length and let paranoia do it's best (I presume what abcde does) possibly adding a diagnostic tag to the output so it could be marked to be re-ripped perfectly in future when it works?

Also, I've got two more cd drives arriving today, I'll try with those and see how it works out.

[akostadinov]

For me at least using cdparanoia instead of cd-paranoia worked to some extend. By default it didn't want to even start copying. But disk is so broken it can't reach last track. Retrying track 2 forever. So I can't report whether last track works well or not.

[KokoseiJ]

I tried using xiph cdparanoia binary, but while it did successfully find the offset, It still bugs out at the end of the disc complaining how the size doesn't match. with --force-overread, It couldn't even read the first track, saying file size 0 did not match expected size 6491564 .

The drive I'm using is HL-DT-ST DVDRAM GH22LS50, with offset +667. Every other tracks work fine, but it bugs at the last track.

If it helps, I have 2 drives in my system- other one is HL-DT-ST DVDRAM GH24NS90 with +6 offset. This one works completely fine.

I did not prepare logs in case it's something already covered in this thread, but since it's reproducible I'll happily provide additional logs if needed.

EDIT: I also have 6 more drives made from Samsung and LG. haven't checked if they were in the database, but if you need to test with some drives I think I could help.

[WildPenquin]

Commenting here since the error messages brought me here.

First, my drive is HL-DT-ST (LG Electronics) BD-RE BH10LS30, which according to the db, should have an offset of +667. I'm using the Xiph.org cdparanoia (on Arch Linux):

$ cdparanoia --help
cdparanoia III release 10.2 (September 11, 2008)

(C) 2008 Monty <[email protected]> and Xiph.Org

Specifying offset manually with whipper (whipper offset find -o 667) fails with the error, and setting this manually in whipper configuration file prevents whipper (or cdparanoia) to rip any tracks. They all fail with the same error.

What can/should the user do as a workaround? Or are there any? Should they just manually set (a wrong) offset in their configuration file?

[davygrvy]

It has something to do with the wrong version of cdparanoia.  See the big report on this for instructions how to fix.  I'd be complete and include the link, but I'm on my cell and don't have it handyOn Nov 3, 2021 5:45 AM, WildPenguin ***@***.***> wrote: Commenting here since the error messages brought me here. First, my drive is HL-DT-ST (LG Electronics) BD-RE BH10LS30, which according to the db, should have an offset of +667. I'm using the Xiph.org cdparanoia (on Arch Linux): $ cdparanoia --help cdparanoia III release 10.2 (September 11, 2008) (C) 2008 Monty ***@***.***> and Xiph.Org Specifying offset manually with whipper (whipper offset find -o 667) fails with the error, and setting this manually in whipper configuration file prevents whipper (or cdparanoia) to rip any tracks. They all fail with the same error. What can/should the user do as a workaround? Or are there any? Should they just manually set (a wrong) offset in their configuration file? —You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android.

[WildPenquin]

Hi @davygrvy , and thanks for your reply!

I got confused somehow and thought whipper is using Xiph.org's cdparanoia, although it isn't.

In any case, I could not find any clear way of working around this here or in the cdio-paranoia bug report. That's why I asked.

Anyways it seems whipper (python?) respects PATH, so I can use Xiph.org's cdparanoia by making a symlink in $HOME/bin (since that is in my search $PATH before /usr/bin): ln -s /usr/bin/cdparanoia $HOME/bin/cd-paranoia. Now whipper seems to work to some extend, finds the offset correctly etc.; but ripping the last track fails, and Xiph.org's cdparanoia does not have the option --force-overread.

So, in which way (specifically) can I work with whipper? Is the only way patching lbcdio-cdparanoia at the moment? Which patch should actually work? Or does/should Xiph.org's cdparanoia work? From the comments this seems a bit unclear to me (on a drive with a large offset such as mine +667).

[tsweet64]

Just a thought (maybe there's a good reason this isn't done, idk), but what if we access libcdio-paranoia via the cdda2wav binary instead of cd-paranoia or cdparanoia? Ironically cdda2wav seems to give even more options for controlling paranoia (see the manpage) than cd-paranoia does. Might require some major reworking, but would it be a possible solution?

Unlike cd-paranoia, cdda2wav does not seem to experience this glitch when ripping the last track with an offset of 667. cyanrip, another project (which implements libcdio-paranoia itself, rather than calling an executable) also succeeds.

Only problem is, the --offset flag on cdda2wav seems to work differently and I can't immediately determine why. It cuts off several seconds of the audio when I specify 667. Maybe this option is a no-go after all...

[WildPenquin]

Hopefully I'm not going too much off tanget here, but isn't part of the problem just these drives being bad H/W with too large off an offset? Then SW developers are just pulling their hair out trying to get the drives working by making software workarounds for crappy hardware ;-).

Personally, I've "solved" this by using an old MBP for ripping instead of my problematic desktop computer drive; I've noticed it uses a much smaller offset, and does not have problems with clearing cache. I get much faster and consistent rips with it anyways (with whipper or cyanrip, or probably any SW using cdparanoia).

Still, it would be nice to get these drives working somewhat.

[mdosch]

Since I can't use whipper anymore due to this bug I found fre:ac which is also available for Linux as a temporary replacement. It can check the ripped tracks with accuraterip and is what I am using for a while now. Of course I would still prefer to use whipper as I prefer KISS CLI and TUI applications but maybe this is also helpful as a workaround for others to get verified rips while whipper is not working due to this cdparanoia bug.

[mdosch]

I figured out that using cdparanoia instead of cd-paranoia fixes the bug as well. Just replace cd-paranoia with cdparanoia in all source files.

[45054]

Unfortunately switching back to cdparanoia would re-introduce a bunch of bugs that were fixed in cd-paranoia. Most notably #74

[mdosch]

So people with "high offset devices" can either choose on using a working but buggy cdparanoia or a less buggy but not working cd-paranoia. That's not really a comfortable situation but whipper can'T change anything there. I also see that upstream seems not realliy interested in this issue.

…

On 18.09.2022 16:48, 45054 wrote: Unfortunately switching back to cdparanoia would re-introduce a bunch of bugs that were fixed in cd-paranoia. Most notably #74 -- Reply to this email directly or view it on GitHub: #234 (comment) You are receiving this because you commented. Message ID: ***@***.***>

[Viktini]

I also see that upstream seems not realliy interested in this issue.

Well that actually sucks. What drives or offsets are known to work with new cdparanoia? Asking since I am buying a new blu-ray drive.

[buddyabaddon]

I believe I have a fix for this issue libcdio/libcdio-paranoia#38.

If others with different drive offsets can help test (mine is +667), I'd like to hear your results.

You'll need to build libcdio-paranoia with my change and use it with Whipper.

[mdosch]

That's great news, I will try to build cd-paranoia with your patch and give it a try.

…

On 16.02.2024 04:29, buddyabaddon wrote: I believe I have a fix for this issue libcdio/libcdio-paranoia#38. If others with different drive offsets can help test (mine is +667), I'd like to hear your results. You'll need to build libcdio-paranoia with my change and use it with [Whipper](https://github.com/whipper-team/whipper). -- Reply to this email directly or view it on GitHub: #234 (comment) You are receiving this because you commented. Message ID: ***@***.***>

[iMartyn]

I can confirm that once I fought with autotools (what year are we in, 1995? Saving space by not creating ./configure automatically...) for long enough, your patched version worked perfectly for my +667 drive. Very happy to see this working, big thanks!

[buddyabaddon]

what year are we in, 1995?

I mean, you are ripping audio CDs ;) - Glad to hear it's working for you too though!

As a side-note, I managed to get my hands on an old drive with a negative sample read offset so I can dig into libcdio-paranoia handling in such scenarios. I suspect there are other issues there as well.

[harry-newton]

I can also confirm the patched version worked for my +667 drive. Like iMartyn and others I'm very happy to see this working.

/H

[MerlijnWajer]

Great to see the collaboration and good to see there's a fix in place now. I think we can close this merge request, unless we want to print some hint in whipper in the version isn't as high as required?

[Viktini]

Can confirm it works on Fedora without manual recompilation now the patched version has made it upstream. 👍 (Fedora 40, Pioneer BDR-XS07U / +667, libcdio-paranoia 10.2+2.0.1-12.fc40)

[nis]

libcdio-paranoia is updated in NixOS unstable.
I'm not on the unstable channel, but a shell with whipper from unstable is easy.

nix-shell -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/nixpkgs-unstable.tar.gz -p whipper

Apart from the many warnings, the rip finished perfectly with my BDR-UD04 and a +667 offset.