Re: [Libcdio-devel] Fedora bug report concerning CD-TEXT

[Thomas Schmitt]

Hi,

after the libcdio CD-TEXT problems seem to be diagnosed and
on the way of being fixed, i now look at cdrdao's source.
(On Debian 8 i had to comment out a stat(2) call in
 ./dao/ScsiIf-linux.cc because of strange C++ problems.)

First observation: Like libcdio it does not implement text
repetition by single TAB.
Second: A colorful zoo of drivers for unstandardized 1990s
hardware obscures the activities around ISRC reading.

By help of gdb i could catch cdrdao when it issues SCSI command
BEh READ CD with Sub-channel Selection Bits set to 1:
  ./dao/CdrDriver.cc : CdrDriver::analyzeTrackScan()
  ./dao/GenericMMC.cc : GenericMMC::readSubChannels()
This command is used to read all of the track data.

The MMC-4 specs say in table 353 and  6.24.3.2.2:
  "001b | RAW P-W Sub-channel data shall be returned."
  "Raw P-W sub-channel is the 96 bytes of sub-channel returned
   in the order received from the disc surface."
The complete command is
  {0xbe, 0x00, 0x00, 0x00, 0x18, 0xcf, 0x00, 0x00, 0x1a, 0xf8,
   0x01, 0x00}
>From the reply it picks the ISRC. (Probably returned by the command
multiple times while it is applied to the whole track.)

So the SCSI commands for obtaining ISRC differ between libcdio
and cdrdao.
The command used by libcdio is deprecated since MMC-5.
The command used by cdrdao is not deprecated but implies reading
a substantial part of the track before the first ISRC appears in
sub-channel data.


It is possible that the command 42h READ SUB-CHANNEL is broken
on contemporary drives and gives libcdio wrong replies.
But before blaming the drive firmware, it might be worth a try to
set in
  libcdio-0.93/lib/driver/mmc/mmc.c
the transfer length to the value 24 that is actually described in
MMC-4 and not to 28, as given by the buffer size.

--- lib/driver/mmc/mmc.c.orig   2014-09-25 03:19:42.000000000 +0200
+++ lib/driver/mmc/mmc.c        2016-04-01 11:20:19.949259693 +0200
@@ -551,7 +551,7 @@ mmc_get_track_isrc_private ( void *p_env
                              )
 {
   mmc_cdb_t cdb = {{0, }};
-  char buf[28] = { 0, };
+  char buf[24] = { 0, };
   int i_status;
 
   if ( ! p_env || ! run_mmc_cmd )

Best would be to apply the two-step approach of first executing
with transfer length 4, learning the Sub-channel Data Length from
bytes 2 and 3 of the reply, and then re-execute with a transfer
length of 4 more than the told value.


(My motivation to implement ISRC reading from sub-channel in
 libburn is now very low. What a swamp.)


Have a nice day :)

Thomas