mpglib/mpg123 MP3 Decoding

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

mpglib/mpg123 MP3 Decoding

Robert Leiking

Hi there!

Currently I am using the mpglib (MPG123vers???) sources from LAME 3.97 to run a decoder on a high performance 32bit microcontroller.
 
I am getting the message "bitstream problem: resyncing..." very often. Is this a problem of the mp3 file I am decoding or could this be an internal decoding problem?

Is this a major malfuction or quite common during the decoding process?

What do this members of the structure mp3data_struct in mpglib.h mean:"ssize, dsize, bsize, bsnum"?

In this structure: Does "framesize","fsizeold" represent the number of samples within one mp3 frame (1152 for a Mp3 file, right?) or does it mean the length of a frame in bytes?

Thanks!

Robert


--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
_______________________________________________
mp3encoder mailing list
[hidden email]
https://minnie.tuhs.org/mailman/listinfo/mp3encoder
Reply | Threaded
Open this post in threaded view
|

Re: mpglib/mpg123 MP3 Decoding

Ruckert Martin
This is a problem with your bitstream. mpg123, however, is
not very good at resyncing. So once the player looses track
most likely the whole rest of the file is skipped.

Martin Ruckert

Robert Leiking wrote:

> Hi there!
>
> Currently I am using the mpglib (MPG123vers???) sources from LAME 3.97 to run a decoder on a high performance 32bit microcontroller.
>  
> I am getting the message "bitstream problem: resyncing..." very often. Is this a problem of the mp3 file I am decoding or could this be an internal decoding problem?
>
> Is this a major malfuction or quite common during the decoding process?
>
> What do this members of the structure mp3data_struct in mpglib.h mean:"ssize, dsize, bsize, bsnum"?
>
> In this structure: Does "framesize","fsizeold" represent the number of samples within one mp3 frame (1152 for a Mp3 file, right?) or does it mean the length of a frame in bytes?
>
> Thanks!
>
> Robert
>
>


--
-------------------------------------
Prof.Dr.Martin Ruckert
Munich University of Applied Sciences
FB07 Mathematics and Computer Science
Lothstrasse 34
D-80335 Munich
GERMANY
_______________________________________________
mp3encoder mailing list
[hidden email]
https://minnie.tuhs.org/mailman/listinfo/mp3encoder
Reply | Threaded
Open this post in threaded view
|

Re: mpglib/mpg123 MP3 Decoding

Thomas Orgis
Am Mon, 15 Jan 2007 16:10:43 +0100
schrieb Ruckert Martin <[hidden email]>:

> This is a problem with your bitstream.

You have metadata embedded? Perhaps a stored shoutcast stream with the
periodic track meta info? Album art?

> mpg123, however, is
> not very good at resyncing. So once the player looses track
> most likely the whole rest of the file is skipped.

This may be true for the decoder version in lame, but I just feel urged
to say that the stand-alone mpg123 has improved somewhat in that
respect.
At least for files, on resync it looks for something like a valid
header and does a readahead of one frame to peek if there is another
valid header following.
I worked on quite some problematic files and up to now was able to fix
the mpg123 decoder for all them.
Though, there is a rather new bug on mpg123 bug tracker with some files
that worked with pre0.59s but not with the new (descendent from 0.59r)
0.6x.

The lame mpglib based decoder is based on code that was taken from
mpg123 before the pre0.59s (IMHO).
Generally, the mpglib package needs fixing -- merging improvements that
happened in the console application mpg123.
Can you check if the standalone mpg123 (0.63 and pre0.59s) can play
your files correctly? If so, it should be just a matter of some work to
get the newer mpg123 code into mpglib.

I (the main mpg123 maintainer) have sincere plans to do this mpglib
update from which in turn lame could re-include code, but it would take
me some months to find the time to do it alone (thesis work).
Perhaps if you are motivated to get your microcontroller project going
with some coding (I assume you are when hacking already;-) we could
help each other.
There already was an attempt to make mpglib work on a SHARC 32bit DSP,
btw - we got the code basically working on it, but the project was let
down and so we didn't come to the part with bugfixing the decoder with
fresher mpg123 code.


Thomas.
_______________________________________________
mp3encoder mailing list
[hidden email]
https://minnie.tuhs.org/mailman/listinfo/mp3encoder
Reply | Threaded
Open this post in threaded view
|

Re: mpglib/mpg123 MP3 Decoding

Alexander Leidinger
Quoting Thomas Orgis <[hidden email]> (from Mon, 15 Jan 2007  
19:37:34 +0100):

> Am Mon, 15 Jan 2007 16:10:43 +0100
> schrieb Ruckert Martin <[hidden email]>:

>> mpg123, however, is
>> not very good at resyncing. So once the player looses track
>> most likely the whole rest of the file is skipped.
>
> This may be true for the decoder version in lame, but I just feel urged
> to say that the stand-alone mpg123 has improved somewhat in that
> respect.

> The lame mpglib based decoder is based on code that was taken from
> mpg123 before the pre0.59s (IMHO).
> Generally, the mpglib package needs fixing -- merging improvements that
> happened in the console application mpg123.
> Can you check if the standalone mpg123 (0.63 and pre0.59s) can play
> your files correctly? If so, it should be just a matter of some work to
> get the newer mpg123 code into mpglib.

> I (the main mpg123 maintainer) have sincere plans to do this mpglib
> update from which in turn lame could re-include code, but it would take
> me some months to find the time to do it alone (thesis work).

In the LAME CVS we have "HIP", which is a merge of some newer mpglib  
code with what we have in LAME currently. The mpglib code in LAME is  
changed in some parts to suit our needs. I don't know more, you need  
to consult the CVS history if you want to know more.

Bye,
Alexander.

--
If you think before you speak the other guy gets his joke in first.

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137
_______________________________________________
mp3encoder mailing list
[hidden email]
https://minnie.tuhs.org/mailman/listinfo/mp3encoder
Reply | Threaded
Open this post in threaded view
|

Re: mpglib/mpg123 MP3 Decoding

Robert Leiking
In reply to this post by Thomas Orgis

-------- Original-Nachricht --------
Datum: Mon, 15 Jan 2007 19:37:34 +0100
Von: Thomas Orgis <[hidden email]>
An: [hidden email]
Betreff: Re: [mp3encoder] mpglib/mpg123 MP3 Decoding

> Am Mon, 15 Jan 2007 16:10:43 +0100
> schrieb Ruckert Martin <[hidden email]>:
>
> > This is a problem with your bitstream.
>
> You have metadata embedded? Perhaps a stored shoutcast stream with the
> periodic track meta info? Album art?
>

It definitely was a bitstream problem: there was a bug in my own memory access implementation, which I had to write since I don't have a filesystem...

Seems that it's working fine now, though it takes quite long to decode even a very short mp3 (far from real time), currently I'm trying to figure out where the main workload comes from.

> The lame mpglib based decoder is based on code that was taken from
> mpg123 before the pre0.59s (IMHO).
> Generally, the mpglib package needs fixing -- merging improvements that
> happened in the console application mpg123.
> Can you check if the standalone mpg123 (0.63 and pre0.59s) can play
> your files correctly? If so, it should be just a matter of some work to
> get the newer mpg123 code into mpglib.
>
> I (the main mpg123 maintainer) have sincere plans to do this mpglib
> update from which in turn lame could re-include code, but it would take
> me some months to find the time to do it alone (thesis work).
> Perhaps if you are motivated to get your microcontroller project going
> with some coding (I assume you are when hacking already;-) we could
> help each other.

Sure, we could help each other, but my project is more focussed on benchmarking the DSP performance of that specific microcontroller. MP3 decoding and encoding (would be the next step) is just taken as an example DSP application. So getting one open source algorithm running and hand-optimising it afterwards on assembler level might be more important for me than trying out several different implementations.

> There already was an attempt to make mpglib work on a SHARC 32bit DSP,
> btw - we got the code basically working on it, but the project was let
> down and so we didn't come to the part with bugfixing the decoder with
> fresher mpg123 code.

Maybe you could give me some more information about this stuff:

> What do this members of the structure mp3data_struct in mpglib.h mean:"ssize, dsize, bsize, bsnum"?
>
> In this structure: Does "framesize","fsizeold" represent the number of samples within one mp3 frame (1152 for a Mp3 file, right?) or does it mean the length of a frame in bytes?
>

regards

Robert


--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
_______________________________________________
mp3encoder mailing list
[hidden email]
https://minnie.tuhs.org/mailman/listinfo/mp3encoder
Reply | Threaded
Open this post in threaded view
|

Re: mpglib/mpg123 MP3 Decoding

Thomas Orgis
Am Tue, 16 Jan 2007 13:08:21 +0100
schrieb "Robert Leiking" <[hidden email]>:

> > There already was an attempt to make mpglib work on a SHARC 32bit DSP,
> Maybe you could give me some more information about this stuff:

Well, we started working on a branch of mpglib for this dsp. Including giving the result as 32bit float instead of converting to integers...
Not too much changes were needed, actually. There were some bugs that arised from the fact that every data type on this dsp was 32 bits wide.
Well, you can see what happened there via

http://mpg123.de/cgi-bin/viewvc.cgi/mpglib/sharc_dsp/

>
> > What do this members of the structure mp3data_struct in mpglib.h mean:"ssize, dsize, bsize, bsnum"?
> >
> > In this structure: Does "framesize","fsizeold" represent the number of samples within one mp3 frame (1152 for a Mp3 file, right?) or does it mean the length of a frame in bytes?
> >

These are for the frame data size. The number of of samples is normally 1152, but can be 576 or 384 ... that number should be the same throughout a file.
Frame data size depends on the bitrate and can vary for VBR files (which consist of frames with differing bitrate values), short:

fr->framesize  = (long) tabsel_123[fr->lsf][2][fr->bitrate_index] * 144000;

;-)

Alrighty then,

Thomas.

--
Thomas Orgis - Source Mage GNU/Linux Developer
(http://www.sourcemage.org) OrgisNetzOrganisation ---)=-
http://orgis.org GPG public key: http://thomas.orgis.org/public_key
_______________________________________________
mp3encoder mailing list
[hidden email]
https://minnie.tuhs.org/mailman/listinfo/mp3encoder
Reply | Threaded
Open this post in threaded view
|

Re: mpglib/mpg123 MP3 Decoding

Robert Leiking

Hi Thomas,

is there also a fixed point implementation available from mpglib or mpg123??
Or is this SHARP DSP already in fixed point?

cheers

Robert


-------- Original-Nachricht --------
Datum: Thu, 18 Jan 2007 01:37:45 +0100
Von: Thomas Orgis <[hidden email]>
An: [hidden email]
CC:
Betreff: Re: [mp3encoder] mpglib/mpg123 MP3 Decoding

> Am Tue, 16 Jan 2007 13:08:21 +0100
> schrieb "Robert Leiking" <[hidden email]>:
>
> > > There already was an attempt to make mpglib work on a SHARC 32bit DSP,
> > Maybe you could give me some more information about this stuff:
>
> Well, we started working on a branch of mpglib for this dsp. Including
> giving the result as 32bit float instead of converting to integers...
> Not too much changes were needed, actually. There were some bugs that
> arised from the fact that every data type on this dsp was 32 bits wide.
> Well, you can see what happened there via
>
> http://mpg123.de/cgi-bin/viewvc.cgi/mpglib/sharc_dsp/
>
> >
> > > What do this members of the structure mp3data_struct in mpglib.h
> mean:"ssize, dsize, bsize, bsnum"?
> > >
> > > In this structure: Does "framesize","fsizeold" represent the number of
> samples within one mp3 frame (1152 for a Mp3 file, right?) or does it mean
> the length of a frame in bytes?
> > >
>
> These are for the frame data size. The number of of samples is normally
> 1152, but can be 576 or 384 ... that number should be the same throughout a
> file.
> Frame data size depends on the bitrate and can vary for VBR files (which
> consist of frames with differing bitrate values), short:
>
> fr->framesize  = (long) tabsel_123[fr->lsf][2][fr->bitrate_index] *
> 144000;
>
> ;-)
>
> Alrighty then,
>
> Thomas.
>
> --
> Thomas Orgis - Source Mage GNU/Linux Developer
> (http://www.sourcemage.org) OrgisNetzOrganisation ---)=-
> http://orgis.org GPG public key: http://thomas.orgis.org/public_key
> _______________________________________________
> mp3encoder mailing list
> [hidden email]
> https://minnie.tuhs.org/mailman/listinfo/mp3encoder

--
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
_______________________________________________
mp3encoder mailing list
[hidden email]
https://minnie.tuhs.org/mailman/listinfo/mp3encoder
Reply | Threaded
Open this post in threaded view
|

Re: mpglib/mpg123 MP3 Decoding

Jaroslav Lukesh
look at MADplay

JL.

----- Original Message -----
From: "Robert Leiking" <[hidden email]>


>
> Hi Thomas,
>
> is there also a fixed point implementation available from mpglib or
> mpg123??
> Or is this SHARP DSP already in fixed point?
>
> cheers
>
> Robert

_______________________________________________
mp3encoder mailing list
[hidden email]
https://minnie.tuhs.org/mailman/listinfo/mp3encoder
Reply | Threaded
Open this post in threaded view
|

Re: mpglib/mpg123 MP3 Decoding

Thomas Orgis
In reply to this post by Robert Leiking
Am Fri, 02 Mar 2007 18:18:13 +0100
schrieb "Robert Leiking" <[hidden email]>:

>
> Hi Thomas,
>
> is there also a fixed point implementation available from mpglib or mpg123??
> Or is this SHARP DSP already in fixed point?

The SHARC is 32-bit float, we even changed mpglib to skip the conversion to int for that.
There is some code / macros in mpg123 for fixed point but they don't seem to work atm or are not complete.
As I see it you use mpg123 in floating point mode - on an arch without floating point, you use kernel math emulation.
I didn't benchmark how well this performs (yet... I have a 486 and a 386 system to play with - on the 486 mpg123 is clearly faster than mpg321, which uses mad).

So if you want fixed point, you indeed better look into mad, because that's the point they are very proud of: fully fixed point math.
For normal PC cpus, using the floating point math makes more sense - at least with mpg123 it is more efficient.


Alrighty then,

Thomas.
_______________________________________________
mp3encoder mailing list
[hidden email]
https://minnie.tuhs.org/mailman/listinfo/mp3encoder
Reply | Threaded
Open this post in threaded view
|

Re: mpglib/mpg123 MP3 Decoding

Robert Leiking
Hi Thomas,

> There is some code / macros in mpg123 for fixed point but they don't seem
> to work atm or are not complete.

Just because I'm curious about it, which macros do you mean, in which files??

> As I see it you use mpg123 in floating point mode - on an arch without
> floating point, you use kernel math emulation.

The controller has got a floating point unit, but there are library functions, which I want to integrate for optimization, those are designed for fixed point arithmetic. E.g. to replace the inverse DCT part(I assume there's the most workload) would be easier using fixed point parameters. So not every part has to be in fixed point.

> I didn't benchmark how well this performs (yet... I have a 486 and a 386
> system to play with - on the 486 mpg123 is clearly faster than mpg321, which
> uses mad).

So I assume 486 and 386 are fixed point as well, right?

>
> So if you want fixed point, you indeed better look into mad, because
> that's the point they are very proud of: fully fixed point math.
> For normal PC cpus, using the floating point math makes more sense - at
> least with mpg123 it is more efficient.
>

Thanks a lot!

Robert


--
"Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ...
Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out
_______________________________________________
mp3encoder mailing list
[hidden email]
https://minnie.tuhs.org/mailman/listinfo/mp3encoder
Reply | Threaded
Open this post in threaded view
|

Re: mpglib/mpg123 MP3 Decoding

Thomas Orgis
Am Fri, 02 Mar 2007 23:35:27 +0100
schrieb "Robert Leiking" <[hidden email]>:

> Hi Thomas,
>
> > There is some code / macros in mpg123 for fixed point but they don't seem
> > to work atm or are not complete.
>
> Just because I'm curious about it, which macros do you mean, in which files??

grep for REAL_IS_FIXED ... it's not that much, really ... mpg123.h essentially
I didn't work with these in my time as maintainer, I have to admit.

> The controller has got a floating point unit, but there are library functions, which I want to integrate for optimization, those are designed for fixed point arithmetic. E.g. to replace the inverse DCT part(I assume there's the most workload) would be easier using fixed point parameters. So not every part has to be in fixed point.

Well... MMX computes fixed point values in the floating point registers ... so the mmx asm optimization of mpg123 does something like that already.
Look at decode_i386.c, decode_mmx.s and dct64_mmx.s ... best in current svn, since I reorganized the structure of the optmization code.
 
> > I didn't benchmark how well this performs (yet... I have a 486 and a 386
> > system to play with - on the 486 mpg123 is clearly faster than mpg321, which
> > uses mad).
>
> So I assume 486 and 386 are fixed point as well, right?

Yes and no. both machines have a fpu. Questions is if this one is really better than perhaps mad or float emulation.
I've heard from ppl that they played cd quality mp3s on 386DX40 (one said even 386DX25 - but he admits that he is not sure anymore).
Having the fpu on the 386 machine is not common (I bought an extra i387 chip).
On the 486 it's included and seems really to do a better job than fixed point. Out of curiosity I'll test how fast emulated float math is, how this compares to mad and mpg123.

Could be interesting to continue that discussion, but I guess we should take it off the mp3encoder list at some point... mpg123 specific stuff is better at [hidden email] .


Alrighty then,

Thomas.
_______________________________________________
mp3encoder mailing list
[hidden email]
https://minnie.tuhs.org/mailman/listinfo/mp3encoder
Reply | Threaded
Open this post in threaded view
|

fixed point MP3 Decoding

Robert Leiking
In reply to this post by Jaroslav Lukesh

Hi all,

it seems that MAD is only handling fixed point calculations in this format:

 * Fixed-point format: 0xABBBBBBB
 * A == whole part      (sign + 3 bits)
 * B == fractional part (28 bits)

Does anyone know about other fixed point Decoder implementations in the 1(sign).15(fractional) or 1.31 format???

cheers

Robert



> look at MADplay
>
> JL.
>
> ----- Original Message -----
> From: "Robert Leiking" <[hidden email]>
>
>
> >
> > Hi Thomas,
> >
> > is there also a fixed point implementation available from mpglib or
> > mpg123??
> > Or is this SHARP DSP already in fixed point?
> >
> > cheers
> >
> > Robert
>
> _______________________________________________
> mp3encoder mailing list
> [hidden email]
> https://minnie.tuhs.org/mailman/listinfo/mp3encoder

--
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
_______________________________________________
mp3encoder mailing list
[hidden email]
https://minnie.tuhs.org/mailman/listinfo/mp3encoder
Reply | Threaded
Open this post in threaded view
|

Re: fixed point MP3 Decoding

Richard-204
thought I would ask the state of mp3 encoding,
since Microsoft is being sued for 1.5 Billion for using the .mp3
in Vista.

is this the sign of the times that closed source compression is dead,
and open source is in?

Thanks -
Rick


On 3/4/07, Robert Leiking <[hidden email]> wrote:

>
>
> Hi all,
>
> it seems that MAD is only handling fixed point calculations in this
> format:
>
> * Fixed-point format: 0xABBBBBBB
> * A == whole part      (sign + 3 bits)
> * B == fractional part (28 bits)
>
> Does anyone know about other fixed point Decoder implementations in the
> 1(sign).15(fractional) or 1.31 format???
>
> cheers
>
> Robert
>
>
>
> > look at MADplay
> >
> > JL.
> >
> > ----- Original Message -----
> > From: "Robert Leiking" <[hidden email]>
> >
> >
> > >
> > > Hi Thomas,
> > >
> > > is there also a fixed point implementation available from mpglib or
> > > mpg123??
> > > Or is this SHARP DSP already in fixed point?
> > >
> > > cheers
> > >
> > > Robert
> >
> > _______________________________________________
> > mp3encoder mailing list
> > [hidden email]
> > https://minnie.tuhs.org/mailman/listinfo/mp3encoder
>
> --
> Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
> Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
> _______________________________________________
> mp3encoder mailing list
> [hidden email]
> https://minnie.tuhs.org/mailman/listinfo/mp3encoder
>
_______________________________________________
mp3encoder mailing list
[hidden email]
https://minnie.tuhs.org/mailman/listinfo/mp3encoder
Reply | Threaded
Open this post in threaded view
|

Re: fixed point MP3 Decoding

Thomas Orgis
Am Tue, 6 Mar 2007 16:59:16 -0500
schrieb "Richard Nagle" <[hidden email]>:

> thought I would ask the state of mp3 encoding,
> since Microsoft is being sued for 1.5 Billion for using the .mp3
> in Vista.

IMHO that hasn't about vista but the windows systems sold in the past up to now which include mp3 tech.

> is this the sign of the times that closed source compression is dead,
> and open source is in?

Nothing to do with that. It doesn't matter if it's open or closed source compression.
You apparently have to watch out for two patent holders now on getting your usage licensed.
Thomson allows free-of-charge open source mp3 technology, but I wonder what Alcatel is after there.
Though I don't see lame in danger - there 's no money. They'd more likely sue every company out there that made some fortune with mp3.

The sign I see is that US laws/courts are nuts. 0.5% of the value of every Windows PC sold (not only Windows, the whole box!).
Alcatel and Thomson should fight a bit about who now is to ask about mp3 but I don't think Alcatel wants any testing there as long as it can milk some companies in US.
Hm, I should be careful for ranting here... but a positive sign I see is that Microsoft says that software patents are not good:-)

I for sure do not see my personal usage of mp3 technology affected.


Thomas.
_______________________________________________
mp3encoder mailing list
[hidden email]
https://minnie.tuhs.org/mailman/listinfo/mp3encoder
Reply | Threaded
Open this post in threaded view
|

DCT64

Robert Leiking
In reply to this post by Thomas Orgis
Hi all,

I just have a few questions regarding the discrete cosine transform in dct64.c as I want to rewrite it on assembly level:

- Which method was used to decompose the transform into smaller steps? Is this version regarded as the most efficient approach?

- Has someone got a fancy signal flow graph of it? Or anything similar?

- My assumption is that it synthesises from 32 subband frequency samples into the 32 time domain samples, right?
So why is it called dct"64" then?

Thanks!

Robert



--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
_______________________________________________
mp3encoder mailing list
[hidden email]
https://minnie.tuhs.org/mailman/listinfo/mp3encoder
Reply | Threaded
Open this post in threaded view
|

Re: DCT64

Guillaume POIRIER
Hi,

On 3/29/07, Robert Leiking <[hidden email]> wrote:
> Hi all,
>
> I just have a few questions regarding the discrete cosine transform in dct64.c as I want to rewrite it on assembly level:


You should check and compare Lame's dct64 code with the one on MPlayer's mp3lib.
There already are some implementation in SSE, MMX, Altivec, etc...

check them out here: http://svn.mplayerhq.hu/mplayer/trunk/mp3lib/

Guillaume
--
Rich, you're forgetting one thing here: *everybody* except you is
stupid.
    Måns Rullgård
_______________________________________________
mp3encoder mailing list
[hidden email]
https://minnie.tuhs.org/mailman/listinfo/mp3encoder
Reply | Threaded
Open this post in threaded view
|

Re: DCT64

Robert Leiking

Hi Guillaume,


> You should check and compare Lame's dct64 code with the one on MPlayer's
> mp3lib.
> There already are some implementation in SSE, MMX, Altivec, etc...
>
> check them out here: http://svn.mplayerhq.hu/mplayer/trunk/mp3lib/
>

Thanks for that hint, I assume that these are slightly modified versions of the assembler versions in the mpg123 lib, right?

cheers

Robert


--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
_______________________________________________
mp3encoder mailing list
[hidden email]
https://minnie.tuhs.org/mailman/listinfo/mp3encoder