mp3PRO?

mp3PRO is an audio compression algorithm (or codec) that combines the MP3 audio format with spectral band replication compression methods. It claims to achieve transparency at lower bitrates than MP3, resulting in a file nearly half the size of standard MP3.

A different way of describing it:

It was a time long ago and Ogg Vorbis had not
yet entered the picture. I was young. I was naive. I believed that even closed formats would stay forever.

I was out of hard disk space.

And this format was promising to halve my MP3 files in half!

In my tests I found out that it sounded pretty good, too, so I decided to go ahead and use mp3PRO
for my audio collection...

And halved it, it did. And I got some much needed disk space. And I installed Linux...

Time passed...

And, as expected, Linux (and the BSDs) shook my world... I became an addict; I learned to worship Stallman and Raymond, I coded in C and C++ and Perl and Python... I read manuals and infopages... I became a hermit...

...and after 10 years of working in silence, it dawned on me... now that I was using open-source OSes, how would I listen to my music?

Closed formats: A Royal Pain In The...

To add insult to injury, in the years that passed, not only had Ogg Vorbis emerged, it had also surpassed mp3PRO in terms of quality/bitrate. So not only did my music collection suffer silence at the hands of a closed format, it was also sounding inferior...

I contemplated re-coding all my CDs in Vorbis... But I am lazy... I am also a somewhat-adept coder, so I started investigating...

Option 0: In-Duh-vidual

Well, mp3PRO files are in fact valid MP3 files. You can listen to them with any MP3 decoder - but you are only listening to the first 22KHz of the spectrum... To hear the rest, you need an mp3PRO-aware decoder... So the quality of the sound is rather flat, similar to that of a radio station...

Option 1: Wine

WINE is a great piece of software. Does it run Winamp, with its mp3PRO plugin?

Of course it does!

In the snapshot above, you can see the nice IceWM window decorations (I love spartan window managers). You can also see that the file being played is, in fact, an mp3PRO file - which sounds every bit as delicious as it does under Windows, at a smooth 44KHz.

Option 2: Mass conversion

Then again, WINE is a beast. Perhaps it is better to "bite the bullet" and transcode the files from mp3PRO to Vorbis... Harddisk space is now cheaper than air (almost), so I can use this nice "dBpowerAMP Music Converter" thingie that I downloaded from the Web, to convert my files to WAVs, and re-encode them in Vorbis. This tool supports mp3PRO through the Winamp plugin, so there, I am out of excuses...

Or am I?

Do I have to Cick/Click/Click for all the music files I have? Hundreds of them...?

Option 3: XMMS

Then again, why transcode? The frequency information is there, why re-encode it in another format?

All I want is to be able to listen to my files using a native Linux solution... Let's Google...

What do you know!... THOMSON released an mp3PRO plugin for XMMS, back in 2005!... Now there's something I did not expect.

Then again, people all over the web are complaining about it ("it doesn't work" - "it borks my XMMS") ... let's try it anyway...

Option 4: MPlayer

Well then, why did these people complain? It works fine, in both my Gentoo and my Debian Etch... And now that I have an XMMS plugin, I can even use MPlayer's xmms demuxer, and do ANYTHING I want with my mp3PRO files... filter them, transcode them, flip them sideways...

Let me show you - oh wait!

Here's something weird... I compiled my MPlayer with --enable-xmms and fed it (using -demuxer xmms) with an mp3PRO file...

In other words, it is the plugin that decides the quality of the output (parameter "rate"). The function pointer to "disk_open" is
passed to the plugin in a structure (of type OutputPlugin) during plugin initialization, and the plugin calls it when it knows enough about the input to decide what output it is going to generate.

The million dollar question, is why does the plugin call disk_open with 22KHz when used under MPlayer, but with 44KHz
when used under XMMS?

Since we asked for -demuxer xmms, MPlayer tries to dynamically load (through dlopen) all the XMMS plugins existing under /usr/lib/xmms/Input/. One of them is libmp3PRO.so, and yes, one of the symbols referenced (as well as defined!) inside it, is getbits. This is of course a completely different function!

At this point, "ld" has a problem. Which getbits definition (of the two addresses now available in MPlayer's process space) should it use to "patch" the invocations to getbits inside the newly loaded code of libmp3PRO.so?

It turns out, that in my case, it used the getbits from libmp3lame.so!

What this means, in plain terms, is that "ld" tried to put the shoes of a midget on Andre the Giant.

The results, could have been ANYTHING. I was amazed to see that this didn't cause a crash; pure luck, as it turned out: a function inside the plugin (SbrCrcCheckMp3) tried to use getbits, and ended up calling the COMPLETELY different implementation of the function offered by the code inside libmp3lame. This foreign code, returned a completely unexpected value to SbrCrcCheckMp3, and so the poor function considered the Sbr information (spectral band replication) to be "bad" - and disabled the decoding of the upper frequencies (the ones above 22KHz!).

This of course explains all the poor people that complain about this plugin "borking" their XMMS... What happens is truly random... In my case, I was lucky - my XMMS and its plugins didn't offer an alternative getbits, so everything was fine under XMMS. Under MPlayer, however, I could have gotten any kind of behaviour. Crash, corruption...

Other people, apparently, were not so lucky.

Executive summary: Friggin' binary blobs! If only we could dispose of them...

So how do I fix this?

Easy. You just have to build an MPlayer that...

Doesn't contain any getbits implementation

Doesn't link to any library that contains a getbits implementation

That's not as hard as it sounds. Basically, after configuring MPlayer with configure --enable-xmms, I had to do 2 things:

edit config.mak and remove -lmp3lame from the 2 places where it appeared

And now, the sky's the limit... If I choose to, I can transcode my files into vorbis using pipes (and avoid the Gigabytes of WAVs that "Option 2" would require)... or I can apply any kind of runtime filter (e.g. -af sub, -af extrastereo, -af karaoke, etc).

The comments on this website require the use of JavaScript. Perhaps your browser isn't
JavaScript capable or the script is not being run for another reason. If you're
interested in reading the comments or leaving a comment behind please try again with a
different browser or from a different connection.