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

[Rocky Bernstein]

Thomas - thanks yet again for digging into this deeply, comparing with MMC
specs and cdrdao. Sure, change mmc as given above, and add a routine to try
the 2-step approach if that's the way you think best.

As for overall code design, let me review how I've broken out the code. The
file mmc_hl.c was intended for this kinds of approaches where we try a
couple of ways to do get a logical function done using more lower-level
primitives in mmc_ll.c and mmc.c.

Fee free to make a branch in github for this, for example called,
cdtext-isrc  and make the changes there. If you are not comfortable with
github or don't want to make the changes directly there, Just send them to
me or put them in a libcdio patch request and I'll take care of that.

Again, thanks.

On Fri, Apr 1, 2016 at 5:34 AM, Thomas Schmitt <address@hidden> wrote:

> 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
>
>
>