AudioBand puts the current song and its controls in the Windows taskbar

A taskbar overlay driven by media sessions

Audio Band is described as allowing you to display song information from various sources directly in the taskbar, and the mechanism it relies on is the media session that Windows exposes to applications. That design decision explains most of what the project does and does not do. Because the information comes from the system's global media session rather than from a player specific API, a player that publishes media sessions can be supported without writing code against it. The Windows 10 entry in the supported list points at a community maintained list of working applications for the GSMTC, the Global System Media Transport Controls, which is the Windows mechanism that reports what is playing and lets software control playback. The project lists Spotify, iTunes, MusicBee and Windows 10 applications such as Groove Music as supported, and the documentation covers how to support a preferred player and how to develop locally.

The visible result is a taskbar that carries the album art, the artist name, the song title and a progress indicator, plus playback controls. The screenshots in the repository show the same panel with a custom theme, which is the point of the fourth listed feature, the ability to customize the look of it entirely. The audience is narrow and specific, Windows desktop users who keep a music player running in the background and who want glanceable information without alt tabbing.

Plugins are how a new player gets added

The feature list puts plugin support third, right after displaying the current song and controlling music from the taskbar, and the documentation gives supporting a preferred audio player its own section. That ordering reflects how the project actually extends. Rather than shipping a separate integration per player, AudioBand defines a plugin surface, and the bundled Spotify, iTunes, MusicBee and generic Windows session support are implementations of it. For a user this matters because it is the difference between waiting for a pull request and writing an adapter. For a developer it is the difference between a closed tool and one with a documented extension point, which is why the contribution guidance invites people to report bugs, suggest features and send pull requests.

The repository layout is consistent with that. There is a src/ directory holding the application, a tools/ directory that is usually where developer utilities and helper scripts live, and a .github/ directory carrying the workflows and issue templates, alongside CONTRIBUTING.md. The C# choice is not incidental either: on Windows, a .NET application can attach to the taskbar through the shell interfaces without requiring a native Win32 interop layer for everything, and a WPF based interface can draw the album art and customisable visuals that the feature list promises.

Getting it installed, and where the real documentation lives

The project documentation is hosted on GitHub Pages, and the README links straight to it with the note that it contains information on how to install Audio Band, how to support your preferred audio player and how to develop it locally. The README does not list the individual install commands or the steps for building from source, so the honest thing is to point you at those pages rather than guess at a package name or a build flag. The documentation site is the place to look for the current install route, the list of supported players in detail, and the developer setup for a local build.

The releases tell you where the project is in its life. Version 1.2.5 was published on 2025-05-10, before that 1.2.4 on 2024-06-25 and 1.2.3 on 2023-09-21, and the repository records a last push on 2026-04-20. That combination is worth reading carefully: the code is still being touched, but the shipped binaries have not moved in a year and a half. The maintainer's own warning is the clearest statement of status, and it is a warning rather than a plan to continue, so the README does not promise a fix for the issues listed in it.

Maintenance status, stated plainly

The first thing in the README is a callout saying the project is no longer being actively maintained, while still welcoming pull requests, with a link to issue 152 for more. That is unusual to see at the top of a README and it tells you the maintainer has made a considered decision rather than run out of time. The practical effect is that the plugin surface and the supported player list will drift with Windows itself. A player that ships a new media session format, or a Windows release that changes the shell interfaces, will not get an update from this project unless someone volunteers one. The plugin model partially protects you here, since an adapter you write yourself keeps working when the surrounding application does not, but that is a workaround rather than a fix.

There is also a licensing detail to check before you ship anything. The repository carries both a LICENSE file, the MIT licence named by the repository metadata, and a separate LICENSE-3RD-PARTY file. Projects that draw on libraries, icon sets, fonts or other assets usually need to reproduce those terms, and the presence of the third party file indicates that this one does. Read both before you redistribute the application, particularly if you intend to bundle it with your own tooling.

What it is not, and what to use instead

AudioBand sits in a narrow space, and it is easy to confuse it with two other kinds of tool. The first confusion is with a full media player or a unified remote control. AudioBand does not manage your library, does not offer cross device control and does not sync anything between machines; it reads what is already playing and offers transport controls for it. If your need is a remote control for speakers in another room, this is the wrong tool. The second confusion is with the operating system's own media overlay, the flyout that Windows shows when you press a media key. AudioBand's argument is that it is more customisable than that and carries album art and progress in the taskbar itself, which is a real but narrow advantage.

The alternatives differ in approach rather than in feature count. The native Windows flyout requires no third party software at all and stays in step with the system, at the cost of the customisation AudioBand exists to provide. A richer third party utility such as ModernFlyouts, whose community list AudioBand links for Windows session support, does similar overlay work for system surfaces, so if you are on a recent Windows version and your goal is the modern flyout experience rather than a music specific display, that project may serve you better. A media server or a remote control application solves the cross device problem that AudioBand deliberately leaves open, with a server component to install and accounts to manage. None of them replaces the specific thing AudioBand does, which is a music focused taskbar panel with a plugin model.

Where the taskbar approach stops working

There are hard edges to a taskbar hosted application, and they are the reason a project like this can be marked unmaintained without the idea being wrong. The display lives in a small, fixed area of the taskbar, so long track names, long artist names and some window widths will be truncated or clipped, and how gracefully that happens depends on the theme. The taskbar itself has changed shape across Windows releases, with the release of Windows 11 and the move to centered taskbar icons altering the space available and the way third party shells attach to it. An application that renders into that region depends on shell interfaces that Microsoft can and does change.

Second, media session support is not universal in practice even where the platform offers the API. A player that does not publish a global media session, or that publishes an incomplete one, will show a panel with missing fields or no transport buttons, and the README's own pointer to a community list of working applications exists precisely because the set of players that behave well is smaller than the set of players people use. Third, the plugin route only pays off if someone is willing to write and maintain the adapter, so a player with a small user base may never get one. That is a maintenance cost that lands on you rather than on the project.

Editorial conclusion

Adopt AudioBand if you run Windows, want the current track and playback controls one click from the taskbar, and are willing to rely on a project its own maintainer has marked as no longer actively maintained. Do not adopt it if you need a maintained upstream, because the project states plainly that it is unmaintained and points to issue 152 for the reasoning, and the last published release is v1.2.5 from 2025-05-10. Before you install it, read the documentation pages for your specific player, check the third party licence file that sits beside the project licence, and confirm that the player you use is on the supported list or can be added through the plugin model.

Frequently asked questions

Official sources

1. AudioBand/AudioBand on GitHub
2. Issues
3. License: MIT
4. README
5. Releases