I can't remember the last time I ran a good fever, so I couldn't tell ya. I could mention that my seven-year-old turns into a damn brat when he gets one, but...
Updated the scoreboard, uploaded a project with all of the submissions included, and gave some of the "cheaty" wolves honorable mention. I'm sooooo tired.
I'm working at gaint project which is share between developers the project is place at one computer and we are accessing it through the network localy we're using wamp server now in wamp display error is off what I want is to open(on) display error for specific ip address (for me) except other tw...
Ahem, I believe I licensed that under MIT, meaning you have to give attribution to me. ;) I'd prefer "The Supreme Overlordly Knob of the Door, Superior to Mankind in All Ways," but anything goes — Doorknob5 secs ago
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 ...
Hmm, I did a project similar to what echonest.com does a while back that might help. It basically used FFT, beat and pitch detection to give a sample that was usually around 40kB for a 180 second song.
That's somewhere around 1800 bits/sec, which might compress well. The downside is that I'm not sure how well it would decode back to PCM. It was for a rhythm game, so it would be a MIDI-like representation, but it might still be recognizable.
@mniip You've either got an error in your calculation or you've misread the question. Unlike the image-in-a-tweet challenge, which imposed a 140 character limit, it's asking for "140 bytes or less of printable UTF-8-encoded text". That imposes a loose upper bound of 18.667 bits per second.
And since it's printable chars that rules out 33 values per byte, imposing an upper bound of 7.8 bits per byte; and since it has to be UTF-8 that places additional constraints; I suspect that the achievable encoding limit is about 140 * 7 bits of information, for 16.333 bits per second.
It's certainly written that way, but I wonder if that is truly the intent. If the intent was simply to make it tweetable (140 characters), that makes a big difference. It may have been a mistake, but unless corrected/clarified, I may have to rethink my approach.
None of this matters if I don't get some food before my head explodes. The only real delivery place we had says "Closed for the holidays." and everything else is pizza...
There's a Sonic like a block away... I think I can make it...
Corn Dogs and more soda than I could possibly want
@PeterTaylor Regarding codegolf.stackexchange.com/a/26219 : can you please stop shortening your code even further and instead help me improving the much more performant version ;-)
Can anyone help with codegolf.stackexchange.com/a/26173 ? I don't speak TI-BASIC. Maybe I miss the built-in icosahedric calculation engine or anything alike?
My idea was to convert to a simple notation/midi type of format and compress that. Then on decode generate PCM from that. It would be incredibly lossy and would only capture the main melody, but it might work out all right. Music with a lot of "noise" probably wouldn't work so well, but simple instrumentals might.
I'm definitely not going to try a straight-up compression of PCM data, no matter how lossy.
I am considering a similar approach. But 60 seconds is quite long and if the music is not completely boring we have something like 200 distinct notes (for a single voice!) and thus we have <10 bits for encoding a single note.
My thought on highly compressed music was to take a MIDI-esque approach but encoding chords rather than notes. For slow waltzes at 120bpm that means 1 byte per chord and a bit of overhead for bpm, voice, etc.
