this post was submitted on 27 Nov 2023
3 points (100.0% liked)

Data Hoarder

168 readers
1 users here now

We are digital librarians. Among us are represented the various reasons to keep data -- legal requirements, competitive requirements, uncertainty of permanence of cloud services, distaste for transmitting your data externally (e.g. government or corporate espionage), cultural and familial archivists, internet collapse preppers, and people who do it themselves so they're sure it's done right. Everyone has their reasons for curating the data they have decided to keep (either forever or For A Damn Long Time (tm) ). Along the way we have sought out like-minded individuals to exchange strategies, war stories, and cautionary tales of failures.

founded 1 year ago
MODERATORS
 

Does that mean there was bitrot ready in the original file? Something else? How is the checksum even generated successfully if it's corrupted or undreadable in the first place.

Any way to fix?

top 9 comments
sorted by: hot top controversial new old
[–] [email protected] 1 points 11 months ago (1 children)

Are you saying it fails to make a checksum at all? What program? Try this one: https://github.com/gurnec/HashCheck/releases/tag/v2.4.0

[–] [email protected] 1 points 11 months ago (3 children)

I am on using hashcheck lol. It works. But when checking, it comes out as unreadable.

[–] [email protected] 1 points 11 months ago (1 children)
[–] [email protected] 1 points 11 months ago

I can create the .md5 file but upon opening it to test, it comes up as "unreadable" status.

[–] [email protected] 1 points 11 months ago

Why are you using third party tools for this?

An "unreadable" result sounds like a failure from HashCheck - What does your OS Native tools give you?

[–] [email protected] 1 points 11 months ago

What? The hash is just a number in a text file. Open the md5 with notepad?

You aren't very clear... Are you saying it creates the hash, but then verifying fails? I don't know what you mean by unreadable

[–] [email protected] 1 points 11 months ago (1 children)

It is important that you check to see if the file really is pristine after you take the first checksum. That you can read and use the file. Otherwise you may take a checksum of a file that is already corrupt. That is not very useful.

Most likely it is not actually spontaneous bitrot. It is much more likely that somebody made the file corrupt. Usually it is some form of user error.

[–] [email protected] 1 points 11 months ago (1 children)

Its an audio file. I can play it but cant tell easily without playing through it to see if it is corrupted at certain parts.

[–] [email protected] 1 points 11 months ago

Then you have to assume that the file already is at least a little corrupt. What you need to determine is if the level of corruption is so bad that it is a problem. If it crash an audioplayer or the file sounds bad. Ideally you have a backup copy that is better or you can download or create a new file that works OK. Possibly you can re-encode the file to fix problems. It will degrade audio quality if the encoding is lossy. But perhaps not enough to be noticeable.

Some audio file formats have embedded checksums. FLAC or WavPack. Perhaps more? You should be able to find utilites that can compare the embedded checksum with the current stored data.

In the future use a checksummed format or store separate checksums. Or zip the files. The zip format has embedded checksums. (Same with all(?) other compressed formats.)