View RSS Feed

The Ill-Tempered Audiophool

bitrot: A shell script to detect changes in the audio component of ALAC files

Rate this Entry
One of the best things about FLAC is that it contains an internal checksum, so you can see if the audio portion of the file has been changed (i.e., corrupted in some way, or has suffered "bit rot"). You can change the tags embedded in the file all you want, and it won't alter this checksum. The only thing that will cause it to change is damage to the audio content of the file.

Wouldn't it be nice if ALAC had the same feature? It turns out the Apple OS X command-line utility can do this for lossless ALAC, aiff, and a few otehr types of files. In the case of AIFF, it can actually embed the checksum in the file itself, but it can't do that for ALAC files. However, using another OS X command-line utility, xattr, you can add this (or anything you please) to the resource fork associated with the ALAC file.

The following is a shell script that will do exactly this for you, for ALAC files. In the future, I might expand this to do it for aiff as well, or you could modify it easily enough. Anyway, here is the shell script on google code:

https://zsh-templates-osx.googlecode.../darwin/bitrot

Download it, make it executable ( chmod a+x bitrot ) and stick it in your $PATH, and Bob's your uncle. (For compatibility with the example launchd plist file below, I suggest putting it into /usr/local/bin ). Read the shell script for more details. [I wrote it in zsh because it is better than bash. Try doing recursive globbing ( **/*.m4a ) in bash.]

I recommend running it as a background process manually when you want to create the checksums. Then you can run the actual checking process from a lauchd script or /etc/periodic however often suits you. It is set to log only changes it detects in ~/Library/Logs/bitrot No news (or log file) is good news. If you want a reality check, run bitrot -l . It goes fairly quickly. I haven't tested this on a system in which Spotlight has been deactivated, but it might not work properly on those. Let me know.


Example launchd plist file. You can name this local.bitrot.checker.plist and put it into your user's Library/LaunchAgents folder. Make sure you edit the WorkingDirectory string entry first, providing your own username, and the actual path to where your music files reside. This will check your files every sunday at 1 am. You may wish to adjust this according to your listening habits and degree of paranoia.

Code:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Label</key>
	<string>local.bitrot.checker</string>
	<key>WorkingDirectory</key>
	    <string>/Users/yourusername/Music/iTunes/iTunes Media/Music</string>
	<key>ProgramArguments</key>
	<array>
		<string>/usr/local/bin/bitrot</string>
		<string>-c</string>
	</array>
	<key>StartCalendarInterval</key>
	<dict>
		<key>Hour</key>
		<integer>1</integer>
		<key>Minute</key>
		<integer>3</integer>
		<key>Weekday</key>
		<integer>0</integer>
	</dict>
</dict>
</plist>

Updated 01-27-2014 at 12:20 PM by wgscott

Categories
Personal Blogs , computer

Comments

  1. wgscott's Avatar
    After running bitrot to get the checksums, you might want to write-protect the audio files. Here is how:

    From another thread I started ...

    Quote Originally Posted by wgscott View Post
    After making the bitrot shell script, I realized it really only warns you of accidental file corruption, but not accidental deletion, which appears to be a more common problem.

    The simple unix way to prevent this is to modify the write-permission bit for the files and the directories that contain them. This is fairly simple and almost instantaneous, e.g.:

    Code:
    cd ~/Music/iTunes/iTunes\ Media/Music
    chmod -Rv u-w *
    chmod changes the permission setting. (There is a Finder way to do this as well, in the Get Info pane for the top directory).

    -Rv makes it recursive, and the (optional) v gives some verbose output. u-w sets the user's write (and delete) permission bit off, and the * is the unix wildcard.

    You would have to undo this to edit the file-embedded (vs the iTunes db) metadata, but that seems a small price to pay. Notice that I only do this to the music files and their enclosing directories, not the actual iTunes "library" database.

    Here is how to globally undo it:

    Code:
    cd ~/Music/iTunes/iTunes\ Media/Music
    chmod -Rv u+w *
    The enclosing directory is assumed to be ~/Music/iTunes/iTunes\ Media/Music, which is the iTunes default. You need to change it if you have a non-default location (as I do, but I use a symbolic link).