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

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).

## closed as too broad by Stanley Pawlukiewicz, Matt L., lennon310, jojek♦Jul 30 '18 at 15:46

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

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#.

• thanks. This can be a an indirect answer for question (2). I just need to not read the code because code and much more explanatory containing all required details. Do you have an answer for question (1)? what is x(1)? what's it unit? decibels? – nano Jul 20 '18 at 20:34
• you will need to get some book (i dunno which book is most appropriate, because i do not know your skill level) that explains sampling and some other concepts. just knowing how to code in C# is not going to be enough. – robert bristow-johnson Jul 20 '18 at 20:37
• the notation i pretty much insist on using is "$x(t)$" for continuous-time functions and "$x[n]$" for discrete-time functions (which i consider to be a better notational convention than "$x_n$"). they are dimensionless in the computer. no units but are proportional to the instantaneous voltage that comes out of a microphone or the voltage that goes into a loudspeaker amplifier. the scale factors that convert the dimensionless value of $x[n]$ to physical properties, like voltage or instantaneous pressure difference from atmospheric, those are properties of the electronics and transducers. – robert bristow-johnson Jul 20 '18 at 20:40
• I think there must be a pre-electronic physical meaning for $x(1)$ too. But the speaker voltage can be enough to understand. thanks. – nano Jul 20 '18 at 20:45
• About my skill: I'm familiar with coding and math. but completely new to sound processing. I started reading a few books on sound processing but they started to use very technical language. I could not understand and continue. Do you know any booking for newbies? – nano Jul 20 '18 at 20:52

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.