One idea on where to start (which validates that you're able to process the audio file, before deciding how to implement the data transformations) would be to focus on implementing your points 3, 4, and 11 (load file, pass over or process metadata, and loop over the stream of values in the file until done) would be to print the value stream - this is probably the part that's the most involved technically and least interesting to what you're trying to accomplish, since it's audio format specific, with the rest of your proposed project (modifying the values and saving back to another stream) are the parts you're more likely to experiment with continuously and discover as you go. Loading the file, finding the audio data values, and "processing" them one by one (in the empty case just printing these or something else that doesn't alter the input stream) is the framework that's probably going to be constant, and may be the part that's either totally non-interesting to you or possibly frustrating (I would assume this is the part that will probably require the most library use or C specific code, and probably involves looking into the audio format you're using).
Once you have a "do something to each value in the data" loop set up, choosing what to do (some mathematical transformation like base-N digit reversal) seems like it would be easier to add into that framework; more like tinkering with the transformation choices than building a "big project" each time - the audio file processing is more or less constant work, hopefully reusable for all files of the same format for any transformation you're making.
Not sure if that helps, and if you're not comfortable with C or another programming language already, you might find libraries in python that work sufficiently well. C is probably a good tool for the job, but there's a lot of overhead you might be able to avoid using a higher level language. The overhead is mainly in steps 3, 4, and 11 if I understand the problem and guess about what the code will look like when it's working.
If there's already a great library that makes steps 3, 4, and 11 easier for you that's awesome, and then making your inner loop steps 5 through 10 something you can plug into the outer framework (passing a function pointer that takes audio values and returns output values might make sense for that?). If you haven't already looked into this, libsndfile might be a good place to start.
Looking at the Mathematica docs (reference.wolfram.com/language/ref... for example) it looks like a high level Audio object based on arrays of numbers was already present, almost certainly you'll need to find the library that does this for you in C or read some file format docs to determine how to do it for yourself.
There's no harm (especially if it's not too slow for you) to do this in Mathematica first and only move to C if you need a speed boost or want to do things that aren't made easy there. My assumptions without a lot of experience are that Mathematica will be sufficiently fast for shorter samples and performance may suffer for longer or higher sample rate inputs.
For further actions, you may consider blocking this person and/or reporting abuse
One idea on where to start (which validates that you're able to process the audio file, before deciding how to implement the data transformations) would be to focus on implementing your points 3, 4, and 11 (load file, pass over or process metadata, and loop over the stream of values in the file until done) would be to print the value stream - this is probably the part that's the most involved technically and least interesting to what you're trying to accomplish, since it's audio format specific, with the rest of your proposed project (modifying the values and saving back to another stream) are the parts you're more likely to experiment with continuously and discover as you go. Loading the file, finding the audio data values, and "processing" them one by one (in the empty case just printing these or something else that doesn't alter the input stream) is the framework that's probably going to be constant, and may be the part that's either totally non-interesting to you or possibly frustrating (I would assume this is the part that will probably require the most library use or C specific code, and probably involves looking into the audio format you're using).
Once you have a "do something to each value in the data" loop set up, choosing what to do (some mathematical transformation like base-N digit reversal) seems like it would be easier to add into that framework; more like tinkering with the transformation choices than building a "big project" each time - the audio file processing is more or less constant work, hopefully reusable for all files of the same format for any transformation you're making.
Not sure if that helps, and if you're not comfortable with C or another programming language already, you might find libraries in python that work sufficiently well. C is probably a good tool for the job, but there's a lot of overhead you might be able to avoid using a higher level language. The overhead is mainly in steps 3, 4, and 11 if I understand the problem and guess about what the code will look like when it's working.
If there's already a great library that makes steps 3, 4, and 11 easier for you that's awesome, and then making your inner loop steps 5 through 10 something you can plug into the outer framework (passing a function pointer that takes audio values and returns output values might make sense for that?). If you haven't already looked into this, libsndfile might be a good place to start.
Looking at the Mathematica docs (reference.wolfram.com/language/ref... for example) it looks like a high level Audio object based on arrays of numbers was already present, almost certainly you'll need to find the library that does this for you in C or read some file format docs to determine how to do it for yourself.
There's no harm (especially if it's not too slow for you) to do this in Mathematica first and only move to C if you need a speed boost or want to do things that aren't made easy there. My assumptions without a lot of experience are that Mathematica will be sufficiently fast for shorter samples and performance may suffer for longer or higher sample rate inputs.