How to convert a sound signal function to wave file? [closed]

Question

I am new to understanding sound signals. A sound signal, as far as I know, is a real function of time $x:[0,\infty)\to \Bbb R$. For example, $x(t)=\sin(t)$ is a sinusoidal signal.

1. What is $x(t)$. For example, what are the numbers $x(1)$ or $x(2)$? What do these numbers represent?
2. How can I produce a sound file e.g. sound.wav from a signal function, e.g. $x(t)=\sin(t)$. Can you give me a simple code (in c#, c++,..) for converting $x(t)$ to a sound file? (I need the code just to see and understand the details).

Answer 1

i don't consider this a "bad" question. But there is a lot that nano needs to deal with.

first, you must be able to think about conceptually and mathematically converting your continuous-time signal

$$ x(t) = \sin(\Omega t) $$

into a discrete-time signal

$$ x[n] = \sin(\omega n) $$

how $n$ is related to $t$ and how $\omega$ is related to $\Omega$. this requires knowledge of the sample rate.

finally, after creating an array of samples, you can write that array to a .wav file using a library such as this one from Erik de Castro Lopo. you might have to massage the code to make it work for C#.

or you can learn about the format of the particular .wav file (nowadays they can be float or int format) and write that file using the C# counterparts to fopen(), fwrite(), and fclose(). but i dunno shit about C#.

Answer 2

For the first question: analog sounds are vibrations traveling through a medium and that can be heard. They are function of space, and can be measured with a physical unit, classically pressure. Perceived at one location (possibly moving), you can see it as a function of time. But you could validly consider a 2D signal s a sound.

You can model the 1D version by a unitless function like a sine. Yet, I don't consider a sine as a sound, because it has not unit. It is more a representation.

Know, recorded sound files require to convert a continuous entity into a semi-unitless, discrete sequence of bits. It is discretized in time, in instants represented by integers: [1], [2], etc. while keeping in mind that "[2] minus [1]" represents a difference in the "real time" in seconds. It is discretized in amplitude: the continuous $s(.)$ values with units (bars) are converted into a finite binary representation $s_Q[.]$, between some minimal and maximal almost unitless value.

So, only a finite subset of the continuous values $s(t)$, $t\in \mathbb{R}$, are kept as $s_Q[k]$, each of them being represented by some number of bits, say 16 bits: $s_Q^{15}[k]$... $s_Q^1[k]$, $s_Q^0[k]$.

I said semi-unitless above, as the quantity of real time between $s_Q[2]$ and $s_Q[1]$, and the conversion from the unitless $s_Q[1]$ to an approximation of the unit-based $\hat{s}(1)$ are still implicit. They should be made explicit so that a system can convert the binary file back to an audible sound via a loudspeaker. It often uses an inverse calibration function: $\hat{s}(1) = a s_Q[1]+b$.

So generally, a natural digital sound file has a linear pulse-code modulation (LPCM). It is often made of some header bytes describing the structure of the file, the numbers of bits for sample, the sampling frequency, the conversion factor to bars, and then the series of bits for each sample:

$\mathrm{[header]}\; s_Q^{15}[0],\ldots,s_Q^1[0],s_Q^0[0],s_Q^{15}[1],\ldots,s_Q^1[1],s_Q^0[1]\ldots$

Then, more efficient structures, using prediction, Fourier transforms, can be used, but this is another story.

For the second one: I know of no code that can convert $s(t)$ into $s_Q[n]$, since computers rarely deal with continuous signals. One needs analog/digital converters first.