Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: mppenc 1.15r now compiling on OSX (Read 10897 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

mppenc 1.15r now compiling on OSX

With the help of Case, I've been able to get access to the MPC sources and have been able to get mppenc compiling on OSX.  After I do a little bit more testing (and cleaning up of the Makefile ) and optimize the compile settings for more speed, I'm hoping to post some binaries for people to use.

I'll be sending the changes back to Frank, so hopefully MPC will be supported in any future versions as well.

For those that are curious, I'm getting 4.5-5.5x with absolutely no optimization settings (as opposed to the x86 builds), no vectorization, no asm, etc.  This is with GCC 3.3 on a powerbook G4 1.3ghz.  I also only tested fatboy and castanets so far which may not be representative.  I'll experiment some with other options and also try compiling with IBM xlc to see how much of a speed increase I can get.

mppenc 1.15r now compiling on OSX

Reply #1 –
Nice, more platform support is always good!

The next (hypothetical) question that comes to my mind (after following the thread about Frank's and Christian's phonecall):

What if Frank decides to not continue working on the sv7 version, or maybe even the sv8 version, or will start some kind of new project, are you going to make a roundup of the 1.15r version (something like a final sv7 version) like was proposed in the phonecall thread? What's your opinion ?

I think it's a good thing that you have access to the sources btw.

mppenc 1.15r now compiling on OSX

Reply #2 –
Nice to see the Macs get some support thrown their way... good to see your still around Dibrom as well. )

Any ideas on how to improve MPC?

Regards

AgentMil
-=MusePack... Living Audio Compression=-

Honda - The Power of Dreams

mppenc 1.15r now compiling on OSX

Reply #3 –
I recall a bug of version 1.15r : The encoded data is taken from the end of the wav header until the end of the file in the source file, which encodes garbages when some additional info is written after the audio part, like with wavs recorded by SoundForge, for example.
It produces audible clicks at the end of the mpc files made from these wavs.
The solution is to take exactly the amount of audio data that is specified at the end of the wav header instead of encoding the whole file.
Version 1.14 doesn't have this problem.

Discussion of the problem : http://www.hydrogenaudio.org/forums/index.php?showtopic=9750

mppenc 1.15r now compiling on OSX

Reply #4 –
A final SV7 version would be nice indeed. It could include the fix proposed by Pio and use --xlevel by default.

dev0
"To understand me, you'll have to swallow a world." Or maybe your words.

mppenc 1.15r now compiling on OSX

Reply #5 –
Quote
What if Frank decides to not continue working on the sv7 version, or maybe even the sv8 version, or will start some kind of new project, are you going to make a roundup of the 1.15r version (something like a final sv7 version) like was proposed in the phonecall thread? What's your opinion ?

I don't think so.  For one, I don't think it is my place to do this -- I was simply interested in seeing mppenc working on osx.  Secondly, I don't have the proper knowledge to offer much in this kind of sense.  I wouldn't feel comfortable proclaiming a "final" version of SV7 simply because I've had no hand in its direct development and know so little about it that it would be a pretty empty proclamation.  I would never do anything like this without contacting Frank anyway, and if he responded, chances are that he'd probably do it himself.

If there is absolutely no chance that Frank will even consider looking at SV7 again, then there might be a possibility that I'd try to help organize (i.e. not do much of the work here myself) an effort to finish things up, but I still wouldn't do this without his permission at least.

mppenc 1.15r now compiling on OSX

Reply #6 –
Quote
good to see your still around Dibrom as well. )


Thanks

Quote
Any ideas on how to improve MPC?


Not really.

This isn't my aim here though for the most part.  I'm not out to make any fundamental changes to mppenc, I just wanted to get it compiling on OSX.  The next thing I'd like to do, which may fall under the "improve MPC" part, is get some altivec routines into the encoder/decoder like there are for 3dnow/SSE.  The performance is pretty lackluster on the G4 right now and it could be made a whole lot faster.

This probably doesn't concern the vast majority of worried MPC users on the board here, but if nothing else, I think it's a step in the right direction and could, at the very least, serve to show Frank that there are still more people who want to see MPC move forward and who are even willing to help out towards this end in the different ways that they are able.

mppenc 1.15r now compiling on OSX

Reply #7 –
Quote
I recall a bug of version 1.15r : The encoded data is taken from the end of the wav header until the end of the file in the source file, which encodes garbages when some additional info is written after the audio part, like with wavs recorded by SoundForge, for example.
It produces audible clicks at the end of the mpc files made from these wavs.
The solution is to take exactly the amount of audio data that is specified at the end of the wav header instead of encoding the whole file.
Version 1.14 doesn't have this problem.

Discussion of the problem : http://www.hydrogenaudio.org/forums/index.php?showtopic=9750

Thanks for the information on this.  I remember seeing this thread but had forgotten about it.

I don't really have the knowledge (or probably the time) to track this down and fix it right now.  Maybe Case has some ideas, or could contact Frank about looking into fixing it.

mppenc 1.15r now compiling on OSX

Reply #8 –
Quote
If there is absolutely no chance that Frank will even consider looking at SV7 again, then there might be a possibility that I'd try to help organize (i.e. not do much of the work here myself) an effort to finish things up, but I still wouldn't do this without his permission at least.

It goes without saying that it will not happen without Frank's permission, that would be rather disrespectful for the work he has done for musepack.

It is just a bit of peace of mind (at least for me) that someone like you is somewhat involved and has access to the source code. I would be rather irritated if mpc in his current state (some alpha version) would die a slow death.

mppenc 1.15r now compiling on OSX

Reply #9 –
What about the player though? Is there any non-console based players for Mac?
The object of mankind lies in its highest individuals.
One must have chaos in oneself to be able to give birth to a dancing star.

mppenc 1.15r now compiling on OSX

Reply #10 –
Quote
What about the player though? Is there any non-console based players for Mac?

I can't think of any off the top of my head, but there might be some.  XMMS would be the first obvious choice, since it should be trivial to get the MPC plugin working with that (might already work now even).

Now that there will be an encoder available, it might also be possible to generate some interest in getting MPC working with the quicktime stuff to where it would be playable through iTunes.

mppenc 1.15r now compiling on OSX

Reply #11 –
OK, here is an initial revision of the mppenc binary:

Edit: See new link below

Despite the ppcv part, the encoder will run on a G4.  Right now I'm getting ~7.2x with a G4 1.3ghz powerbook.  This is compiled with IBM xlc with the best combination of optimization flags that I was able to arrive at.  GCC, similarly configured, gives only around 5-5.5x average speed.

It would be helpful if people could test this out (especially people on G5's) and report your findings.  The binary had to be configured dynamically due to the way OSX is setup, but I tried to remove dependencies for everything that should be problematic.

Just as a warning, I have done very little testing of the output of this compile, so there might be some problems in that regard as well.  I encourage anyone who is able to test this out.

mppenc 1.15r now compiling on OSX

Reply #12 –
I've made a bundle with the optimized xlc mppenc compile, along with regular gcc compiles of mppdec, both one with esd support (depends upon the Fink esound package) and one without.

The mppdec compiles are not optimized with xlc yet because one of the optimization flags I'm using is causing problems and I haven't had time to track down which one yet.  The speed is already decent enough there though and isn't nearly as critical as it is with the encoder.

The mppdec compiles have the endianess issues fixed, so either streaming to esd or writing .wav files will produce proper output, instead of only .aiff working properly.  I've also added support for MacOSX realtime prioritization stuff (the normal mppdec doesn't have support for this on MacOSX and so there's lots of stuttering at times) so that realtime playback via esd does not skip or stutter under load.

The next thing I'd like to look at adding would be native MacOSX audio output support, so that there is no need to depend on esd at all.  I don't know when I'll have time to do this though.

If anyone (rjamorim? Case?) would like to add these binaries to their pages, they are more than welcome to.

mppenc 1.15r now compiling on OSX

Reply #13 –
Quote
Any ideas on how to improve MPC?


gday..

@ Dibrom.

personaly i don`t care much about bitrate/size..
as long a encoder is transparent.

i do wish it would be xx faster.. and i as of now
the last mpc encoder is exelent in micro-dynamics..
(almost perfect..) but on over-compressed music..
it assume a little more work can be done..


mppenc 1.15r now compiling on OSX

Reply #14 –
Quote
If anyone (rjamorim? Case?) would like to add these binaries to their pages, they are more than welcome to.

Here they are:
http://rarewares.hydrogenaudio.org/mpc.html

If you want, Dibrom, feel free to update the binaries and the page yourself whenever you create a new compile.

Regards;

Roberto.

mppenc 1.15r now compiling on OSX

Reply #15 –
It's nice to see that some more "official" MPC binaries than SV7.1 are available. Personally, I don't see much benefit in it. As long as there is no library available, it is highly unlikely that any player - other than XMMS, perhaps - will see support for MPC. But it'll be nice to have lying around

Considering optimisations; you could perhaps take a look at Apple's vecLib. It may be simpler to reuse that than rewrite Frank's code. About XLC; I doubt you'll see any significant improvement over GCC 3.3. Although it's capable of generating AltiVec-optimised code, it's written for the G5, and IIRC tests showed that it was either as fast or slower than GCC 3.3 on other processors.

mppenc 1.15r now compiling on OSX

Reply #16 –
Quote
Considering optimisations; you could perhaps take a look at Apple's vecLib.  It may be simpler to reuse that than rewrite Frank's code.

Thanks for the info.  I've heard about this and a few other possibilities, but I'm not sure how likely I'll be to try and implement the changes necessary to add support for these kinds of things.  We'll see I guess.

Quote
About XLC; I doubt you'll see any significant improvement over GCC 3.3. Although it's capable of generating AltiVec-optimised code, it's written for the G5, and IIRC tests showed that it was either as fast or slower than GCC 3.3 on other processors.


Well I'm already getting ~7-7.2x average with XLC vs 5-5.5x average with GCC.  That's a pretty significant increase, around the same level of increase as using ICL over GCC or MSVC for LAME, and is in line with the numbers I remember seeing for the benefits of using XLC on a G4 (even though it is not stated to support the G4), which were ~50% on average (vs over 100% or more on the G5 IIRC).  I expect the difference to be much more significant on a G5, but unfortunately nobody has gotten back to me on any figures yet.

mppenc 1.15r now compiling on OSX

Reply #17 –
Quote
it is highly unlikely that any player - other than XMMS, perhaps - will see support for MPC


In one of the recent threads ChristianHJW mentioned mplayer is expected to provide MPC support soon on OS X.
The object of mankind lies in its highest individuals.
One must have chaos in oneself to be able to give birth to a dancing star.

mppenc 1.15r now compiling on OSX

Reply #18 –
Quote
Well I'm already getting ~7-7.2x average with XLC vs 5-5.5x average with GCC.  That's a pretty significant increase, around the same level of increase as using ICL over GCC or MSVC for LAME, and is in line with the numbers I remember seeing for the benefits of using XLC on a G4 (even though it is not stated to support the G4), which were ~50% on average (vs over 100% or more on the G5 IIRC).  I expect the difference to be much more significant on a G5, but unfortunately nobody has gotten back to me on any figures yet.

This is very interesting; especially considering I got a slowdown on my G3 from compiling LAME with XLC. It'd be nice to give those binaries a try to see if XLC did generate AltiVec instructions - if it did, the binary shouldn't run on my iMac.

BTW, have you checked if the files generated by the two compiles are identical? IIRC XLC has some warning about strictness at -O3 and above.

mppenc 1.15r now compiling on OSX

Reply #19 –
[deleted]

mppenc 1.15r now compiling on OSX

Reply #20 –
I don't know if you're alloewd to do this, Dibrom, but it would be cool, if you release mppenc as shared library for various plattforms.

mppenc 1.15r now compiling on OSX

Reply #21 –
this is awesome. i get 13.5x encoding on a dual g5 2 gig.

now i just need a way to play them.

mppenc 1.15r now compiling on OSX

Reply #22 –
Quote
this is awesome. i get 13.5x encoding on a dual g5 2 gig.

now i just need a way to play them.

OMG, almost as fast as my 1.6 GHz PC that gets 16x  Get working on the AltiVec optimizations, Dibrom!

mppenc 1.15r now compiling on OSX

Reply #23 –
Quote
OMG, almost as fast as my 1.6 GHz PC that gets 16x   Get working on the AltiVec optimizations, Dibrom!

yeah, but that is infinitely faster than the 0x i was getting on my G5 before this.

mppenc 1.15r now compiling on OSX

Reply #24 –
Hmm, that's OK. Macs have always had crappy hardware because of the lack of competition. G5 is only the processor  I'd bet a dual 2GHz G5 is indeed slower than an Athlon 2GHz on average. BTW G5 Altivec is basically a hack. Apple insisted on Altivec to use it as a buzzword before the switch to IBM, thus IBM is forced to put an hasty hack onto the PowerPC core. And this compile is not yet fully optimized.

But it's cool that mpc encoding is ported to another architecture. I hope the playback comes soon. What happened to mplayer mpc support? ChristianHJW?

I wish it would work on an IA-64 FreeBSD by the time I make the switch.
The object of mankind lies in its highest individuals.
One must have chaos in oneself to be able to give birth to a dancing star.