I have been ripping my CD collection into Kanora alphabetically, and as of this week I am somewhere in the Gs. Just under 4,000 tracks. About 150 GB of lossless ALAC files, with a 320 kbps MP3 companion generated alongside every track so the same library can escape the Apple ecosystem whenever it needs to.
That is not a finished job. It is not even close to half, if I am honest about what is still sitting in boxes. But it is far enough in to have learned some things, and far enough in that this has stopped being a convenient test library and started becoming my actual music collection again.
I have done this before, in various forms. There have been big iTunes libraries. There has been Plex. There have been folders of carefully ripped and tagged music spread across machines and drives over the years.
And, somehow, tracks have disappeared. I have never conclusively proved why. I have long suspected that some of the stranger iTunes-era losses were connected to iTunes Match or Apple Music trying to reconcile my library with Apple's catalogue. Plex has had its own particular ability to make me wonder whether the files, the database or the application itself was currently telling me the truth.
Whatever the cause, I have been here before: maintaining a large digital music collection while gradually losing confidence that what I put into it would still be there later.
So this time I am building the software as well as the library.
That changes the relationship quite a bit.
img-0965.jpg
Why alphabetically
Mostly because that is how the shelf is organised.
A to Z by artist.
So the ripping order mirrors the physical collection exactly, which has turned out to be useful in two directions: I can work through the shelf without thinking about what comes next, and Kanora gets tested against the same sort order I already expect from the collection in the room.
That exposed sorting problems surprisingly early. Band names were being treated too literally. Surnames needed proper sort values. Artists beginning with "The" needed to sort where a human expects them to rather than filling half of T.
So the physical shelf became a reference implementation, in a way. If Bryan Adams is in the right place on the shelf and Kanora puts him somewhere else, Kanora is wrong.
There is another advantage too: any other ripping order becomes a decision, and decisions are where this kind of project dies.
The obvious alternative is to rip the good stuff first. That works for about a week, and then you are left with a pile of discs you have implicitly labelled "not worth the effort", which you will never touch again, and a library with holes in exactly the places that make browsing frustrating.
Going A to Z removes the choice entirely. Pick up the next disc. Rip it. Put it back. And because the shelf and the software are meant to agree, every disc also becomes another test of whether Kanora's sorting model actually matches the way a real collection is organised.
I am being dragged through every kind of edge case in roughly the order the alphabet supplies them rather than the order I would have chosen.
That has turned out to be useful.
scr-20260825-mmqr-2.jpg
What ripping 4,000 tracks teaches you
The mechanics are the easy part.
Getting bits off a disc and into a file is solved. What is not solved is everything around it, and doing it a few hundred times in a row makes that painfully specific.
Metadata is not a lookup, it is a judgement.
The online databases are good, and they are also frequently offering you four plausible releases of the same album with different track counts, different years and different bonus tracks. Only one of them is the disc in your hand.
Software that picks for you silently is software that will quietly file your 1994 reissue as the 1987 original and never mention it.
That matters to me because one of the things I want from Kanora is the ability to trust it. If it is uncertain, I would rather it tell me than confidently make a decision I discover years later.
Multi-disc sets are where careless software shows itself.
Two discs, both with a track one, both wanting to be an album. Get the numbering wrong and you have not made a mess you can immediately see. You have made a mess you will discover in three years when something shuffles.
The edge cases are not rare, they are just individually rare.
Compilations credited to different artists per track. Singles that share a title with the album they came from. Discs with no metadata at all, where the only reliable source is what is physically printed on the disc.
Every one of those is uncommon. Across several hundred discs you meet all of them.
Nothing about a rip is fire and forget.
A drive stalls. A disc is scratched in one spot. You notice halfway through that you picked the wrong release.
If the app cannot cancel cleanly, retry, or let you change your mind, then every one of those becomes a manual cleanup in the file system later.
Do that a few dozen times and you have exactly the sort of library I am trying not to build again: one where the application's view of the collection and the files underneath it gradually stop agreeing.
scr-20260825-modu.png
Why ALAC and MP3
The format choice is deliberate.
ALAC is the lossless master because my primary ecosystem is Apple. Macs, iPhones, iPads, Apple TV, CarPlay — it plays natively everywhere I actually use it, so there is no reason for me to introduce extra friction into the main library.
But I do not want the collection tied to Apple hardware. So every ALAC rip also gets a 320 kbps MP3 companion automatically.
That is the compatibility copy. It goes onto USB drives for car stereos. It can be streamed to DLNA devices. It works with old hardware, weird hardware, cheap hardware and anything else that just understands MP3 and does not need to know what Kanora is.
The ALAC copy is the archive. The MP3 is the portable one. I do not have to decide between fidelity and compatibility because storage is cheap enough that keeping both is the simpler answer.
scr-20260825-ryqq.jpg
The alphabet has basically become my test plan
This has not just been a long ripping job.
It has turned into a proper dog-fooding exercise: thousands of real tracks, hundreds of real discs, and whatever awkward data the collection happens to throw at the app next.
I did not have to get very far into A before that started paying off. One of the first serious problems came from a Bryan Adams double album.
That exposed enough weaknesses in multi-disc handling that I spent most of a week with Claude tightening the whole thing up.
Import logic needed work. MusicBrainz disc-number mapping needed work. The model needed to understand multi-disc releases properly rather than treating the disc number as a bit of incidental metadata attached to otherwise independent tracks.
Fixing that one album ended up making the schema considerably more capable. It also exposed sorting problems.Band names were being treated too literally. Surnames needed proper sort values. Artists beginning with "The" needed to sort where a human expects them to rather than filling half of T.
So what started as "why is this Bryan Adams album wrong?" fed directly into proper sort fields, better artist modelling and a more explicit distinction between how something is displayed and how it should be ordered.
I got to the SECOND CD in my collection...
img-0970.jpg
Then I hit audiobooks.
This was just before a road trip, so I decided to import the BBC Lord of the Rings radio drama: thirteen discs. That uncovered a completely different problem.
The importer's de-duplication logic had been written with music in mind, where seeing the same title repeatedly on the same release is unusual enough to be suspicious. Audiobooks do not care about that assumption.
When track one on multiple discs is called something like "Opening Titles", those are not duplicate files. They are thirteen different track ones on thirteen different discs.
The de-duplication logic had to become disc-aware. Again, that was not a theoretical edge case I came up with while staring at the schema. I put a thirteen-disc audiobook into the drive and the assumption broke immediately.
That has been the pattern all the way through. A disc goes in. Something I thought was finished turns out not to be finished.
Kanora gets better.
Two more bugs I would never have found any other way
The alphabet has been an excellent bug detector.
Another one appeared when I noticed the ripping screen was correctly identifying a Del Amitri disc as a single, and the library was showing it as an album, merged into the identically titled album with no way to separate them.
That turned out to be three independent faults stacked on top of each other, one of which is that the ALAC container I am using for the lossless archive does not preserve the release-type tag in the way I expected.
The MP3 companion did. So the compatibility copy was carrying information that the lossless master had lost.
That is exactly the kind of thing that can sit unnoticed for years if you only test the happy path.
Reading the code would never have found it. Running the actual tools, ripping an actual disc and then looking at what came out did. The next one is worse, and I found it by wanting to go faster.
Ripping is bound almost entirely by the optical drive. A disc takes four to eight minutes to read and the Mac spends nearly all of that time doing very little. The obvious move when you are several hundred discs from the end is to plug in a second drive.
You cannot. Yet.
The queue runs one job at a time.
And underneath that, the commands that lock, unlock and eject a drive never say which drive they mean. They act on whatever the system considers the default.
So with two drives attached, Kanora can eject the disc it is currently ripping. That is not a future parallel-ripping problem. That is a bug that exists today for anyone who plugs in a second optical drive, whether or not parallel ripping ever ships.
It gets fixed first.
Then the queue learns to run one job per drive. Which means the answer to "when do I get to the Zs?" partly depends on me fixing my own software.
That is roughly the correct relationship between a person and a tool they built for themselves.
img-0982.jpg
Building a library I trust again
The thing I am enjoying most is not that my CD collection is becoming digital.
I have had digital music libraries for decades. What is different is that I am building one again while also building the software responsible for looking after it.
There is no mystery database somewhere that I cannot inspect. There is no cloud service deciding that one recording is equivalent to another. There is no catalogue against which my collection needs to be reconciled.
The files are mine. The metadata is mine. Kanora is supposed to describe what is actually there, not replace it with its own idea of what should be there.
And if something disappears, changes or gets classified incorrectly, I can find out why.
That sounds like a fairly low bar for music software, but after years of iTunes libraries, Match, Plex databases and various migrations between machines and drives, I have learned not to take it for granted.
I still have old music folders where I am fairly certain something used to exist and no longer does.
I could never tell you exactly when it vanished. That is the thing I do not want from this library. Kanora is deliberately being designed so that the collection can survive Kanora itself.
The files and the library metadata live together. If I move them to another disk, another Mac, a NAS, or eventually another piece of software entirely, the collection should still make sense.
The ALAC files are ordinary files. The MP3 companions are ordinary files. Nothing about the collection should become useless just because Kanora is not running. The application should earn the right to be trusted with it.
And I think this is the important bit: ripping the collection has become part of how it earns that trust.
This is not a synthetic test library anymore. It is my real collection, with all the annoying, inconsistent, oddly authored things that real collections contain.
A Bryan Adams double album rewrote the multi-disc logic.
A thirteen-disc Lord of the Rings audiobook broke the de-duplication assumptions.
A Del Amitri single exposed a hole in the metadata model.
A second optical drive exposed a device-management bug.
That is several thousand tracks of integration testing with consequences I actually care about.
Ripping hundreds of my own CDs through Kanora is proving to be a considerably better way of testing it than any collection of unit tests and sample albums ever could.
And there is another side to it.
Scanning through the collection on a screen next to the amplifier, which is what the little Pi shelf browser is for, feels completely different from searching a catalogue containing essentially every record ever released.
Not because streaming is bad, and not because I have suddenly rediscovered the concept of a music library.
It is because this particular library represents about twenty-five years of my decisions. These are the records I chose to buy. The good ones are there. The terrible purchases are there. The singles I bought for one B-side are there. The odd compilations, strange versions and things I had completely forgotten owning are there.
Nothing gets removed because a licence expired. Nothing gets substituted because a service believes another version is close enough.
There is less in it than there is on Spotify or Apple Music. That is precisely why browsing it is interesting.
img-0969.jpg
I am on G.
I will report back from somewhere around M.