Re: [Libcdio-help] reading the whole 2352 bytes from every type of sector

[Matheus Izvekov]

On Wed, Mar 5, 2008 at 4:22 PM, R. Bernstein <address@hidden> wrote:
> Matheus Izvekov writes:
>   >
>   > The problem is that currently in libcdio this would not work for image 
> files,
>   > because there is no way to do something similar to a GP_CMD_READ,
>   > CDIO_MMC_READ_TYPE_ANY, as you call it.
>
>  Actually, CDIO_MMC_READ_TYPE_ANY doesn't do what you want.  It is more
>  of a "do the right kind of read for whatever format is in there". Not
>  return all the data that is in a frame.

No it really is "return all the data that is in the frame".
Thats actually what the cdrom command I'm trying to emulate does.

>
>   > If I would go as implementing
>   > this, should I create another primitive function, or add support for that 
> mmc
>   > command on the CD image drivers?
>   > IMHO, mmc_read_cd is too complex for an operation this simple,
>
>  Heh, heh. I think were getting the "dilemma" of simulating a CD-ROM
>  for a particular CD image format ;-)
>
>
>   > so maybe an
>   > additional function would be better.
>
>  libcdio does have some higher-level functions based on mmc. The
>  closest thing there right now is cdio_read_sectors. But it doesn't do
>  what you want.
>
>  Furthermore, I suspect what you want may not be as simple as you
>  imagine, although there may be some special cases which are simple.
>  general.
>
>  Depending what image format is used and how the image was created
>  (e.g. Disc-at-once, Track-at-once, or sector), the various bits of
>  data may or may not be explicitly represented in the image. It is
>  possible, that some of the error correction for various modes may be
>  computed just before writing tracks/sectors to the CD medium. Also the
>  mapping of how something appears in the CD image and how it can appear
>  in a subchannel can be a bit arbitrary.  For exampe CD-Text
>  information is given in one place in BIN/CUE. How that text gets split
>  and put as subchannel information somewhat arbitrary.
>
>
When the image has less information than requested,
if its possible to recompute it then fine, but if its not, returning
an error is really the best that can be done.
Now for the cd-text example, if the other side is supposed to work on
all the allowed ways to encode the
information in the subchannels, as the spec dictates, then we choose
whatever way is most convenient for us
and be done with it.

Now thats not really my case, as playstation cds dont have cd-text and
normally all image files are written in 2352 bytes mode.