I’m mostly certain “playmus” only plays things considered Music by SDL_mixer.
(eg, MODs and friends… I’m not sure that that includes MP3s.)
It does include MP3s, actually, although I personally consider MP3 data to
fall more into the “wave data” category. If nothing else, this limits us
from mixing more than one MP3 channel at a time.
I’ll be fixing this in the future, as I discussed a while ago.
I believe, though, SMPEG comes with a “plaympeg” program.
…which is somewhat better at play MP3s than playmus is anyhow.
Just a bit of a tangental gripe:
SDL_mixer use SMPEG for playing MP3’s. SMPEG uses splay for its mp3
decoding. splay is an absolutely horrible decoder. Its slow and its
audio quality is crap. Want scientific proof? Look at this:
Whoever’s doing the SDL_voice thing (The name doesn’t quite explain what
it does. SDL_audioformat?) please allow the use of libmpg123 (and maybe
MAD for some embedded platforms…) as the decode engine. smpeg/splay
is horrid. (I’ve considered hacking smpeg to use mpg123, but haven’t
seriously looked into it yet…)
Whoever’s doing the SDL_voice thing (The name doesn’t quite explain what
it does. SDL_audioformat?) please allow the use of libmpg123 (and maybe
I changed the name, at Sam’s suggestion, to SDL_sound.
MAD for some embedded platforms…) as the decode engine. smpeg/splay
is horrid. (I’ve considered hacking smpeg to use mpg123, but haven’t
seriously looked into it yet…)
I put SMPEG support into SDL_sound, but it doesn’t work yet (I probably
screwed up some sort of SMPEG state). If you want to put a mpg123 backend
in there, I will definitely accept it (and there’s no reason we can’t have
both, even in the same libSDL_sound.so). Please check out the information
at SDL_sound, and get on the mailing list listed at
the bottom of that page if you want to tackle this, or advise me while I
tackle it.
Be careful of the license. mpg123 is GPL (or was when we were considering
adding it to mpeg4ip), and you don’t want to include a GPL project into a
LGPL project.
Bill
Ryan C. Gordon wrote:>>Whoever’s doing the SDL_voice thing (The name doesn’t quite explain what
it does. SDL_audioformat?) please allow the use of libmpg123 (and maybe
I changed the name, at Sam’s suggestion, to SDL_sound.
MAD for some embedded platforms…) as the decode engine. smpeg/splay
is horrid. (I’ve considered hacking smpeg to use mpg123, but haven’t
seriously looked into it yet…)
I put SMPEG support into SDL_sound, but it doesn’t work yet (I probably
screwed up some sort of SMPEG state). If you want to put a mpg123 backend
in there, I will definitely accept it (and there’s no reason we can’t have
both, even in the same libSDL_sound.so). Please check out the information
at SDL_sound, and get on the mailing list listed at
the bottom of that page if you want to tackle this, or advise me while I
tackle it.
Be careful of the license. mpg123 is GPL (or was when we were considering
adding it to mpeg4ip), and you don’t want to include a GPL project into a
LGPL project.
Be careful of the license. mpg123 is GPL (or was when we were considering
adding it to mpeg4ip), and you don’t want to include a GPL project into a
LGPL project.
Be careful of the license. mpg123 is GPL (or was when we were considering
adding it to mpeg4ip), and you don’t want to include a GPL project into a
LGPL project.
Took a look on Friday - nowhere in the READMEs does it say LGPL. That was
with the mpg123 0.59r version. I did not check out the development tree.
You MUST use the latest development version. There’s a one line mention in
the mpglib README on that release. It’s just the “mpglib” directory, too.
The rest is GPL’d, still. You have been warned.
It doesn’t have layer 1 or layer 2 Mpeg decoding - which is not a problem
for mp3, but may be for SMPEG.
I’ve been meaning to ask; what exactly makes mpg123 better than SMPEG?
Someone said, “it’s based on splay, which sucks”, but the SMPEG crew has
made about a million patches to the decoder. Specifics, benchmarks,
perhaps examples in the code are appreciated.
(I’ll start: SMPEG_playAudio() apparently mixes into the buffer you give
it, instead of overwriting it (which I didn’t see documented). This could
be made a tiny bit speedier by having an option to disable this behaviour
for things that don’t need it (such as SDL_mixer, which will be doing the
mixing itself further down the line).
RCG> I’ve been meaning to ask; what exactly makes mpg123 better than SMPEG?
RCG> Someone said, “it’s based on splay, which sucks”, but the SMPEG crew has
RCG> made about a million patches to the decoder. Specifics, benchmarks,
RCG> perhaps examples in the code are appreciated.
Taken from the original mail by Callum Lerwick:
"Just a bit of a tangental gripe:
SDL_mixer use SMPEG for playing MP3’s. SMPEG uses splay for its mp3
decoding. splay is an absolutely horrible decoder. Its slow and its
audio quality is crap. Want scientific proof? Look at this:
Whoever’s doing the SDL_voice thing (The name doesn’t quite explain what
it does. SDL_audioformat?) please allow the use of libmpg123 (and maybe
MAD for some embedded platforms…) as the decode engine. smpeg/splay
is horrid. (I’ve considered hacking smpeg to use mpg123, but haven’t
seriously looked into it yet…)"
RCG> I’ve been meaning to ask; what exactly makes mpg123 better than SMPEG?
RCG> Someone said, “it’s based on splay, which sucks”, but the SMPEG crew has
RCG> made about a million patches to the decoder. Specifics, benchmarks,
RCG> perhaps examples in the code are appreciated.
Taken from the original mail by Callum Lerwick:
"Just a bit of a tangental gripe:
SDL_mixer use SMPEG for playing MP3’s. SMPEG uses splay for its mp3
decoding. splay is an absolutely horrible decoder. Its slow and its
audio quality is crap. Want scientific proof? Look at this:
mpg123 current crashes on about 1/3 of my mp3 files…
madplay crashes on a smaller number (maybe 1 in 20)
SMPEG crashes on -none-. It plays them all. Without fail. Or even any
kind of sound artifacts… which both mpg123 and madplay suffer.
(SDL_audio is most stable audio system on my computer
Don’t quit using smpeg…
Thanks!
- TeunisOn Mon, 24 Sep 2001, Neil Griffiths wrote:
It would be interesting to see the MPEGaudio class turned into an
interface which is subclassed to SPLAYaudio and MPGLIBaudio, so that the
user can, at compile time if not runtime, choose the decoder that works
best for her needs.
Then again, I’m not going to do it, but I like the idea of this being in
SMPEG more than I like the idea of having to support two decoders for the
same file type in SDL_sound.
(And coincidentally, the SMPEG decoder in SDL_sound is working now.)
mpg123 current crashes on about 1/3 of my mp3 files…
madplay crashes on a smaller number (maybe 1 in 20)
What version of mpg123? mpg123 as embedded in xmms which I’ve been
primarily using since it was X11amp, has never had a problem with the
tens of thousands of mp3’s from all manner of shady sources I’ve thrown
at it over the years.
SMPEG crashes on -none-. It plays them all. Without fail. Or even any
kind of sound artifacts… which both mpg123 and madplay suffer.
(SDL_audio is most stable audio system on my computer
Any kind of sound artifacts? Thats all I hear. It does all kinds of
terrible warbling to lower freqencies in particular.
Not to mention just being slow. Playmus take 60% CPU time playing an mp3
on an Alpha 166, whereas mpg123 takes 20%.
Don’t quit using smpeg…
Please, please stop using smpeg…
What the unix world really needs, is a generalised audio/video codec
system. And do it better than windows.
mpg123 current crashes on about 1/3 of my mp3 files…
madplay crashes on a smaller number (maybe 1 in 20)
What version of mpg123? mpg123 as embedded in xmms which I’ve been
primarily using since it was X11amp, has never had a problem with the
tens of thousands of mp3’s from all manner of shady sources I’ve thrown
at it over the years.
mpg123-0.59r – which -is- the latest version. and sound artifacts?
breakup, long pauses in playing, occasional garbage. Happens with madplay
as well but much less often. As before none of these happen with SMPEG.
and TBQH I don’t notice any particular speed probs - when I set plaympeg
to --novideo that is g… but I haven’t tested it that far.
and on audio/video generalized codec system:
it’s a common wish SDL isn’t the place for that… heh
this is the last I post on this unless someone comes up with SDL related.
I know there’s interest in using mpg123 rather than smpeg for mp3 playing
in SDL_mixer and such - I’d prefer not, or a choice if that’s possible.
mpg123 just has had too many problems on my machine…
(mpg123 started being a problem some time last year with some new
encodings btw… I still haven’t tracked it down)
Wouldn’t it be possible to suppoer all of mpg123, smpeg and mad, and
allow to choose which to prefer, i.e. just like you can tell SDL
which video driver you prefer if multiple are available…
Wouldn’t it be possible to suppoer all of mpg123, smpeg and mad, and
allow to choose which to prefer, i.e. just like you can tell SDL
which video driver you prefer if multiple are available…
Oooh! Can we have another undocumented environment variable?
At 17:14 Uhr -0400 26.09.2001, Ryan C. Gordon wrote:
Wouldn’t it be possible to suppoer all of mpg123, smpeg and mad, and
allow to choose which to prefer, i.e. just like you can tell SDL
which video driver you prefer if multiple are available…
Oooh! Can we have another undocumented environment variable?
It is documented, and I didn’t propose we use that approach.
First of, there should be a configure switch for each support MP3
backend; furthermore if only mad is available on a system, it will
only compile in support for that (of course).
Then, on run time, it will use the “default” MP3 engine (the order of
preferences should be changeable by a call in the app source maybe).
An env variable could still be used as an additional modifier, could
be quite useful in some cases, but only as a last resort.
