Re: [Libcdio-devel] Ready for merging: libcdio branch trackno-higher-one

[Thomas Schmitt]

Hi,

i wrote:
> > So does cd-info not read the FILE name from .cue ?

Rocky Bernstein wrote:
> If only there was some way an open source project had available where this
> could be figured out....

Asking is faster than code digging. Further, this is only a small problem
on the way to a test for start track number > 1 in a .cue file.
I will need help, at least with the libcdio housekeeping aspects of the task.


Edd Barrett wrote:
> I noticed that in cd-paranoia, if you pass `-d some.bin` it assumes that
> it should look at `some.cue`. Perhaps the same for `cd-info`?

I now tried

  $ cd test && ../src/cd-info --no-device-info --cue-file 
data/cdda_track_4_5.cue -d cdda.bin

and still get

  ++ WARN: could not retrieve file info for `data/cdda_track_4_5.bin': No such 
file or directory
  ++ WARN: init failed
  cd-info: data/cdda_track_4_5.cue: Error in opening CDRWin BIN/CUE image for 
CUE input 

When i try
  ... --cue-file data/cdda_track_4_5.cue -b cdda.bin
i get

  cd-info: another source type option given before.
  cd-info: give only one source type option.
  cd-info: Source specified in previously data/cdda_track_4_5.cue and 
data/cdda_track_4_5.cue


I wrote:
> > (The displaid track numbering is wrong: 1 and 2 instead of 4 and 5.
> >  Are Edd's changes for libcdio already merged in ?)

Edd Barrett wrote:
> Could this be the same problem as?:
> https://github.com/rocky/libcdio-paranoia/pull/20#issuecomment-450437694

So it is still an open problem.

Let's have a look at lib/driver/image/bincue.c and src/cd-info.c ...

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

src/cd-info.c has only one difference between openbsd_fixes_to_master_for_merge
and master:
  
https://github.com/vext01/libcdio/commit/6a129e460c25d7ba6362983b337085a46ba0fa50
It fixed the wrong headline display
  CD-ROM Track List (1 - 2)
which did not match the track list numbers if the driver returned the
first track number correctly.
With bincue.c the headline matches the list numbering. So most probably the
driver returns the wrong numbers.

In charge are functions _get_first_track_num_image() and
_get_num_tracks_image() in ./lib/driver/image_common.c.
They access p_env->gen.i_first_track and p_env->gen.i_tracks which both are
supposed to be filled by bincue.c.

_init_bincue() sets .first_track to 1 and calls parse_cuefile() with a
non-NULL argument "cd". It too sets cd->gen.i_first_track to 1 before
examining the TRACK lines:

        /* TRACK N <mode> */
      } else if (0 == strcmp("TRACK", psz_keyword)) {
        ...
          if (1!=sscanf(psz_field, "%d", &i_track)) {

The variable i_track is not used further. The only purpose for the scanf()
is to check whether some arbitrary number is written there.

Remedy would be to record the track number of the first TRACK line
as p_env->gen.i_first_track and to demand that the subsequent TRACK lines
bear nicely incrementing numbers.

Then we probably get errors when using track numbers ...
I will try what happens.

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

Indeed bincue.c insists in the existence of a .bin file with the same path
as the .cue file, except that the suffix ".cue" is replaced by ".bin".

This is semi-complex to fix. It would need research about the exact CUE
rules for the FILE parameter and would possibly break use cases where
the ignorance towards FILE causes success.

Details:

In bincue.c function parse_cuefile() the .bin file name is read from keyword
FILE and gets prepended the directory part of the .cue file path.

        /* FILE "<filename>" <BINARY|WAVE|other?> */
      } else if (0 == strcmp ("FILE", psz_keyword)) {
        if (NULL != (psz_field = strtok (NULL, "\"\t\n\r"))) {
          char *dirname = cdio_dirname(psz_cue_name);
          char *filename = cdio_abspath(dirname, psz_field);
          if (cd) cd->tocent[i + 1].filename = strdup(filename);

Result is "data/cdda.bin".
(Actually i'd expect "cdda.bin" as written in the .cue file. I am unsure
 what the .CUE specs say ...)

But function parameter "cd" is NULL in this first call. So the obtained
filename gets thrown away.
(If it was recorded, there still would be the semantic problem of having
 a per-track parameter that is used as per-cue-file parameter.)

The calling function cdio_is_cuefile() returns as bin name a guessed
string where it simply replaces ".cue" by ".bin":

  psz_bin_name=strdup(psz_cue_name);
  ...
    if (psz_cue_name[i]=='c' && psz_cue_name[i+1]=='u' && 
psz_cue_name[i+2]=='e') {
      psz_bin_name[i++]='b'; psz_bin_name[i++]='i'; psz_bin_name[i++]='n';
      if (parse_cuefile(NULL, psz_cue_name))
        return psz_bin_name;

Result is "data/cdda_track_4_5.bin".

So the caller cdio_open_cue() records this name before it calls _init_bincue()
which really wants to see the "source" file.

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


Have a nice day :)

Thomas