We've sent a verification link by email
Didn't receive the email? Check your Spam folder, it may have been caught by a filter. If you still don't see it, you can resend the verification email.
Started March 8th, 2014 · 135 replies · Latest reply by minagarmehei 7 years, 11 months ago
http://freesound.org/people/Trebblofang/sounds/234163/
http://freesound.org/people/Trebblofang/sounds/234164/
http://freesound.org/people/Trebblofang/sounds/234165/
Single Windows DLL files or sets of DLL files glued together interpreted as RAW PCM sound files
of various sample rate/bit depth parameters.
Trebblofang wrote:http://freesound.org/people/Trebblofang/sounds/234163/
http://freesound.org/people/Trebblofang/sounds/234164/
http://freesound.org/people/Trebblofang/sounds/234165/Single Windows DLL files or sets of DLL files glued together interpreted as RAW PCM sound files
of various sample rate/bit depth parameters.
This is nothing short of awesome!
As I was listening it reminded me of something. It threw me back to my teens: actually, I done this before. - I loading game files into audio editors on my Amiga computer! I used to go looking for and rip the game and music sounds (ooops!, Yes, I know, copyright infringement!). - My music was not being published anywhere, so I can say those sounds remained for my own private use. Plus, there was no internet back then and I certainly did not know anything about copyright in those days.
Anyway... I digress...
The point being that I collected many sounds of the data itself. Some of which I eventually used in little music tunes. - This was back in the early 90s! Who would have thought I would not only be doing this again, but actually doing it together with a group of people over the internet!
So, thanks Trebblofang for taking me back to my younger days
And these files are certainly amongst the best I ever heard.
A few seconds in one of those cool sounds remind me of the data tapes of our dear old home computers like the ZX Spectrum or Commodore 64
AlienXXX wrote:
@toiletrolltube
Trebblofang's files are begging to be cut to bits (literally! pun intended), stretched and processed!
Another portion of experimental sounds.
Over 4000 of text files copied to one folder and glued together using command "copy /b *.txt output.raw". Result file opened as 44kHz/16bit/Stereo RAW PCM (Intel PCM) audio in Audition.
Strongly dehissed, normalized.
freesound.org/people/Trebblofang/sounds/234279/
Large set of PSD files copied to one folder and glued together using command "copy /b *.psd output.raw". Result file opened as 44kHz/16bit/Stereo RAW PCM (Intel PCM) audio in Audition.
Strongly dehissed, normalized.
freesound.org/people/Trebblofang/sounds/234312/
I was thinking that I don't particularly care for treating images as sonograms and doing inverse FFT to create sound from them. Oh sure, it's fun for a few times, but the sounds have no integrity and seem totally unnatural because, well, they are. Surely I could think of a better way to map image data to sound that uses more familiar constructs as an intermediate mapping. Perhaps we could first convert a bitmap to an SVG composition, as there are already some automated tools that do that, and even try "simplifying" that composition repeatedly -- ideally the sound it gets mapped to could sound reasonably similar from one iteration to the next. The idea is that the various SVG structures could be individually mapped to sound constructs, either in parallel or in series, with graphical properties of the various objects becoming descriptors for the waveforms or harmonic spectra, FM and AM intervals and amounts, durations and envelopes, etc. But I didn't know enough about the SVG structure and language (yes, it's XML, but that's the format, not the semantics). I started to go down this road and begin inventing mappings for various SVG concepts to either sound structures or sound-generating sub-circuitry (DSP blocks, if you prefer, perhaps like an analog-box circuit), but the truth is that I really can't afford to engage in such a heavy investment of time to such a thing. I'll just mention the idea here in case someone else is inspired to do it, and then you can share the result with me. It could even make a patentable and sellable product!
But let me also point you to a recent article in the proceedings of the first international workshop on artificial intelligence and cognition (AIC 2013), which you can copy for private and academic purposes only. The contents are here and the article of potential interest is Towards a Cognitive Architecture for Music Perception by Antonio Chella. What this has to do with experimental sound creations techniques, I'm not sure, but somehow it seemed to fit. So there.
Friendly warning: Take cover, the hailstorm of belated Easter eggs is coming!
Fresh of upload and still unmoderated is the TrebbloSynths pack with 30 relatively melodic-friendly sounds:
http://www.freesound.org/people/copyc4t/packs/14435/
Next comes the TrebbloDrums pack (15 sounds):
http://www.freesound.org/people/copyc4t/packs/14436/
As if this weren't alarming enough, here's a pack of 8 alarms and other loopable sounds, the TrebbloLoops pack:
http://www.freesound.org/people/copyc4t/packs/14437/
Enter the TrebbloGUI pack, 15 short sounds that can be used for button presses in interfaces:
http://www.freesound.org/people/copyc4t/packs/14438/
Too short? Here are 2 background ambience sounds, over 1 minute long, in the TrebbloScapes pack:
http://www.freesound.org/people/copyc4t/packs/14439/
These and the next sounds, for a total around 110, come from this one:
http://www.freesound.org/people/Trebblofang/sounds/234163/
Most of the processing is quite basic; although we have means to obtain anything from anything else, I think going that far would miss the point of the dare.
The most exotic effect used, and just a few times most of which not in these packs, is a comb filter; the rest is basically EQ/filtering, stretching, pitch changing.
copyc4t, today's upload moderators' nightmare
Trebblofang wrote:Thank you very much! And deeply sorry for the spam you'll get with the remix notifications
Wow! Incredible work, copyc4t!
By the way, only the synth pack is still pending, all the other uploaded packs are available.
The final pack still to upload is the TrebbloNoises, with around 30 sounds.
Another way to take image data and treat it as spectral data to be converted back to sound would be to take advantage of the fact that lower frequencies need to change more slowly and upper frequencies more quickly, by using a radial sweep (think radar screen). The pixels near the center are for the low frequencies, the very lowest being from the center pixel and having the same amplitude across the entire output. The pixels at the edges are for the uppermost frequencies and change the most rapidly. By smoothly interpolating between the pixels, you can easily calculate the values for each frequency in the spectrum at a given output sample by mapping the line from the center to the edge (for the angle of that sample) to the frequency. I think this could yield interesting results. Anybody want to code it? I've thrown together a first pass at the pseudo-code, probably with bugs, but that's as far as I can take it right now:
imageToSound( im, dur, rate, angle, minf, maxf )
# determine common values used repeatedly
# center point
im.cx=im.width/2
im.cy=im.height/2
# spectral resolution (number of oscillators)
res=int(sqrt((im.width*im.width+im.height*im.height)/4))
# handle bounding of frequency range of those oscillators
if(maxf<=minf||maxf<=0||maxf>rate/2) maxf=rate/2
if(minf$gt;=maxf||minf<0) minf=0
# main stuff
samples=dur*rate;
initializeSoundOutput(rate,samples) # however you do that
for(t=0;t<samples;t++)
p=t/samples # proportion
angle+=2*PI/samples # angle in radians through the image
sum=0 # will become the sound amplitude for this sample
for(o=0;o<res;o++) # foreach oscillator
freq=(maxf-minf)*o/res+minf # this is a linear mapping... you might want log instead
oscAngle=angle*dur*freq # phase
sum+= sin(osc[o]) * interpolate(im, angle) # or use different waveform than sine
sum/osc.length # or you could go on to do other processing on it
outputSample(sum) # however you do that
interpolate(im, angle)
#TODO:
#find intersection of line from center at angle to whichever edge it hits
# and determine the length both in the x and y direction (as lenx and leny)
lenx=?
leny=?# real-valued indexes into the image:
x=im.cx+cos(angle)*lenx
y=im.cy+sin(angle)*leny)
pixel = interp2d(im, x, y) # linear is easiest, but use whatever you prefer
return pixel.luminosity # or some other mapping from pixel to loudness
@zimbot
I kind of follow your idea. Less clear on the pseudo-code, but I know what you mean.
MApping of frequencies on the 'radar' Interpretation of an image should be linear since the number of points within a circle of radious R increases linearly with R. (can work the maths, if you want, but rather not do it here on this post).
If you map linear distance from center of radar to frequency using a log scale you get less definition as frequency increses. - could be a problem and resul tin too many artifacts. Although for the purpose of the sound generation techniques we are using here, sound fidelity is not really an issue
Anyway, rather than code all of that into a program. I think the lazy solution is to find a graphics program that already does the conversion of images between polar (i.e, radar style) and cartesian (i.e., the more usual X,Y) and then use one of the many image-to-sound programs already suggested to convert to sound
Further update: the TrebbloSynths pack is now available!
http://www.freesound.org/people/copyc4t/packs/14435/
Countless thanks to the moderators
AlienXXX wrote:
I think the lazy solution is to find a graphics program that already does the conversion of images between polar (i.e, radar style) and cartesian (i.e., the more usual X,Y) and then use one of the many image-to-sound programs already suggested to convert to sound
Good idea. I didn't even realize that GIMP has this built-in, but it does. So I tried comparing the output of AudioPaint on some sample images before and after the GIMP conversion. I found that it makes a huge difference for images that are already radially-arranged. For example, a full-frame flower with tiny white radial pedals against a dark background and a yellow center. But the result still wasn't all that interesting.
AlienXXX wrote:
Also, what happens if you make the conversion slightly (or not so slightly) off-centre?
My guess it that it would depend more on the arrangement of image structure -- if you have railroad tracks converging to a point on the horizon that is off-center, you can bet it will make a big difference if you center your radius on that point.
A more impactful factor is whether you map the entire vector all the way to the edge, as I intended, or if you truncate it to a constant-radius circle. Horizontal and vertical structures are fairly common in many images, and when aligned, form distinctly steady tones and rapid spectral onsets and cutoffs with standard inverse-sonogram approach -- if you use a radial approach that maps to the edges, then you get a similar effect for horizontals when the edge terminating the vector is the top or bottom, and a similar effect for the verticals when the edge is the left of right. That's because, while sweeping across them, the structures maintain the same proportional position on the vector. And, necessarily, there is an abrupt transition (4 times) through the diagonals. But if you cut off the outer edges and use only a circle, then horizontals and verticals will always be sweeping across different frequencies. You may or may not want that.
I think it would be interesting, too, to create radial sonograms, especially due to the difference in duration for lower vs higher frequencies. FFT and inverse FFT does not lend themselves to exploiting this difference well, so (for example) to get high resolution in lower frequencies you must use a much large sample size, which means the time window for your sonogram has to be so large as to create a lot of horizontal smear, plus you get way more resolution than you want or need in the higher frequencies; whereas for high frequencies you get all the resolution you might want with relatively short sample sizes. There are adaptive approaches to blending differently sized window durations, but it's complicated and not as straightforward to program. This is a standard issue in spectral analysis, working with the time-window size vs. frequency resolution trade-off.
And by the way, the "log" thing I mentioned in the pseudo-code above would really mean what AudioPaint calls "exponential" vs linear. I started out with linear and then tried exponential, and as expected, you get more interesting things going on with the exponential mapping because more of the image data is being mapped into "meaningful" frequency range. So I just figured it would be similarly useful in the radial approach, and it is. The loss of resolution is not so important when it is centered in the higher frequencies because our perception of tones is based on the logarithm of the frequencies anyway. The difference between 100 and 200 Hz may only be 100 Hz, but there, it is an octave, while the same Hz difference between 1800 and 1700 is just about 1 cent less than a semitone. The difference between 17400 and 17300 is only about 10 cents. In fact, it's much more noticeable when you don't use exponential, and instead use linear, because you can hear gaps between the oscillators that are relatively wide as musical intervals (in the lower frequencies). This of course depends on the size of the image in a program like AudioPaint. I found that when I built a small image (less than 200 pixels each way), the result from AudioPaint ended up sounding like a bunch of organ notes (out of tune) all being played together, which isn't exactly the effect you want from inverse FFT -- the window size was simply too small, being based on the height of the image.
I expect AlienXXX knows all that, I'm just explaining for the sake of anyone else reading.
I only have two comments to what you say.
zimbot wrote:
This is a standard issue in spectral analysis, working with the time-window size vs. frequency resolution trade-off.
Also, all of that you know and put here in detail for clarity for others.
However, where I disagree wth you, is that in the case here of image-to-sound conversion, there is no need to firstly extract the frequencies from the sound recorcing. Here, we are starting from the sonogram already and applying the inverse process to convert it into a sound. The window width is the size of one point in the image (and the user is free to decide how long that lasts in time) - For example 300 x 300 picture rendered as a 1 min sound, each pixel has a duration of 0.2s=200ms. But if you render the same image file to a sound only 3s long, each pixel is now only 0.01s = 10ms.
So, when converting a cartesian coordinate (i.e., X-Y) picture to sound, there is no reason why you should get wobbly low frequencies or poorly represented transients. That process only occurs in the conversion of sound-to-picture.
The second point where I 'disagree' is conversion of a radial picture (radar-style) to sound.
Either directly or via first converting to a normal X-Y coordinate picture (using GIMP, for example) and then convert to sound.
Either way, you are limited to the point grid on the initial image as the 'resolution' of your data-set.
I am assuming you are taking a normal picture and reading it it radially from a point, in radar-sweep fashion.
The perimeter of a circle is 2*pi*R, where R is the radius. The number of pixels will be proportional to R. Near the center of the sweep, there are less pixels. At the exact center, there is only 1 pixel.
This mens that the lowest frequency will not change throughout the durtion of your sound.
We should assign this to 0Hz and make that point black, so there is no DC offset on your sound.
As you move away from the origin, each concentric circle will have more points. But near the origin there are very few.
So in the case of a radially scanned picture, you encounter the same problem as with FFT conversion: low frequencies have 'large windows'/low resolution. Probably resuting in wobbly bass, gurgling sounds and blurred transients.
My guess (and I emphasize 'guess' because I have not tried it) is that this problem is minimized with a linear frequency scale.
However, I agree that a logarithmic scale (called exponential in Audiopaint) will produce more musically meaningful results from a picture with a radial pattern. - because equal radial distances will translate into octaves.
Of course, all of that becomes an academic discussion, because sound fidelity or high-sound quality is not a major concern on the techniques we are experimenting with