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
ordecode
. - 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 yourdecode
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.