Frequently asked questions

flac, mp3, wav, m4a (both AAC and Apple Lossless), aac, ogg, opus, aiff, wma, WavPack (.wv) and Monkey's Audio (.ape).

Some of those — Apple Lossless, aiff, wma, WavPack, Monkey's Audio — aren't formats the built-in playback engine can decode, so bard quietly decodes them itself, once, into its own cache, and plays from that. Lossless sources stay lossless the whole way. You don't configure anything; seeking and gapless playback work the same either way, and as always your files are never touched.

If there's a format you want supported, please report an enhancement (see below).

Deliberately not supported. DSD is a 1-bit format that can't be played "as itself" through a normal computer audio stack: every player that supports it either converts it to PCM on the fly, or hands it bit-exact to a DSD-capable DAC over a special path. Converting DSD to PCM quietly defeats the reason people keep DSD files in the first place, and the bit-exact path is a promise bard can't currently make (see What is bard? on quality versus purity). So bard doesn't index DSD files at all, rather than play them in a way that pretends. If DSD support ever arrives, it will be the real thing.

bard stores all its data locally in a sql database on your computer. No tracking, no metrics, no data collection, no crash reports, no need to create an account. Your library — what you have, what you play, what you favorite — never leaves your machine.

There are exactly two things bard can contact the internet for, and both are off until you turn them on (you're asked once, during setup, and can change your mind any time in Settings):

• Artwork lookups — if you allow it, bard sends album and artist names (nothing else) to theaudiodb.com to find covers and portraits your files don't carry, downloads each image once, and keeps it locally. It's a free API, no account or token involved. Don't want it? You can set artwork yourself from an image file — your own images always outrank anything fetched — and a Settings button deletes everything bard ever downloaded.

• Update checks — if you allow it, bard asks the release feed (github.com/Ehsun/bard-release) for the latest version when it starts. The request says nothing about you, your library, or even which version you're running. Don't want it? New releases are announced right here on bard.fm, and Settings has a manual Check for Updates button that works regardless.

That's the whole list. If a version of bard ever needs to contact anything else, it gets documented here before it ships — that's a standing rule of the project, not a good intention.

Yup, you provide the cloud, if you want. If you have some kind of folder sync, you can ask bard to use it to store and pull updates. This use-case is for when you use bard from multiple computers, but have the same library on both. If you only have one computer that you play music from, just ignore this option entirely.

I introduced this feature because my music library is on a cloud-synced drive, and I want favorites/playlists that I create on my personal computer to transfer over to my work computer.

Yes you can! As long as you map it as a folder to your computer. If you can browse to it via your OS's native file browser, bard can read it.

If you're instead asking about network API calls to fetch music (much like streaming), well then no, bard doesn't do that. At least not today. Might be a feature I add in the future.

bard has an option to backup your entire database, it will output a file you can save and re-import later. I do this frequently, especially since the product is in beta right now.

Please note: your database does not contain your music. It is only the associated data that bard had put together: your playlists, your favorites, and your tags. Only you can be responsible for backing up your actual music files.

No, and it never will. No music player should modify files on disk, music playback should be a read-only operation. As far as bard's development is concerned, this is Commandment #1, the Prime Directive, General Order One, the One Ring to Rule them All. All of those things combined.

During onboarding bard will ask you for a single directory under which your music ought to be stored. It will scan this directory recursively and store the metadata and location of the songs that it finds. bard relies entirely on your music file's metadata to organize and display this. This is intentional, most music you buy will have the correct metadata embedded in the file. Each file will specify song name, artist, album name, and will even embed the album image. This, along with possibly much more.

Right now, bard reads the obvious metadata of artist/album/song, but additionally pulls out composer and album image. You can always see the full metadata in the file by bringing up the modal menu (three-dots) on a song, and clicking "Track Info". Note that I have not done any negative testing, i.e. testing to see what bard will do if I give it a totally garbled and senseless set of metadata. But if you experience it, please do file a bug (see later FAQ).

In my opinion, a music library is only as good as its metadata. I still organize my music on disk via /artist/album/song, but bard completely ignores folder structure.

No, see above. It is my opinion that your music player should not have the ability to edit your files. Music players should inherently be read-only applications. There are so many reasons for this: preventing accidental edits, preventing edits that aren't thought through, preventing irreversible changes. Metadata changes need to be done by a different tool. I have used metaflac and ffmpeg with good results. You may prefer a GUI based application though I've not tried any.

Metadata is serious business. Managing your own music well is a bit like being a librarian — have a good system in place, use it consistently, and if you change it, make sure you change it everywhere. But accept that nothing is perfect. I suppose it's like organizing anything really.

Well, not exactly.

bard implements a virtual layer between the file on disk, and what's presented in the app. Right now this is only applicable to album image because I find that to be the most commonly-missing piece of information in my library. For a whole lot of "Unknown Album", you may want to upload a custom image. When you "edit" the album image, what you are really telling bard is to store and display that image instead for that particular album.

In the future I may expand the data that can be virtualized. But never will this app modify any of your actual files on disk. The only file it will modify is its own database file and items you export/backup out of it.

bard fingerprints the metadata, so it's able to re-map your library to the database. Your favorites, playlists and tags will survive.

But see my note earlier about not having done a lot of negative-testing. I haven't tried to break bard's ability to recognize the library, so there's always corner cases that may not work. If you encounter an issue, I'd be grateful to know about it.

I have a form setup for feature requests and bugs:
github.com/Ehsun/bard-feedback/issues

Just click "New Issue".

For random comments or... yelling, you can write to me at ehsunx@pm.me.

Yes, I did fall to temptation by rolling my own thing here, but I really didn't like anything out there.

While I didn't take a sabbatical or go on a pilgrimage to look for the right tool, I did a bit of searching around and found most apps wanting in some way. I built generated bard specifically for my own needs. It's free if you want it, and I'd like to entertain ideas/requests anyone has for it. But I'll be happy even if no one else ever uses it. It's something I use daily now to enjoy my music.

And yes, I generated it using AI. I'm underselling the effort a little here, it's not like asking midjourney to generate 4 images of a cat drinking espresso and call it a day. It took several months from inception of the idea to get what I have at the time of writing (January to August 2026), and numerous late nights. Writing software is not the only part of creating a digital product/service, and it's not always the hardest either. This project had me step into the shoes of a technical product manager, a manual tester, and devops/release engineer, all at once. I've been a professional developer for two decades, but I'm tired of reading RFCs and API specs in order to craft every byte of pre-compiled (or pre-interpreted) code just so. The shortcut to having the perfect music player was there and I took it.

What I wanted in a local music player:

• An aesthetically pleasing presentation. (Highly subjective quality, but there it is.)
• A "map" of the song, i.e. the waveform.
• Separation between whole albums and singles.
• Ability to organize music in ways that are meaningful to me (via tagging).
• An interface that lends itself to intentional, meaningful listening, as well as background, ambient listening.