Feature request: Configurable CD read speed to improve read stability (PoC included)

[strict-flower]

Thanks for developing the crate, It has been very helpful!

This crate works well with most CDs in my environment, but I encountered unstable reading behaviour with a SACD + CD hybrid disc.

My tested environments are macOS Tahoe (26.5.2) and USB-connected BD drive (Logitec LBD-LPWAWU3NDB). Used this crate with fd71208.

I think It's a drive-and-disc compatibility issue because the CD layer of a hybrid SACD disc can be more sensitive to physical reading conditions. I found that limiting the read speed to 10x, or slower, resolved the problem.

The following macOS patch demonstrates the workaround. It is not production-quality but It was sufficient to read the affected disc reliably.

diff --git a/src/platform/macos/native/read_cd.c b/src/platform/macos/native/read_cd.c
index 815aef9..947ba55 100644
--- a/src/platform/macos/native/read_cd.c
+++ b/src/platform/macos/native/read_cd.c
@@ -83,6 +84,9 @@ bool read_cd_sectors(int fd, uint32_t lba, uint32_t sectors, uint32_t format_id,
     read.bufferLength = totalBytes;
     read.buffer = dst;

+    uint16_t speed = 1764;
+    ioctl(fd, DKIOCCDSETSPEED, &speed);
+
     int ret = ioctl(fd, DKIOCCDREAD, &read);

     if (ret < 0) {

In the future, I would like to use this crate with configurable read-speed setting. The patch above could serve as a Proof-of-Concept for such a feature.

I could also implement the corresponding Linux support, but I can't implement / test the Windows side because I don't have access to a Windows PC. For that reason, I haven't opened a PR or proposed a concrete API implementation yet.

If anyone with access to a Windows development environment is interested in this issue, I would be happy to collaborate on implementing the feature.

[Bloomca]

@strict-flower hey, thanks a lot for using the crate, that's awesome to see!

We can definitely expose the speed knob. I will research how can we do so on Windows & Linux, but given that you have a working PoC which sets it via ioctl, it should be available as IO_CTL command there as well.

Feel free to open that PR, you can implement only the macOS change (and Linux if your environment allows to do so) and I can provide Windows support.

The only thing about the library is that currently the main branch is quite different from the latest published version, I introduced a few breaking changes, so the next version will be 1.0.

So I suppose we can add speed to the read_with_options (ref) to the ReadOptions struct.

You can also take a look at how retries are implemented -- it basically tries to read less sectors each failed time, so maybe we can do so for speed as well? Or maybe not, and constant speed is better.

Let me know your thoughts and whether you are interested to work on that. I have all 3 platforms available, so can implement/test on each one.

[strict-flower]

@Bloomca Thanks for the quick reply and suggestion! I can currently write the platform-specific code only for macOS, but I can implement the Rust API layer completely. I should be able to submit it as a PR in a few days.

Below is a memorandum on the API design.

As a precedent, we can refer to the Linux implementation and documentation ( https://kernel.org/doc/html/latest/cdrom/cdrom-standard.html ). On Linux, we can set the read speed using the CDROM_SELECT_SPEED ioctl with a multiplier. We can also retrieve the maximum read speed. On macOS, the speed can similarly be set using the DKIOCCDSETSPEED ioctl and retrieved using DKIOCCDGETSPEED, but DKIOCCDGETSPEED returns the current speed, not the maximum one.

According to SCSI MMC-3 ( https://www.13thmonkey.org/documentation/SCSI/mmc3r10g.pdf ), we should use the GET PERFORMANCE command to obtain information about supported read speeds. However, this is not directly available as an ioctl on macOS. Moreover, sending raw SCSI commands would make the implementation more complicated to maintain. The Linux implementation can obtain this information, but it depends on low-level driver implementation details (e.g. drivers/scsi/sr.c).

Therefore, I think the API should accept an arbitrary speed multiplier, while commonly used speed settings can be provided as constants. A code sketch is as follows:

struct CdSpeed {
  multiplier: u16,
}

impl CdSpeed {
  const X1: Self = Self::new(1);
  const X2: Self = Self::new(2);
  ...
  
  fn new(multiplier: u16) -> Self {
    Self { multiplier }
  }
}

Since MMC-3 specifies that The Logical Unit is to select the Logical Unit Read Speed specified or any higher rate (MMC-3, p. 272), specifying a lower speed should not be problematic, but requesting a higher speed is drive-dependent. AFAIK, in practice, such a request seems to be treated the same as 0xFFFF (the optimal speed specification), but this behaviour is neither standardized nor an established de facto convention.

[Bloomca]

Just for your information, on macOS we cannot send direct SCSI commands -- while it is possible, it forces the device to be exclusively locked, and when released, it will be remounted. It is really annoying and was the original implementation. Sending specific ioctl commands is the way to go there.

As for design, what do you thing about providing an enum? My main goal with this crate is to provide sensible defaults and to abstract the underlying complexity, so I think overall we can

Like:

enum ReadSpeed {
    Normal,
    Slow,
    Max,
    Custom(usize),
}

And then we can write a function to match enum to specific speeds.

Although a struct can provide methods to slower/speed up relatively. I assume that the speed can be used in 2 main cases:

1. to make the drive quiet
2. to retry in case of errors (which seemed to be your original goal)

You can also take a look at how retries are implemented -- it basically tries to read less sectors each failed time, so maybe we can do so for speed as well? Or maybe not, and constant speed is better.

I am also curious to hear what do you think about that -- to intentionally slow down the drive if we fail to read (and potentially speed it back up)

---

Feel free to open that PR, and we can discuss the API there! Also don't worry about Linux/Windows, I can provide the implementation for them.