My son Dave wrote again, filling in more details of his project. (It's 
important that he work in HTML5.)

Are there additional converters or processors available to him in Android 
that might be better suited to his task?

Thanks again for comments. (Stephen: Thanks for your reply, which I 
forwarded.)

Art Hunkins
-----
Dave writes further:

I'm editing with faad, which converts from m4a to wav (but not to mp3 or ogg 
I think). Then using sox to apply filters, trim, fade, etc and then 
transcode to mp3 and ogg. sox does not work well with the m4a library that 
faad uses; and none of the other native Android formats work in the webkit 
HTML view that you see on the phone. So the plumbing is complex. I would be 
interested in any tools that convert m4a directly to mp3 or ogg, 
particularly when I need to optimize for timing. (Currently the whole thing 
takes less than 15 seconds for a medium-length sound file, which is probably 
acceptable for a demo. In order to automate, I have to use command-line 
tools that can be installed under Linux (it helps if they work on Mac too).

-----
Dave originally wrote:

> I am having some difficulty and wondering if you can help me. In my 
> 'distill' app I have four steps in my audio transformation from the phone 
> to what the final web listener hears.
>
> 1. I'm recording in m4a which is mpeg-4 format with aac encoding native on 
> the phone.
>
> 2. Then I'm transcoding to 16-bit PCM in WAV format for use on the server
>
> 3. I take the 16-bit PCM and perform some filtering on it while also 
> trimming and fading the clips, before finally outputting mp3
>
> 4. Last I take the mp3 from the previous step and convert to ogg-vorbis
>
> Two things are bothering me about the process I'm currently using:
>
> First, the 16-bit PCM / WAV file is huge compared to all the others, and 
> since it's in the middle I know I could save time by encoding, writing and 
> subsequently reading and decoding a smaller intermediate file.
>
> Second, the output at the end (the mp3 and ogg files, which are the ones 
> heard by the web users) has lots of high-frequency artifacts in it.
>
> Intuitively, I feel like down-sampling (or simply *not* upsampling the 
> intermediate wav file) should solve that problem--however I'm not sure how 
> to do it; just wanted to check with you to see if there is something 
> rudimentary that I'm missing. (Plus, I don't really understand half of 
> what I typed.)