On Sat, Dec 29, 2018 at 8:03 AM Thomas Schmitt <scdbac...@gmx.net> 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 > > >
