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

[Rocky Bernstein]

On Sat, Dec 29, 2018 at 8:03 AM Thomas Schmitt <address@hidden> wrote:

> 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.
>


Yes that has been the case ever since this code was started about 20 years
ago. Either work within that limitation or fix it.



>
> ----------------------------------------------------------------------------
>
>
> Have a nice day :)
>
> Thomas
>
>
>