Audio Codecs

From what I can tell from the website, the Helix decoder is MP3 only (i.e. no layer-I or layer-II support), is written in C++, and is licensed under the Real Networks Public Source License (RPSL). For those reasons, and the fact that MAD is tried and tested, I think we should stick with MAD -- DaveChapman

The fixed int Helix MP3 decoder is not written in C++, it's written in C. RPSL is an OSI license and GPL compatible. It is tried and tested - Motorola use it in their phones. -- AlastairS^?

The RPSL is most definately not GPL compatible. They do list it as a compatible license, but that more or less just means that the GPL is RPSL compatible, rather than the other way round. Which is of course a huge joke. The license even has a note to that effect. -- JonasHaeggqvist

Another option is Stephane TAVENARD's MPEGDEC library as ported to the Coldfire here.
I have set this up to work with Rockbox, but the gains weren't as great as we hoped. I have no further time/desire to work on it, but if anyone feels like picking it up, it's available here. -- ThomJohansen

NOTE: There is currently some controversy with an apparent GPL-incompatible change to the FAAD2 license - see this thread at HA for details (especially comment #35)

RealNetworks released an open source fixed point HE-AAC decoder. Note: the license doesn't appear to be GPL compatible - any opinions?

DanHollis: The Podzilla guys seem to think its GPL compatible. More details HERE

RichardOBrien: The RCSL/RPSL (RealNetworks Public Source License) under which the AAC decoder was released, at Helix Community, is compatible to GPL but not the other way around.

PatrickSchuetz: I agree with RichardOBrien, for more details: HERE

For MP4 parsing, FAAD's mp4ff library would be nice, but it uses malloc rather excessively and the code in CVS for ALAC seems to work, with some minor changes for AAC support. Probably best to roll our own.

Another tricky issue is AAC gapless playback - a discussion of the subject is here

No integer version available.

Real and Microsoft signed a deal to release open source code to play Windows Media in Helix later this year. No word yet on if this will be GPL compatible or even integer. We will just have to wait and see. -- JonathanHull

AC3 is the most common audio format for DVDs, so support for this format would allow you to rip the audio from a DVD and play it directly on your DAP without re-encoding. An obvious next step (if technically possible) would be "AC3 pass-thru" via the optical digital output to a standalone AC3 surround decoder.

Quality is very, very suboptimal - RobertoAmorim

According to this topic and the changelog, FLAC 1.1.2 has a compiler define (FLAC__INTEGER_ONLY_LIBRARY) that builds the whole library (decoder, encoder, etc.) with integer only. The remaining problem is the usage of 64-bit ints in the code. But it appears that someone is working on that.

FFmpeg has a LGPL decoder.

jmac, a java implementation of Monkey's Audio is also an option (under LGPL).

The codec is heavily x86-centric with lots of x86 assembly to speed up parts of the code - particularly a neural network. Unless it's very heavily optimized for 68K and PortalPlayer, it won't run real-time. And some compression modes (Extra high, Insane) probably won't run no matter how much you optimize it - RobertoAmorim

A thing to note is that sid files have no notion of playing time. They are simply programs that go on forever, either with music that loops or silence. Traditionally this has been fixed by looking up playtimes in a database of file-md5 hashes which includes more or less every song available on the net.

Furthermore, each file may contain many subtunes.

DanHollis: sidplay2 appears to be completely integerized.

MartinArver: Unfortunatley, libsidplay, which is the lib for sidplay2, is written in c++. I have been looking at an older version of libsidplay(1.36.59), this has fixpoint-math. But, as it is written in c++ it seems we have to build the toolchain with c++ enabled for this to compile.

SNESamp actually uses the SNESapu emulator for SPC decoding. It is indeed the most accurate SPC700 APU emulator publicly available. Unfortunately, all emulation code is written in x86 assembly (NASM) - RobertoAmorim

Unlike the sid format SPCs are single songs, which have ID666 tag support, and every SPC file is 64kb in size. However, the more popular RSN format acts more like a sid file and contains all songs from a game (RSNs are simply RAR files which contain SPCs [which have a 90% average compression rate] named to RSN). Some players support RSN, others I believe do not.

Mikmod is for some reason often used, but I've been told that it lacks support for many features in some formats. This is a C library.

Modplug (the project also releases libmodplug) should have better support and it seems that it has very limited use of floats. However, libmodplug is in C++. People talking about Mikmod vs. Modplug.

Another option might be XMP which is C.

There's also DUMB which is said to be an accurate module player library (also C).

Any thoughts on which has the best support? Modplug is probably not feasible.

I have written a simple MIDI player for Linux in C++, now rewriting it in C in hopes of making it work with Rockbox. Currently the C port is able to allocate memory for the file, decode it, sequence events, and interpret them enough to play the file using the sound card an a very simple sinewave-based synthesizer I threw together. I am hoping to find an adlib emulation engine that I can import into this thing, and possibly a wavetable engine if I can find good patches.

It plays sound and at this state, it may actually work on the iRiver if someone ports the sound output routine in pctest.c to write to the iRiver DSP.

I guess the MIDI codec would have to be more of a plug-in, as it loads the entire file at once and then plays it from memory...

You may want to look for the Gravis UltraSound patches; they are floating around and used by software MIDI players such as TiMidity++

I have looked at TiMidity++ as well as the music engine used by ScummVM... Does anyone know of a good description of the Gravis UltraSound patch format? Those patches store a good deal of information, such as waveform looping, envelope, etc.. but I cannot find a guide that explains the fields in the file. Any ideas?

There seems to be downloadable Gravis patch info here.

All right.. playback, looping, interpolation (No more ghetto lowpass filter!), drums, panning, pitch wheel and all that work fine. I have just added envelope support. It works but could probably use some more exhaustive testing. I don't know how well envelope stuff will work on the target, given the amount of extra work it puts on the processor compared with the difference it makes to the output. I guess at this point the code needs to be built for and tested on the target.. but I don't really know what kind of functions it uses for file I/O, etc. Maybe someone can help me with that.. someone who actually has an iriver, etc.

Updated synth sample here. This plugin needs a separate soundset to work. This is available here. Extract its contents into the /.rockbox directory. Warning: file is around 22MB in size.

The plugin can play back midi in 22kHz in realtime on coldfire based targets, still not realtime on pp based targets.