Hi,
during discussion of problems after Edd Barrett added code from OpenBSD
driver to NetBSD driver, i spotted that the old code in netbsd.c assumes
track numbering to start with 1.
CD track numbers are not sorting ranks but mere attributes of the
track entry in the table of content. MMC-1 (i.e. very old and CD-only)
says in the description of command READ DISC INFORMATION:
"Valid track numbers are from 01h to 63h. The first track number is
not required to be one. A disc may start with any valid track number.
The track numbers between the first and last track number shall be in
contiguous ascending order, except for lead-out areas."
Later versions of MMC are less specific about the gapless ascending order.
Let's compare libcdio's netbsd.c with gnu_linux.c :
get_track_msf_linux():
if (i_track > (p_env->gen.i_tracks+p_env->gen.i_first_track)
|| i_track < p_env->gen.i_first_track) {
return false;
} else {
struct cdrom_msf0 *msf0=
&p_env->tocent[i_track-p_env->gen.i_first_track].cdte_addr.msf;
(Function pointer .get_track_lba is NULL in gnu_linux.c.)
get_track_msf_netbsd() (This is the old one in netbsd.c):
if (track_num > TOTAL_TRACKS + 1 || track_num == 0)
return false;
msf->m = cdio_to_bcd8(_obj->tocent[track_num - 1].addr.msf.minute);
get_track_lba_netbsd() (This is the one imported from OpenBSD):
if (!p_env->gen.toc_init ||
i_track > (p_env->gen.i_first_track + p_env->gen.i_tracks) ||
i_track < p_env->gen.i_first_track)
return (CDIO_INVALID_LBA);
return (p_env->tocent[i_track - p_env->gen.i_first_track].addr.lba +
CDIO_PREGAP_SECTORS);
So the functions for Linux and OpenBSD expected first track number != 1,
the old function for NetBSD does not.
A similar difference is to see between
get_track_format_linux()
and
get_track_format_netbsd()
-------------------------------------------------------------------------
I propose to beef up both netbsd.c functions so they take into respect
that p_env->gen.i_first_track can be larger than 1:
get_track_msf_netbsd()
get_track_format_netbsd()
Due to lack of testing opportunities with real iron, i cannot submit a
tested patch. The change itself is not complicated. But heavy testing
would be needed.
If we need to produce a test CD with start track number != 1, i could
propose a run of cdrskin with option "cd_start_tno=". (Should work on
both BSDs in question. Much cdrecord knowledge can be recycled with cdrskin.)
Have a nice day :)
Thomas
