Yesterday morning, I had been half asleep on the train on the way to work and i don’t exactly know how i got to the point of thinking about this. it was related to the generation of music with some of the libraries I’ve toyed with in processing, but it went way crazy. First I was picturing the contrary to common notion that sound is created from silence: sound being added or multiplied to what’s already there. So, the idea started to evolve a little and I thought how cool it would be to create a piece of music or even an instrument of sorts that is initially based on a very clearly recognized constant. Not like a rhythm or even a synth chord. A more raw sound that would be intentionally manipulated by creating interference patterns. Maybe this is another way to think about the same thing, but I guess I enjoy doing shit backwards before settling on what I’m told to do.

This got me thinking about other physical aspects of sound. To my limited knowledge, there isn’t nearly as much consideration dedicated to sound physics simulation in game development compared to visual. But they surely have a lot in common, right? Consider this: any object that has been registered to some physics simulator might have properties that express its simulated mass, friction, resistance, dampening factors, shape, etc. Forces can be applied to them. There are also properties that act like constants for the environment like gravity and maybe even some friction or resistance that is applied to anything that has a non-zero velocity. But these are constants that never change to account for turbulence created by an object displacing the air. This is one limitation but maybe we aren’t too far off this kind of computing. Or maybe we’re there already. Anyway, this all might seem complicated, but the idea is really simple: an object traveling through space collides with and displaces a number of other objects which produces a unique sound per incident. all of this is multiplied together to create the cognition of one sound in one moment of time. We might have a long way to go before this kind of computing can be done at 60 fps, but it might be a fun thing to experiment with in processing on a smaller scale.

what we were noticing was the playback of mp3s (or more specifically in our case, flvs with mp3 data embedded) had a some odd millisecond delay at the beginning and/or end of the duration no matter what we tried to do.

this was the breakthrough in our research: http://www.8bitrocket.com/newsdisplay.aspx?newspage=315

the key point to take note in this guy’s post is the id3 tag stuff. to confirm his findings, this is a display of the spectral frequency of the original uncompressed wav:

a wav file's spectral frequency

and here is an mp3 compressed directly from the wav (made in soundbooth, also tried soundtrack and itunes/qt):

an mp3's spectral frequency display

i’m pretty sure the black margin at the beginning and end of this file is where the id3 information resides, which is what was giving us the resulting momentary blips of sound, killing our loop.

now, in our case, it made less sense to use the mp3 file format without wrapping it in a flv due to some architectural needs for certain events that flvs can deliver that mp3s cannot.  so rather than experimenting with the flv and seeking to a given frame since this solution would never provide for the level of precision we would need, we opt’d to utilize our asset swf and embed the the wav and convert it to mp3 within flash.  the conversion to mp3 within flash did not cause us the same problems as the directly loaded mp3 did.  this logically assumes that the flash-native mp3 compression tool does not include id3 tagging in the final output.  regardless, this resolved our looping problem.  yay!