ars.md

Cable or 2Go? Two ways to feed a Hugo 2 from an iPhone

Fri, 05 Jun 2026 00:00:00 GMT

If you own a Chord Hugo 2 and an iPhone, there are two good ways to get music from one into the other. You can run a USB cable straight from the phone to the Hugo 2. Or you can bolt a Chord 2Go onto the back of the Hugo 2 and have the phone send music to it over your network. People ask me which is better often enough that it’s worth laying out properly — including the part where the honest answer is “it depends, and not for the reason you’d guess.”

I build 1-bit, the iOS player I’ll use for the walkthrough, and it does both paths. So I’ve spent a lot of time A/B-ing them on my own Hugo 2. Here’s what I’ve found.

The thing nobody points out

Both paths end at the same input on the Hugo 2.

The Hugo 2 is the DAC in both cases — it does the decoding, the conversion to analogue, all the parts that make a Chord sound like a Chord. And the 2Go doesn’t bypass any of that. The 2Go is a transport: it pulls a file off your network and feeds the Hugo 2 over the very USB input your cable would otherwise plug into. Same DAC, same digital input, same decoding.

So the question was never “which sounds better, the Hugo 2 or the Hugo 2.” It’s narrower and more interesting than that: what should be driving that input — your phone, or the 2Go? That’s the entire decision.

Path A — the cable: phone as transport

The simplest version. A USB cable from the iPhone to the Hugo 2, and 1-bit sends the audio straight down it, bit-exact, DSD wrapped in DoP if that’s what you’re playing. I wrote the full how-to for this in How to play DSD on an iPhone — the cable rig is exactly that setup.

What’s good about it:

It works anywhere. No network, no bridge, no setup. Plane, train, hotel, a friend’s couch — if the phone and the Hugo 2 are in the same bag, you have a full hi-fi.
It’s rock solid. There’s no discovery, no multicast, no router to misbehave. You plug in and it plays.
It’s genuinely portable. This is the rig the Hugo 2 was arguably designed for — a battery DAC and a phone, untethered from the wall.

What’s not:

The phone is in the audio path. It’s the transport now, which means it has to stay physically attached, it drains its battery doing the work, and it ties up the only port you’ve got.
The phone is electrically noisy. It’s a general-purpose computer full of radios and switching supplies, and the cable couples some of that to the DAC. Hold that thought — it’s the whole case for the other path.

Path B — the 2Go: phone as remote

Now the network version. The 2Go is attached to the Hugo 2 and joined to your Wi-Fi. Your music lives on a 1-bit bridge somewhere on the same network. In 1-bit you pick the 2Go as the output and press play. The full click-by-click is in Setting up a Chord 2Go with an iPhone, but here’s the part that matters for this comparison:

The phone never touches the audio. It hands the 2Go a link to the file on your bridge, and the 2Go fetches and plays it itself. The phone drops out of the path entirely and becomes a remote control.

What’s good about it:

You can walk away. Lock the phone, leave the room, let the battery sit at 100%. The 2Go keeps playing because it’s the one doing the playing.
The DAC is isolated from the phone. This is the real audiophile argument for the 2Go, and it’s a fair one: the noisy general-purpose computer is no longer galvanically tied to your DAC. The transport feeding the Hugo 2 is now a purpose-built, battery-powered streamer instead of a phone.
It’s a tidy home rig. Once it’s set up, the experience is “open app, press play” from anywhere in the house.

What’s not:

It needs your network and a bridge. The music has to live on a bridge for the 2Go to have something to fetch — on-device files and SMB shares can’t be cast this way. And the whole thing depends on your LAN behaving.
It can have network gremlins. Multicast quirks, client isolation, a flaky mesh node — none of it fatal, all of it covered in the 2Go guide’s troubleshooting, but it’s complexity the cable simply doesn’t have.

The bits are identical — so set your expectations

Here’s the part the format wars won’t tell you: both paths are bit-exact. The cable sends the original file’s bits down USB with no resampling. The 2Go fetches the original file and plays it untouched. DSD works on both — over the cable it goes as DoP, and the 2Go receives the whole .dsf and hands it to the Hugo 2 intact.

So the same album, played both ways, arrives at the Hugo 2 as the same data. Anyone promising you a dramatic sound-quality leap from switching is selling something. If there’s a difference, it lives entirely in that one remaining variable — electrical noise from the transport — and how audible that is on any given system is a genuinely contested question. I can hear myself wanting to hear it, which is exactly when I trust it least.

Where they actually differ

Strip away the bits, which are equal, and you’re left with this:

The phone’s job. Cable: it’s the transport, tethered and working. 2Go: it’s a remote, free to lock and pocket.
Isolation. Cable: phone noise reaches the DAC. 2Go: a purpose-built transport sits between them.
Dependencies. Cable: none. 2Go: your network, plus a bridge holding the library.
Reliability. Cable: as reliable as plugging in a cable. 2Go: as reliable as your Wi-Fi.
Where it shines. Cable: on the go. 2Go: a settled home system.

So which is optimal?

The non-cop-out answer: they’re optimal for different lives, and most people who own both end up using both.

At home, the 2Go is the nicer way to live. The phone is free, the battery’s full, the DAC is fed by a dedicated transport instead of a pocket computer, and “press play and walk off” is just a better daily experience than being leashed to a cable. If you have a fixed listening spot and a network you trust, this is the one to set up.

On the move — or any time you want zero failure points — the cable wins, and it gives up nothing on the bits to do it. It’s the more reliable path and the only portable one. When the Hugo 2 is in a bag rather than on a shelf, there’s no contest.

What I’d gently steer you away from is buying a 2Go expecting it to sound better than a clean USB cable into the same Hugo 2. That’s not what you’re paying for. You’re paying for the phone to leave the audio path — for the freedom and the isolation, not for a different stack of bits. If those are worth it to you, it’s a lovely upgrade. If you mostly listen on the go, save the money and keep using the cable; you already own the bit-exact path.

The reassuring thing about a Hugo 2 is that you can’t really get this wrong. Cable or 2Go, the DAC at the end is the same and the bits reaching it are the same. Pick the path that fits where you listen, and let the Chord do the part it’s good at. If you haven’t set up either yet, start with the DSD-over-cable guide — it’s the five-minute version — and graduate to the 2Go when you want the phone out of the loop.

Setting up a Chord 2Go with an iPhone

Thu, 04 Jun 2026 00:00:00 GMT

The Chord 2Go is a lovely, slightly fiddly little network streamer. Getting an iPhone to send music to it — the real bit-exact version, not some down-sampled AirPlay copy — is one of those tasks that’s simple once you know the path and baffling until you do. This is the path I use.

Fair warning up front: I make 1-bit, and version 1.5 added the feature this guide leans on. The networking ideas apply to any DLNA setup, but the click-by-click is 1-bit plus its bridge. If you run a different player, skim for the concepts and ignore my screenshots-in-prose.

What the 2Go actually is

It’s a network streamer. It pulls music off your network (or an SD card) and feeds a Chord DAC — it bolts onto a Hugo 2, or works with other DACs through the 2Yu adapter. It speaks several protocols: Roon, AirPlay, DLNA/UPnP, MPD. The one we want is DLNA/UPnP, because it can move your files bit-for-bit with no re-encoding on the way.

Why not just AirPlay?

You can AirPlay to a 2Go, and for background listening it’s fine. But AirPlay re-clocks and caps the stream — it isn’t the bit-exact path you bought a Chord for. DLNA is different in a subtle but important way. With AirPlay, the phone pushes a stream to the 2Go. With DLNA, the phone just tells the 2Go where the file lives, and the 2Go fetches and plays the original itself. The phone stops being in the audio path. That’s the part that makes it bit-exact.

What you need

A Chord 2Go on your network (with a Hugo 2, or via 2Yu with another DAC)
An iPhone with 1-bit 1.5 or newer
A 1-bit bridge running on your network, with your library on it
All three on the same LAN — same Wi-Fi, same subnet

One thing to get clear before you start: this is a bridge feature. The 2Go plays by fetching a file from a URL, so the music has to live on a bridge for it to have something to fetch. Tracks on an SMB share or sitting on the phone itself can’t be cast this way — there’s no address for the 2Go to pull from.

Step 1 — Get the 2Go onto your network

Use Chord’s GoFigure app to join the 2Go to your Wi-Fi (or wire it in). That part is Chord’s territory and their docs cover it well, so I won’t re-tread it. Just confirm the 2Go is actually on your network and reachable before going further — most of the “it doesn’t work” emails I get are really “the 2Go was never online.”

Step 2 — Run a bridge with your library

The 1-bit bridge is the free, open-source companion server — Mac, Windows, Linux, or a Raspberry Pi next to your music drive. Point it at your library, pair your phone with the QR code from the admin console, and you’re set. If you already listen to 1-bit through a bridge, you’ve done this step and can move on.

Step 3 — Turn on the bridge’s DLNA MediaServer

This is the piece that makes the whole 2Go path exist, and it’s off by default. Switch it on and the bridge advertises your library on the LAN as a DLNA server that the 2Go can read.

One thing worth saying plainly: UPnP has no authentication. While that MediaServer is running, anyone on your network can browse and stream that library. So it only ever binds your local network — never a public address — a public-mode bridge refuses to start it at all, and you should only turn it on for a network you trust. Leave it off on café or shared Wi-Fi.

Step 4 — Pick the 2Go in 1-bit

Open Now Playing, tap the output picker, and the 2Go shows up as a renderer. Other DLNA control apps you might already use — mconnect, BubbleUPnP, Linn Kazoo — work the same way; the 2Go is just the one I built this against. Select it.

Step 5 — Press play

Here’s what happens under the hood: 1-bit hands the 2Go the track’s metadata and a link to the file on your bridge. The 2Go fetches the audio itself over your LAN and plays it, bit-exact, into your Chord DAC. Nothing routes through me or any server I run — at that point the phone is basically a remote control, and you can lock it and walk off while the music keeps going.

DSD works too, by the way. Because the 2Go receives the original file rather than a stream from the phone, a DSD track arrives intact and your Chord setup decodes it the way it always does. The 2Go does the work; the phone is just pointing at the bytes.

When the 2Go won’t show up

Check that everything is on the same subnet. Guest networks and a router setting usually called “client isolation” or “AP isolation” will hide your devices from each other. This is the number-one cause, by a wide margin.
Confirm the DLNA MediaServer is actually on in the bridge admin console.
Mind multicast. DLNA discovery uses SSDP, which rides on multicast, and some mesh Wi-Fi systems drop multicast between bands or nodes. If discovery is flaky, getting the phone and bridge onto the same band or node often fixes it.

When it shows up but won’t play

The track has to live on the bridge. If you’ve selected the 2Go but you’re playing from an SMB share or on-device files, there’s nothing for it to fetch. Add (or move) the music to the bridge and try again.

Chord spent years of firmware getting the 2Go to this point; it took me one release to plumb the iPhone side into it. And the reward for all of it is that the setup disappears: open the app, pick the 2Go, press play. That’s the bar for gear like this — once it’s working, you should never have to think about it again.

How to play DSD on an iPhone

Thu, 04 Jun 2026 00:00:00 GMT

Some version of this lands in my inbox most weeks: “I put my DSD files on my iPhone and nothing plays them right. What am I doing wrong?” Usually the answer is nothing. The iPhone just doesn’t play DSD the way you’d expect, and a lot of apps cover for that in a way that quietly defeats the point.

I build 1-bit, an iOS player that plays DSD properly, so I’ve spent more hours in this corner than is strictly healthy. Here’s the whole picture in plain terms — what you need, what trips people up, and how to check you’re actually hearing DSD and not a polite imitation of it.

What DSD actually is

DSD is Direct Stream Digital — the format behind SACD. Instead of the 16 or 24 bits per sample that PCM uses (CDs, FLAC, most of what you own), DSD stores audio as a single bit, sampled millions of times a second: 2.8 MHz for DSD64, 5.6 for DSD128, 11.2 for DSD256. It’s a different way of describing the same sound. On disk it usually shows up as a .dsf file, occasionally .dff. If you want the longer version of why it exists, I wrote about it when 1-bit launched.

The catch nobody mentions

iOS has no built-in DSD playback. Apple Music won’t do it. The Files preview won’t do it. Out of the box, the iPhone is a PCM device, full stop.

So every app that claims to “play DSD” on iOS is doing one of two things. Most convert it to PCM first — easy, works everywhere, and sounds fine to almost everyone. A few wrap it in something called DoP and send the untouched bits to a DAC built to decode them. The second one is what you’re actually after, and it needs specific hardware.

What you need

An iPhone — USB-C (15 or newer) makes life easier; Lightning works with a camera adapter
A USB DAC that supports DSD over DoP
Your DSD files (.dsf) somewhere the app can reach
A player that sends DSD as DoP without converting it

You need a real DAC — the phone can’t do this alone

DSD has to be decoded by hardware made for it. The built-in output, Bluetooth, AirPlay — none of them carry a true DSD stream. Bluetooth and AirPlay are lossy or PCM by the time they reach the other end, so “DSD over Bluetooth” isn’t DSD anymore; it’s a conversion with extra steps.

What works is a USB DAC that lists DSD or DoP support. DACs from Chord, iFi, FiiO, Topping and the like generally handle it — check the spec sheet for the words “DSD” or “DoP” before you buy. And to be clear: a cheap USB-C-to-headphone dongle is a DAC, but a PCM-only one. It’ll play your music; it won’t lock to DSD.

What DoP is, and why you keep seeing it

DoP stands for DSD over PCM, and it’s the trick that makes any of this possible. iOS won’t hand a raw, native DSD stream to a USB DAC. So the whole industry does the same workaround: take the 1-bit DSD stream, pack it inside PCM-shaped frames, and add a little marker that tells the DAC “this looks like PCM but it isn’t — it’s DSD wearing a coat.”

The DAC reads the marker, unwraps the frames, and decodes the original bits. Nothing is lost in the wrapping; it’s the same data, just couriered in a container iOS is willing to carry. The only requirement is that your DAC understands DoP. Most modern USB DACs do.

The trap: “playing” a file vs actually playing DSD

This is the part that fools people, including careful ones.

An app can play your DSD album, show the right title, scrub through it like normal — and be silently converting it to 48 kHz PCM the entire time. It plays. It just isn’t DSD anymore. That’s the default behaviour of a surprising number of iOS players, because conversion is the path of least resistance.

Here’s how to know which one you’ve got: look at the DAC, not the app. A DAC decoding real DSD lights up a DSD or DoP indicator, or shows the rate outright — DSD64, say. If it reads PCM 44.1 or PCM 48 while you’re “playing” a DSD file, you’re hearing a conversion. The DAC is the honest witness here. The app’s screen will tell you whatever the app wants to tell you.

Doing it, step by step

Since 1-bit is my app I’ll use it for the walkthrough, but most of these steps apply to any player worth using.

Plug the DAC into the iPhone. USB-C to USB-C on a 15 or 16. On older Lightning iPhones, you need Apple’s Lightning-to-USB Camera Adapter.
Put your DSD files where the app can see them — an SMB share or NAS, a 1-bit bridge, or dropped straight into the app’s folder over Finder or Files.
Play a DSD album. 1-bit reads the .dsf, wraps it in DoP, and sends it to the DAC with no mixer and no resampling in the way.
Check the DAC. It should report a DSD/DoP lock — DSD64, DSD128, whatever the file is. That’s the whole game. If you see that, you’re done.

A word on Lightning, USB-C, and power

On USB-C iPhones a plain cable usually just works. On Lightning iPhones the bare Camera Adapter is fine for low-power DACs, but a hungrier desktop DAC may pull more than the phone wants to give — that’s when you want the version of the adapter with the extra Lightning power port, so the DAC isn’t running off the phone. If a DAC connects and then drops out a few seconds later, suspect power before anything else.

When it doesn’t work

No sound at all. Either the DAC doesn’t do DoP, or your cable is charge-only (a classic — swap the cable first).
It plays, but the DAC says PCM. The app is converting. Look for a “bit-exact” or “no resampling” setting, or switch to a player that doesn’t convert in the first place.
The DAC won’t lock, or clicks between tracks. Some DACs — Chord’s FPGA-based ones especially — need a moment to re-lock. A good player builds that settling time in so you don’t hear it.
The app says “no DAC” or doesn’t recognise your gear. That’s almost always iOS hiding the DAC’s identity from the app, not an actual fault. I went down that whole rabbit hole in a separate post.

Do you even need DSD?

Honest answer, since someone always asks: the gap between DSD and good high-res PCM is smaller than the format wars make it sound. If you have DSD files — SACD rips, native DSD recordings — play them as DSD; there’s no reason to throw bits away converting them. If you don’t have any, you’re not missing some hidden tier of sound by listening to clean FLAC.

The point of all this was never that DSD is magic. It’s that if you went to the trouble of owning it, your phone ought to play it exactly as it is. Get the three things right — a DAC that speaks DoP, files the app can reach, a player that doesn’t quietly convert — and the iPhone makes a genuinely good DSD transport.

1-bit 1.5, the one with Chord 2Go support

Wed, 03 Jun 2026 00:00:00 GMT

1-bit 1.5 is on the App Store. Same URL, new build, free update.

The easter-egg card in Settings → About keeps the multi-line habit it picked up in 1.4. This release’s verse is “One hundred three commits are past, / The music breathes, unfettered, vast. / Pure bit-perfect sound takes flight, / To fill the room with deep delight. / Let every note and chord revive, / In beautiful version 1.5.” That fifth line is doing double duty — the headline feature is playing to a Chord 2Go.

What’s new

Play to a Chord 2Go (and other DLNA renderers)Cast a track to a DLNA / UPnP renderer on your network — the Chord 2Go is the target I built this for, and generic renderers (mconnect, BubbleUPnP, Linn Kazoo) work too. Pick it from the Now Playing output picker. The app hands the renderer the track metadata and a link to the file on your own bridge; the renderer fetches and plays the audio itself, bit-exact, over your LAN. Nothing routes through a server I operate.

Playlist backup to your bridgeOff by default, per bridge. The playlists you build in the app can now back up to the bridge you run, so they survive a reinstall or a re-pair. They go only to your bridge — never to me, never to a third party. Tracks that come from another bridge or from local / SMB storage stay as opaque references.

Listening history to your bridgeOff by default, per bridge. Turn it on and the app reports each play — track, when, how long, codec, and where available the output device and DAC sample rate — to your own bridge. It’s your data: it lives on the bridge host, shows up on the admin console’s new Data page (histograms, most-played, export), and the bridge never forwards it anywhere.

On-device diagnosticsA small daily performance summary — CPU/energy, memory, playback runtime — pulled from Apple’s on-device MetricKit and surfaced in the in-app diagnostics screen. It never leaves your phone. Handy when something feels off and you want to see whether the app is the culprit.

A note on the Chord 2Go path

DLNA casting is a bridge feature, not a standalone one. The renderer pulls the audio straight from your bridge over the LAN, so the track has to live on a bridge — an SMB share or the on-device library can’t be cast this way, because the renderer needs a URL to fetch from. And one thing worth saying plainly: UPnP has no authentication. While the bridge’s DLNA MediaServer is on, any device on your LAN can browse and stream that library. So it’s off by default, it only ever binds your local network (never a public IP), and a public-mode bridge refuses to start it at all. Turn it on for a network you trust, and leave it off on shared Wi-Fi.

And on the bridge side

Bridge 0.1.5 ships alongside — 45 commits since 0.1.4, iOS wire protocol unchanged at v1.

The big one is the DLNA / UPnP MediaServer that makes the Chord 2Go path possible: an All Tracks list plus a Folders hierarchy with free-text search, bit-exact audio, cached upscale variants surfaced as alternate streams. Then the two storage features that land on the bridge: per-device playlist backup and an opt-in listening history, both viewable on the admin console’s new Data page with JSON / CSV export. Plus a public-mode pairing-QR fix (the QR now carries the served Let’s Encrypt cert fingerprint and the public dial URL, so phone pairing no longer trips the TLS pin), a sudo bridge update fix for FUSE-mounted libraries, and honest variant accounting across the admin views. Full release notes on the bridge releases page.

The data we collect is still none

Two of the new features move your data off the phone — but only to a server you run, and only if you turn them on. Playlist backup and listening history are off by default and go solely to your own bridge. DLNA playback stays on your LAN. When backup or history is enabled, the app mints a random per-device identifier (stored in the Keychain, not linked to your Apple ID or any ad identifier) so the bridge can keep each device’s backups separate. The MetricKit summary never leaves the device. No new third-party services, and aside from the multicast capability that SSDP discovery needs, no new permissions. The privacy policy spells all of it out, and the App Store nutrition label stays “Data Not Collected”.

Same audio path

No transcoding. No resampling. No mixer in the path. DSD goes out as DoP to your USB DAC; PCM goes out at the file’s native sample rate; and when you cast to a DLNA renderer, the renderer fetches the original bytes from your bridge and does its own job. The phone moves bytes and metadata; the hardware does the rest. How DSD playback is handled →

The unromantic version

If you have 1-bit installed: open the App Store and tap update. Your SMB shares, bridge pairings, and Settings carry over. DLNA casting, playlist backup, and listening history are all off by default — you turn them on if and when you want them. To play to a Chord 2Go, enable the DLNA MediaServer on your bridge first, then pick the renderer from Now Playing.

If you’re new: it’s a free download, iPhone or iPad, iOS 26.1 or later. Bring a NAS or a bridge, a USB DAC for DSD (or a Chord 2Go on the network), and music you actually like.

1-bit 1.4, the one that goes in the car

Tue, 26 May 2026 00:00:00 GMT

1-bit 1.4 is on the App Store. Same URL, new build, free update.

Last release I shipped a codename that lied about the version. This time I went the other way. Open Settings → About in 1.4, tap the easter-egg card, and instead of a single-line codename you get a small poem: “One hundred three commits deep, while the tired engineers sleep. Offline downloads finally stand, CarPlay grids across the land. Tap the text and clear the view, version 1.4 is ready for you.” The two main features are right there in the verse, so I’ll keep the writeup short.

What’s new

CarPlayBrowse, search, tap-to-play, and a Now Playing view on a CarPlay head unit — reading the same on-device library that’s on your phone. Uses Apple’s CarPlay Audio entitlement, so it’s a real CarPlay app, not a screen mirror. DSD is hidden from CarPlay because DoP markers can’t survive head-unit playback; everything else plays.

Offline downloadsPick a track, an album, a playlist, save it to the iPhone. Files live in app-private storage, are hidden from Files, and are excluded from iCloud backup (so they don’t quietly fill your iCloud quota). Delete the download, delete the share, or uninstall the app — they’re gone.

Diagnostic logs in SettingsA rolling buffer of recent log lines lives at Settings → Logs. The logs stay on the device. A Share button is there for the rare case I ask you to send them — never automatic, never on by default.

DSD-domain DSP (Beta)An optional on-device chain — decimator, sigma-delta modulator, volume stage — that stays in the DSD domain instead of converting to PCM first. Off by default. Beta because thermal headroom on older iPhones can still surface the odd crackle, and I’d rather call that out than pretend it’s settled.

And on the bridge side

Bridge 0.1.4 ships alongside — 44 commits since 0.1.3, wire protocol unchanged at v1.

Two big themes. Public-mode hosting: bridge init —public spins up a bridge intended for a small VPS, with native Let’s Encrypt provisioning via autocert, a single-user admin auth layer, and an endpoints filter so the public listener only exposes /v1/health and the /v1/share/… family. CarPlay-optimized variants: a new optimize-… variant class and a two-channel priority queue so on-demand CarPlay transcodes don’t sit behind a lifetime Upscale backlog. Plus a tile-grid Library Inspector, a Prometheus /metrics endpoint on the admin listener, and a background orphan-sidecar GC sweeper. Full release notes on the bridge releases page.

What got refined

A small carve-out in the iOS pinning policy: bridges deployed with a custom domain and a public Let’s Encrypt cert are now ATS-trusted, while LAN, Tailscale-magic-DNS, IP-literal, and mDNS hosts still pin against the fingerprint captured at pairing. The shape of what the app sends — paths, byte ranges, MusicBrainz IDs — is identical. The Settings screen got an IA pass to make room for the v1.4 surfaces. The deployment target is now iOS 26.1.

Same audio path

No transcoding. No resampling. No mixer in the path. DSD goes out as DoP to your USB DAC; PCM goes out at the file’s native sample rate. The phone moves bytes; the DAC does the DAC’s job. How DSD playback is handled →

The unromantic version

If you have 1-bit installed: open the App Store and tap update. Your existing SMB shares, bridge pairings, and Settings carry over. Offline downloads, the DSP chain, and the log viewer are all off by default — you turn them on only if and when you want them. CarPlay shows up the moment you plug into a head unit.

If you’re new: it’s a free download, iPhone or iPad, iOS 26.1 or later. Bring a NAS or a bridge, a USB DAC for DSD, and music you actually like.

1-bit 1.3, the one where we forgot to change the codename

Sat, 16 May 2026 00:00:00 GMT

1-bit 1.3 is on the App Store. Same URL, new build. Update on your iPhone and it’ll be there.

Open Settings → About in the new version and tap the easter-egg card. You’ll find: Version 1.3, codename “Too Late, Too Soon”. Which was 1.2’s codename. The release checklist has a step for this — three sites in AboutView.swift that have to move together every release — and the checklist quietly didn’t get run this time. Once a build is uploaded to App Store Connect, the easter-egg version is frozen in the binary; the only fix is a fresh build and a re-submission, which is not what 1.3 needed. So the codename slip ships as-is, and the iOS repo’s CLAUDE.md now opens the release-checklist section with this exact story so the next release doesn’t repeat it. Honest changelog: a codename that lies about the version, fixed in 1.4.

The actual shape of 1.3 is the boring kind of release: the scanner becomes less demanding of your attention, the library starts understanding music that isn’t pop-rock, and a Listening Tips guide collects the things that make this app sound the way it should.

What’s new

Opportunistic background scanYour first scan of a big library can keep going after you background the app. iOS schedules a one-shot task; the work runs only when the device is charging, idle, and on Wi-Fi. The whole thing stays on your phone — no traffic beyond the SMB or bridge connection you’d already authorised. Off-switch in Settings → Refresh.

Classical metadataComposer, conductor, and work fields land in the library. Opera, symphonic, and concert recordings group the way the music does instead of being flattened against ALBUMARTIST. Bridge 0.1.3 extracts the same fields server-side; SMB sources read them out of the file tags directly.

Listening tips, in one placeA new in-app guide collects the things that make 1-bit sound the way it does: which DAC, what DoP actually is, why DSD pre-caches by default, when gapless does and doesn’t work, when to bypass crossfeed. Open from Settings → Listening Tips.

Long-press a folderHold any folder in the browser to play it, queue it next, append to a playlist, or jump to its album — without leaving the browse view. Small thing; surprising how often you reach for it once it’s there.

And on the bridge side

Bridge 0.1.3 ships alongside — 62 commits since 0.1.2, wire protocol unchanged at v1, every change additive. The headline:

A new Library Inspector in the admin console: folder-first browse, FTS5 search, cursor-paginated virtualized scroll, inline metadata edit, per-track variant management, a stats drawer, and a Jobs page for upscale runs. Classical extractors (composer / conductor / work / original year / BPM) across FLAC, MP4, AIFF, WAV, DSF, and DFF. Multi-value ARTIST / ALBUMARTIST preserved on FLAC and MP4 instead of being collapsed. ALAC source bit depth read from the MP4 alac atom rather than inferred. A configurable upscale.variantsDir with source-mirrored layout plus a bridge upscale move CLI. And a Tailscale Let’s Encrypt cert-expiry warning at startup so the iOS ATS 398-day re-pair cliff stops being a surprise. Full release notes on the bridge releases page.

What got refined

The v1.2 per-share cellular gate now also stops the next-track preloader from quietly reaching for cellular when you’ve picked Warn before streaming or Wi-Fi only, and Low Power Mode is honoured the same way. Artist Detail filters orphan albums so the view doesn’t show ghosts of moved files. Stale albumID / artistID on tracks are canonicalised on the next access, so a re-scan that re-grouped an album doesn’t leave the queue pointing at the old ID. Album headers gain a mixed-format subtitle (“FLAC 24/96 · DSF DSD64”) for compilations that mix encodings.

Same audio path

The unromantic version

If you have 1-bit installed: open the App Store and tap update. Your existing SMB shares keep working. Your existing bridge pairings keep working. The cellular default stays Always allow; the background scan is on by default but iOS still controls whether and when it runs. Nothing else changes until you say so.

If you’re new: it’s a free download, iPhone or iPad, iOS 18.6 or later. Bring a NAS or a bridge, a USB DAC, and music you actually like.

1-bit 1.2: too late, too soon

Sat, 09 May 2026 00:00:00 GMT

1-bit 1.2 is on the App Store. Same URL as before, new build. Update on your iPhone and you’ll see it.

Too late: 1.2 took a beat longer than planned. Too soon: there’s already more I want to ship. The shape of this release is the gap between the two — the pieces that had to land together, the ones that proved themselves on TestFlight, the ones that didn’t make the cut and roll into 1.3.

The headline: a more honest bridge you can actually feel safe handing to other people on your network, and a per-share cellular gate so DSD doesn’t quietly torch your data plan.

What’s new

Admin-approved pairingBridges can now require explicit operator approval before a new device pairs. The authorized-device list lives on the bridge you run, not on a server I operate. Pairings now feel like the front door of your house — you decide who walks in.

Discover on networkA new tap-to-pair sheet finds nearby bridges, fires the join request, waits for approval, and persists the share automatically. No tokens to type, no QR scanning if you don’t need it.

Optional upscaled variantsBridges can generate optional upscaled PCM variants on request. Generation runs locally on your bridge and never leaves the network you control. Toggle per share; switch source ↔ upscale per track from the Now Playing wand.

Per-share cellular controlPick Always allow, Warn before streaming, or Wi-Fi only. The gate covers bridge and SMB equally — Tailscale-fallback hosts can still reach cellular, so this is the right knob to refuse a 5 GB DSF file on a metered link.

What got quieter

A fully lock-free render path (no syscalls during the audio callback). Hardened DSF parsing (the sort of belt-and-braces that only matters when something corrupted breaks through). Smoother variant switching mid-track. PCM gap recovery on long screen-off / sleep cycles. Same bit-exact output, fewer edges to catch on.

Same audio path

The unromantic version

If you have 1-bit installed: open the App Store and tap update. Existing SMB shares keep working. Existing bridge pairings keep working. The cellular default is Always allow, so nothing changes until you say so.

If you’re new: it’s a free download, iPhone or iPad, iOS 18.6 or later. Bring a NAS or a bridge, a USB DAC, and music you actually like.

1-bit 1.1, from the heart

Wed, 29 Apr 2026 00:00:00 GMT

1-bit 1.1 is live on the App Store — same URL, new version. Update on your iPhone and you’ll see it.

Most of 1.1 doesn’t show up in a bullet list. It’s the rough edges from launch week — pairing flows that didn’t quite hold, scanner behaviour on bigger libraries, the long tail of small fixes you only find once real people start using the thing. The headline addition on top of all that polish: the 1-bit bridge — a free, open-source companion server that gets your library off SMB and onto a transport designed for the app.

What’s new

1-bit bridge, properly launched. A free, open-source companion server you can run on a Mac, a Windows PC, a Linux box, or a Raspberry Pi sat next to your music drive. Pair an iPhone in three steps with a QR code from the admin console, and the phone talks to your library over HTTPS instead of SMB. It’s noticeably faster than SMB — first scan after pairing finishes in seconds — and unlike SMB, it works over Tailscale or WireGuard, so your library is reachable from anywhere your phone has signal. Same bit-exact audio path on the iPhone side: the bridge ships bytes; the phone still owns DSD, DoP, gapless, all of it. Bridge page has the details.

Bonjour for bridges. Nearby bridges show up automatically in the Add-Source sheet. Type the bearer token (or scan the QR) and you’re paired.

The unglamorous half of 1.1. The launch-week fixes that don’t make a feature list — an app-quits-on-launch trace pinned to root services rebuilding on every parent re-eval, a first-launch mass-delete trap on libraries larger than ~500 albums or artists, and auto-revive when iOS 26 silently stops AVAudioEngine ~600 ms after a tap with a USB DAC attached. Settings also got a proper home: theme override, alternate app icons, ReplayGain on PCM (DSD always stays bit-exact), Bauer crossfeed for headphones, a defer-next-track-preload toggle to quiet shuffle and repeat clicks, and a per-DAC resync-delay override for unknown hardware.

A privacy policy that’s actually been audited. Three documents now move together — the in-app screen, the web policy, and the bridge’s own privacy page. Zero personal data collected, by design — which inherently complies with the GDPR (EU), the Swiss FADP, and the CCPA. The policies and the code are checked against each other before every release.

Same audio path. No EQ, no loudness, no resampling, no dithering, no funny business. DSD goes out as DoP to your USB DAC; PCM goes out at the file’s native sample rate. The phone moves bytes; the DAC does the DAC’s job.

The unromantic version

If you already have 1-bit installed: open the App Store and tap update. Your existing SMB shares keep working. Your scan history keeps working. Your Now Playing keeps working. The bridge is additive — you only opt in if you want it.

If you’re new: it’s a free download, iPhone or iPad, iOS 18.6 or later. Bring a NAS, a USB DAC, and music you actually like.

Sonogram's April Glow-Up: A Vinyl, A Particle Storm, and A Landscape That Won't Stop Pulsing

Mon, 27 Apr 2026 00:00:00 GMT

We blinked, two weeks vanished, and somehow the codebase grew three new visualizers, a personality, and a tan. Here’s the field report.

Three new ways to look at sound

🪩 Landscape landed (and then learned to drive)It started life as a humble flat city of bokeh lights. Then it wanted depth. Then traffic. Then a Waze-style chase-cam following a music-reactive car around a tilted MapLibre night map, with shockwaves rippling out on the bass drops. We let it cook. The result is a drone-eye view of a city that breathes with your music. Try it on something with a low end you can feel in your chest.

💿 The Vinyl visualizer spins back inBecause some songs deserve to be watched on a turntable, even a virtual one. Grooves, glow, the whole vibe. Hi-fi nostalgia for an era that mostly existed in our heads.

✨ A new music-reactive Particle visualizerSpectrum reactivity, shockwaves, bloom, light trails. Basically: dump a track in, get a music video out. Save it as a 4K PNG — yes, that button works now (see below).

🧴 The whole site got a glow-up

A new palette, friendlier loading and empty states, a site-wide accessibility pass, and a refreshed About page that finally admits Landscape exists. Mobile fullscreen no longer bullies your iPhone. The Save 4K PNG button no longer dares you to double-click it.

🔍 We got serious about being found

robots.txt, a real sitemap, canonical URLs, structured data — the works. If you’ve been Googling “audio visualizer that doesn’t look like 2008,” we’d like to introduce ourselves.

🛡️ And the boring-but-important stuff

Rate limits where they should be. An audit sweep across uploads and steganography. A tighter CSP. A service worker that finally understands cross-origin. Faster admin pagination. Fewer orphaned audio files in the bin out back. The sort of changes nobody asks for and everyone benefits from.

Take it for a spin at sonogram.ars.md.

When 'no DAC' isn't no DAC

Mon, 27 Apr 2026 00:00:00 GMT

Who this is for

Readers who care about iOS audio plumbing, audiophile gear, and the friction between Apple’s privacy abstractions and high-end-audio expectations.

Skip this if you write iOS code for a living (a third of this will be familiar) or you don’t own — and don’t plan to own — an external DAC of any kind.

A 1-bit user plugged Audeze SINE headphones with the Cipher Lightning cable into an iPhone 13, opened the app, and reported that it “acted as if there was no DAC.”

A note before we start: both the SINE and the Cipher cable are discontinued — Audeze stopped making the SINE around 2019, and the Cipher cable has been listed as discontinued by retailers since. Used units still circulate on the secondhand market, and a non-trivial number of audiophiles are still using them daily. The specific hardware in this story is fading out, but the technical predicament I’m about to describe applies to every Lightning DAC ever made and to every USB-C audio dongle on shelves today. iPhones moved to USB-C with the iPhone 15, and the iOS-side problem moved with them.

The Cipher cable is a DAC. The Lightning port on iPhones is purely digital — every Lightning headphone or audio adapter contains its own digital-to-analog converter, by definition. Audeze’s Cipher goes further: 24-bit / 48 kHz DAC plus a small DSP that runs Audeze’s own EQ for the SINE / iSINE / LCD-i headphones. The cable retailed for about $250 when new.

So when an audiophile-focused music player tells the user “no DAC,” it’s wrong on the facts. But it’s also reflecting something real: from the app’s perspective, this hardware is indistinguishable from a $9 plastic dongle.

Here’s why.

What iOS gives you

When an audio device is connected, iOS exposes it through AVAudioSession. The output port has three string fields a third-party app can read:

portType — a coarse category. Lightning headphones land on .headphones.
portName — a human-readable name. iOS reports "Headphones".
uid — a unique identifier you’d hope was model-specific. iOS reports "Wired Headphones".

These are the strings for the Cipher cable, and for Apple’s own EarPods Lightning, and for any random no-name Lightning headset. On iPhone 15 / 16 with USB-C, plug in a $9 USB-C-to-3.5mm dongle or a $1500 portable USB DAC and AVAudioSession reports the same thin set of generic strings for both. Apple’s audio API treats them as equivalent — identical text labels for hardware that ranges from worthless to high-end.

There’s a reason for this. Apple’s design philosophy with AVAudioSession is abstraction: audio apps shouldn’t have to write custom drivers for every dongle on the market. From the OS’s point of view, all of those devices accept PCM audio at compatible rates over the same connector. The differences (max sample rate, DSP capability, headphone-driver pairing) are hidden because exposing them would push complexity onto every audio-app developer.

For 99% of audio apps, that abstraction is exactly right. For an app whose entire identity is bit-exact playback to whatever DAC the user has invested in, it’s painful.

What I tried before giving up

The instinct of a stubborn engineer is to look elsewhere. There must be some way to learn the model.

USB descriptors. Class-compliant USB DACs identify themselves with a Vendor ID and Product ID — a manufacturer-specific pair of numbers that uniquely names them. On Linux, macOS, or Windows, an app can read these directly. On iOS, IOKit (the framework that exposes them) is unavailable. CoreMIDI doesn’t surface them either. Apple has deliberately left no public API for an app to read VID/PID for an audio device.
AVAudioSession’s port descriptions. As above — the strings are generic and intentionally so.
Bluetooth or AirPlay metadata. Doesn’t apply — Cipher is wired, and the same problem exists for wired USB-C DACs.

So an iOS app cannot, by any supported route, learn that the connected output is anything more specific than its broad port category.

The MFi back-channel

There is a way to see Lightning hardware in detail. It’s just not available to most apps.

Apple’s MFi program (Made for iPhone) certifies accessories through an authentication chip embedded in the cable. When an MFi accessory is plugged in, iOS reads the chip and learns what the accessory says about itself: manufacturer, model, firmware version, capabilities. An app can read all of this through the External Accessory framework — but only if the app declares the manufacturer’s specific protocol string (something like com.audeze.cipher.audio) in its Info.plist under UISupportedExternalAccessoryProtocols.

The catch: the manufacturer has to whitelist the app’s bundle ID before the app can use the protocol string. This isn’t a public API anyone can opt into — it’s a per-vendor, per-app handshake. Audeze’s own Audeze HQ app has the Audeze protocol string and Audeze’s blessing, so when you plug in the Cipher cable it can read the model, adjust the 10-band EQ stored in the cable’s flash, and update the cable’s firmware. My app, or any third-party music player, can’t see any of that — by design.

The result is a quiet asymmetry that audiophile customers don’t usually notice: the manufacturer’s app gets the rich hardware view; everyone else gets "Headphones". There’s no public API I can write that bridges this gap. I’d need a partnership with Audeze — and even then, only Audeze hardware would benefit. The same pattern exists for USB-C DACs, with a similar set of vendor-specific protocols (Apple has not opened the framework up; they’ve only widened the connector).

The fix

Once you accept that you cannot identify the DAC, the fix is just: be honest about what you don’t know.

The original UI had a green Verified DAC card that appears in the now-playing signal-path sheet when the app’s known-DAC list matches by name. For Chord, iFi, FiiO, Topping, AudioQuest’s DragonFly Cobalt, and a handful of others, that match works because their USB DACs report a model-specific name in portName. For anything iOS labels generically — Cipher among them — no match, no card. The user reads the missing card as “the app doesn’t see my DAC.”

The fix:

For external outputs without a profile match, render a neutral grey card that says “External output detected · Standard audio path” alongside whatever name iOS gave us (often just “Headphones”). It looks nothing like the green Verified card, deliberately.
It does not say “bit-exact path active.” That would be a lie. iOS may apply sample-rate conversion silently if the stream exceeds the hardware’s ceiling — and the same UI shows an orange resampling indicator when that happens. A “bit-exact” claim alongside an “iOS is resampling” indicator would be a direct contradiction.
For DSD playback errors on unprofiled hardware, the error message now leads with the most likely cause: “The connected output likely doesn’t support DSD (some Lightning headphones and USB-C dongles are PCM-only).” Less mystery, more useful.
For accessibility, the card combines into a single VoiceOver element with an explicit label — “External output detected: Headphones. Capabilities aren’t in our profile list. DSD may not negotiate.” — instead of forcing a screen reader user to swipe through icon, title, subtitle, info-glyph one element at a time.

That’s the whole fix. No new API surface, no new heuristic, no fragile guesses. The only thing it really does is replace the absence of a green card with the presence of a neutral one.

What I learned

Two things stick.

First: absence of information is different from absence of the thing. The original UI was technically correct — there was no “Verified DAC” card because no profile matched — but the user read it as “no DAC.” The presence of an explicit “External output detected” card uses no new information, and yet completely removes the perception. The most common UX bug in audiophile software, in my experience, is the same as the most common UX bug elsewhere: silently saying nothing when you should say “I’m not sure.”

Second: Apple’s privacy and security philosophy has audiophile collateral, and the lesson outlives the hardware. The MFi walled garden is mostly a good thing — it stops malicious accessories from impersonating each other and stops apps from fingerprinting users by their dongle pile. But it also means that the most basic question an audiophile asks (“is my expensive cable being recognized?”) cannot be answered honestly by any app the manufacturer hasn’t blessed.

The Cipher cable that started this story is discontinued. The DAC chip in your USB-C dongle, whoever made it, is not. If you’ve ever wondered why a music player says “Output: Headphones” while a piece of expensive hardware blinks proudly on your desk, this is why. The DAC is there. The app just isn’t allowed to know its name.

1-bit is out

Tue, 21 Apr 2026 00:00:00 GMT

Today I shipped 1-bit, an iOS music player for people who care how their music sounds.

Why “1-bit”? Because that’s the number that matters. DSD — Direct Stream Digital, the format behind SACD — encodes audio as a single-bit stream sampled millions of times a second, instead of the 16 or 24 bits per sample you get from PCM (think CDs, FLACs, most of Apple Music). It’s a different way of thinking about digital audio, and it’s what 1-bit is built around.

The name is also a promise. The app doesn’t resample, doesn’t remix, doesn’t touch your audio on the way to your DAC. What goes in comes out — bit for bit.

What it does

Point it at an SMB share on your home network — a Synology, a QNAP, a Mac running File Sharing, whatever you already have — and 1-bit scans your library, reads the tags, pulls the artwork, and builds a browseable catalog of your albums and artists. Plug in a USB DAC and hit play.

If you don’t run a NAS, drop files into the app’s Documents folder via Files or Finder over USB and it works the same way.

No accounts. No cloud. No streaming service. Your music, your network, your DAC.

Bit-exact, and what that actually means

For PCM, 1-bit sends samples straight from the file to the audio engine to your DAC, bypassing the iOS system mixer entirely. For DSD, it reads DSF files and packs the 1-bit stream into DoP (DSD over PCM) frames for the DAC to decode natively.

This matters most if you own something like a Chord Hugo 2, a Mojo 2, or one of the many USB DACs that can lock to a native DSD carrier. Those DACs sound their best when software gets out of the way. 1-bit gets out of the way.

It also handles the fiddly parts that trip up most iOS music apps:

Sample-rate renegotiation when you jump from a 44.1 kHz FLAC to a DSD128 album
PLL settling time on FPGA-based DACs (the Chord family needs roughly 700 ms to re-lock cleanly — Hugo 2 will go silent without it)
Gapless playback when consecutive tracks share a format
DoP marker-phase continuity across track transitions, so your DAC never flickers mid-album

Who it’s for

If you have a NAS full of FLACs and DSFs, a good DAC, and a pair of headphones or speakers you actually listen to — this is for you. It’s not trying to replace your streaming service. It’s trying to be the nicest possible way to listen to the music you already own.

1-bit is on the App Store now, for iPhone and iPad running iOS 18.6 or later.

Just press play.

What's new in Sonogram — 11 April 2026 update

Sat, 11 Apr 2026 00:00:00 GMT

It’s been a busy week on Sonogram. Since April 2nd I’ve shipped almost 130 commits covering new visuals, a brand new About page, a raft of stability fixes, and some serious under-the-hood work on performance and frame-rate independence. Here’s a tour of the highlights.

New things to look at

A photorealistic turntable visualThe biggest visual addition: a PBR-rendered turntable built on Three.js. It started life as a standalone Vite project (turntable-visual/) and is now integrated directly into the main app — complete with depth-of-field, proper resource cleanup, and real GPU memory management.

A reimagined Landscape sceneThe landscape visual was looking a bit gloomy, so we brightened the terrain, raised the sun, tamed the fluid effects, and ultimately transformed it into a snowy Alps-at-dawn scene. The sun glow and sky atmosphere now stay in sync with the sun color parameter.

Nebula gets a music-reactive sunburstA new lighting effect that pulses with the music, layered on top of the existing volumetric clouds.

Spectrogram feels aliveWe added a particle system, orbital camera drift, and a dynamic background — the visual now breathes with the track instead of sitting still.

An About pageSonogram finally has a proper About page describing the project and crediting contributors, including Domenico Brizi for the volumetric cloud work.

Mobile hamburger menuTop navigation now collapses cleanly on mobile, with the expand/collapse behavior finally working the way you’d expect.

Things we removed

Part of polishing the app meant trimming visuals that weren’t pulling their weight. These have all been retired:

Fire MandalaLight BulbVinyl (superseded by Turntable)

Under the hood

This is where a lot of the work went, and it’s the kind of thing you feel more than see.

Frame-rate independent smoothing, everywhere

We hunted down every hardcoded smoothing alpha — frequency averages, per-bin ampTex writes, beat smoothing, decay helpers — and rewrote them so the look stays the same whether you’re at 60fps or 144fps. The alphaFreq formula is now self-documenting with explicit target alpha and fps.

Audio processing is a single pass

We collapsed multiple loops into one, deduplicated RMS calculations, and hoisted loop-invariants out of the raymarching and spectrogram animation loops.

Memory and resource cleanup

Mic streams now stop on cleanup, GPU resources are disposed properly, and init races are guarded so you can’t double-initialize a visualizer mid-load. DOF focus calculation was also fixed.

THREE.Clock → THREE.Timer

The landscape and turntable visualizers have been migrated off the deprecated API.

Load-time optimizations

Asset cache-busting now works correctly, esm.sh is preconnected, and the Vinyl visualization’s quadratic audio gain scaling has been fixed.

Refactor: one visualization, one file

Render and shader code for each visualization has been extracted into its own file, which should make future contributions considerably less painful.

Sonogram: Transforming Sound into Visual Fingerprints

Wed, 01 Apr 2026 00:00:00 GMT

Sonogram is a full-stack web app that transforms audio files into unique generative visual artworks — “sonic fingerprints.” Upload a song, and it analyzes the audio’s mathematical properties to produce an interactive 3D visualization.

What it does

StudioUpload or record audio (MP3, FLAC, WAV, etc.). The app runs DSP analysis (spectral features, MFCCs, chroma, tempo, key detection via librosa) and renders a real-time 3D visualization using Three.js.

GalleryBrowse, search, and filter saved public visualizations by title, artist, genre, or BPM. Each piece has a shareable page with server-rendered OG tags for social previews.

Compare ModePlace two tracks side-by-side in a “Mirror Matrix” visualization.

Admin DashboardManage records, toggle visibility, and bulk-export artwork as ZIP files.

EmbeddableEach visualization has an iframe-friendly /embed/ route for external use.

Tech Stack

Layer	Technologies
Backend	FastAPI, SQLAlchemy (SQLite), Uvicorn
Deployment	Fly.io, Docker
Audio Analysis	librosa, scipy, numpy (Single-pass STFT)
Frontend	Vanilla JS (~9K lines), Three.js (WebGL), PWA
Imaging	Pillow (for PNG generation)

Interesting Facts

Steganography

UUIDs are invisibly embedded in artwork PNGs using LSB (Least Significant Bit) encoding in the blue channel.

Magic Bytes”SONO”

LocationFirst 320 pixels

BenefitRe-upload a PNG to recover metadata — no server lookup needed

Hardware-aware Rendering

The frontend auto-detects GPU, CPU cores, RAM, and display size. It then classifies the device into LOW / MEDIUM / HIGH tiers to dynamically adjust:

Resolution scalingBloom strengthParticle density

Deterministic Visuals

A SHA-256 hash of the raw audio bytes serves as the seed. This ensures that the same file always produces the exact same visualization, maintaining a 1:1 relationship between sound and art.

Three Visualization Modes

Users can switch between three distinct modes in fullscreen:

SpectrogramTime-frequency heatmap

CrystalAbstract 3D geometry

LandscapeTerrain-like surface

Key Detection

The app uses the Krumhansl-Schmuckler algorithm. It correlates chroma vectors against major/minor pitch-class profiles to estimate the musical key with high accuracy.

Theme System for AI Art

Includes theme definitions (Bauhaus, Neon Cyberpunk, Aerial Objects) with ControlNet scale parameters, hinting at a future generative AI triptych feature.

Hybrid Architecture

The Gallery and Studio operate as a SPA-style vanilla JS application for speed, while individual sonogram pages (/s/{id}) are server-rendered to ensure rich social sharing metadata and SEO optimization.

The Qobuz that Claude Code Built

Tue, 24 Mar 2026 00:00:00 GMT

Qobuz Hi-Res Music Manager is a self-hosted web application built for audiophiles who want full control over their high-resolution music collection. It connects to the Qobuz streaming service to search, organize, and play lossless audio — up to 24-bit/192kHz FLAC — all from a sleek, dark-themed interface.

What It Does

At its core, the app is an all-in-one music management hub: search Qobuz’s catalog and automatically organize local media files into a local library with proper metadata, cover art, and folder structure.

AI-Powered Discovery — An optional Google Gemini integration lets users search for music using natural language (“dreamy 80s synth-pop with female vocals”) and receive personalized album recommendations based on their favorites.

Multi-Room Casting — Stream to AirPlay 2 speakers, Volumio devices, or manually paired endpoints across your home network, all controlled from the browser.

Real-Time Visualizers — Two canvas-based audio visualizers: a frequency-mapped blob analyzer and a 3D aurora terrain that morphs with the bass. Both are built with the Web Audio API.

By the Numbers

Stat	Value
API endpoints	74
Backend (`app.py`)	6,980 lines in a single file
Frontend (`index.html`)	408 KB — the entire SPA in one file, no build step
External frameworks	Zero (vanilla JS + CSS, no React/Vue/Angular)
Database	SQLite with 2 tables
In-memory caches	600+ entries across albums, artists, and AI results
Supported cast protocols	AirPlay 2, Volumio, manual HTTP

Tech Stack

Python 3.13 + Flask on the backend, with vanilla HTML/CSS/JS on the frontend — no bundler, no framework, no build step. Just run ./run.sh and the browser opens. The entire app is two files: one Python file and one HTML file.

Notable dependencies include pyatv for AirPlay 2 streaming, zeroconf for network device discovery, mutagen for audio tag management, and google-genai for AI features.

What Makes It Interesting

Zero-framework frontend — 408 KB of hand-written HTML/CSS/JS powers a fully responsive SPA with mobile bottom-nav, real-time progress tracking, and 3D canvas visualizations.

Monolithic by design — The entire backend is a single 6,980-line Python file — no microservices, no ORM, no async framework — yet it handles background scheduling, device discovery, and multi-client playback coordination.

AI circuit breaker — Gemini errors trigger a 5-minute backoff to prevent log spam — a production-grade resilience pattern in a personal project.

Smart deduplication — Case-insensitive artist matching merges variants like “K.D. lang” and “k.d. lang” automatically.

Fully offline-capable — No CDN dependencies; the entire UI works without internet once loaded.

Hello, World

Mon, 23 Mar 2026 00:00:00 GMT

Every blog starts somewhere. This is mine.

Why write?

Writing forces clarity. When I try to explain something I half-understand, I quickly discover the edges of my understanding. A blog is a place to build that clarity in public — slowly, post by post.

I’m not trying to be comprehensive or authoritative. I’m trying to think better, and writing is how I do that.

What this blog is

ars.md is a place for notes on:

Technology I’m building or using
Ideas worth examining
Observations that won’t fit anywhere else

Posts will vary in length. Some will be quick notes, others longer essays. I’m not committing to a schedule — just to writing when I have something worth saying.

Comments

At the bottom of each post, you’ll find a comments section powered by Giscus — which means comments are actually GitHub Discussions. You’ll need a GitHub account to comment, which keeps things civil without needing moderation infrastructure.

I’ll try to reply to every comment.

That’s it for the introduction. More soon.

On Minimalism in Software

Fri, 20 Mar 2026 00:00:00 GMT

There is a certain pleasure in software that does one thing well.

Not because complexity is inherently bad — some problems are genuinely complex and deserve complex solutions. But most problems aren’t. And most software accretes complexity not because the problem requires it, but because it’s easier to add than to remove.

The cost of features

Every feature a piece of software has is a feature that must be:

Designed
Implemented
Tested
Documented
Maintained
Understood by the user

The last item is the one we most often forget. A feature that confuses users is worse than no feature at all, because it occupies mental space without providing value.

What minimalism actually means

Minimalism in software isn’t about having fewer lines of code, or a smaller bundle size, or fewer dependencies (though those are often useful side effects). It’s about having fewer concepts — fewer things the user has to understand to accomplish their goal.

A minimal interface is one where the user’s mental model and the software’s model are the same thing. When they diverge, friction appears.

The refactoring that never happens

The problem with complexity is that it compounds. Adding a feature to a simple system is easy. Adding a feature to a complex system requires understanding the existing complexity first, which is expensive, which makes each new feature more likely to add yet more complexity rather than integrate cleanly.

The refactoring that would restore simplicity keeps getting deferred — it’s never the most urgent thing, until suddenly the system is incomprehensible to everyone including the people who built it.

I don’t have a prescription for how to avoid this. I just find myself increasingly drawn to things that are simple. And increasingly suspicious of things that aren’t.