Corrupt Flac files not being reported, no -F option


I’m having two linked problems.

One is that Roon silently fails to recognise FLAC files with frame CRC mismatches.

In practice, this shows up as a track with correct length, but with a flatlined waveform preview after the corrupted frame.

Compounding the issue is that files with such errors are not reported as corrupt in the skipped files inspector, so, at this point, there’s no way to see if there was a filetransfer issue other than manually load every file.

The second is that I can’t seem to find a user-facing flac -f option, which’d allow the option for the decoder to power through errors (it currently skips to next track), at the cost of such a skip potentially being audible, of course.

You are correct in that -F doesn’t exist. Cold comfort. You might suggest that as a new feature. But understand that Roon may skip for reasons other than a corrupted file, so tagging a track as “corrupt” might be problematic.

FWIW, Roon won’t “catch” tracks with illegal characters in the filename. They don’t show up as a skipped file either. The file, I think, gets rejected at the system level, so Roon never officially sees it.


Thanks for the hints.

It’s more exotic than “OS doesn’t see weird filenames”… Roon sees the files, and indexes them, at the correct length, but doesn’t see they’re corrupt, which is why this looked more like a case for @support than a case for feature reqs.

This is what the waveform looks like according to Roon:

I’ve tried forcing re-analysis, as well as downloading the corrupt file from the library, deleting it in the library, and then re-uploading, and the behaviour’s consistent (i.e, it sees the file at correct length, but ignores the corruption).

Here’s what xAct returns on CRC check (I don’t have the CLI tools installed, but I’m pretty sure it’d be the same):

01 [filename]: testing, 11.000000% complete
01 [filename]:

01 [filename]: ERROR while decoding data

Ah, I see. You have a good point. It would seem that Roon doesn’t CRITICALLY scan the entire track before playing. I wonder if performance might be an issue, i.e., front-end scanning of tracks before playing might slow things down. Dunno. Or maybe its a low-yield coding thing. Or maybe… :smile:

It’s just weird. I’d figured it was a performance thing as well, but I’d assume some type of reading through the file would be necessary anyway to generate the graph, which explains the time it takes to analyse new tracks, so my assumption is that it’s more of an oversight than a performance thing. For some reason, it’ll flag broken mp3s, but not broken FLACs… Anyway, it’s no biggie, but maybe @joel or someone else might like to have a look at it once they’re done with all the feature requests.