Re: [Libcdio-devel] unexpected offset in bincue.c for audio sectors

[Eric Shattow]

Would you suggest removing it or making it configurable at run-time?

On Mon, Mar 17, 2008 at 12:27 AM, Robert William Fuller <
address@hidden> wrote:

> Does anybody know what this is about?  I'm pretty sure I know what it's
> about, but I want to confirm.  I spent some time trying to figure out
> why every time I re-created an image file from a rip and re-ripped from
> the new image file, each new rip was progressively off by 68 more audio
> samples, i.e. 272 bytes (2 channels * 2 bytes per channel * 68 samples
> == 272 bytes.)  So I carefully debugged my ripper and couldn't find
> anything wrong with it, so I turned to libcdio and found the source of
> my troubles.  The libcdio code in question is at the end of this message.
>
> My suspicion is that the author of the libcdio code was comparing a CD
> rip with an image rip and was trying to compensate for a CD drive with a
> 68 audio sample read offset.  The author may not have known at the time
> that almost all CD drives have some read offset, with the exception of a
> few Plextors, which is why EAC, cued, and cdparanoia support read offset
> correction.  If that is the case, the 272 byte offset in bincue.c for
> audio sectors is emulating a CD drive with a 68 audio sample read
> offset, which is probably the author's original CD drive!  I'm almost
> certain we need to remove the 272 byte.  Note that this only affects
> audio sectors.  Thoughts?
>
> static driver_return_code_t
> _read_audio_sectors_bincue (void *p_user_data, void *data, lsn_t lsn,
>                          unsigned int nblocks)
> {
>   _img_private_t *p_env = p_user_data;
>   int ret;
>
>   /* Why the adjustment of 272, I don't know. It seems to work though */
>   if (lsn != 0) {
>     ret = cdio_stream_seek (p_env->gen.data_source,
>                            (lsn * CDIO_CD_FRAMESIZE_RAW) - 272, SEEK_SET);
>
>
>