I'm looking for a high-quality, open-source decoder. At a minimum, it should support all 3 layers. Some preferred extras (but not necessities) include ID3 tag reader included, fixed-point code, etc.

I prefer straightforward C/C++ code, and my priority is upon decoder accuracy as opposed to speed. I'm currently working with the dist10 code, but so far no one has stepped forward to say they believe that code is guaranteed error-free (as with all ISO code, THEY make no guarantees).

MAD has been suggested, but it seems to be quite old, and from what little I have seen it only supports MPEG-1, not MPEG-2 and 2.5 info. I would love to see a LAME decoder, but again, as far as I have seen, they only have an encoder. If I had to put together a priority list, it would go like this:

1) Error-free and meets the highest MPEG Audio accuracy level
2) Supports extras, like ID3 tags
3) Fixed-point code
4) Easily readable

Thanks for any suggestions...

mpg123, MAD

Given priority 3), your only option is MAD.

And it suits well priorities 1) and 2) too. Dunno about Priority 4)

Heh, I guess I should have made myself a bit more clear. Item 1 (error-free code, i.e., follows the ISO spec precisely and takes the generally accepted path on those imprecise spec points, and highest output quality, per ISO's definition) is my main concern. All other items listed are icing on the cake, I just put them in order of priority IF they were ALSO available AND criteria 1 was first met. This will eventually end up in an embedded system, so as with all personal projects, it's nice if someone has already done the work for you

I ran through the entire listing of threads in the Tech forum (all friggin' 17 pages!) to see if I could glean some useful info on suitability. Please correct me if I'm wrong, but it seemed as though mpg123 has a difficult time fitting the "error-free code" criteria. The impression I got of MAD is, while it uses strictly fixed-point code, it also does not support many of the changes made after MPEG-1 was released...again, please correct me if I'm wrong.

After reading through those 17 pages, mention is made on several occasions of a LAME decoder, but I can't help but wonder if that was a mistake on the poster's part. Is there a DECODER from LAME? I've briefly looked through the files in the latest release (v3.93.1), but I see no definite indication or demarcation of an encoder AND decoder. Considering how much I like the quality of the encoder (which I unfortunately don't need), I certainly hope a decoder exists.

Thanks for the replies, guys...

I stand corrected, on several points...

Evidently LAME does have a decoder, but it's usefulness for my purposes are overkill in some areas and woefully underpowered in others. I guess that leaves LAME out of the running.

mpg123 looks as though it hasn't been touched since 1999, and there are quite a few bugs and items on the ToDo list. That makes me shy away from it.

MAD, on the other hand, looks like a very good possibility. It's up to date (supporting MPEG-1, MPEG-2 and 2.5), open-source GPL, and claims full compliance in all modes but one (not an issue). The fact that it's already fixed-point is a sweet extra.

Unless someone can pipe in with another selection, I think I have found a contender. MAD will sit on one machine acting as my reference decoder for decode-quality assurance while I code up my version. I think I can sleep a bit easier now having reasonable confidence in what I eventually create will be compliant.

Thanks again, guys!

iirc lame uses mpg123 for decoding

for an updated mpg123, you could get it out from the fb2k sdk. peter has added loads of bugfixes and improvements to it.

is there an (win32) executable of this?

mpg123 has a difficult time fitting the "error-free code" criteria

There's mpg321 which seems to be a new implementation (or something like that?) of mpg123. Maybe mpg321 is what you need?
EDIT http://mpg321.sourceforge.net/

mpg321 = MAD decoder as far as I understand

Quoted from http://mpg321.sourceforge.net/about.html

I've personally worked with mpg123's mpglib, it works fine as long as your MP3 is totally error free but any errors and it falls over quite badly :-(

I have no experience with MAD myself but it's suppose to be good, my problem is I wanted a LGPL MP3 decoder and mpglib was the only one to meet that.

Recently however I have come across a library called mpegsound which is part of splay that's LGPL that's suppose to work better but I haven't managed to get it implemented in my sound system yet to test it out.

Moving away from dist10 is probably a good idea, from my experiments with it, it seemed to work well for decoding but I never checked the sound quality, but I believe it handled errors ok. The problem with it, is it's extremely slow and the code is hugely unreadable, you'd be better off rewriting it from scratch which I started to do at one point, but there is a lot of work in writing an MP3 decoder so it never got done.

I'd be interested if anyone has anymore suggestions for MP3 decoders, for such a popular format there is relatively few good implementations of it

Doug

Actually, after I cleaned up the code a bit by removing the #ifdef scattered throughout the code, it seems to be fairly straightforward. The separation between layers is reasonable, and the common code is all in one file. Yes, it's ungainly and slow, but it did what I needed (or so I thought). The fact that reference code has been known to have buggies isn't a problem if they're documented, but open source code rarely has bugs for long.

I'm like you, Doug, in that I have more confidence in my own skills than pre-written code, so I too decided to write mine from scratch. The main chunk of the decoder was fairly easy (if not a test on my reading and comprehension skills), but the bitstream manager was the toughest part for me. All of the implementations I had seen so far were too kludgey or unwieldy, but I just couldn't decide upon a set of functions that were both clean AND useful (I could always get one OR the other, but not both at the same time). I kept saying to myself, "There HAS to be a better way to read from the disk, separate header and data info, etc."

If mpg321 is based, at least in part, upon MAD, then MAD by itself should be good enough for my purposes. Looking through the zip file last night it seems as though it includes not just the decoder source itself, but also code for creating plugins for WinAmp, various output file types, etc. That works for me.

Before Peter's mpglib hacks to deal with corrupted MP3s, "mpglib ist death" messages appeared pretty frequently for me. If you can make any use out of the mpglib in the foobar2000 sdk, that will probably be your best bet.

Is peter going to send those changes back into the mpg123 mainline?

- Agent 86