Files previously played in Roon now listed as corrupt (ref#2BBJSJ)

Hi! What’s not quite right with Roon?

· None of the above quite fits

None of the above quite fits

· None of these quite match

Tell us what's going on

· Files listed as corrupt but have played in Roon in the past

Tell us about your home network

· Unifi

I tried playing some music today and some files are showing as corrupted. They have played in the past, you can see plays listed here:

I then loaded them in MP3Val, which said there were some header mismatches. Every other mp3 player is playing them without issue. I corrected them in MP3Val and then copied them over the existing files, so Roon should now have “good” files.

However, when I run the re-analysis it still says they are corrupted, but it also doesn’t show that these are updated files.

I can also play them in ARC:

So I guess, the question is: why are these all of a sudden “corrupt?” Why did copying over the files with validated files not resolve the issue? Why can ARC play them?

Did something change in the Roon validation in the past few releases? This album has been loaded since 2021 when I moved to Roon and I have over 40 plays of the songs on it, so what happened in Roon?

Is there a way to proactively scan? I didn’t have any notice these were corrupt until I went to play them today. Doing a focus for corrupt files only yields this album and another song I tried to play today that had the same issue, so I fear how much the rest of my roon library will not play.

Here is a link to the original file and the “fixed” version from Mp3val.

I did a little more validation. The version in ARC is streaming from the Roon core, so the same file that is being called “corrupt” is working fine on ARC.

Can we relax the “corrupt” flag on the desktop client? :sweat_smile:

Albums, sorted by artist and filtered by downloaded:

Perhaps this fix in the upcoming update may help

Hello @WWLAladdinSane

Thanks for the thorough troubleshooting on this, that MP3Val output is a big help.

We have a theory but want to confirm it with you rather than assume: there’s a known issue where CRC-protected MP3 frames get falsely flagged as corrupt by Roon, and it’s possible that’s what you’re running into here, especially since the file plays fine everywhere else, including ARC streaming from the same file. Could you please share the full/exact error text MP3Val gave you (not just “header mismatches” summarized), so we can confirm whether it specifically mentions a CRC check failure? If you know what software originally encoded or ripped this file, that would help too, since some encoders enable CRC protection by default and others don’t.

If it does turn out to be CRC-protected MP3s, the good news is a fix for exactly that is already in Roon 2.71 (build 1674), currently on our Early Access branch, and should ship in an upcoming production release. You’re welcome to try it now if you’d like to confirm: EarlyAccess: Roon 2.71 Build 1674 and ARC 1.81 Build 422 are Live!

Please share those details and we’ll go from there.

Thanks @vadim & @Suedkiez ! I’m not sure what software did the original encode, but I would suspect it is XLD (MacOS), which uses LameMP3, I’ve been using that for years. I generally use Yate to edit/write tags.

Here is the raw output of Once:

Analyzing file “\KINGGHIDORAH\GamingPC_share\01 Once.mp3”…
WARNING: “\KINGGHIDORAH\GamingPC_share\01 Once.mp3”: Wrong number of MPEG data bytes specified in Xing header (8039241 instead of 8034618)
INFO: “\KINGGHIDORAH\GamingPC_share\01 Once.mp3”: 8881 MPEG frames (MPEG 1 Layer III), +ID3v2, Xing header, CRC
Done!

Here is another file that is also giving a corrupt error:

Analyzing file “\KINGGHIDORAH\GamingPC_share\Colors.mp3”…
INFO: “\KINGGHIDORAH\GamingPC_share\Colors.mp3”: 10159 MPEG frames (MPEG 1 Layer III), +ID3v2, Xing header, CRC
Done!

So both are CRC, but Once does have something Mp3Val flags as an error, but nothing that has stopped Roon from playing it in the past.

The new release today resolved all my corrupt file issues. Thanks everyone!