Re: [Libcdio-devel] speaking of pre-gap detection....

[Robert William Fuller]

R. Bernstein wrote:
> Robert William Fuller writes:

snip

>  > So, we're back to the age old question of how to export this 
>  > information.  What is your opinion of the following for an API?
>  > 
>  > lsn_t cdio_get_track_pregap_lsn(const CdIo_t *p_cdio, track_t i_track);
>  > 
>  > I would have it return CDIO_INVALID_LSN if the data isn't available.
>  > 
>  > Thoughts, questions, concerns?
>
> I'm cool with this. What do others think?

I have been thinking about this.  A more general interface would look 
like this:

lsn_t cdio_get_track_index_lsn(const CdIo_t *p_cdio, track_t i_track, 
int index);

Hence, to get the "pregap" which is index 0 in the Q sub-channel, you 
would use cdio_get_track_index_lsn(cdio, trackno, 0);

I think this would be better because it is one interface that 
accommodates both pregap (index 0) and the other 99 possible per-track 
indices, although initially I would probably only support index 0 for 
the image drivers.

Interestingly, the cdrdao and bincue image drivers already set a 
"pregap" field in "tocent", although it has a different meaning because 
it comes from the cue sheet or toc file's "PREGAP" keyword.  While it 
does mean index 0, it additionally implies silence.  Curiously, it is 
never used beyond setting it.  I thought about co-opting this field so 
as not to change the ABI, but I'm not sure what is usually done?

In the interest of keeping things simple, cued uses this data structure 
to store indices:

lsn_t rip_indices[ CDIO_CD_MAX_TRACKS + 1 ][ CUED_MAX_INDICES ];

Note that this is about 40K in size.  I'm not sure about the memory 
constraints for libcdio, so I have some misgivings about using a similar 
structure in libcdio.  What are your thoughts?

Regards,

Rob