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!