EQBuddy supports more audio formats than the Watch page indicates.

[wizen]

Audio options for custom sound list only WAV and MP3 files, but entering * and picking a .ogg file works, as well. Perhaps there are other supported audio formats whose files are not being listed?

---

EQBuddy 1.88.3 · Windows 19045

[DranakCorps-bot]

You're right on both counts, and the mismatch is ours.

The file picker filters on *.wav;*.mp3. Playback goes through the operating system's own media stack, which handles considerably more than that — .ogg among them, as you found by typing * and picking one. So the picker is advertising a restriction that the player doesn't actually have.

Two ways to make it honest, and the picker is the one that should move: it will list the formats that genuinely work, rather than the documentation being narrowed to match an arbitrary filter. Anything the OS can play should be offered.

One thing worth knowing while that's pending, since you've already found the workaround: whatever format you pick, the volume slider applies to it. That wasn't always true — a custom file that couldn't be found used to fall through to a system beep that the slider couldn't reach, which read as "the slider works for the built-ins and does nothing for my file". Fixed in 1.88.2; if you ever see a custom sound ignore the volume, that's a bug worth reporting rather than a limitation.

Thanks for testing past the filter instead of assuming it was the whole story — that's the only reason this was findable.

[DranakCorps-bot]

Done in v1.91.0 — the picker moved, not the promise.

It now offers ogg, opus, m4a, aac, wma, flac, aiff, mid and midi alongside wav and mp3, in both the Options sound picker and the spawn-alert one. "All files" is still on the end, deliberately: that list is what we know about, not a limit on what your machine can decode. Nothing validates the extension anywhere in the app — a format none of us has heard of still plays if the OS can play it, exactly as .ogg already did when you typed * and found it.

Two things your report turned up that I didn't expect:

• The filter was written out six times across the two builds, and the two had already drifted apart — the Linux/macOS build was offering .ogg and Windows wasn't. One shared list now, both pickers composed from it, so they cannot disagree again.
• Every doc comment in the code that described the setting said "a .wav/.mp3 path". Those were repeating the picker's restriction back as though it were the rule. They say "any format the OS can play" now.

Testing past the filter instead of assuming it was the whole story is the only reason this was findable — the app has always played more than it offered, and nothing on screen would ever have said so.