My issue is that I just noticed Roon identified files as corrupt. They play fine outside Roon, and “Re-analyze track” removes the corrupt label, but it comes back when I try to play the track.
Is there any way for Roon to tell me what is wrong with this file?
Roon flags a file as corrupt when it encounters decoding errors while reading the audio stream. Since Roon is built around bit-perfect playback, it needs to decode every sample in the file exactly as it was encoded - it won’t silently skip or interpolate over damaged sections. Many other players do exactly that, which is why the same file can appear to play fine elsewhere: they conceal the error and keep going, while Roon stops and marks the file instead.
“Re-analyze track” clears the label because the initial analysis pass may not hit the damaged part, but as soon as playback reaches it, the file gets flagged again.
To see what exactly is wrong with a file, you can check its integrity outside Roon:
For FLAC files: run flac -t "filename.flac" - this tests the full stream and reports CRC/decoding errors.
For any format (FLAC, ALAC, WAV, AIFF, MP3): run ffmpeg -v error -i "filename" -f null - - this decodes the entire file and prints every error it finds, with timestamps.
If errors are reported, the file itself is damaged, and the fix is to re-rip or re-download it from the source. If you'd like, share the one affected track and we can take a closer look at it. Please feel free to upload them [url=https://workdrive.zohoexternal.com/collection/nqcgjac23027d90a441bda2c314de49d7958a/external]here[/url].
Thanks also for the feedback on the intake form - we’ll pass it along.
We have good news and a clear answer. We examined your file directly and reproduced the issue on our test system. Your file is not damaged at all: it passes full frame-level integrity checks, including its built-in checksums.
Here is what is actually happening. Your file was encoded (LAME 3.98, 2003) with an optional MP3 feature called CRC protection, where each frame carries a small checksum. This is rare and perfectly valid, but Roon’s playback engine currently rejects such files on open and mislabels them as corrupt. That also explains the behavior you observed: the analysis step accepts the file (so “Re-analyze” clears the label), while playback rejects it (so the label comes back). We have filed this with our development team, and your file gave us an exact reproduction case, thank you for that.
In the meantime, there is a quick and lossless workaround. Repackaging the file rewrites the frame headers without touching the audio data:
ffmpeg -i “input.mp3” -c copy “output.mp3”
We verified this on your track: the repackaged copy imports and plays in Roon normally, with identical audio content. If you have other files from the same era or ripper showing the same label, the same command will fix them too.
Thanks again for the report and for your patience with the testing steps.
Perfect, happy to help. Also, thanks for the workaround in the meantime. It worked flawlessly. Just for reference (if anyone else is running into this), I extended the command for applying it to all files in a directory.
Fish shell:
mkdir -p converted
for f in *.mp3
ffmpeg -i "$f" -c copy "converted/$f"
end
Bash
mkdir -p converted
for f in *.mp3; do
ffmpeg -i "$f" -c copy "converted/$f"
done
