[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Robert William Fuller
Subject: Re: [Libcdio-devel] unexpected offset in bincue.c for audio sectors
Date: Mon, 17 Mar 2008 03:33:00 -0400
User-agent: Thunderbird (X11/20071013)

R. Bernstein wrote:
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.

Are you saying we should make an API change? Or are you saying this is a big enough correction it should go with the next release?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]