mpg123-devel

[mpg123-devel] Heads up

[Thomas O. <tho...@or...>]

Hi,

just wanting to say that I'm not entirely dead and still intend to get
mpg132 1.16.0 out. I wanted to hack in the build system switch to allow
K6 users to skip on suboptimal dxt36 (runtime switching is perhaps just
to much needless work and testing), but stumbled over an old patch for
APIC support instead. So, you can extract album art via libmpg123 now
(see MPG123_PICTURE and the list of
http://mpg123.orgis.org/api/structmpg123__picture.shtml in
http://mpg123.orgis.org/api/structmpg123__id3v2.shtml).

That might be interesting for fancy jukebox applications that are too
lazy to use proper tag libraries. Since clearly not every one needs
this, the picture parsing must be enabled explicitly. There is
mpg123-id3dump now, which is an extension of
http://mpg123.orgis.org/api/id3dump_8c.shtml and also can write album
art to files.

This new program is not part of the Windows builds (the packages
created by the build script); it needs adaption to support unicode file
names, at least, on that platform. JonY: you feel like fixing it up and
at the same time collect the code you would duplicate from mpg123.c in
a common spot? All those define checks really have gotten ugly, no need
to have them twice:-/

Any other last words befor 1.16.0? I really want this performance boost
out there.


Alrighty then,

Thomas

Re: [mpg123-devel] Heads up

[JonY <jo...@us...>]

On 9/16/2013 10:37, Thomas Orgis wrote:
> Hi,
> 
> just wanting to say that I'm not entirely dead and still intend to get
> mpg132 1.16.0 out. I wanted to hack in the build system switch to allow
> K6 users to skip on suboptimal dxt36 (runtime switching is perhaps just
> to much needless work and testing), but stumbled over an old patch for
> APIC support instead. So, you can extract album art via libmpg123 now
> (see MPG123_PICTURE and the list of
> http://mpg123.orgis.org/api/structmpg123__picture.shtml in
> http://mpg123.orgis.org/api/structmpg123__id3v2.shtml).
> 
> That might be interesting for fancy jukebox applications that are too
> lazy to use proper tag libraries. Since clearly not every one needs
> this, the picture parsing must be enabled explicitly. There is
> mpg123-id3dump now, which is an extension of
> http://mpg123.orgis.org/api/id3dump_8c.shtml and also can write album
> art to files.
> 
> This new program is not part of the Windows builds (the packages
> created by the build script); it needs adaption to support unicode file
> names, at least, on that platform. JonY: you feel like fixing it up and
> at the same time collect the code you would duplicate from mpg123.c in
> a common spot? All those define checks really have gotten ugly, no need
> to have them twice:-/
> 

Sure, will take a look at it, does it have to go in for the 1.16 release?

> Any other last words befor 1.16.0? I really want this performance boost
> out there.
> 

Btw, ffmp3float clocked in at 7.6s average while mpg123 at 7.2 average
on a 20+ minute mp3. Tested on an Core-i7 Windows machine with the mpv
player.

Re: [mpg123-devel] Heads up

[Thomas O. <tho...@or...>]

Am Mon, 16 Sep 2013 11:13:29 +0800
schrieb JonY <jo...@us...>: 

> Sure, will take a look at it, does it have to go in for the 1.16 release?

Well, this depends on you. It's there for UNIX and built normally, but
I did not add it to the windows-build.sh. So it's not part of the
binaries you'll provide. Once we got around fixing it up, it can go
fully public for Windows, too, at any later time.

> Btw, ffmp3float clocked in at 7.6s average while mpg123 at 7.2 average
> on a 20+ minute mp3. Tested on an Core-i7 Windows machine with the mpv
> player.

Nice! This is a definite advantage, while at the same time being
testament to both mpg123 and ffmpeg being quite optimized. 5% may not
be noticeable much to users, but it is to me;-) What was the comparison
with 1.15.4?


Alrighty then,

Thomas

Re: [mpg123-devel] Heads up

[JonY <jo...@us...>]

On 9/16/2013 17:05, Thomas Orgis wrote:
> Am Mon, 16 Sep 2013 11:13:29 +0800
> schrieb JonY: 
> 
>> Sure, will take a look at it, does it have to go in for the 1.16 release?
> 
> Well, this depends on you. It's there for UNIX and built normally, but
> I did not add it to the windows-build.sh. So it's not part of the
> binaries you'll provide. Once we got around fixing it up, it can go
> fully public for Windows, too, at any later time.
> 

OK, I've made it use unicode argc/argv, but I have yet to test if it
actually works. The printfs strewn about might be hard to deal with.

>> Btw, ffmp3float clocked in at 7.6s average while mpg123 at 7.2 average
>> on a 20+ minute mp3. Tested on an Core-i7 Windows machine with the mpv
>> player.
> 
> Nice! This is a definite advantage, while at the same time being
> testament to both mpg123 and ffmpeg being quite optimized. 5% may not
> be noticeable much to users, but it is to me;-) What was the comparison
> with 1.15.4?
> 
> 
> Alrighty then,
> 
> Thomas

Retested today:
mpg123-1.16.0  7.5s
mpg123-1.15.4 10.5s
ffmp3float     9.2s
ffmp3         11.4s

Not sure what changed, but these were today's 3-run average figure on
the same file.

Re: [mpg123-devel] Heads up

[Thomas O. <tho...@or...>]

Am Mon, 16 Sep 2013 19:24:52 +0800
schrieb JonY <jo...@us...>: 

> OK, I've made it use unicode argc/argv, but I have yet to test if it
> actually works. The printfs strewn about might be hard to deal with.

Note that I also took the cheap route to just tell that the program
dumps text in UTF-8, regardless of locale. Won't that also work on
Windows? Would conversion be needed?

Also, when it's tested, it should be added to the windows-build script.

> Retested today:
> mpg123-1.16.0  7.5s
> mpg123-1.15.4 10.5s
> ffmp3float     9.2s
> ffmp3         11.4s

> Not sure what changed, but these were today's 3-run average figure on
> the same file.

Well, as long as the numbers look right;-) Seriously, I'll see to it to
at least have comparisons on Core2 and K10, maybe I'm able to dig out
K7, too, but no promises. I'd rather focus on the release; and perhaps
at least running the build on a K6 to verify selection of dct36.


Alrighty then,

Thomas

Re: [mpg123-devel] Heads up

[Thomas O. <tho...@or...>]

Am Mon, 16 Sep 2013 04:37:44 +0200
schrieb Thomas Orgis <tho...@or...>: 

> Hi,
> 
> just wanting to say that I'm not entirely dead and still intend to get
> mpg132 1.16.0 out. I wanted to hack in the build system switch to allow
> K6 users to skip on suboptimal dxt36

The other way round, dammit ... _disable_ them on K7 cores, enable on
K6. Well, it's all the same: Guessing from CPUID is possibly
error-prone; let's stay with disabled dct36_3dnow(ext) by default and
have a configure switch to enable it.


Alritghty then,

Thomas