From the first time I got to successfully compile a sample file for the PSP I've been after a MP3 decoding library or something of the kind. Since I could not find any, I tried to learn the MP3 format and write my own decoder. Since I found it somewhat daunting to cope with the complexities of the format, I decided it would take less time to make my own MP3-like audio format, and here is my first attempt: I call it NWA, which was supposed to stand for New Wave Audio, but Numb Wrists Audio would make a better name after so much typing. OK, a MP3 decoding library would be much better all right, but this mostly a matter of study; I expect anybody interested in compression techniques will find this, at least, educative.
The goal of all this is to develop a MP3-like lossy-compression audio format that was far more simple and easy to understand than MP3 itself, and provide the entire source code within a single .C file, and a very simple API, so that one can truly understand everything that goes on in there. That is NWA. My first version of NWA is based on public-domain algorithms: it uses the discrete cosine transform to change the audio signal from time domain to frequency domain, then applies quantization, discarding many higher-order frequencies, and finally compresses the resulting data by applying an implementation of the LZW algorithm (dictionary-based compression).
Raw audio data -> [DCT] -> [quantization] -> [LZW encoding] -> NWA
For the time being, I've written an encoder and decoder: nwa_encoder and nwa_decoder. Right now they are very simple, and require to load the entire audio file into memory before encoding, which is far too memory-demanding to be of any practical use, but are a good example of the usage of the codec. Plus, the DCT is not a good transform to use in audio applications because of ugly artefacts that stem from the fact that discontinuities appear at the interfaces between encoding-blocks: if you listen carefully to the output of nwa_decoder you'll notice a rapid succession of clicks (one click every 512 samples to be precise), so the audio quality is not that good yet.
Nevertheless, the thing works (!) and it made me very proud. You can achieve compression ratios of 1:8 to 1:10 with a reasonable audio quality.
Right now, only mono files @ 44100 hz are supported, but that is really easy to change. It's not lightning-fast, but not too sluggish, either. On my 1600 some MHZ laptop I achieve 1.5x encoding speed and some 4x decoding speed. Maybe this is still a little slow for a PSP, but I expect to improve performance.
Things to do in the immediate future:
- Use MDCT (Modified Discrete Cosine Transform) instead of DCT, to get rid of the clicking noise (it takes into account the neighbouring encoding-blocks when transforming, so that those discontinuities do not arise). I've tried the MDCT but didn't get it to work. If anybody can help me out with that, I'd be very thankful.
- Use a FAST version of the cosine transform (right now I'm using the naive O(n^2) implementation)
- Allow for stream-encoding and decoding, so that you don't need to load the entire file into memory to encode or decode.
- Support different audio formats & frequencies.
- Improve speed.
- Use the same algorithms to make a JPEG-like format, the NWI, and maybe a MPEG-like format, the NWV
Anybody interested in the codec or willing to contribute is encouraged to contact me for the source files ; )
MP3-like audio library for the PSP
MP3-like audio library for the PSP
void printSignature(void) {
printf("Brought to you by Kazlivsjy\n");
}
printf("Brought to you by Kazlivsjy\n");
}
Sounds pretty cool :)
You are most likely pushing decoding on the psp currently though, have you tryed compiling with -ffast-math to see if it speeds up encoding/decoding much?
Most likely as you say, cleaning your DCT implementation will give the best speed up.
I'm too busy with other projects to help, but I'll watch out for futher news :)
Keep us informed.
Danzel.
You are most likely pushing decoding on the psp currently though, have you tryed compiling with -ffast-math to see if it speeds up encoding/decoding much?
Most likely as you say, cleaning your DCT implementation will give the best speed up.
I'm too busy with other projects to help, but I'll watch out for futher news :)
Keep us informed.
Danzel.
