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
