first off, can someone explain what's so offensive about the national anthem being translated into spanish? don't we want more people singing the anthem, rather than fewer? doesn't translating american documents like the anthem—or the constitution, or the bill of rights—actually help to "spread democracy" as they say? isn't it a good thing?
some republicans, including the president, have been frothing over a new recording of the anthem in spanish. never mind that the anthem had already been translated into spanish as early as 1919, or that the US state dept actually has four translations posted on its website.
the whole thing is silly, and in protest bloggers have been doing things like posting the pledge of allegiance in spanish. but i want to talk about this boingboing post by xeni jardin titled American national anthem "sung" in more code-forms . here's how it starts:
In response to panicked partisan panty-bunching caused by Spanish remakes of The Star Spangled Banner, we pointed this week to a Morse Code MP3 and a binary expression of the American national anthem.
BoingBoing reader Remy Porter kindly translated that binary code into this sound file (157K MP3 Link). It's an unsigned 8-bit PCM rendition at a 2400Hz sample rate. If it sounds like monotone noise, well, that's 'cause it is. Remy explains:Generally binary data ends up coming out like that. For a fun experiment, grab a JPG and a linux box and type:
cat /path/to/jpg > /dev/sound
- being far more random, those have much more noise; bleeps and bloops across a wide range. ASCII text- which I assume this was encoded from- has a much smaller randomness- a VERY small randomness, and it ends up sounding about the same.
now, i love this idea. converting the national anthem to an mp3 by interpreting the ascii data as sound... why, that's databending! however, the actual mp3 is a bit boring. it's just a few seconds of tone. i'm not sure how he created it; i'm guessing he created an ascii text file of the lyrics in binary and ran it through a cat command like the one he describes.
unfortunately, remy's comments about "randomness" are a bit imprecise. maybe he just didn't have time to fully explain. but randomness is about the last thing you want, because when you're talking about an audio signal, randomness translates into noise. and by noise, i don't mean "bleeps and bloops" but white noise or pink noise. i love noise (some would call me a noise artist), but in this circumstance, it's probably not what you're looking for.
if you sonify and listen to a lot of jpegs, a few blips and bleeps aside, you'll start to notice that most of them sound pretty much the same, and what they sound like is static. this is because of the file compression inherent in the jpeg format. compressed or encrypted data "looks" almost completely random, and when it is sonified you typically end up with pure noise, the aural equivalent of snow on your tv screen. occasionally you'll get a good one, but most jpegs are pretty dull-sounding.
if you're sonifying data in this fashion (i like to use the term databending), and you're looking for interesting sounds, what you really want is patterns, not randomness. data that's full of patterns will give you all kinds of bleeps, swooshes, and tones you're never heard before. data that's truly random will result in static. (in files like jpegs, the most sonically interesting part of the file is often the header and/or footer, the part that is not compressed.)
in fairness to remy, he is on the right track about why the sonified ascii file isn't all that interesting. the limitations of the ascii set mean that ascii data has a limited range of values, so the range of possible sounds is much smaller than with binary data. (this is particularly true if your text is simply a string of 0s and 1s, as remy's aparently was.) this is a big part of why binary data tends to sound more interesting than ascii data: you do want a wide variety of values in your data; you just don't want it to be truly random. the other reason is that text documents tend to be so damn short! sometimes you just need more data.
if you're sonifying data in this way—using the method remy describes in unix/linux or by opening files in a wav editor in windows (tip: set your "file type" to either "all files" or "raw")—the files that will sound the most interesting will generally be unencrypted, uncompressed binary formats. i've had lots of success with uncompressed image formats (BMP, TIF, and PSD) and executable binaries. just make sure you don't accidentally make a change to an executable and then save over it... the program will be ruined.
in keeping up with the theme, and hopefully to demonstrate what i'm talking about, i found a colorful website and took a screenshot of it. (i like this page in part because it mentions that the anthem is sung to the tune of to anacreon in heaven.) i saved this screenshot in three different formats—JPG, BMP, and PSD—then i opened up all three in sound forge (mono, 8-bit, 22,050Hz) and converted the waveforms to mp3s.
mp3s begin here
anthem-jpg.mp3: the screenshot as a JPG converted to MP3. the first two seconds or so are interesting; that's the header and the start of the image data. the remaining 13-14 seconds are little more than white noise. this is pretty typical-sounding for a JPG.
anthem-psd.mp3: the screenshot as a photoshop file converted to MP3. uncompressed, so this is much longer, about 1:34. low grumbling sounds, static washes, and occasional onslaughts of clicking. i've heard much cooler-sounding PSDs, but this one's not too boring.
anthem-bmp.mp3: the screenshot as a BMP converted to MP3. at almost 3 minutes long, this one could almost fit on an industrial record. highly rhythmic and relatively listenable.
anthem-bmp-44100.mp3: the BMP again, this time converted at 44,100Hz. it sounded interesting at 22,050, but the tempo seemed off so i tried listening to it again at 44,100, 11,025, and 8,000. i thought 44,100Hz was possiblythe most interesting of the three.
anthem-bmp-8000.mp3: again, this time at 8,000Hz. what the hell, i'll put this one up, too. converting at the low rate of 8,000Hz stretches the BMP out to more than 8 mins long, so this file is bigger (7.5MB). it still sounds very crunchy, but at this tempo is pretty danceable.¶