How can I store audio files in the uC ROM so as to serially transmit it to a decoder chip?
All files are simply sequences of numbers. Each byte in a file represents a number in the range [0..255]. A text file is such a sequence of numbers, but the values of bytes making up the text file tend to be limited to the range [32..126] with a few others like 9, 10, 13. That's because this range of numbers is also defined to have textual meaning according to the ASCII table:



An .AMR (Adaptive Multi-Rate audio) is a binary file, meaning that the data it contains doesn't represent text, and it probably uses the full range of [0..255]. If you tried to open such a file in a text editor like notepad, it would look like total gibberish. If you want to have a look inside a binary file, it's best to use a Hex editor. You'll find that your file looks something like this:



Still gibberish, but at least you can see the data represented in a number of ways. On the far right, is how the file might look if opened in a very good text editor. (In Notepad it would probably look worse than this). You can see a lot of random letters, punctuation, and funny looking characters that don't appear in the ASCII table above. That is basically what your C compiler thinks you're trying to say when you #include the .ARM file.

In the central panel you can see the bytes represented as hexadecimal numbers instead. This is a more meaningful way to view a binary file. And this is roughly how you need your .AMR file to look before your C compiler will understand it.

If I wanted to compile that file shown in the picture above, my C compiler would want to see this:

xdata char mp3[]={
  0x1D, 0x50, 0xAA, 0x37, 0xD5, 0x80, 0x9B,  .......  
};


So what you need is a tool which can turn a binary file into the C code where each byte of the file is written out in hex.

Fortunately, other people have run into this problem before, and written tools to do it. You might try this one which is called bin2h, or even this one, which is also called bin2h.