Help / Troubleshooting

The first DTS or AC-3 track can take a minute or two to start

You press play on a DTS, AC-3 or TrueHD track and nothing happens for a long moment. Then it plays normally, and so does every surround track after it. What you are waiting on is your security software inspecting the surround decoder before Windows will let it run, and that normally happens only once.

The short answer

Surround formats do not go through the same decoder as FLAC or MP3. They go through FFmpeg, a separate program that ships inside Vesari Stylus, which the app launches as its own process for the track you are about to hear.

The first launch of that program is the slow one. It is a big file, around 223 MB, and it is unsigned, so Windows Defender or whichever product you run reads it end to end before allowing it. Expect roughly one to two minutes on that first run. Windows keeps the result, so every start after it is quick.

There is nothing to change and nothing is broken. It is a one-time cost on your PC, not a toll you pay at every launch.

Which files this affects

Only the ones handed to that decoder:

.dts, .dtshd, .ac3, .eac3, .thd and .truehd.
.wav files holding a DTS bitstream instead of plain PCM, which is what a DTS-CD rip is. Vesari Stylus checks the RIFF header and scans the first 8 KB of every WAV for the DTS sync word, so these route to the surround decoder despite the .wav name.
Anything the built-in decoder cannot read on its own, such as Monkey's Audio, WMA or Matroska audio. Those fall back to the same program, so they can be slow to start for the same reason.

FLAC, MP3, AAC, OGG, ordinary WAV, AIFF, WavPack and ALAC are decoded inside the app and do not touch it.

What you see while you wait

The elapsed time stays at 0:00 and the seek bar does not creep forward. The position clock counts real decoded audio only, so it cannot run ahead of what you can hear. Sound and counter start together.

Why it happens once

Each surround track gets its own short-lived decoder process, so the app is not holding anything open between tracks. What makes the first one slow sits outside the app: reading a large program off disk, and letting your security software inspect it. Windows caches both.

Anything else that has already used the decoder has paid the cost for you. A library scan that had to probe a raw bitstream file, a ReplayGain scan over surround tracks, or starting a CD rip all leave it warm. The ripper does this deliberately, waking the decoder on a side thread as the rip begins, so the first track's verification is not held up by it.

Ways to shorten it

Play one surround track early, before you settle in to listen, or let a CD rip do it for you.
Install FFmpeg with winget. Vesari Stylus puts a winget-installed copy ahead of its bundled one, and your security software has quite possibly cleared that copy already. Checking the bundled surround decoder has the single command. A copy installed some other way does not take precedence, so winget is the route that helps here.
Add Vesari Stylus to your antivirus exclusions. The same article explains why security software takes an interest in this file.

In a queue, the cost lands at the front

Once a surround track is playing, the next track's decoder starts as soon as the current one has finished decoding, which is well ahead of what you are hearing. A queue of surround albums therefore pays the wake-up once, at the very start, and runs on from there.

What the Signal Path shows afterwards

In DSP Rack, the Signal Path readout shows a surround track's Source as the file type alone, with no bit depth or sample rate, and no Resample stage appears. That is not a fault. The surround decoder hands over audio already converted to your device's rate and does not report what the file's own rate was, so the app shows nothing rather than guessing.

When it is not this

The track never plays at all, or every surround track is silent while the rest of your library is fine. That is the decoder missing rather than waking. See Checking the bundled surround decoder and A track won't play or is flagged damaged.
It breaks up part way through rather than being slow to start. See Playback stutters, drops out or skips.

If it never gets faster

If every surround track is slow to start, including later in the same sitting, the scan explanation does not fit. Open Settings → Logs and use the search box in Application Logs to look for FFmpeg. One line is written each time a track is routed to the surround decoder, so you can see whether the app is reaching it at all. Reading the logs covers what else is in there.

Then use Settings → Support → Report a Bug, which attaches your recent logs. Say which format, how long the wait is, and whether it happens on the second and third surround tracks too. Is this a bug? How to report it explains what makes a report useful.

← All help articles