From Trunk to Project
Last summer I put a Sony VGP-XL1B in the trunk of my car. It's a 200-disc FireWire carousel changer from the Windows Media Center era, about 30 pounds of mechanical absurdity that I'd been holding onto for roughly 20 years. The plan was to drop it at FreeGeek in Minneapolis. I'd already accepted that I was never going to install Windows Media Center Edition just to rip some discs. Vista could talk to the device, but I don't own a PC with a FireWire port.
Then I forgot about it. For six months. It just sat in my trunk through fall and winter.
In February 2026, I popped the trunk and had a moment.
Claude has been proving itself pretty capable in my day-to-day work. Maybe I could ask it to control a 20-year-old disc changer?
I'd been getting my money's worth out of a Claude Max subscription over the past several months. Could it figure out how to talk to a 20-year-old disc changer?
Dare to Dongle
Step one was physical: get the changer connected to a modern Mac. I already had a FireWire-to-Thunderbolt 2 adapter from a project years ago where I digitized a stack of MiniDV cassettes. Turns out you can daisy-chain a Thunderbolt 2-to-Thunderbolt 3 adapter on top of that to reach a USB-C Mac. It's ridiculous looking but it works. Or should work.
When the adapter arrived I hooked everything up. Nothing. I tried different ports, swapped cables, power-cycled the changer. I even blew into the FireWire connector like an NES cartridge. Still nothing.
Then I remembered the whole point of this project: let Claude figure it out.
I described the setup and asked Claude to find the device. Claude identified the real problem pretty quickly: I was running macOS 26 Tahoe, which removed FireWire support entirely. Not deprecated. Removed. Could I virtualize an older macOS and pass the FireWire adapter through? Nope. Virtualization doesn't forward Thunderbolt peripherals like that.
Luckily, I had a 2012 Mac mini collecting dust with Catalina still installed. I booted it up, SSH'd in, and ran:
ioreg -r -c IOSCSIPeripheralDeviceType08Nub
The changer showed up. Two devices, actually.
How Many Devices You Hiding Behind That Port?
This is where it got interesting. Claude found a blog post by Alex Bowden who had done some incredible hardware-level reverse engineering of this exact device, probing the serial protocol between the internal boards with a logic analyzer. That post gave us a foundation to work from.
The VGP-XL1B presents itself as two completely separate SCSI devices over FireWire using the SBP-2 protocol. One LUN is the DVD-ROM drive. The other is the media changer, the robotics that move discs between 200 carousel slots, an import/export port, and the drive. They share a FireWire controller (an Oxford Semiconductor FW911 chip) but operate independently.
The media changer board runs an Innovasic IA188ES processor (a descendant of the old AMD 80C186) with battery-backed SRAM that tracks the state of every carousel slot. That last detail is important: the device remembers which slots have discs in them even when powered off. It maintains its own internal map of the carousel. When you issue SCSI commands to move media, the changer updates this internal state and physically moves the robotics arm to grab, rotate, and place discs.
Claude walked me through the SCSI Media Changer command set: INITIALIZE ELEMENT STATUS to refresh the internal map, MODE SENSE to read element address assignments (how many slots, drives, and transport elements exist and where they start), READ ELEMENT STATUS to query which slots are full or empty, and MOVE MEDIUM to physically relocate discs between elements. The whole thing is controlled through IOKit's SCSITaskDeviceInterface on macOS.
Opening the Machine
It took an afternoon of back and forth. Claude would generate code, I'd compile and run it on the Mac mini, and we'd iterate on the results. But at a certain point I needed to physically verify what was happening inside the changer. Which slot numbers corresponded to which physical positions? Was the carousel rotating the right direction? Was the disc actually being gripped by the transport arm?
So I opened it up. The internals are surprisingly modular: a carousel tray, a robotic arm on a rail, the FireWire controller board, the changer controller board, and a standard IDE DVD drive that Sony sourced separately. I ran commands from the terminal while watching the arm move, confirming slot addressing and making sure the insert/eject/load operations matched what the SCSI spec described.
The Window Gets Smaller While You're Standing In It
Here's a fun one. Midway through development, Anthropic released a new version of Claude Code as a native install, replacing the old npm-based version. The new version doesn't run on Catalina. The tool I was using to reverse-engineer an obsolete protocol on an obsolete OS was itself moving on from that OS.
I was still able to install the deprecated npm version of Claude Code on the Mac mini to keep iterating. But it was a good reminder of how many things had to line up for this project to work at all. macOS 26 killed FireWire. Claude Code's native install killed Catalina support. The physical discs themselves are degrading. I happened to have a 2012 Mac mini with the right OS, the right adapters from a previous project, and caught the window where Claude Code still ran on it. Six months later, any one of those things could have been the reason I never got around to it.
What Does "Eject" Even Mean?
One thing that tripped us up was naming. In the context of a disc changer, "eject" is ambiguous. Does it mean eject the disc from the DVD drive back to its carousel slot? Or eject the disc from the machine entirely, out through the import/export port so you can physically grab it?
We settled on a clear terminology in mchanger:
- load: carousel slot → DVD drive
- unload: DVD drive → carousel slot
- insert: IE port → carousel slot
- retrieve: carousel slot → IE port
- eject: drive → slot → IE port (the convenience combo)
There's also automatic disc swapping: if you load slot 42 while slot 17 is in the drive, mchanger unloads 17 back to its slot first. And it handles macOS-level disc ejection before any physical movement, so you don't yank a mounted filesystem out from under the OS.
brew install toml0006/mchanger/mchanger
mchanger load --slot 42 -v
From CLI to App
Once mchanger was solid, the next step was obvious. I didn't want to type 200 individual load/image/eject commands. I needed batch automation with a visual interface.
I asked Claude to build a macOS app. Claude initially started writing the SCSI code from scratch, and I had to remind it that we'd already built mchanger. It should just link against the library. Claude suggested creating a static library target, which made sense: one shared C library, one CLI tool, one Swift GUI app, all using the same underlying code.
Discbot is the result. A native Swift app with a grid view of all 200 slots, color-coded by status: green for full, blue for currently in drive, grey for empty. It remembers disc information between sessions, storing volume labels, disc types, and imaging status in a local database.
The feature that made this whole project worthwhile is batch imaging. Select a range of slots (or all of them), pick an output folder, click go. Discbot loads each disc, mounts it, creates an ISO with hdiutil, unmounts, ejects back to the slot, and moves on to the next one. Fully automated. I pointed the output at my NAS and walked away.
200 Discs at a Time
The physical workflow ended up being straightforward. The VGP-XL1B has bulk load and unload buttons that cycle through slots, presenting each one at the IE port. Load 200 discs, close the machine, run the batch, wait a few hours, open the machine, bulk unload, repeat with the next batch.
The most cumbersome part is still the physical handling. You're feeding discs into a slot one at a time, waiting for the carousel to rotate. But it moves faster than you'd expect for a mechanical device from 2005. And the payoff is that once the discs are loaded, the entire imaging process is three button clicks and zero interaction from me.
I worked through 30+ years of accumulated optical media this way. Old software installs, photo backups from before cloud storage, music collections from college, a copy of Red Hat Linux 7 that I'm pretty sure I mail-ordered from a magazine. Will I ever look at most of these ISOs? Honestly, probably not. But a few terabytes on a NAS I already own costs effectively nothing, and the physical discs were taking up real space in real boxes.
Your Old Media Has an Expiration Date
If you have optical media in boxes somewhere, the window for easy digitization is getting smaller. macOS 26 killed FireWire. CD-Rs from the early 2000s are already past their expected lifespan. The drives that can read them are disappearing from modern machines. And "I'll get to it eventually" has a way of quietly becoming "I can't do this anymore."
You don't need a 200-disc changer to deal with it. A USB DVD drive and hdiutil (or dd on Linux) gets the job done one disc at a time. The point is to start now, while the hardware still works and the software still exists.
Both mchanger and Discbot are open source. Disk is cheap. Physical space is not.
Comments