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.