Re: [Libcdio-devel] CD_MSF_FORMAT vs LBA on NetBSD

[Thomas Schmitt]

Hi,

> Thanks for your on-going patience.

I was in no way bored. (And now there is a potential problem of my own
software with 32-bit GNU/Linux, at least with Guix. Grrr.)


> If I print the computed leadout for my 5-track CD starting at 7:
> ...
> Clearly the leadout track should be 12, not 6.

So this is decided now.


> https://github.com/vext01/libcdio/commit/539c52488506c5bacdfebbcafc5406034a0
738fd

Looks ok, so far.

> Note however that the cd-info output is correct both before and after this
> fix

The index for _obj->tocent[] is 5 in original old and current new state.

But i would really be surprised if it worked with the intermediate state
where this was already in place:

  track_idx = track_num - first_track;
  msf->m = cdio_to_bcd8(_obj->tocent[track_idx].addr.msf.minute);

but the conversion from CDIO_CDROM_LEADOUT_TRACK was still:

  track_num = TOTAL_TRACKS + 1;

The original state was:

  track_num = TOTAL_TRACKS + 1;
  ...
  msf->m = cdio_to_bcd8(_obj->tocent[track_num - 1].addr.msf.minute);

So the access to CDIO_CDROM_LEADOUT_TRACK was obviously the only one that
was correct (on NetBSD, see below) if first_track was larger than 1.

------------------------------------------------------------------------

Now there is still a problem remaining down in the netbsd.c driver, which
by a long shot guess i blame on differences between NetBSD and OpenBSD:

>  11: 09:41:34  043459 audio  false  no    0        no
> 170: 09:41:34  043459 leadout (97 MB raw, 97 MB formatted)

lead-out should start after track 11, not at the same address.
What do you get from this run ?

  cdrskin dev=/dev/... -toc

My test CD yields

  ...
  first: 4 last 6
  track:   4 lba:         0 (        0) 00:02:00 adr: 1 control: 0 mode: 0
  track:   5 lba:      2682 (    10728) 00:37:57 adr: 1 control: 0 mode: 0
  track:   6 lba:      5364 (    21456) 01:13:39 adr: 1 control: 0 mode: 0
  track:lout lba:      8046 (    32184) 01:49:21 adr: 1 control: 0 mode: -1
  Media summary: 1 sessions, 3 tracks, closed CD-RW


Track number 170 = 0xAA is indeed CDIO_CDROM_LEADOUT_TRACK. So cd-info
is not mislead in this case.

If so, then in lib/driver/netbsd.c we have
  track_num = 5 + 7 = 12
  track_idx = 12 - 7 = 5
The start address is then taken from
  _obj->tocent[5]
by .addr.msf.minute, .addr.msf.second, and .addr.msf.frame.

Can you verify that the values of track_idx == 4 and track_idx == 5
are indeed identical on OpenBSD ?

The values seem to come from netbsd.c function _cdio_read_toc() which gets
them directly from ioctl(CDIOREADTOCENTRIES):

        req.data_len = (TOTAL_TRACKS + 1) /* leadout! */
                * sizeof(struct cd_toc_entry);
        req.data = _obj->tocent;

        res = ioctl(_obj->gen.fd, CDIOREADTOCENTRIES, &req);

I fail to find out whether this ioctl is supposed to deliver lead-out info
on track (last_track + 1) rather than on track 0xAA.

It might be worth to reduce req.data_len to

        req.data_len = TOTAL_TRACKS * sizeof(struct cd_toc_entry);

and to do a separate call of ioctl(CDIOREADTOCENTRIES) with

       req.starting_track = 0xAA;
       req.data_len = sizeof(struct cd_toc_entry);
       req.data = ((char *) _obj->tocent) +
                   TOTAL_TRACKS * sizeof(struct cd_toc_entry);

(I am unsure whether (_obj->tocent + TOTAL_TRACKS) yields the right offset.)

If this works on OpenBSD, it must be tested whether it works with NetBSD.
Doubts come from comparing

  
https://ligurio.github.io/openbsd-tests/6.0/coverage.sbin_mount_udf_mount_udf.c.html

which does it separately with starting_track = CD_TRACK_LEADOUT (= 0xAA),
against

  
https://ftp.st.ryukoku.ac.jp/pub/NetBSD/NetBSD-release-8/src/usr.sbin/mscdlabel/main.c

which does it like libcdio's netbsd.c in a combined ioctl call.

--------------------------------------------------------------------------

A small problem in cd-info.c:

> CD-ROM Track List (7 - 5)

Shouldn't that be "(7 - 11)" ?
I see in libcdio/src/cd-info.c :

    printf("CD-ROM Track List (%i - %i)\n" NORMAL,
           i_first_track, i_tracks);

where "i_tracks" probably should be "i_first_track + i_tracks - 1".

Do you agree ?

--------------------------------------------------------------------------

Have a nice day :)

Thomas