Robert William Fuller writes:
> Eric Shattow wrote:
> > Would you suggest removing it or making it configurable at run-time?
>
> I would remove it. The cd-paranoia included with libcdio already has a
> read offset correction option (-O). Similarly, my own ripper, cued,
> does read offset correction as well. It is easy enough for the
> application programmer to do read offset correction.
>
> If we make it configurable, then we need to add it to NRG and all the
> other drivers as well. Adding it to the operating system drivers will
> be a real pain because then we have to apply an offset across sector
> boundaries, which means reading additional sectors. This is best done
> at a higher level, like the application level, which is how libcdio's
> cd-paranoia and cued manage it.
>
> The most painless fix is to not change the model, but fix the bug. Even
> if in the long term it is decided to change the model, the bug needs to
> be fixed in the short term. By the way, it looks like the cdrdao driver
> also has a 272 byte offset, probably for the same reason the bincue
> driver has it.
Without a doubt the 272-byte offset is a hack that I put in for lack
of understanding what was going on. I think I did notice that the
drive on a Solaris box gave a different offset.
Since the next release will have API changes, it would be a good time,
release-wise, to fix this as well. cd-read will need an "audio
offset-correction" option and possibly the reference doc should be
updated and some regression tests may need correcting.