Help / Troubleshooting
My DSD files have a dead seek bar, or are flagged as damaged
Two faults used to land on .dsf and .dff files: the seek bar had no scale and no total time, and Library Health counted them as damaged. Both are fixed, and clearing them takes one update and one rescan.
The short answer
- Install the current version by running its installer over the one you have. Your library, playlists and settings are untouched. See Updating Vesari Stylus.
- Open the app. The false damaged flags on DSD tracks are cleared the first time it opens your library, so the Damaged / undecodable files count drops without you pressing anything.
- Run Rescan Library on the Tools tab. Your DSD tracks are marked for one fresh read that fills in length, sample rate and channel count, and the seek bar comes back with them.
Both steps are one-time.
Why the seek bar was dead
The tag reader that handles the rest of your library has no reader for DSD, so length, sample rate, channels and bit depth came back empty and nothing was stored for them. With no known length the seek bar has no scale, so it is switched off: the slider greys out with the tooltip Track length unknown, seeking unavailable, and the total time shows dashes. Elapsed time still counts up, and the track still plays.
A scan now asks the bundled FFmpeg decoder for those properties whenever the tag reader comes back empty on a .dsf, .dff or .ape. The catch was the files already indexed: a rescan skips any file whose size and modified time still match what is on disk, so those rows would have kept their blanks forever. The update marks exactly those rows for one fresh read, which is why step 3 matters.
One property stays blank on purpose. DSD is one-bit, with no PCM bit depth to report, so the app leaves that field empty rather than invent a number. A DSD track's quality badge shows the format and a very large sample rate, 2822.4 kHz for DSD64, with no bit depth.
Why they were flagged as damaged
Super-Tag identifies music partly by acoustic fingerprint, and the fingerprinting tool carries its own cut-down decoder. That decoder has no reader for the DSDIFF container, so it could not open a .dff at all. The wording it returns for a file it cannot open mentions invalid data, and the code reading it took that for a corrupt-audio verdict. A message that condemns an entire container format is describing the format, not your audio.
Failing to open a file is now told apart from failing to decode one, so that wording is no longer a damage verdict. A .dff is also pre-decoded through the app's full FFmpeg before fingerprinting, so it gets a real fingerprint. .dsf is deliberately left out of that pre-decode: the fingerprinting tool does have a reader for that container and opens it directly, so an extra decode would only cost time.
The clearing pass covers .dsf and .dff alike, with one deliberate exception. If the loudness scanner also skipped a track, that track's flag is left alone. The loudness scanner uses FFmpeg, which reads DSD fine, so a skip from it is an honest finding about that file. If a DSD track still sits under Damaged / undecodable files after you update and rescan, treat it as real and replace the file. Every Library Health category, explained covers the card, and Library Health counts that look wrong covers counting oddities.
What actually happens when a DSD file plays
Playback tries the built-in decoder first, which has no DSD reader, then falls back to the FFmpeg copy that ships with the app. FFmpeg converts the one-bit stream to PCM at the rate your output device is running, and that PCM is what you hear. The file on disk is never altered.
Some consequences:
- Your DAC receives PCM. Native DSD output and DSD over PCM are not in this build, and carry no date. See Known limitations and what is coming.
- In WASAPI Exclusive, the Lifetime-tier output mode, a DSD track opens the device at 48 kHz, and the boundary into it is never gapless, so expect an ordinary gap where it starts.
- The Bit-perfect row on the Devices page reads NO once a DSD track has played; before anything is measured it shows a dash. With no source depth to compare against the output, the app declines to make the claim rather than guess. See Bit-Perfect mode.
- Tags cannot be written into a DSD file, and the app does not read tags out of one either, so a DSD track is listed by its filename. Super-Tag can identify it and store the match in your library, but the write into the file fails and the track appears under Matched but not written to file. That match lives in the library and not in the file, so it does not travel with it.
If it is still wrong
If DSD tracks still show dashes after updating and rescanning, or a cleared count comes straight back, tell us. Use Report a Bug in Settings and say which extension it is, .dsf or .dff. Is this a bug? How to report it explains what that sends.