Embedding of Ogg Files in Images Blocked

Yet, concatenating any other kind of data to the end of an image (such as a repeated string like "NYO~NYO~NYO~NYO~") is allowed.

I'm guessing it will take about 15 seconds until someone slightly modifies the script and sound image creation process to XOR the oggs with a simple bit pattern.

>>19

Write a small encoder/decoder to encode your file using all but the MSB of each pixel, and use the high bit to display a 1bpp picture of an animé face or instructions to decode it or whatever.

Of course moot could then decode the image and check whether specific pixels match an MP3 header, but he can't block the general method -- you can just change the details of it every couple of days with no problems.

This is basically a more complex version of ``save this file; convert to BMP; rename it to shit.exe'' but yeah.

>>19
In the bathroom, I realized I am an idiot, along with a few naysayers on /a/.

The imageboard script already has to decode JPGs and other images to generate thumbnails, so that pretty much rules out the question of whether it's practical to decode all images to detect embedded sounds. If it were possible to stall the servers with a "million lels" attack in an image, someone would already be doing it.

Now I just need to know if JPGs don't finish decoding until EOF.

>>20
Don't get me wrong, I'm well aware that it will always be possible to encode arbitrary data in images.
The novelty of soundimages depends on there being both a valid, user-selectable image (ie not "noise") and a valid audio file, however, so for the purposes of this discussion, I'm only considering methods of tacking data onto the end of a valid image.