.werkkzeug 3 released
category: offtopic [glöplog]
You know we tried that one time but we had trouble sending it over the intertubes!
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!
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.
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.)
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?
"The way MP3 works is that it doesn't store lyrics where there's no singing in the tune." /rept^ai/
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...
I hereby submit my first serious entry to a democompo, length: 0 bytes.
I guess I won that compo then...
dotwaffle, please come to the compo area, your entry does not work. i repeat, dotwaffle, to the compo area, your entry doesn't work.
Quote:
OMG :D:D:D"The way MP3 works is that it doesn't store lyrics where there's no singing in the tune." /rept^ai/
dotwaffle: 0/0 crashes on my universe :( fix plz?
Preacher: Come on, I'm going to vote for my own entry ;)
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.
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!
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!
ryg: Arse! I've deleted it! Any chance you made a backup of the not-working one and I'll fix that one?
http://en.wikipedia.org/wiki/Jan_Sloot
infinite compression. sounds interesting. I wanna see that working.
Also, rept^ai is technically correct
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.
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 :)