Apologies if this is already something easy to do in Roon, but I don’t see how.
When importing new files, Roon will analyze the audio. As the KB points out, this is a good time to indicate files that are corrupt in some manner. I’ve actually seen this twice: once with a FLAC album and once with an AAC album from iTunes. And, sure enough, the files were corrupted. Cool feature. I even created a book mark on a “Focus” defined by showing all corrupted files.
But, once the file has been imported and analyzed, is that the end of the corruption detected? I mean short of a failure to playback the file itself?
I would be great to see a button in settings to force a re-analyze of all files in a given storage location, with a displayed page with a list of files determined to be corrupted.
Like the backup feature, it would also be cool to be able to schedule this to run periodically.
Now… put on your future cap… in the blue-sky world of Ken’s ultimate version of Roon, my 3TB Dropbox is also used to backup my actual audio files (not just the Roon DB). After detecting a corrupted audio track, Roon auto-magically reaches out to my Dropbox and restores the damaged file.
I’ve spent a lot of time thinking about what Roon could do with the local library in Dropbox, but I’ll stop.
Under Settings - Storage, there are three dots to the right of your storage location. Clicking on the dots opens a menu that includes a Force Rescan. The next step I’m not sure about unless you go back to Focus to find the newly scanned corrupted files.
Correct me if I am wrong, but rescan is not the same as re-analyze. Rescan is just looking for new/removed files. Re-analyze will perform the complete audio analysis and identification processing on the audio tracks.
Why should Roon have anything to do with backing up or restoring music files? I don’t want Roon to have anything to do with backing up or restoring files.
Roon needs to stick to its core competencies and backup isn’t and shouldn’t be one of them.
Files detected as corrupt on import is all you should need. If your system is regularly corrupting file data then that needs addressing first.
Also, if you sync your data with dropbox as a backup, what is to stop the corrupted file being mirrored to dropbox and overwriting the ‘good’ copy?
Yes, I understand all that; I worked in the storage industry for a long time. But it does happen more than people realize, usually as a result of a software error.
if you sync your data with dropbox as a backup, what is to stop the corrupted file being mirrored to dropbox and overwriting the ‘good’ copy?
Right, that’s the whole point of periodically checking the local copy. It’s called “scrubbing” in the storage world. If you are routinely checking data, you have a greater likelihood of detecting bad bits w/o replicating the damage to a back-up location.
Well, if the music files were being written to all the time then there might be some reason to be concerned about corrupted files. But, the music files are not being written to, at all. They are being read. Bits randomly flipping on hard drives is not all that common. Also, scrubbing only works if you have an OS with checksums designed to do scrubbing.
If you use FLAC, you can use command line tools to check the integrity of the FLAC checksums. I use FLAC so I can do this any time I want.
How? Roon does not keep checksums on its own. Does Roon use FLACs checksum system to verify FLAC files? I don’t think it does. How would it check the integrity of file formats that don’t have a checksum system like ALAC or WAV or AIFF?
Seriously…how? I never worked for storage company or in the storage industry so you may have information I don’t have. How could Roon detect corrupt data in music files?
Roon does not checksum the files itself. Most audio file types do not create checksums when the files are created. FLAC is the exception but I don’t see Roon verifying that checksum. Maybe they could. But you still have all the other file formats to deal with.
The bottom line is don’t see it as Roon’s job to verify the integrity of the music files. That falls to the OS or the user.
Roon reports corrupted files. I looked through the knowledge base, but it doesn’t state how it identifies corrupted files. Does anyone know how Roon does this? I’ve got several files in my collection that didn’t rip correctly. They have glitches. Why doesn’t Roon see these as corrupt?
Roon reports files that it cannot read as the files they claim to be as corrupt. That is header information at the beginning of the file. That is way different than data corruption in the music data. Roon does not detect that. I could go in and flip all kinds of bits and Roon would never notice…even on initial scan.
It may be that all Roon does is attempt to parse the header and/or any embedded id3 tags or INFO chunks (i.e. WAV). Failure to do so means the file is corrupt. Beyond that… I don’t know. I did a little searching to see if anyone is looking at a PCM waveform and detecting bad data, like a sample that doesn’t fit with the surrounding samples. Many tools out there that “detect/repair” audio files, but these also seem to be limited to header/metadata correction - not the PCM data, itself. So, I guess this whole “feature suggestion” is a worthless red herring.
Yeah, it seems Roon identifies corrupted files as files it can’t read. I’ve not experienced this, but I know others who’ve had Roon hang on a corrupted file, presumably one that wasn’t identified as corrupt by Roon. Maybe a feature request to add more robust file analysis?
…and some people already have problems with how long the current Roon implementation takes analyzes tracks. As is said previously, it really isn’t Roon’s job to check music files for data corruption. Other than with FLAC with its own checksum in the file, how would Roon know if the data was correct or not???
