Would you suggest removing it or making it configurable at run-time?
On Mon, Mar 17, 2008 at 12:27 AM, Robert William Fuller <
[EMAIL PROTECTED]> 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);
>
>
>
