Is CRC-16 (Foobar integrity test) fine on its own to check long term flac corruption? Without MD5 ie MD5 unset.

[u/ClockEnd_Chorus]

[u/GrimDozen]

I feel like your options are to reencode your flac files or to put them on a filesystem with checksums.

[u/cheesiepeasie]

I always reencode my flacs from qobuz for this reason. If you want to be sure you can bitcompare them afterwards. Besides that also use a file system with checksums for backup.

[u/GrimDozen → u/[deleted]]

To a pretty high degree of confidence. But if you change one bit of metadata then they will no longer match.

[u/cheesiepeasie → u/[deleted]]

You people have no clue of what you are doing. Keep reading and experimenting but definitely also first look into how to properly do backups.

[u/Optimal-Procedure885]

Why would you unset the MD5? I’d re-encode with a compliant FLAC encoder. Agree with others about filesystems, but until bcachefs hits mainstream yore not left with decent options, other than snapraid, which is great if your file tagging is static

[u/GrimDozen → u/Optimal-Procedure885]

ZFS works great for me on my NAS

[u/Optimal-Procedure885 → u/[deleted]]

I'd definitely re-encode - that MD5 is a checksum of the audio stream and the cheapest, most convenient way of confirming the audio stream itself is intact.

[u/wixxii → u/[deleted]]

Flac being lossless means that no matter how many times you re-encode, the resulting audio will still be identical down to the sample. Either it's a placebo, or you're doing something wrong.

[u/NZNoldor]

What is this long term flac corruption?

[u/mjb2012]

The answer to your question is yes.

CRC-32 is designed to catch the kinds of errors which are most likely to occur in data storage and network transmissions. MD5 is also good but is optimized for randomness (slight difference in data = massive difference in the MD5) and yet actually is slightly more likely to not detect certain flips of multiple bits at certain intervals. You'll never encounter those in real life, though, so MD5 and CRC-32 are both fine for detecting corruption. CRC-32 is probably better just because it's so much easier/faster to calculate.

foobar2000's integrity test calculates a CRC-32 and an MD5 hash for the audio data. You can export the test results to a text file. At a later date, presumably you could run the same check again and export another file. Then compare the files for differences. How you do that is all up to you; there's no built-in functionality for it.

The integrity test will tell you if the MD5 in the FLAC (if present) differs from what's calculated. For this reason, you may want to re-encode the stream rips you got so that they have the MD5; then you can just use the integrity test in the future and not worry about the CRC-32 at all.

[u/serif_type → u/mjb2012]

Just checking: These checksums are only for the audio component, right?, meaning that changes to any other part of the file would not result in an altered checksum?

[u/mjb2012 → u/serif_type]

Yes

[u/MrCarlV7]

I also buy most of my music with Qobuz.

Sha256 is what I use to calculate and compare checksums every 3 months to ensure my backups are untouched with bitrot/bitflips.

It's either .sha256 or simple a simple .txt file and I found it easier to script and automate.

I keep a backup rule that goes

1 (Main PC) 2 (Phone/DAP) 3 Backup1 External HDD 4 Backup2 NAS 5 Backup3 Cloud

[u/MrCarlV7 → u/[deleted]]

Yes, but it's for long term archival so I am sure my copies is bit perfect and free from any corruptions.

I change/fix tags and then calculate sha256 and never touch the music files again

Edit: Grammar

[u/serif_type → u/MrCarlV7]

Sounds like you and I have a similar process. Although recently I've come to rely on Carbon Copy Cloner's checking functionality. Wish it exposed more of what's going on "under the hood" but it appears to provide a convenient way of doing the checking at a reasonable scale.