Musepack Forums

Musepack Forums (
-   MPC for UNIX (
-   -   mppenc 1.16 slower? maybe it's my compiler (

nospaulatu 21 January 2007 07:41 pm

mppenc 1.16 slower? maybe it's my compiler
hey folks. i was glad to hear there's a new mppenc out. i was hoping for a binary, like previous releases, but i went ahead and compiled it.

i finally got around to using it today, and it seems the encoding speed is pretty slow. I'm currently running at around 7x, where normally with 1.15 i'd be getting 22x. not that it makes much difference, since i'm ripping and encoding at the same time, but it still worries me.

i noticed 1.15 uses nasm to compile and 1.16 doesn't.

i'm running Arch Linux, which is a bleeding edge i686 distro. i have cmake 2.4.5, gcc 4.1.2, automake 1.10, autoconf 2.61, nasm 0.98.39 ... that's all i could think of that is relevant.

anyway, so i'm hoping to see people reporting their 1.15 vs 1.16 speeds (i'm assuming no slowdown, since somebody else would have complained by now), and hopefully a statically linked binary. or maybe instructions on how to extract a deb package, since they have binaries.


nospaulatu 21 January 2007 07:53 pm

don't you hate when people post without doing some research first?

well, i extracted the rarewares deb package, and yes, it encodes faster.

so then something about my compiler is producing slower builds than what you guys are using, that wasn't there in 1.15.

xmixahlx 21 January 2007 11:12 pm

the difference is compiler flags... try using -O3 -ffast-math


nospaulatu 26 January 2007 08:24 pm


Originally Posted by xmixahlx (Post 1470)
the difference is compiler flags... try using -O3 -ffast-math

hmm that hasn't improved things. am i doing it wrong?

make clean
CFLAGS="-O3 -ffast-math" make

i also tried exporting CFLAGS first, then running make. same results.

Lefungus 27 January 2007 12:50 pm

I only got those awful speeds when using a debug binary. Anyway, it's entirely dependent on your CFLAGS. You can gain a bit by tweaking it, or crippling it.
mppenc-1.16 *should* use correct cflags by default (they're no the best for your arch but should work ok on most cpu).
Since you're using arch linux, please post the PKGBUILD you're using.

About nasm, it's not used in 1.16 because as far as I'm aware:
- It's 3dnow code only
- It has been disabled for ages in previous mppenc versions

nospaulatu 29 January 2007 08:01 am

actually, i don't have a PKGBUILD as i simply tried building mppenc to see how it performed (i wanted to see how the new fast seeking compared between 1.15 and 1.16 on a 30-minute recording)

i used the default cflags at first, then tried specifying the ones xmix recommended.
lefungus, you're an arch user, right? i think i've seen you on the forums there (i'm known as paranoos usually). you've compiled mppenc on an arch system, and it ran full speed? i haven't done anything strange (to my knowledge!), so i can't understand it. especially considering i can compile 1.15 and it works fine.

Lefungus 29 January 2007 06:18 pm

I used arch a few years ago, I tried to reinstall it this week end, but all their iso refuse to boot on my computer, probably due too an incompatibility with my motherboard.

What you can try is setting
in CMakeLists.txt
and attach the log somewhere here

nospaulatu 30 January 2007 05:40 am

alright, here's the log.
(hmm... the file doesn't appear on the list below. the file is stored here. hopefully that works.)

Lefungus 30 January 2007 07:12 pm

It's not the log I want :)
Try, with the modified CMakeLists.txt

"make clean && cmake . && make > output.log 2>&1"

and post output.log somewhere

nospaulatu 01 February 2007 06:29 am

whoops :)

here's a paste of the output

nospaulatu 01 February 2007 06:36 am


it appears that trying to run make inside the mppenc-1.16 directory yields good results, while running make while in the src subdirectory results in the slow build i was experiencing earlier.

strange! well, thanks anyway!

All times are GMT. The time now is 06:24 am.

Powered by vBulletin® Version 3.8.11 Beta 2
Copyright ©2000 - 2021, vBulletin Solutions Inc.