I have no experience as a programmer, but I was curious if it would be feasible to add in support for Monkey's Audio files. For those that may not be aware of the format, it's a lossless compression format that is designed for music and gives you files that are 50%-60% of teh original size. Compressing entire albums takes only a few minutes too.

The source code has recently been made available too. Info can be found at... you guessed it!
www.monkeysaudio.com

So, anybody up to the task? Sure would be nice to have all my files archived in a lossless format even at the cost of losing some of the music I currently carry.

From what I understand, the only way this can be done is via new player software. Only the empeg team at SonicBlue has access to this. You'd have to generate a lot of interest here in order for them to consider it worth while (they have a lot of projects right now under developement). Recently, it seems that Ogg Vorbis support is coming very soon.

Actually, this could be done in Hijack as well, by having Hijack (kernel) do transparent decompression, transforming the file into a .wav before feeding it to the player.

Hijack would also have to trick the database rebuild into thinking that the codec tag was "wav" instead of "monkey".

Not terribly difficult, if somebody else were to write a stream-based decoder for it, that takes a filedescriptor & buffer & bytecount & offset as parameters, and returns that many bytes from the decompressed file, without excessively re-reading it (though probably fine if it did).

Cheers

Wow, this is a really scary thought. Hijack could implement custom decoders. Wow.

Yeah, I know.. really scary.

But such are the possibilities with an open-source kernel at the heart of the beast.

Cheers

Monkey's Audio is closed-source and Windows-only. FLAC would probably be better. But check out this comparison.

Mark, can you be more specific about the decoder interface you'd desire? Implemented as a C function to plug straight into the kernel? Input or output or both buffer? Bytecount and offset of the incoming or outgoing data?

From the web site: "The Monkey's Audio source code is now freely available."

Cheers

>Mark, can you be more specific about
>the decoder interface you'd desire?

int decode_audio(int fd, unsigned char *buffer, int bytecount, offset_t offset, void **localdata);

The function reads from "fd", and returns "bytecount" bytes of decoded .wav style audio into "buffer". The "offset" parameter indicates the starting offset of the output .wav stream for this call to the function. This does NOT correspond to the offset of the actual file on disk.

The "localdata" parameter points to a NULL pointer on first call, and the decode_audio() function may then allocate memory as needed with kmalloc() and change the pointer to reference it.

On file closure, Hijack will kfree() the pointer if non-NULL.

Cheers

Whoops. My bad. Old data floating around in the brain. (It would help if I read the whole original post, I suppose.)

Lemme see if I can't whip something together. I'll probably start with FLAC for political reasons (they were always open source), but I can't imagine that either would be too hard (unless there're significant FP ops needed).