libcdio-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] check_cue.sh failing with cdda_4_5 image on MinGW


From: Thomas Schmitt
Subject: Re: [Libcdio-devel] check_cue.sh failing with cdda_4_5 image on MinGW
Date: Wed, 20 May 2020 09:29:00 +0200

Hi,

i had a look at _cdio_get_track_msf in lib/driver/MSWindows, because i
assumed that this would be used with MinGW.

The driver seems only partly prepared for start track number > 1.
But i cannot derive the particular mistake of cd-info from what i see in
the code.

So which driver is in effect with that failed test ?

-------------------------------------------------------------------------
What's wrong with lib/driver/MSWindows:

The implementation of .get_track_msf does not subtract the track number
offset, but rather subtracts 1 before using its parameter i_tracks as
index to p_env->tocent[].

  ...
    The "leadout" track is specified either by
    using i_tracks LEADOUT_TRACK or the total tracks+1.
  ...
  */
  static bool
  _cdio_get_track_msf(void *p_user_data, track_t i_tracks, msf_t *p_msf)
  {
    ...
    if (i_tracks == CDIO_CDROM_LEADOUT_TRACK) i_tracks = p_env->gen.i_tracks+1;

    if (i_tracks > p_env->gen.i_tracks+1 || i_tracks == 0) {
      return false;
    } else {
      cdio_lsn_to_msf(p_env->tocent[i_tracks-1].start_lsn, p_msf);
      return true;
    }

The two implementations of reading the Table-Of-Content subtract the
track number offset when filling p_env->tocent.

lib/driver/MSWindows/aspi32.c : read_toc_aspi

    p_env->gen.i_tracks  = tocheader[3] - tocheader[2] + 1;
    ...
      for( i = 0 ; i <= p_env->gen.i_tracks ; i++, j++ ) {
        ...
        p_env->tocent[ i ].start_lsn = ...

lib/driver/MSWindows/win32_ioctl.c : read_toc_win32ioctl

    p_env->gen.i_tracks  = cdrom_toc.LastTrack - cdrom_toc.FirstTrack + 1;
    ...
    for( i = 0 ; i <= p_env->gen.i_tracks ; i++, j++ ) {
      p_env->tocent[ i ].start_lsn =

So to deliver the correct entries, _cdio_get_track_msf() has to be called
with i_tracks = tocent index + 1. I.e. first valid i_tracks is 1, not
the nominal first track number.

But src/cd-info.c calls cdio_get_track_msf and thus win32.c
_cdio_get_track_msf with indice from a loop starting at the nominal
first track number:

    for (i = i_first_track; i <= CDIO_CDROM_LEADOUT_TRACK; i++) {
      ...
      if (!cdio_get_track_msf(p_cdio, i, &msf)) {
        ...
      ...
      /* skip to leadout */
      if (i == i_first_track + i_tracks - 1) {
        i = CDIO_CDROM_LEADOUT_TRACK-1;
      }
    }

So it seems not much of a riddle why the leadout LSN and MSF are wrong.
But why then is the cd-info line for track 5 correct ?
Why does win32.c:_cdio_get_track_msf not bail out by this test
when i_tracks is 4 or 5 ? (p_env->gen.i_tracks is supposed to be 2.)

      if (i_tracks > p_env->gen.i_tracks+1 || i_tracks == 0) {
        return false;

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


Have a nice day :)

Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]