[WIP] Add read speed option by strict-flower · Pull Request #60 · Bloomca/rust-cd-da-reader

strict-flower · 2026-08-11T01:41:12Z

Under development

Description

Background discussion is #59

Adds an option to request to set the read speed of the tracks.

Bloomca

I think this API looks good! I left a few comments for the implementation, also there a few typos in the comments but we can fix it later.

I think we should an example of "slow_read_track" which would read the first track from the default drive at 10x.

@strict-flower One question I am curious about and forgot to ask in the issue. If custom multiplier does persist (we'll need to test it), do you think we should set speed back to optimal in the drive destructor?

Bloomca · 2026-08-12T20:58:09Z

+    /// By MMC-3 specification, It can be set to the optimal speed of the drive when it executes SET CD SPEED command with read speed (KB/s) = 0xFFFF.
+    /// On the Linux, the read speed will selected by the CDROM_SELECT_SPEED ioctl with speed = 0. It'll set the speed automatically and highest speed that supported by the drive.
+    Optimal,
+    /// Use the custom speed with specified multiplier.


We should add some inline documentation that it is 176KB/s * multiplier. Also maybe give an example that 10x is usually slow enough.

I tried to add that. Is this what you had in mind?

Bloomca · 2026-08-12T21:23:13Z

+#include <IOKit/storage/IOCDMediaBSDClient.h>
+
+Boolean request_cd_read_speed(int fd, uint16_t target_speed_kbs) {
+    int ret = ioctl(fd, DKIOCCDSETSPEED, target_speed_kbs);


I think we need to pass a pointer there (I remember it from your example in the issue and here it dereferences

just typo. I've fixed that.

Bloomca · 2026-08-12T21:39:02Z

+    let target_speed_kbs = if multiplier == 0 {
+        0xffff
+    } else {
+        multiplier * 176400 / 1000


This can overflow. With u16, it is not that hard to do, however, generally seems that audio CD can max out at ~52.

So maybe we can clamp the multiplier to 100x?

I've changed CustomMultiplier(u16) to CustomMultiplier(u8) since u8 is sufficient to it I think. This change will fix it.

Bloomca · 2026-08-12T21:39:52Z

+        multiplier * 176400 / 1000
+    };
+    if target_speed_kbs > u16::MAX.into() {
+        // TODO: Implement error handle (CdReaderError?)


Similar to before, I think it might be easier to clamp the multiplier and this way we will never overflow

same as above

strict-flower · 2026-08-16T07:09:54Z

@Bloomca Thanks for the quick review. I've fixed them. I'll write & testing the Linux implementation today.

One question I am curious about and forgot to ask in the issue. If custom multiplier does persist (we'll need to test it), do you think we should set speed back to optimal in the drive destructor?

I tested that.

The DKIOCCDSETSPEED ioctl seems to set the drive speed until the disc is ejected. Below is my experiment summary.

Read with Unchanged -> corrupted and 24x
Read with CustomMultiplier(10) -> success and 10x
Read with Unchanged -> success and 10x
Eject and re-insert the disc
Read with Unchanged -> corrupted and 24x

... and the default state seems to be Optimal, but we can't confirm that because DKIOCCDGETSPEED only returns the current speed¹, according to my experiments.

I also tested that. I inserted eprintln! in the read loop to print the return value of the DKIOCCDGETSPEED ioctl, and it changed between 10x and 24x depending on the actual read speed. This means that it returns the current speed. ↩

strict-flower · 2026-08-16T07:38:39Z

I think it's difficult to restore the original state. At least, macOS doesn't seem to provide a way to get the original state.

Moreover, we could get the read speed performance data of the drive, but we can't get the current speed policy of the drive. In other words, even if the current speed is 10x, we can't determine whether the value was set by another program, is the default value of the drive, or was selected automatically.

~~Therefore, I think just setting Optimal is the best way to implement the destructor.~~ (deleted, please read the next comment)

strict-flower · 2026-08-16T10:49:21Z

I wrote the implementation for Linux and tested. It seems to work correctly.

Also I tested Optimal / Unchanged / CustomMultiplier with the USB-connected drive that I used for the macOS test, and it doesn't behave the same way as on macOS. I didn't retrieve the read speed, but I only observed whether the read succeeded or returned corrupted data (It could probably be obtained using GET PERFORMANCE, but I haven't implemented that yet).

Read with CustomMultiplier(10) -> success
Read with Unchanged -> success
Read with Optimal -> corrupted
Read with Unchanged -> success
Read with CustomMultiplier(1) -> success

Although I didn't eject the CD during the above procedure, the speed setting did not persist. On Linux, it seems to be reset on each open(2).

Additionally, I tested this on an internal disc drive (ASUS BC-12D2HT). This drive seems to ignore the requested speed with the SET CD SPEED command¹. Nevertheless, this behaviour doesn't necessarily violate MMC-3, because MMC-3 specifies that The Logical Unit is to select the Logical Unit Read Speed specified or any higher rate.

Thus, unlike my earlier comments, I think the best destructor behaviour may be OS-dependent. However, there is also the possibility that we don't need to restore the policy at all.

macOS: Optimal (?)
Linux: Nothing to do.
Windows: ?

Unlike the USB-connected drive, it could read the disc correctly with all settings I tested. However, the USB-connected drive could read most discs correctly at 24x, so there may still be some hidden hardware-specific issue. ↩

Add an option to requesting read speed into ReadOptions (working at m…

35c4516

…acOS only) Bloomca#59

Bloomca reviewed Aug 12, 2026

View reviewed changes

strict-flower added 2 commits August 16, 2026 14:59

Fix typo and change the type of multiplier to u8

32b1457

Fix rustdoc

b6367f4

Add a speed change request feature for Linux

29b3e74

strict-flower added 2 commits August 16, 2026 21:27

Improve an error handling flow of request_cd_read_speed

255147b

Fix rustdoc

7f3f5ce

Navigation Menu

[WIP] Add read speed option - #60

[WIP] Add read speed option#60
strict-flower wants to merge 6 commits into
Bloomca:mainfrom
strict-flower:dev-speed-option

strict-flower commented Aug 11, 2026

Uh oh!

Bloomca left a comment

Uh oh!

Bloomca Aug 12, 2026

Uh oh!

strict-flower Aug 16, 2026

Uh oh!

Bloomca Aug 12, 2026

Uh oh!

strict-flower Aug 16, 2026

Uh oh!

Bloomca Aug 12, 2026

Uh oh!

strict-flower Aug 16, 2026

Uh oh!

Bloomca Aug 12, 2026

Uh oh!

strict-flower Aug 16, 2026

Uh oh!

strict-flower commented Aug 16, 2026

Uh oh!

strict-flower commented Aug 16, 2026 •

edited

Loading

Uh oh!

strict-flower commented Aug 16, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

strict-flower commented Aug 11, 2026

Description

Uh oh!

Bloomca left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

strict-flower commented Aug 16, 2026

Footnotes

Uh oh!

strict-flower commented Aug 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

strict-flower commented Aug 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Footnotes

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

strict-flower commented Aug 16, 2026 •

edited

Loading

strict-flower commented Aug 16, 2026 •

edited

Loading