Jump to content

Bit rot and filesystems

Recommended Posts

Brilliant, Bill!


One great feature of Apple's afhash program is that it appears to compute the hashcode from the audio data only, excluding the tags. This is good for those of us who modify the tags from time to time, since the original hashcode should remain invariant.


That's an advantage over the Linux approach which that change the hashcode whenever you modify a tag embedded in an audio file.

HQPlayer (on 3.8 GHz 8-core i7 iMac 2020) > NAA (on 2012 Mac Mini i7) > RME ADI-2 v2 > Benchmark AHB-2 > Thiel 3.7

Link to comment

Besides how can you take an article seriously by someone using the Unity interface?



One never knows, do one? - Fats Waller

The fairest thing we can experience is the mysterious. It is the fundamental emotion which stands at the cradle of true art and true science. - Einstein

Computer, Audirvana -> optical Ethernet to Fitlet3 -> Fibbr Alpha Optical USB -> iFi NEO iDSD DAC -> Apollon Audio 1ET400A Mini (Purifi based) -> Vandersteen 3A Signature.

Link to comment
That's an advantage over the Linux approach which that change the hashcode whenever you modify a tag embedded in an audio file.


It doesn't matter from corruption detection point of view, because checksums are compared against the latest modification point. And with log structured file systems like Btrfs you can also make snapshots and compare old and new versions of the file or revert the changes you made.


And of course it is not bound to any particular file type, same checks apply to all files regardless of content.

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment

More stable link: bitrot: A shell script to detect changes in the audio component of ALAC files - Blogs - Computer Audiophile


Here is my first attempt to write a shell script to detect bitrot (changes) in ALAC files.




Download, make sure the file is called bitrot with no suffix, and change the executable bit, i.e.,


chmod a+x bitrot


Now put it in your $PATH


cd to a directory that contains your ALAC files you want to protect.


Run the shell script like this to create the checksums:


bitrot -w


It will write a checksum for the audio part of the file (which should never change) to a new metadata attribute in the resource fork of each audio file (assuming you are on an Apple HFS+ filesystem). The advantage of doing this is the shell script doesn't touch your actual audio file (and it makes the shell script easier to write for me at least).


To check the files at a later time, simply run the same command, but with -c instead of -w.


bitrot -c


Here is some sample output, after I deliberately damaged one of the files (using vim):



Link to comment

Just to be sure I took the NAS aproach - freenas.

I'm using six hdds configured as zfs raid-Z and scrub my data periodically (30 days).

and smartctl weekly checks for every hdd in order to predict hdds failures. It is not bullet proof but add another layer of checks for reliability of the hardware.

and most important I use off site back-up as well.


google search "bit roting zfs"

ZFS - Wikipedia, the free encyclopedia - Data integrity

http://www.freenas.org/ pretty easy to install and configure and the documentation/community support is very good. You can even create one click virtual machines for upnp server or various services.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Create New...