cdparanoia toc does not agree with cdrdao-toc, cd-paranoia also reports different (but better) lengths

[MerlijnWajer]

CD UPC: 094635010220 Seems to be this CD: https://mojim.com/tw104790x1.htm

I will make a cue/bin copy of it for later analysis, but it causes failures when ripping the last track, since cdparanoia and cdrdao do not agree on the track length. cd-paranoia gets is more right, seemingly? (Need to verify that this holds true)

cdrdao

Cdrdao version 1.2.3 - (C) Andreas Mueller <andreas@daneb.de>
/dev/sr0: ATAPI iHAS124   F Rev: CL9E
Using driver: Generic SCSI-3/MMC - Version 2.0 (options 0x100000)

Reading toc data...

Track   Mode    Flags  Start                Length
------------------------------------------------------------
 1      AUDIO   0      00:00:00(     0)     03:17:71( 14846)
 2      AUDIO   0      03:17:71( 14846)     04:09:35( 18710)
 3      AUDIO   0      07:27:31( 33556)     03:40:42( 16542)
 4      AUDIO   0      11:07:73( 50098)     03:53:01( 17476)
 5      AUDIO   0      15:00:74( 67574)     04:00:40( 18040)
 6      AUDIO   0      19:01:39( 85614)     03:38:31( 16381)
 7      AUDIO   0      22:39:70(101995)     05:18:14( 23864)
 8      AUDIO   0      27:58:09(125859)     03:23:64( 15289)
 9      AUDIO   0      31:21:73(141148)     03:05:34( 13909)
10      AUDIO   0      34:27:32(155057)     03:19:05( 14930)
11      AUDIO   0      37:46:37(169987)     03:47:22( 17047)
Leadout AUDIO   0      41:33:59(187034)

cdparanoia

cdparanoia -Q
cdparanoia III release 10.2 (September 11, 2008)

Table of contents (audio tracks only):
track        length               begin        copy pre ch
===========================================================
  1.    14846 [03:17.71]        0 [00:00.00]    no   no  2
  2.    18710 [04:09.35]    14846 [03:17.71]    no   no  2
  3.    16542 [03:40.42]    33556 [07:27.31]    no   no  2
  4.    17476 [03:53.01]    50098 [11:07.73]    no   no  2
  5.    18040 [04:00.40]    67574 [15:00.74]    no   no  2
  6.    16381 [03:38.31]    85614 [19:01.39]    no   no  2
  7.    23864 [05:18.14]   101995 [22:39.70]    no   no  2
  8.    15289 [03:23.64]   125859 [27:58.09]    no   no  2
  9.    13909 [03:05.34]   141148 [31:21.73]    no   no  2
 10.    14930 [03:19.05]   155057 [34:27.32]    no   no  2
 11.    28447 [06:19.22]   169987 [37:46.37]    no   no  2
 13.       31 [00:00.31]   332819 [73:57.44]    no   no  2
TOTAL  198465 [44:06.15]    (audio only)

cd-paranoia (libcdio)

cdparanoia III release 9.8 libcdio 0.83 x86_64-pc-linux-gnu
(C) 2001 Monty <monty@xiph.org> and Xiphophorus
(C) 2004, 2005, 2008 Rocky Bernstein <rocky@gnu.org>

Report bugs to bug-libcdio@gnu.org

Table of contents (audio tracks only):
track        length               begin        copy pre ch
===========================================================
  1.    14846 [03:17.71]        0 [00:00.00]    no   no  2
  2.    18710 [04:09.35]    14846 [03:17.71]    no   no  2
  3.    16542 [03:40.42]    33556 [07:27.31]    no   no  2
  4.    17476 [03:53.01]    50098 [11:07.73]    no   no  2
  5.    18040 [04:00.40]    67574 [15:00.74]    no   no  2
  6.    16381 [03:38.31]    85614 [19:01.39]    no   no  2
  7.    23864 [05:18.14]   101995 [22:39.70]    no   no  2
  8.    15289 [03:23.64]   125859 [27:58.09]    no   no  2
  9.    13909 [03:05.34]   141148 [31:21.73]    no   no  2
 10.    14930 [03:19.05]   155057 [34:27.32]    no   no  2
 11.    17047 [03:47.22]   169987 [37:46.37]    no   no  2
 13.       31 [00:00.31]   332819 [73:57.44]    no   no  2
TOTAL  187065 [41:34.15]    (audio only)

[MerlijnWajer]

cdparanoia indeed tries to rip 6 minutes of data, but fails halfway. Suggesting that it indeed gets the toc wrong.

[carnager]

try cdparanoia with the overread patches

[RecursiveForest]

That's fascinating. Do you know why cd-paranoia (libcdio) is reporting 31 frames as track 13, but cdrdao reports them as part of the leadout? Is there an entry for track 13 in the lead-in Q subchannel data?

What does EAC say?

[JoeLametta]

@MerlijnWajer

cd-paranoia (libcdio)

Don't know if it changes the outcome but keep in mind that you're using an ancient version of that software. (Latest tagged one being: cdparanoia III release 10.2 libcdio 0.94)

[MerlijnWajer]

I am not so sure if the overread patches matter. But I have confirmed that cd-paranoia (from libcdio) seems to get it right every time where cdparanoia gets it wrong. Have about 7 CDs that exhibit this problem.

Have not tried it with EAC. Can share some copies of the CDs?

libcdio gets it right, so I don't think the matter necessarily matters here.

[MerlijnWajer]

I have code to switch between implementations. Will try to commit that soon.

[RecursiveForest]

Sharing copies of the CD = the fast way to get my eyes on a problem. I also don't mind spending some money to buy copies if we can't bin/cue/write them easily.

[RecursiveForest]

regarding switching, is that something we want to be togglable at the user level, or should we just force the switch? I can see good cases for both.

[MerlijnWajer]

I have about 9 more in my possession for at least another week, and copies of several of them. The solution was simply to switch to libcdio cd-paranoia, as it does get it correctly. I at this point see little use in staying with cdparanoia.

[MerlijnWajer]

I would go for something like --cdparanoia-implementation <bin-name> and default to libcdio-cdparanoia?

[RecursiveForest]

I am also convinced that a switch to cd-paranoia is the right thing to do, although having an interim period where we allow fallback to cdparanoia might ease the transition / help sort out bugs. I'm not sure if adding even more complexity / more runtime options is good long term though, which is why I wouldn't want such a flag to stay around forever. I'd be happy with it if we had a concrete milestone after which we would drop --cdparanoia-implementation.

I still want to keep this issue open because right now we're still planning on using cdrdao for reading the toc, and places where it differs from cd-paranoia are important.

[JoeLametta]

I'd be happy with it if we had a concrete milestone after which we would drop --cdparanoia-implementation.

Maybe we can schedule it for milestone 2.0?

I am not so sure if the overread patches matter.

It still seems to be something useful even for cd-paranoia (libcdio): see here.

[JoeLametta]

Shall I close this one? (because of #213).

[JoeLametta]

Closed because of #213.