Congrats for the new release.

After at least three years I played again with mpc. Besides confirming that this Musepack version encodes and decodes faster than ogg (ogg2.83-aoTuVb5), aac (Nero Digital™ Audio+ 1.1.34.2) and mp3 (lame3.98b5) by at least 20% (Intel Core2Duo at 3 GHz) I have compared mentioned encoders at bitrates around 130-135 kbps (q 0.4 and -V4 -V5) using 4 albums of pop and disco genre.

aac -> not abx-able
ogg -> nearly never abx-able
lame -V4 -V5 and mpc Beta 1.16 (SV8) -> often abx-able

I'm impressed by aac, but if you don't pay much attention when listening, all encoded music in this bitrange sound terrific.

Question: has mpc room for tuning in the 128 kbps range?

Since when is Lame -V4 in the 130 k range ??
I average around 160 k with 20 GB collection.

You're right, I was talking about -V5 and have corrected it in my post. The -V4 average I have is 156 kbps (50 GB mp3 encoded from lossless with lame3.98b5).

On my Core Duo (Yonah), mppenc SV8 encodes at 17x while the SSE3MT Lancer build of aoTuVb5 encodes at 40x.

But no other familiar lossy codec beats Musepack at decoding, it's the only one that does 200+x on my setup.

Something's not right with that 17x number. Even I get 26.5x on my Athlon64 3500+

Can you test your processor with Lancer Vorbis SSE3MT? It may simply be due to architectural differences. My Yonah's a 1.8 GHz and I'm using a laptop.

Dual core CPUs are known to be much slower then single cores when you use programs which are not optimized for multithreading.

Test result:
mpcenc --quality 7: 26.52x (exact number)
lancer SSE3MT -q 7: 27,95x (rounded up)

(Note that I have a single core Athlon64.)

Haha, I've been spoilt silly by Lancer SSE3MT. Musepack is really THE speed king, though I still want a SSE3MT version of mppenc!

This should get a TOS8 warning, somehow.

What does this have to do with sound quality?

My own tests:

HARDWARE SETTINGS:
• Intel Core2Duo E6300
• MSI-7318 motherboard
• 2x512 MB DDR (533 Mhz?)
• 320 GB HDD, partitioned and defragmented

SOFTWARE SETTINGS:
• test file : 9:58.933 (26412960 samples)
• encoding GUI & speed values: foobar2000 0.9.4.5b
• encoders: see complete log files for information


NOTE:
The test is restricted to the encoders I already have on my harddrive. Three different categories of settings:
- portable bitrate (~130 kbps)
- ultra-high lossy bitrate (~320 kbps)
- lossless (only WavPack & FLAC)

I performed three encodings for each setting and I kept the fastest one.

Most important: these results applies for one single file encoding. One core is used (excepted for Vorbis LANCER, which is the only multithreaded audio encoder available).

RESULTS:



MPC is slightly faster (7...15%) than Nero AAC and LAME, but much more slower than Vorbis (up to 3 time faster), Fraunhofer MP3 (4.66x faster at high bitrate), WavPack lossy (~3x faster) - and abysmally slower than true audiophile (lossless) encoder (up to ~9x slower).

In other words LAME, Nero Digital and MPC's are more comparable to turtles than rabbits. Musepack is in 2007 anything but a fast encoder¹ (unlike in 2001, golden age of the format) but is indeed less slow -consolation- than two big competitors


...Yes, in the kingdom of turtles and snails



Anyway, congrats to the MPC developers - though SV8 only adds some fundamental stuff (seeking, possible video muxing) other formats got for a decade.


N.B. information about encoders'version & settings used in my test here


___
¹: as already shown in the amazing test performed by Nyaochi.

Just a reminder, guys. The current SV8 encoder doesn't use any ASM optimizations. Speed isn't the top priority (yet). We'll have to wait until the optimizations are implemented. Right now the encoder is plain C. Comparing it to Lancer, which is optimized to hell and back, is not quite fair .

I made and published this table/test in order to break the neck to some wrong statements about SV8's position in speed hierarchy (see some messages above).
We will see in the future how much speed mpcenc will gain with optimisations.

I don't see anything unfair with it, if a person making decisions due to speed (which IMO is quite superficial) has to decide NOW. Most of us don't decide on that basis anyway, or we'd be using the Gogo(?) version of LAME instead of the latest one.

My use of SV8 will be limited to the SV7 to SV8 conversion process. I'm encoding new CDs to TAK nowadays.


Well, I'm sorry, I have my own informal results which conclude like yours, but since they are informal, I'll trust someone else's especially if their explanation for their results are convincing. It just so happens that they have a pro-Musepack agenda, perhaps?

I always thought MPC decoding speed was the advantage over MP3 and Vorbis

It is one advantage - probably the last remaining one over LAME and Vorbis.

That's only true if you compare a slow dual core Pentium D against a faster single core Pentium 4. Core 2 Duo will beat a single core Pentium 4 in pretty much any computation, regardless of whether it's optimized for multi-threading or not.

You could say that a Core 2 Duo beats a Pentium 4 left-handed, i.e. using only one core

I took some time to write down speed measurements to backup my statements in the starting posts after reading guruboolez measurements and comments.

CPU Intel E6600 at 3.0 GHz with FSB at 334 GHz on Asus P5B motherboard
RAM DDR2 at 833 GHz

flac v1.2.0
lame3.98b5
ogg2.83-aoTuVb5
Nero Digital™ Audio+ 1.1.34.2
Musepack-SV8-beta

Test file is a single wavfile made of 4 pop albums: 3:22:53.943 (536870900 samples) 2.753.241.836 bytes
En- and decoding were done from the commandline. Speed- and timemeasurements were copied when coder displayed these information, if not I used a stopwatch to measure encoding time (Nero and FLAC). I know, a bit primitive! Tests were done twice and afterwards I eliminated the slowest measurements.

Source files are on a WD5000AAKS and resulting files are written to an other WD5000AAKS hard disk. OS Windows XP is on an other drive and both WD hard drives had no activity other then that caused by the encoding or decoding process. I wanted to ensure maximum hard disk speeds (especially flac speeds can decrease a lot caused by other disk activity).


The decoding speed of mpc is impressive. Maybe that's the reason why they say batterylife of Rockbox firmware is longer with mpc then with mp3 or ogg.

x49 decoding speed for MP3 on a C2D E6600?! My Duron 800 used to decode MP3 faster.
What OS are you running? If you're on a Win32 platform I strongly suggest to use foobar2000's "decoding speed test" embedded tool rather than a stopwatch. My C2D E6300 just measure LAME -V5 decoding at 175x.

I run WinXP SP2 up-to-date. I didn't know about the mentioned optional plugin. I installed it and got this:


Compared with my results measured with commandline encoding flac and mpc show lower decoding speeds (mpc still being the winner) but mp3, aac and ogg are significantly higher. This is strange, I will look into it in a few days. An explanation will be hard to find I suppose.

And: measuring with a stopwatch isn't the point because tenths of seconds or even a deviation of two seconds doesn't differ too much the result (and I'm not drunk or whatever )

You'd be suprised if you try Lancer build of oggdec. Don't forget to set -t option for benchmark.

Try Timer for measuring encoding and decoding time. Process Time is relevant value.

Decoding speed test:

mpcdec v0.9.0 - 201.155 x
oggdec 1.9.3 Lancer SSE - 152.969 x

Processor: AMD Sempron 2200+