Fixed point math MP3 encoder
Posted: Sat Jun 16, 2012 10:26 pm
This seems to be pretty much forgotten:
http://sourceforge.net/projects/libshine-fxp/
The Shine encoder was originally written by one of the LAME devs as a lean and simple MP3 encoder, then someone else fixed it to remove all FPU math and adapted it for RiscOS. Then later someone cleaned it up for regular Linux use.
I downloaded it, renamed Makefile-generic to Makefile, edited the gcc line in that file to remove the "-m32" option and it compiles ok (just run make in that folder). I just tested ./shineenc-gen on my ARM NAS:
3m48 WAV file ripped from CD (Aphex Twin - Pulsewidth.wav):
lame 3.99-5 (from ipkg) @128Kbps - encoded in 6min09secs
shineenc v1.01 @128Kbps - encoded in 42secs
shineenc v1.01 @320Kbps - encoded in 46secs (Sounds perfectly fine on headphones to me, though my test track isn't ideal for assessing quality. Guitar music might be better to show up any problems).
This is a huge speed improvement over LAME on ARM CPU - 13x faster! Apparently the audio quality isn't quite as good as LAME because the encoder is not as complex, but since it's only an additional 10% time penalty to encode at 320Kbps then it might as well be used at that bitrate. The goal is only to transcode audio when devices won't play mp4, wma or flac or whatever.
So I wonder if this might be usable via a wrapper script to replace FFmpeg's libmp3lame encoder. I guess the main problem is that it's expecting a wav file input. Using a wrapper I guess you'd need to wait for the entire source file decode to happen first, then feed that wav into shineenc before you could start playing the transcoded file. I checked to see if FFmpeg supports using this lib (libshine-fxp) but no sign of that unfortunately. I guess it could be hacked in, but you'd need to know your way around the FFmpeg sources (or perhaps it's not that hard - here is an example of changes to graft in support for another lib: https://lists.ffmpeg.org/pipermail/ffmp ... 43788.html).
Anyway, it's something to think about and maybe experiment with, since it brings realtime audio transcoding to low power systems. Currently FFmpeg's ac3 encoder is the only one that is efficient enough for ARM CPUs to transcode in realtime.
My compiled binary (with source) for ARM Synology NAS (Marvell 628x):
http://dl.dropbox.com/u/1188556/libshine-fxp.tgz
http://sourceforge.net/projects/libshine-fxp/
The Shine encoder was originally written by one of the LAME devs as a lean and simple MP3 encoder, then someone else fixed it to remove all FPU math and adapted it for RiscOS. Then later someone cleaned it up for regular Linux use.
I downloaded it, renamed Makefile-generic to Makefile, edited the gcc line in that file to remove the "-m32" option and it compiles ok (just run make in that folder). I just tested ./shineenc-gen on my ARM NAS:
3m48 WAV file ripped from CD (Aphex Twin - Pulsewidth.wav):
lame 3.99-5 (from ipkg) @128Kbps - encoded in 6min09secs
shineenc v1.01 @128Kbps - encoded in 42secs
shineenc v1.01 @320Kbps - encoded in 46secs (Sounds perfectly fine on headphones to me, though my test track isn't ideal for assessing quality. Guitar music might be better to show up any problems).
This is a huge speed improvement over LAME on ARM CPU - 13x faster! Apparently the audio quality isn't quite as good as LAME because the encoder is not as complex, but since it's only an additional 10% time penalty to encode at 320Kbps then it might as well be used at that bitrate. The goal is only to transcode audio when devices won't play mp4, wma or flac or whatever.
So I wonder if this might be usable via a wrapper script to replace FFmpeg's libmp3lame encoder. I guess the main problem is that it's expecting a wav file input. Using a wrapper I guess you'd need to wait for the entire source file decode to happen first, then feed that wav into shineenc before you could start playing the transcoded file. I checked to see if FFmpeg supports using this lib (libshine-fxp) but no sign of that unfortunately. I guess it could be hacked in, but you'd need to know your way around the FFmpeg sources (or perhaps it's not that hard - here is an example of changes to graft in support for another lib: https://lists.ffmpeg.org/pipermail/ffmp ... 43788.html).
Anyway, it's something to think about and maybe experiment with, since it brings realtime audio transcoding to low power systems. Currently FFmpeg's ac3 encoder is the only one that is efficient enough for ARM CPUs to transcode in realtime.
My compiled binary (with source) for ARM Synology NAS (Marvell 628x):
http://dl.dropbox.com/u/1188556/libshine-fxp.tgz