Hello @eBerdnA,
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.