[nicosp]

Problem

The cdrdao driver can't open the TOC written by cdrdao read-cd --read-raw --read-subchan rw_raw:

• RW_RAW is ignored, so every sector is read at the wrong offset.
• The DATAFILE length is read as a start position. This also breaks existing images: the test suite's cdda.toc and vcd2.toc open with negative track LSNs.
• Data files are opened relative to the current directory instead of the TOC.

Changes

• Fix those three problems.
• Read each track's audio from its own file, offset and block size.
• Return the stored sub-channel data through an emulated READ CD: none, raw P-W or formatted Q.
• Implement cdio_audio_read_subchannel(): the Q position of the last audio sector read, as READ SUB-CHANNEL gives on a drive. This doesn't use MMC.
• Add a test with a small synthetic RW_RAW image.

Why this is a draft

This enables MMC commands on disc images: the cdrdao driver now implements run_mmc_cmd, so mmc_read_cd() works on an image the way it does on a drive. Only READ CD is emulated, and mmc-supported? stays false. If an image driver shouldn't answer MMC commands, I can switch to a separate API for reading a sector's sub-channel data instead.

Testing

• make check passes at each commit.
• Programs that check pre-emphasis with cdio_audio_read_subchannel(), such as cyanrip, no longer fail on every track of an RW_RAW image.
• On a 55-track enhanced CD image, cyanrip read the disc ID and pregaps from the sub-channel data. The tracks ripped from the image matched an AccurateRip-verified rip from the drive.

Not handled

PREGAP length/silence, SILENCE/ZERO, and packed RW sub-channel data.

🤖 Generated with Claude Code

[rocky]

I am okay with an image driver supporting MMC commands. @skr4n @pbatard: Your thoughts?

[pbatard]

I'll be blunt here: I do not care about any of the drivers, or cdrdao, since I do not use them in any of my projects, so you can really do whatever you wish here as far as I am concerned.

[rocky]

I'll be blunt here: I do not care about any of the drivers, or cdrdao, since I do not use them in any of my projects, so you can really do whatever you wish here as far as I am concerned.

Ok. Thanks for the information. Sorry for the noise.

[skr4n]

I am okay with an image driver supporting MMC commands. @skr4n @pbatard: Your thoughts?

In my opinion, this is the continuation of libcdio's design mistake that I've observed when working on libcdio-rs. That being the tendency to overload or generalize things.

For example, the library is centered around CdIo_t, which is designed as a general object that can represent either an image or hardware.
The problem with this is that when CdIo_t is initialized as an image, all hardware routines are pointless (eject(), mmc()), and are made out to return NULL or a dummy response (such as with hardware_info() returning libcdio as the vendor).

If an image driver shouldn't answer MMC commands, I can switch to a separate API for reading a sector's sub-channel data instead.

Here, as you pointed out, an image driver is implementing an MMC routine.
It would indeed be better if a more appropriate routine is used, or created if one doesn't exist. (I'm not as familiar with the code, @rocky might guide here).

Existing code and design is indeed hard to change, given the prevalence of this library. However, if new code and interfaces diverge from this, it will be better long term.

[nicosp]

The alternative to MMC emulation is to introduce a new API:

typedef enum {
  CDIO_SUB_NONE   = 0,  /**< 2352 bytes, no sub-channel */
  CDIO_SUB_PW_RAW = 1,  /**< 2352 + 96 bytes of raw interleaved P-W */
  CDIO_SUB_Q      = 2,  /**< 2352 + 16 bytes: the 12 Q bytes with their
                             CRC, padded to 16 as MMC READ CD returns it */
} cdio_read_sub_t;

driver_return_code_t
cdio_read_audio_sectors_sub(const CdIo_t *p_cdio, void *p_buf, lsn_t i_lsn,
                            cdio_read_sub_t i_sub, uint32_t i_blocks);

This will be used in place of mmc_read_cd().

Physical drives will use mmc_read_cd() and as bonus this can also be implemented for macOS with ioctl.