pouët.net

.werkkzeug 3 released

category: offtopic [glöplog]
You know we tried that one time but we had trouble sending it over the intertubes!
added on the 2011-09-11 07:52:32 by ryg ryg
http://www.pouet.net/prod.php?which=57725 now farbrausch has done mp3 in 4K? are they mad?
No, in fact that is a chiptune (probably sid) so I guess Farbrausch is faking here!
added on the 2011-09-11 11:58:37 by chromag chromag
they probably stored the music as a jpg (you can do it if you put two 8 bit sound samples per pixel). probably as a jpeg2000, that probably explains the high compression ration. nothing beats jpg, cause lots of clever people worked on the stardard for many years.
added on the 2011-09-11 18:10:36 by iq iq
i agree with iq. i rather store the data of my 64k in jpg that is designed by years and years of state of the art research by real scientists, rather than this weird .ktx datatype made by a few weird german computer hobbists on a sunny afternoon!!
Actually, the Farbrausch 4K is really quite clever - it's using fractal compression. The object has lots of holes in it, which means it takes up almost no space in the executable, leaving more room for the music. (In theory, it should have an infinite number of holes because it's a fractal, but kb ran out of time.)
added on the 2011-09-11 19:57:46 by gasman gasman
so an infinite number of holes means an infinite amount of nothingness, so he could effectively get the damn thing down to 0 bytes?
It makes sense - after all, why waste space on storing zeroes?
added on the 2011-09-11 21:05:37 by gloom gloom
"The way MP3 works is that it doesn't store lyrics where there's no singing in the tune." /rept^ai/
added on the 2011-09-11 21:18:57 by Gargaj Gargaj
I still think there should be a democompo where your number of votes is divided by the number of bytes in your entry to give you your score.

I hereby submit my first serious entry to a democompo, length: 0 bytes.

I guess I won that compo then...
added on the 2011-09-12 02:19:59 by dotwaffle dotwaffle
dotwaffle, please come to the compo area, your entry does not work. i repeat, dotwaffle, to the compo area, your entry doesn't work.
added on the 2011-09-12 05:49:28 by ryg ryg
Quote:
"The way MP3 works is that it doesn't store lyrics where there's no singing in the tune." /rept^ai/
OMG :D:D:D
added on the 2011-09-12 05:51:44 by ferris ferris
dotwaffle: 0/0 crashes on my universe :( fix plz?
added on the 2011-09-12 19:44:19 by Preacher Preacher
Preacher: Come on, I'm going to vote for my own entry ;)
added on the 2011-09-12 20:01:45 by dotwaffle dotwaffle
dotwaffle, we still don't have a working version of your entry. this is the last call. if you don't run to the compo area with your entry on an USB stick RIGHT THIS SECOND, you'll be disqualified.
added on the 2011-09-12 20:30:13 by ryg ryg
Who cares about Procedural, JPEG or MP3?
They only offer finite compression, whereas my new technique offers INFINITE compression!
Why go for finite, when you can have INFINITE?!?

It is based on the well known fact that zeroes compress MUCH better than ones as gloom correctly pointed out.
Instead of storing expensive ones, we can simply flip them to zeroes with cool bit tricks like XOR.
All we need is a small amount of side information with the offsets of the ones.
Considering how much better zeroes compress, I cannot really
see this becoming an issue. You can even do clever stuff like DELTA coding
the offsets to make them extra small! They can be made even smaller by
storing their prime factors instead of the actual numbers!! Or just use logarithms!
Too many ideas to type!!!

As i didn't make any, sensible, assumptions about the input data, we can simply
run the algorithm again and again until INFINITE compression has been obtained!

This unfortunately doesn't work if the new compressed file is mostly or all ones...
But if it's mostly ones, then it will be mostly zeroes if we flip it !!! So the
bad case turns into a very good one with more than half zeroes! All that is needed is just
one more bit of meta-data. But as at least half of the bits will now be zero that is not
a problem!
added on the 2011-09-12 21:05:43 by mentor mentor
ryg: Arse! I've deleted it! Any chance you made a backup of the not-working one and I'll fix that one?
added on the 2011-09-12 21:11:27 by dotwaffle dotwaffle
http://en.wikipedia.org/wiki/Jan_Sloot
added on the 2011-09-12 21:12:15 by superplek superplek
infinite compression. sounds interesting. I wanna see that working.
added on the 2011-09-12 21:14:17 by yumeji yumeji
Also, rept^ai is technically correct
added on the 2011-09-12 21:16:04 by mentor mentor
it will be necessary anyway - how else would you store unlimited detail?
niels: "Tilburg".... hmmm
Infinite compression is easy to implement. The tricky bit is correctly decompressing the 0 byte archive.
Quote:
this thread is so dumb. why reverse engineer a demotool? the authors are available and (as far as i know) they are more than willing to share their knowledge.


word.
added on the 2011-09-12 22:43:07 by Defiance Defiance
Quote:
storing their prime factors instead of the actual numbers


actually, i love the idea. in fact, you could force your signals (splines, mesh vertices) to be allowed to take only values which have less than a given amount of different factors in their decomposition, to ensure your sequences never get too long, and that you index into a small table of primer numbers. mentor, you made my day :)
added on the 2011-09-13 06:33:56 by iq iq

login