One of the easy mistakes in music software is to talk about CD ripping as though it has already been solved. It has not. The happy-path mechanics are solved in the sense that you can get bits off a disc and end up with files on a drive, but that only covers the least interesting part of the job. The part that still matters is everything around it: identifying the right release, deciding what to do when metadata is incomplete, handling multi-disc sets without mangling the numbering, making a sensible choice when a drive stalls, and ending up with files that feel like the beginning of a library rather than the aftermath of a utility.
That distinction has shaped how I’ve been building the ripping flow in Kanora. I never wanted the feature to be a ceremonial checkbox, because people who still rip discs are not doing it out of nostalgia alone. They are doing it because they bought the album, they want control over the files, and they probably expect the resulting library to outlast whichever streaming service is currently fashionable. If the app gets the very first step wrong, it poisons everything after it. A bad rip is not just a transient inconvenience. It is bad archive material.
So the design ended up leaning in a fairly opinionated direction. Rather than treating the rip as a fire-and-forget background task, Kanora tries to treat it as a supervised ingest. The app reads the disc, looks up the release, lets you correct metadata before the job starts, and keeps enough state around cancellation, retry, and duplicate detection that you do not feel trapped once the process is underway. That is how features like multi-disc identification, CD-TEXT fallback search, and release switching found their way in. None of them are especially glamorous on their own, but together they make the difference between “the software can rip a CD” and “the software understands why I am bothering to rip this CD at all.”
The optional MP3 companion work grew out of the same line of thinking. In a perfect world the archive would stay lossless and every destination in the house would handle it gracefully. In the actual world, some older boxes behave better with something lighter, some network playback paths are happier when you do not ask them to transcode on the fly, and sometimes you just want an export-friendly copy without inventing a separate workflow. So Kanora now has the option to create a 320 kbps MP3 alongside the main rip in a single pass. Importantly, that companion copy is not treated as the “real” library asset and it is not automatically added to the collection. It is a pragmatic extra, not a quiet lowering of standards.
This is also a good example of where AI tooling has been useful without being magical. I did not ask a model to “build CD ripping.” That would be a fast route to something theatrical and brittle. What I did use the tools for was scoping and edge-case pressure. Once the core flow existed, it became much easier to ask pointed questions: what are the failure states for a stalled rip, where does duplicate detection belong, how should the UI behave if release lookup comes back thin, what sequence of prompts gets me from an implementation diff to a proper checklist of tests and follow-up tickets. That kind of use has been consistently valuable. AI is good at helping me expand the perimeter of a problem once I already understand its centre.
The more I work on Kanora, the less interested I become in pretending physical media is merely a quaint hobby. There is a practical seriousness to it. You bought the thing. You can hold the thing. You can rip it today, re-rip it later, compare editions, preserve the liner information, and decide where the files live. That is not anti-streaming melodrama. It is just a different relationship to the music. Streaming is unmatched for breadth and convenience, but it is still access on someone else’s terms. A disc on the shelf is slower, heavier, and much less ambiguous.
That is why I keep coming back to the idea that ripping is archival work disguised as utility work. The software has to respect that. It has to produce the right files, in the right place, with the right metadata, while being honest about the rough edges instead of burying them under a comforting spinner. If I get that part right, the rest of the library has a fighting chance of feeling solid. If I get it wrong, all I have done is automate disorder.
There is still work to do here. The flow is real, but I want it to become calmer under stress, clearer when metadata confidence is low, and more exact about what it has decided on the user’s behalf versus what still needs a human eye. That has become the recurring pattern in Kanora generally: the most useful features are the ones that stop trying to look finished too early and instead become steadily more trustworthy over time.