For a long time, BakBeat had the hard part underneath it.

It could scan libraries. It could read metadata. It had a growing CLI. It understood devices better than a normal music app ever needs to. It already had the bones of the thing.
But “has the bones” and “feels like a real music player” are not the same.

Over the last stretch of work, I did a full audio feature gap evaluation against the stuff people expect from a competent desktop music app. Not the fantasy roadmap version. The real one. Playlists. Repeat. Queue persistence. Ratings and favorites. Lyrics. Drag and drop. Mini player. Artwork. Sorting. Playback stats. Tag writing. The everyday stuff that makes a player usable instead of merely promising.

And now, for the first time, BakBeat is on the other side of that line.

 

What changed

This pass closed a massive amount of ground.

BakBeat now has a real playlist experience in the Mac app, backed by the same CLI-first system underneath it. Playback statistics are tracked. Favorites are first-class. Repeat modes persist. Queue state persists. Artwork shows up where it should. The app responds to media keys and publishes proper Now Playing info. Lyrics are visible. Drag and drop works. There is a proper mini player. Columns can be customized. Full-size artwork viewing is in.

More importantly, those features were not bolted on as isolated UI tricks.

They were implemented under the same rules the rest of the project uses:

• CLI-first where it matters

• explicit state over magic

• deterministic behavior over silent background mutation

• contract-first support claims instead of hand-wavy “probably works”

That last one matters a lot.

 

What BakBeat is not going to fake

One of the clearest outcomes from this pass was confirming that some “expected” behaviors should stay out unless they can be done correctly.

BakBeat does not auto-mutate your library because the filesystem changed behind your back. Scan and import remain explicit operations. Filesystem observation may inform the UI later, but it does not get to rewrite persisted library state on its own.

That is not missing polish. That is the product rule.

In the same category, gapless playback, crossfade, and EQ were intentionally moved into a later audio architecture review instead of being treated like quick checklist items. They depend on deeper engine decisions, and pretending otherwise would just create another pile of half-truths.

 

Why this pass mattered

A lot of software projects get stuck in the uncanny valley where the internals are impressive but the day-to-day experience still feels incomplete.

This pass was about getting BakBeat out of that valley.

It was about making sure the app can do the boring, normal, expected things that make people trust a player. The stuff users do constantly, not the fancy demo-path stuff.

And because BakBeat is aimed at a stranger world than most players — old MP3 devices, MiniDisc workflows, explicit library state, CLI parity, future sync discipline — getting the standard player layer right matters even more. The weird stuff only works if the normal stuff is solid.

 

What’s next

This does not mean BakBeat is “done.” Not even close. It means the audio-player foundation is now much more believable.
The next phase can be more honest and more focused:

• deeper audio architecture work

• expanded device flows

• broader format and metadata support where proof exists

• more refinement around the player experience itself

That is a much better place to build from than “still missing half the obvious stuff.”

BakBeat started as a dream of a modern iTunes for old hardware and honest libraries. After this gap pass, it finally feels less like a pile of promising subsystems and more like an actual player.

And that is a big damn milestone.