cdrdao does not properly detect toc encoding

[MerlijnWajer]

(Note: This is currently a stub-ticket, useful for me to keep track of the various things I need to look at; I will add more info over time and remove this note)

I currently have about 10 CDs which exhibit this error (probably more, but it's non fatal for those):

Reading toc data... WARNING: Could not determine if raw toc data is BCD or HEX. Please report! WARNING: Using TOC data retrieved with generic method (no multi session support). WARNING: Use driver option 0x80000 or 0x100000 to assume BCD or HEX data.

This is fatal for issues that have more than one session. In this case whipper/morituri will try to read from each of the sessions, but since CDRDAO cannot detect the raw toc data encoding, it will simply always return the same, regardless of the session that whipper/morituri is trying to read.

In the case of two sessions, with the first session containing 13 audio tracks, and the second session containing two data tracks, you end up with a whopping '26' tracks in whipper/morituri. And it will try to rip all of them.

I have made a bin/cue copy of a few of the CDs that raise this error, burned them to a CD, and examined that the same behaviour occurs. I will upload them to one of my servers later so that others can hopefully help debugging the issue.

[MerlijnWajer]

Of course, if a CD has only one session, not being able to detect the encoding of the raw toc data is not fatal, but it would still be good to get this fixed.

I will also attempt to contact cdrdao developers shortly

[MerlijnWajer]

By the way, one can force such a driver option like so:

--driver generic-mmc:0x100000

Or --driver generic-mmc:0x80000

Use with cdrdao read-toc

[MerlijnWajer]

I will use this GH issue to make a log of CDs that exhibit this problem. I've found that forcing hex for multi-session CDs working in for my 10 CDs. But other CDs where cdrdao also cannot properly detect the TOC fail when forced into hex mode, at the last track.

[MerlijnWajer]

https://archive.org/details/cd_limin

(This issue might not completely apply to whipper, as whipper will likely fail earlier in the process)

Title: 請你不要哭 Artist: 李蕙敏 MB DiscID: u3wSfEympm7hQTBP8Nwyozy6UkA-

Has only one session and no data tracks.

Reading toc data... WARNING: Could not determine if raw toc data is BCD or HEX. Please report! WARNING: Using TOC data retrieved with generic method (no multi session support). WARNING: Use driver option 0x80000 or 0x100000 to assume BCD or HEX data.

When forcing HEX TOC, the TOC is off by a second or two at the end, and will fail ripping the last track (both are done with --fast-toc):

Reading toc data...

Track   Mode    Flags  Start                Length
------------------------------------------------------------
 1      AUDIO   0      00:00:00(     0)     04:41:57( 21132)
 2      AUDIO   0      04:41:57( 21132)     04:17:05( 19280)
 3      AUDIO   0      08:58:62( 40412)     03:23:23( 15248)
 4      AUDIO   0      12:22:10( 55660)     04:12:10( 18910)
 5      AUDIO   0      16:34:20( 74570)     03:05:37( 13912)
 6      AUDIO   0      19:39:57( 88482)     04:33:63( 20538)
 7      AUDIO   0      24:13:45(109020)     04:17:07( 19282)
 8      AUDIO   0      28:30:52(128302)     02:12:30(  9930)
 9      AUDIO   0      30:43:07(138232)     03:52:68( 17468)
10      AUDIO   0      34:36:00(155700)     04:24:62( 19862)
Leadout AUDIO   0      39:00:62(175562)

With this toc, cdparanoia will read beyond the end of track 10:

Sending all callbacks to stderr for wrapper script
cdparanoia III release 10.2 (September 11, 2008)

401: Invalid track number
Time/sector offset goes beyond end of specified track.

Generic will report this:

------------------------------------------------------------
 1      AUDIO   0      00:00:00(     0)     04:41:57( 21132)
 2      AUDIO   0      04:41:57( 21132)     04:17:05( 19280)
 3      AUDIO   0      08:58:62( 40412)     03:23:23( 15248)
 4      AUDIO   0      12:22:10( 55660)     04:12:10( 18910)
 5      AUDIO   0      16:34:20( 74570)     03:05:37( 13912)
 6      AUDIO   0      19:39:57( 88482)     04:33:63( 20538)
 7      AUDIO   0      24:13:45(109020)     04:17:07( 19282)
 8      AUDIO   0      28:30:52(128302)     02:12:30(  9930)
 9      AUDIO   0      30:43:07(138232)     03:53:35( 17510)
10      AUDIO   0      34:36:42(155742)     04:24:20( 19820)
Leadout AUDIO   0      39:00:62(175562)

cdparanoia III release 10.2 (September 11, 2008)

Table of contents (audio tracks only):
track        length               begin        copy pre ch
===========================================================
  1.    21132 [04:41.57]        0 [00:00.00]    no   no  2
  2.    19280 [04:17.05]    21132 [04:41.57]    no   no  2
  3.    15248 [03:23.23]    40412 [08:58.62]    no   no  2
  4.    18910 [04:12.10]    55660 [12:22.10]    no   no  2
  5.    13912 [03:05.37]    74570 [16:34.20]    no   no  2
  6.    20538 [04:33.63]    88482 [19:39.57]    no   no  2
  7.    19282 [04:17.07]   109020 [24:13.45]    no   no  2
  8.     9930 [02:12.30]   128302 [28:30.52]    no   no  2
  9.    17510 [03:53.35]   138232 [30:43.07]    no   no  2
 10.    19820 [04:24.20]   155742 [34:36.42]    no   no  2
TOTAL  175562 [39:00.62]    (audio only)

I believe whipper will fail here with a non matching toc and table.

Will upload the image later this week (for debugging purposes only).

[JoeLametta]

I will also attempt to contact cdrdao developers shortly

Did they reply to you?