Redbook - glue & hardware access for Cd Audio

announcements
1

Phew! After a month of work, I've just published redbook. It's finally at the stage where polishing any more would be going past the point of "if you're not slightly embarrassed by your code when you publish, you waited too long".

I'm tired now, hope this is not too long a post.

I'd love to hear any feedback

What it is

  • a load of "glue" bringing together various crates into a coherent whole for handling audio CDs
  • direct hardware access for windows (linux is high up on the todo-list)
  • a simple cd-ripper for windows (a GUI is top of the todo-list)

End-to-end functionality

  1. Hardware access Read audio data from a CD
  2. Parse & lookup information on the album including coverart, generate tags & embeddable coverart
  3. Encode music to wav or flac

Why?

  1. I'd had enough of manually ripping CDs, then polishing the tags, then downloading the coverart, then embedding it, ... So I thought "how hard could it be?" :wink:
  2. I started to research available crates, found many I liked that did various bits of the workflow
  3. I looked at cdda_reader and was unwilling to use a crate with no a load of unsafe but no SAFETY comments. When I started to audit the unsafe I found it would be just as easy to implement it myself, plus there were better ways to achieve the same result.

Other crates I glued together

Each of these deserves a shout-out for the quality of the API

  • cdtoc - for parsing a TOC (table of contents) and calculating links/IDs for online directories
  • musicbrainz_rs - for querying MusicBrainz and parsing the results
  • flacenc - for encoding to FLAC (currently slightly broken after changes to portable_simd earlier this year)
  • metaflac - for tagging FLAC files

Safety & low-level hardware access

  • Unlike other examples, I've made exclusive use of specialised OS-APIs for accessing Audio Cds, rather than issuing raw SCSI commands. That means I leverage all the relevant functionality of the drivers.
  • I've mocked up every ffi function used.
    • This gives in-place documentation, including safety requirements, in IDE when coding
    • means you can code on any OS and still get full rust-analyzer & clippy support
    • means I could create a series of tests and run miri on them to check for UB in the mid-level code which calls the ffi
  • The safety comments are complete and relevant. Any module which doesn't need unsafe is forbid(unsafe), the rest is deny(unsafe_code) + deny(allow_attributes) + a list of other unsafe lints.
  • It goes without saying but, ALL unsafe code is hand crafted by humans. Agents.md specifically forbids any unsafe code changes or generation.
  • Publishing is via immutable releases, so as well as the crates.io & docs.rs source code, the github code & related binaries are guaranteed to be the ones published.

AI usage

Technical

Absolutely NO unsafe code, or code anywhere near unsafe was touched by AI. The code is all mine, I know every line intimately.

While I got various help throughout the process (research, boilerplate, PoCs, reviews, ...), every line of code is mine. I've re-written, hand-crafted, polished and added love, care and pride to every line of the code-base. The ugly corners which are left tucked away are there with my knowledge & probably written by me at an earlier stage, so please don't assume just because you see an Agents.md and a few skills ...

Ethical

I only use mistral - who push for and provide ethical & ecological transparency and work under a regulated jurisdiction. I'm not naive enough to believe this is perfect.
(Sole exception: sourcery-ai provided fast, low-token PR reviews & overly wordy github issues as an aide-memoire)

1 Like