Show me the steps to solve Assignment Part $2$

In the code above, we worked with text files. To the computer though, text is just bytes. So there is no reason we can't use the same techniques to work with a binary file. We are going to work with $.$wav files for this project. A $.$wav file is a type of uncompressed audio file.

Microphones take measurements of audio called samples. For an audio file, it is not uncommon for their to be $44,100$ samples per second $-$ or even more! These files include both metadata and samples. Like most other file types, $.$wav files are very well structured. For instance, we know the following:

The first four bytes of the file will be the ASCII characters 'RIFF'.

The next four bytes are the size of the file with $8$ bytes subtracted. This value is stored as a $32-$bit integer.

The third set of four bytes are the ASCII characters 'WAVE'.

Bytes at the $22$nd and $23$rd position are for the number of channels, stored as a $16-$bit integer. If you have stereo sound, there will be two channels $($a left and a right channel$).$ Mono sound will have only one channel.

Let's see if we can make sense of a sample file. I've created a file called backwards.wav. Let's inspect the first $44$ bytes of it:

$[59]$

$0$s

$!$file $./$shared$/$audio$/$backwards$.$wav

$!$echo

$!$hexdump $-$Cn $44./$shared$/$audio$/$backwards$.$wav

$./$shared$/$audio$/$backwards$.$wav: RIFF $($little$-$endian$)$ data, WAVE audio, Microsoft PCM$,16$ bit, mono $44100$ Hz

$0000000052494646$ a$876160057415645666$d $7420|$RIFF$.$v$..$WAVEfmt $|$

$00000010100000000100010044$ ac $000088580100|........$D$....$X$..|$

$00000020020010006461746184761600|....$data.v$..|$

$0000002$c

I just output the first $44$ bytes $($the metadata$)$ of the file; there are way more bytes in the file that make up the samples. We can see the 'RIFF' and 'WAVE' parts already. If we look closely at the output above, you will notice I ran the file command first. This command tells us somethings about the file. For instance, it shows that the file is mono $(1$ channel$),$ and has a sample rate of $44100$ Hz$.$ It isn't immediately obvious from the output, but these values are stored within the metadata of the file. For instance, if we look at the bytes at location $22$ and $23$ we get $"0100".$ On this system, this $16-$bit $(2-$byte$)$ value equals our decimal value of $1.$ Since we know that bytes $22$ and $23$ are used to store the number of channels, we have just verified that our file is indeed mono.

Side note: How do we get $1$ from $"0100"?$ Well, this system is what we call little endian. This means that the least significant bit of a number comes first. If we were writing our decimal numbers in a little endian way, we would write the number $"42"$ as $"24".$ So really, the number we have stored for the number of channels is $"0001".$

Let's now look at the four bytes starting at location $24.$ These bytes store the sample rate. We should see $44100$ here. I see the bytes $"44$ ac $0000".$ Since this is a little endian system this is really $"0000$ ac $44".$ If you find an online hex converter and type in $"0000$ ac $44",$ you will get $44100$ as the converted value. Very cool!

keyboard$\_$arrow$\_$down

Working with data

If we use the code we've already written, we can load the sample wave file into a byte array. We don't need to make any changes to it$!$

Our read$\_$data function simply pulls all the bytes off the disk and puts them into memory somewhere. We can think of the area of memory as an array of bytes. That's really all a char array is in C $-$ char and byte are basically equivalent. The difference is that we normally think of a char as something visible $-$ but it doesn't have to be$.$ For instance, the new$-$line and tab characters, the system bell, the escape key, all of these are stored as a byte. Just because we can't see them doesn't mean the computer doesn't need a way to store their values.

So$,$ we have a big chunk of bytes. We know that some of these bytes are single characters and some are values stored as multiple byte sequences. We just need to interpret them the correct way. Let's try to print out the values of the first four bytes of the file. We know those should be the characters 'RIFF':

$\%\%$writefile reversal.c

#include

#include

#include "file$\_$tools.h$"$

int main$($int argc, char$**$ argv$)\{$

unsigned char$*$ data;

size$\_$t file$\_$size $=$ read$\_$data$("./$shared$/$audio$/$backwards$.$wav", &data$)$;

printf$("$Size: $\%$lu bytes.

$",$ file$\_$size$)$;

printf$("$First four bytes: $\%$c $\%$c $\%$c $\%$c$",$ data$[0],$ data$[1],$ data$[2],$ data$[3])$;

printf$("$

$")$;

return $0$;

$\}$

Size: $1472176$ bytes.

First four bytes: RIFF

But what if we had interpreted those bytes differently? What if we wanted to see their hex values? We can tell C to change how it interprets the bytes by changing the print specifier. In the code above, we used the $\text{'}\%$c$\text{'}$ to print a character. Let's modify it to use $\text{'}\%$x$\text{'}-$ that will print the hex value:

$\%\%$writefile reversal.c

#include

#include