Final track rip failure due to file size mismatch

[EReckase]

Just installed whipper, testing it out with a short single in my collection, and the final track fails to rip. Log inspection shows:

WARNING:morituri.program.cdparanoia:file size 43941932 did not match expected size 44034188

for each attempt.

cmdline:
WHIPPER_DEBUG=DEBUG WHIPPER_LOGFILE=whipper.log whipper cd rip -L morituri

config:

[drive:HL-DT-ST%3ABD-RE%20%20WH12LS38%20%3A1.00]
vendor = HL-DT-ST
model = BD-RE  WH12LS38
release = 1.00
defeats_cache = True
read_offset = 667
[rip.cd.rip]
unknown=True
output_directory = ~/rips
track_template = new/%%A - %%y - %%d/%%t - %%n
disc_template = %(track_template)s
profile = flac

whipper.log.txt

Note that this happens for every disc I try to rip, not just this one. The last track has a file size mismatch and crashes with a RuntimeError.

Running on xubuntu 16.04.

[EReckase]

cdrdao read-toc --fast-toc --device /dev/sr0 ~/cdrdao_fast.toc
Cdrdao version 1.2.3 - (C) Andreas Mueller <[email protected]>
/dev/sr0: HL-DT-ST BD-RE  WH12LS38	Rev: 1.00
Using driver: Generic SCSI-3/MMC - Version 2.0 (options 0x0000)

Reading toc data...

Track   Mode    Flags  Start                Length
------------------------------------------------------------
 1      AUDIO   0      00:00:33(    33)     06:34:00( 29550)
 2      AUDIO   0      06:34:33( 29583)     06:13:00( 27975)
 3      AUDIO   0      12:47:33( 57558)     04:09:47( 18722)
Leadout AUDIO   0      16:57:05( 76280)

PQ sub-channel reading (audio track) is supported, data format is BCD.
Raw P-W sub-channel reading (audio track) is supported.
Analyzing track 01 (AUDIO): start 00:00:33, length 06:34:00...
Found pre-gap: 00:00:33
Analyzing track 02 (AUDIO): start 06:34:33, length 06:13:00...
Analyzing track 03 (AUDIO): start 12:47:33, length 04:09:47...
Found disk catalogue number.
        	
Reading of toc data finished successfully.

cdrdao_fast.toc.txt

[EReckase]

>soxi /tmp/tmp7EFoea.morituri.wav

Input File     : '/tmp/tmp7EFoea.morituri.wav'
Channels       : 2
Sample Rate    : 44100
Precision      : 16-bit
Duration       : 00:04:09.63 = 11008536 samples = 18722 CDDA sectors
File Size      : 43.9M
Bit Rate       : 1.41M
Sample Encoding: 16-bit Signed Integer PCM

The file is indeed smaller than would be expected (43941932) for that number of sectors.

[EReckase]

It appears that this may be the cdparanoia issue, I have not installed the patched version apparently. Working on that.

[EReckase]

My bad. Works fine with patched cdparanoia.

[JoeLametta]

My bad. Works fine with patched cdparanoia.

Good, thanks for pinpointing the cause.

That cdparanoia bug is known and, considering it affects whipper too, it might be a wise idea to mention it somewhere in whipper's README.

I'm curious: could you test if that same rip operation fails using libcdio-paranoia?

cd-paranoia --stderr-progress --sample-offset=667 --force-cdrom-device /dev/sr0 3[00:00:00.00]-3[00:04:09.46] $HOME/whipper-test.wav`

I'm asking this because whipper is going to switch to libcdio-paranoia (#87) in the near future and I don't know if libcdio-cdparanoia has the same problem "plain" cdparanoia has.

Thanks in advance,

Joe

[EReckase]

./cd-paranoia --stderr-progress --sample-offset=667 --force-cdrom-device /dev/sr0 3[00:00:00.00]-3[00:04:09.46] $HOME/whipper-test.wav
Sending all callback output to stderr for wrapper script
cdparanoia III release 10.2 libcdio 0.83 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.

Looks like it has the same problem, but at least it knows it before it starts ripping into uncharted territory.

[rocky]

@EReckase when you write:

Works fine with patched cdparanoia.

what patch are you referring to and where does one get it?

[EReckase]

Not sure where I saw it in the issue tracker, but this is what I applied to the cdparanoia source:

https://gist.github.com/AnwarShah/560d77f7d7da52553f918f3ecb7401e3

I imagine that it just needs to get applied to cdio-paranoia, @rocky. Thanks for your work on that lib!

[JoeLametta]

what patch are you referring to and where does one get it?

I think the original source of the patch is mustbenice (this is the initial "single" patch).
He posted the "full" patch in the paranoia-dev's mailing list.

[rocky]

Ok. Thanks for the information. A pull request is in review libcdio/libcdio-paranoia#11

Everyone please feel free to comment, or correct it. It would also be nice to get a test case for that problem.

Thanks again.