Musical Tweet Challenge This is the audio version of the Twitter image encoding challenge.

Design an audio compression format that can represent at least one minute of music in 140 bytes or less of printable UTF-8-encoded text.

Implement it by writing a command-line program that takes the following 3 arguments (after the name of the program itself):


The string encode or decode.
The input filename.
The output filename.


(If your preferred programming language lacks the ability to use command-line arguments, you may use an alternative approach, but must explain it in your answer.)

The encode operation will convert from your chosen audio format to your compressed “tweet” format, and the decode operation will convert from your “tweet” format to the original audio format.  (Of course, you're expected to implement lossy compression, so the output file need not be identical to the input, just in the same format.)

Include in your answer:


The source code of your program, in full.  (If it's too long for this page, you may host it elsewhere and post a link to it.)
An explanation of how it works.
At least one example, with a link to the original audio file(s), the “tweet” text it compresses down to, and the audio file obtained by decoding the tweet.  (Answerer is responsible for copyright “fair use” assertions.)


Rules


I reserve the right to close any loopholes in the contest rules at any time.
[Edited April 24] For the input of your encode function (and output of your decode function), you may use any reasonable, common audio format, whether it be:


Uncompressed waveform, like WAV.
Compressed waveform, like MP3.
“Sheet music” style, like MIDI.

Your compressed “tweet” format must actually encode the sounds in the input file.  So, the following types of output do not count:


A URI or file path giving the location where the actual output is stored.
A key to a database table where the actual output is stored as a blob.
Anything similar.

Your program must be designed to compress generic music files, so don't do stuff that's too obviously tied to your specific example song.  For example, if you're demonstrating “Twinkle, Twinkle, Little Star", your compression routine shouldn't hard-code a specific symbol for the sequence do-do-so-so-la-la-so.
Your program's output should actually be able to go through Twitter and come out unscathed.  I don't have a list of the exact characters that are supported, but try to stick to letters, digits, symbols, and punctuation; and avoid control characters, combining characters, BIDI markers, or other weird stuff like that.
You may submit more than one entry.


Judging criteria

This is a popularity contest (i.e., most net upvotes wins), but voters are urged to consider the following:

Accuracy


Can you still recognize the song after it's been compressed?
Does it sound good?
Can you still recognize which instruments are being played?
Can you still recognize the lyrics?  (This is probably impossible, but it would be impressive if anyone accomplished it.)


Complexity

The choice of the example song matters here.


[Added April 24] This challenge will be easiest with MIDI or similar formats.  However, if you take the extra effort to make it work with waveform-type formats, that deserves extra credit.
What's the structure?  Sure, you can meet the one-minute requirement by simply repeating the same 4 measures an arbitrary number of times.  But more complex song structures deserve more points.
Can the format handle a lot of notes being played at one time?


The code


Keep it as short and simple as possible.  However, this is not a code golf, so readability matters more than character count.
Clever, complicated algorithms are OK too, as long as they're justified by improved quality of results.
Scala
Sure, it'd be easier to encode MIDI files, but who's got a bunch of MIDI files lying around? It's not 1997!
First things first: I've decided to interpret a &quot;Unicode byte&quot; as a &quot;Unicode char&quot; and use CJK characters, because:

It matches the image challenge
Twitter is cool with it
I really need those bits

There are a few tricks I use to squeeze every last drop of entropy from the sources:
Firstly, music is made with notes. Moreover, we generally regard the same note in a different octave as the same note (which is why a 12-string guitar sounds right), so we only have 12 possibilities to encode. (when I output B, for example, I actually output a chord, consisting solely of B in all the octaves, a bit like a 12-string guitar).
Next, I remember from high-school music class that most note transitions are small (up or down one note). Jumps are less common. This tells us that there's probably less entropy in the jump sizes than in the notes themselves.
So, our approach is to break our source into a number of blocks - I found 14 blocks per second worked well (side note, I'd always wondered why audio was encoded at 44100 Hz. It turns out that 44100 has lots of factors, so I could have chosen 1, 2, 3, 4, 5, 6, 7, 9, 10, 12, 14, 15, 18, 20, 21, 25, 28 or 30 blocks per second, and it would have divided cleanly). We then FFT these blocks (well, technically not fast, as the library I used isn't fast for non-power-of-2 blocks. And technically I used a Hartley transform, not Fourier).
We then find the note that sounds loudest (I used A-weighting, with high and low cut-offs, mostly because it's easiest to implement), and either encode this note, or encode silence (silence detection is based on SNR - low SNR is silence).
We then translate our encoded notes into jumps, and feed them to an adaptive arithmetic coder. The process for translation to text is similar to the image compression question (but involves some abusive use of BigInteger).
So far, so good, but what if the sample has too much entropy? We use a crude psychoacoustic model to remove some. The lowest entropy jump is &quot;no change&quot;, so we look at our FFT data to try to find blocks where the listener probably won't notice if we keep playing the previous note, by looking for blocks where the note from the previous block is almost as loud as the loudest note (where &quot;almost&quot; is controlled by the quality parameter).
So, we've got a target of 140 characters. We start by encoding at quality 1.0 (max quality), and see how many characters that is. If it's too many, we drop to 0.95 and repeat, until we get to 140 characters (or we give up after quality 0.05). This makes the encoder an n-pass encoder, for n &lt;= 20 (although it's massively inefficient in other areas too, so m'eh).
The encoder/decoder expects audio in s16be mono format. This can be achieved using avconv as:
#decoding ogg to s16be, and keeping only the first 60s
avconv -i input.ogg -ac 1 -ar 44100 -f s16be -t 60s input.raw
#encoding s16be to mp3
avconv -f s16be -ac 1 -ar 44100 -i output.raw output.mp3

To run the encoder:
sbt &quot;run-main com.stackexchange.codegolf.twelvestring.TwelveString encode input.raw encoded.txt&quot;
sbt &quot;run-main com.stackexchange.codegolf.twelvestring.TwelveString decode encoded.txt output.raw&quot;

Full code at https://github.com/jamespic/twelvestring.
Pitfall to note: You'll need nayuki's Arithmetic Coding library, which doesn't currently have Maven artifacts available. Instead, you'll need to locally build and install developster's fork of it.
And here are some samples. They sound awful, but just about recognisable:

Beethoven's 5th: original, encoded - 刲檁囉罓佖镱賑皌蝩蔲恁峕逊躹呯兲搆摼蝺筶槛庬一掛獴趤笲銗娵纜喫覤粠僭嫭裵獄鱨蠰儏咍箪浝姑椻趕挍呪白鸞盙宠埘謭擆闯脲誜忘椐笸囃庣稨俖咛脔湙弻籚砌鍖裏橈镙訁鹻塿骱踠筟七趇杅峇敖窈裞瘫峦咰呹櫬茏蛏姆臸胝婁遼憀麁黦掏毈喙眝綄鴀耢椚筤菮蟞斗俼湛营筬禴籙嬧窻丄
Fur Elise: original, encoded - 訖忢擫鏝拪纒铇鯪薯鉰孝暱埛痏絘僌莻暆鴈屖鳮絒婘譮蠣託騶腀饚緂柤碠瞢碩脅歙棆敗辦冏鄔酾萖苯劺誺軩忇穤锳婁伉巠桭晘酉筟緵俅怚尵鎽蜓崁飿嘔但鈐謽酝屮呤誥俊覊鶮龔癸埙煂臙牎繬肜摲炚雗頨款驦燈菩凧咁楾媡夥俰欓焵韀冊嗥燠鱧駟髉
Twinkle Twinkle Little Star: original, encoded - 欠悺矜莳錥鷗谴裴皽鳺憝漿箔皇殤鸧蜻猻丱
A fun chiptune: original, encoded - 简詐諥尘牿扫鲑龮箫颫齰蠏騁煟靸阒萎囦鮇雝愯訖芉馄鈿鬦嶏觲沠丆贀蛑蛀漥荤侲咔麑桬鲠僵擕灼攲陇亄鹘琾業纟鵼牤棌匩碆踬葫鶙懲欃铳樯柇鋡疡衻澯伅墇搢囻荸香貱夹咽蟽籐屈锂蛉袒貊屨鈦夜镤沄鍡唦魮骬乔蚖醶矕咻喸碋利褼裊匎嶮窢幘六沧鼝瞮坡葍帷锆邵旻符琨鱴郤栱烇仾椃騋荄嘵統篏珆罽

Update
I tweaked the silence threshold in the code, and re-encoded. The encodings have been updated accordingly. Also, I added another song (technically not open source, but I doubt the original copyright holder will feel their IP is under threat), just for fun:

Imperial March: original, encoded - 岼讶湠衢嫵焅喋藭霔憣嗗颟橳蕖匵腾嗅鈪芔区顕樭眀冂常僠寝萉乹俚戂闤灈蟑拷邢音褈霈媬盒萳璥唂焰銯艉鶱縩巻痭虊窻熲紆耺哅淙苉嘏庸锺禒旇蘄籷遪刨繱蕖嬯摺祑仰軈牰杊瘷棏郖弘卄浕眮騜阖鏴鶺艂税寛柭菸採偋隆兎豅蚦紛襈洋折踜跅軩树爺奘庄玫亳攩獼匑仡葾昐炡瞱咏斎煟价藭恐鷖璌榍脅樐嬨勀茌愋

More Updates
I've tweaked the encoder a little, and it's had a surprising impact on quality (I'd forgotten that in DHT, out-of-phase signals are effectively negative, so I was ignoring out-of-phase signals).
An earlier version of the code just took the larger of these out-of-phase signals, but we now take the RMS. Also, I added a fairly conservative window function to the encoder (Tukey, alpha 0.3), to try to combat artifacting.
Everything's updated accordingly.