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: No More MPC? (Read 92722 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

No More MPC?

Reply #50

The vorbis lancer encoders are faster, Wavpack encoder is faster, Dualstream encoder is faster.


True, the encoders may be faster, but decoding takes longer/more power. MP3 may be okay (though slower than mpc), but Vorbis and OptimFrog are very ressource hungry or, said differently, need a lot of time to decode.

So mpc has still something very good. It's blazingly fast decoded (faster than mp3 ) and has quite good quality.



MPC is very fast only on a PC and shows no decoding speed advantages on h/w devices. Vorbis has a memory issue only on limited power h/w devices and no problems on PC. mpc / mp3 / vorbis all decode very fast on PC. Wavpack high & optimfrog fast mode also perform quite good on modern PC's. So again: little advantage on a modern PC and no advantage outside a PC.

No More MPC?

Reply #51
.. they happily use 280k mpc. Can they abx 280k dualstream..

That forum was certainly not this one. As such claims without proof are not tolerated here, so you bring in arguments not from this thread.
Personally I believe Musepack is a good choice for bit rates around 200 kbs(or lower), and that hybrid codecs are a good choice when you aim for 300+.

I also think this is a bit of a dead subject. Nothing to get worked up about. Those who use Musepack do so because it suited their needs years ago, and they haven't found it necessary to switch (completely) yet. So what?
In theory, there is no difference between theory and practice. In practice there is.

No More MPC?

Reply #52
For me the next stage of coding (at present time I'm using Musepack without problems, but not only it one) will be lossless - no headache while choising the best lossy codec. Just no lossy at all. Let my ears choose which sound details are listenable and which are not.   

I just love Musepack.

No More MPC?

Reply #53
Well, IMO, as I once said in a posting (which I fail to find again), why encode in higher bitrate if with lower bitrate I already get transparency? If you're paranoid about transparency, then go lossless. That said, I decide to delve into low-bitrate-friendly codec. Esp. those that are supported in iPaq 2210 (with 3rd party player, if need be). Which is why I end up with Vorbis.

I'd rather fit as many songs as possible in my CompactFlash card with acceptable transparency rather than having far fewer, albeit clearly transparent, songs.

That said, I don't want to shove any format down anyone's throat. But let's be fair; like a poster said previously, to each his/her own favorite format.

( Annnnd I think I'm getting my g/f to start liking Vorbis... yay! God bless those OggPlay developers  now her Nokia9300 can play Vorbis goodness  )

No More MPC?

Reply #54
About the seeking issue:

I'm using foobar 0.9.2 and I have a P4@2.4GHz (Hyperthreading)...

When seeking in a long track for example Godspeed You! Black Emperor - [1998 - f# a# oo #03] Providence (29:02) the problem can be reproduced very easily.

I'm counting the seconds by sayin 21... 22... 23... and so on in German. Because saying Ein-und-Zwanzig... Drei-und-Zwanzig... takes almost exactly one second when you say the numbers immediately after each other.

So seeking from the beginning of this song to minute 2 takes less than a second.
...seeking to minute 5 takes about 1 second.
...seeking to minute 10 takes about 2 seconds.
...seeking to minute 15 takes about 3 seconds.
...and so on. Every 5 minutes take my computer 1 second.*

Now image you want to jump to a certain part of a such a long track but you don't know where it is... that's annoying (the "further you progressed in the track" the more annoying). Also I can imagine in some cases it's not possible at all to use seeking productively... FFWDing via remote control on a media center PC equipped with a low powered CPU for example.

*=Btw, it also depends on the content (bitrate?) of the audio file... long periods of silence (extremely low bitrates) will shorten the wait period accordingly.

No More MPC?

Reply #55
[MPC is very fast only on a PC and shows no decoding speed advantages on h/w devices. Vorbis has a memory issue only on limited power h/w devices and no problems on PC. mpc / mp3 / vorbis all decode very fast on PC. Wavpack high & optimfrog fast mode also perform quite good on modern PC's. So again: little advantage on a modern PC and no advantage outside a PC.


Well, you're right that there's no problem on modern hardware. But on my Pentium 166 MMX vorbis takes MUCH higher cpu-usage to decode than mp3 or even mpc does. But normally, you're fully right. I exaggerated a bit, sorry
flac 1.2.1 -8 (archive) | aoTuVb5.7 -q 4 (pc, s1mp3)

No More MPC?

Reply #56
Time for some benchmarking. I love benchmarking.

Code: [Select]
Pearl Jam - Ten (new european version) / Track 11: Release / Length: 543.426 seconds
System: Athlon XP 3200 (MMX, 3DNow+, SSE) - 1GB DDR400 - NForce2

Vorbis encoder:   OggEnc 2.83  Lancer 20060616(SSE) based on aoTuV b4b
Vorbis decoder:   OggDec 1.92  Lancer 20060616(SSE)
musepack encoder: mppenc 1.15v --Alpha--
musepack decoder: mppdec 1.95e 3DNow/SSE
mp3 encoder:      Lame   3.97  beta 2, Dec 22 2005
mp3 decoder:      mpg123 0.59r 1999/Jun/15

format      | enc. speed | dec. speed | dec. speed (fb2k) | bitrate
------------|------------|------------|-------------------|-------------
vorbis      | 37.85x     | 228.81x    | 174.81x           | 125.3
musepack    | 26.05x     | 440.38x    | 289.66x           | 133.9
mp3         | 19.81x     | 175.70x    | 154.81x           | 138.5

Commandlines used for encoding and decoding:
timethis "start /realtime /b /wait oggenc2 -Q -q 4 test.wav -o NUL:"
timethis "start /realtime /b /wait oggdec test.ogg -o > NUL:"
timethis "start /realtime /b /wait mppenc --silent --radio test.wav - > NUL:"
timethis "start /realtime /b /wait mppdec --silent test.mpc /dev/null"
timethis "start /realtime /b /wait lame -V5 --vbr-new --silent test.wav NUL:"
timethis "start /realtime /b /wait mpg123 -w NUL: test.mp3"

Tests were done four times, fastest run counts. Speeds are rounded and computed from track length and time taken as reported by timethis.exe
Spread between runs was small, less than 0.1s.

Decoding speed for Foobar was measured with Foobar2000 0.9.1, 10 passes, no dsp, high priority, buffer in memory.


Vorbis encodes very fast 45% faster than musepack, but musepack is still the king of decoding speed. I really have no idea which MP3 decoder is fastest, so please let me know and i'll add the result. For now it seems that MP3 is quite slow despite it's age and tremendous development effort.

edit: mpg123 result added for mp3 decoding speed, despite being over 7 years old now (!) it outperforms foobar by 13%. Wasn't foobar's decoder based on mpg123 in the first place? Still, there have to be faster encoders out there, right?

I have no experience with the wiki but if anyone wants to add this please be my guest.

My take on Muspack: It's a good format, but i prefer vorbis, because of:
  • Faster encoding
  • Better hardware support
  • Better performance at low bitrates (<128)
I think Vorbis is an all-round winner, decoding performance is not important to me at all because it's all very fast anyway.
Veni Vidi Vorbis.


No More MPC?

Reply #58
@HbG: What about encoding performance at other compression levels? E.g. Lancer at -q 6, -q 8, LAME at -V2, -V0, Musepack at --insane, --braindead?

If the results still bear the same tendencies (i.e. same relative performance), I may be tempted to put in the facts in the Lossy page of the wiki

No More MPC?

Reply #59
Moreover:
+ MPC:
+ portable hardware support:
+ Rockbox
+ mobile Phones
+ Ipod
+ laptop, Linux, *NIX etc.
+ no seek problems
+ no problems with transcoding to mp3
++ the stable quality, which makes MPC to an archive quality format behind Lossless, to save space, eg. as backup for Lossless collection on different media.


First, "no seek problems" is a lie, as people have reported here several times. If these reports weren't enough, just look at RockBox - seeking is simply impossible there.

Second, WavPack Lossy has the same "features" (granted, except mobile support), with the bonus that there are really no seeking problems. And the other bonus than the main developer is not madly delusional.

Quote
transcoding from high bitrate lossy-wavpack instead from MPC, might be theoretically with less artefacts, though practically, the lossy-wavpack would not serve a good purpose (for me).


WavPack lossy plays on pretty much the same software players Musepack plays at, and pretty much the same Hardware players. With less issues and more flexibility (seekable, handles multichannel, actively developed, error robust, etc.)

Quote
I achieve transparency with lower bitrate MPC than with higher bitrate wavpack-lossy.


That begs for test results. TOS#8 on you!

Quote
There are no secure stable encoder versions, especially in the high bitrate range, sorry, but a lot of other encoder versions.


As guruboolez proved, MPC is not that secure and stable either. The issue is just that the MPC users around here took the security and stability of the format for granted for too long, as up to some years ago criticizing MPC was a horrid taboo in this forum.

Quote
(But you see also with lame, that it's still not perfect at high bitrates, see the findings of halb27 eg. with 320k und unused bits)


As guru mentioned, that has never been proven.

Quote
This is coherent with often uttered personal opinions at HA, that people cannot ABX or listen the difference between 128k vbr modern format and the original.


Actually that notion only started circulating this place after that test.

Quote
And everybody who is curious, should take the MPC challenge, not only on headphone, but also with speakers...


That's beyond the point. Nobody here is saying MPC sucks quality wise. People are saying it sucks on almost all other accounts.

Quote
So, a discussion about aac/ogg vs. MPC is moot, a dead discussion before starting here.


That makes no sense, we aren't discussing only hardware support either.

The point is, these formats have pros at some point or other. MP3 for compatibility, AAC and Vorbis for quality and features, etc. MPC's pros - speed and quality - are not meaningful compared to the competition's speed and quality anymore.

Well, you're right that there's no problem on modern hardware. But on my Pentium 166 MMX vorbis takes MUCH higher cpu-usage to decode than mp3 or even mpc does. But normally, you're fully right. I exaggerated a bit, sorry


I'd like to hear about your experience seeking inside MPCs in that CPU.

No More MPC?

Reply #60
True, the encoders may be faster, but decoding takes longer/more power. MP3 may be okay (though slower than mpc), but Vorbis and OptimFrog are very ressource hungry or, said differently, need a lot of time to decode.

MPC is indeed the fastest format for decoding... on PC. Speed on Mac was reported as much slower. Rockbox people had troubles to ensure real-time MPC decoding whereas other formats (including Vorbis) was more hardware friendly.

Interested fact: according to Frank Klemm, MPC fast decoding speed depends on a patented technology (that could be removed without breaking the format).
Source (2002): http://www.hydrogenaudio.org/forums/index.php?showtopic=2910
Quote
*Philips subband patent can be removed, but
- this would significantly increase CPU load of decoder
- increase significantly latency

No More MPC?

Reply #61
QUOTE
(But you see also with lame, that it's still not perfect at high bitrates, see the findings of halb27 eg. with 320k und unused bits)

Roberto:
As guru mentioned, that has never been proven.


You are wrong?! What's to prove with something like mp3-packer?
I don#t have in mind halb27's various commandlines of various lame encoders,
I think about his findings, when he packed the results of the various encoders (at 320k cbr) with that tool, and certain more modern encoders don't use full 320k obviously.

No More MPC?

Reply #62
You are wrong?! What's to prove with something like mp3-packer?

That CBR 320 encodings are sometimes using padded datas, and that VBR encoding don't. We all know that CBR encodings is unefficient: it's the case for all MP3 encoders, and I wouldn't be surprised to see a Vorbis or AAC repacker saving some bits in the same conditions.
Moreover, the reported issue is not related to quality. On the contrary, I've ABXed in the past MPC up to --insane with quiet samples which were encoded with abnormaly low bitrate.

http://www.hydrogenaudio.org/forums/index....topic=35030&hl=
http://musepack.net/forum/viewtopic.php?p=913#913

This quality issue is much more worrying IMO than issues that have no audible impact.
N.B. for people like the current musepack "developers" who don't trust my own findings, I found a post of Frank Klemm confirming what I experienced myself while testing different encoders:
http://www.hydrogenaudio.org/forums/index....indpost&p=19198


Quote
Originally posted by NickSD


What sorts of quality problems do you think there would be?  Is it likely that only q values less than 5 would have such problems?


--quality 0...7

Problems with HF precision, ringing, stereo imaging and much much more.
Problem with very silent music.
--
Frank Klemm

emphasis is mine.

For ringing, the 1.15v encoder has worsen the issue (at least with standard: see this test). Problem reported one year ago, and the "still-living" MPC encoder hasn't improved since

No More MPC?

Reply #63
So seeking from the beginning of this song to minute 2 takes less than a second.
...seeking to minute 5 takes about 1 second.
...seeking to minute 10 takes about 2 seconds.
...seeking to minute 15 takes about 3 seconds.
...and so on. Every 5 minutes take my computer 1 second.*

I don't know the precise times, but here I listen to symphonies, some with movements > 60 Minutes. Doing a fast forward from 0 to 30 Minutes would let me wait 30 seconds or more I guess. I'm not sure if I am exaggerating (cannot test now), but it was really painful.

No More MPC?

Reply #64
Slow seeking with long tracks is well-known. It's why Citay said "the seek times for single tracks are ok". Single-file CD, or very long tracks (like Bruckner/Celibidache symphonic movement  ) MPC-encoded are very, very slow. With short files, seeking is not immediate, clearly slow compared to other formats, but not too worrying. When I used MPC as main format, I was used to live with that slow seeking; nowadays I find it annoying (and unbearable with long tracks). It's probably a matter of habit.

No More MPC?

Reply #65
For exact seeking in MPC you need to actually partially decode the stream from the beginning because without decoding you don't know how large a frame is and where the next one starts (no synchronization/sync pattern or anything -- hell, frames don't even start on a byte boundary IIRC! It's the very definition of "packed raw")

Clearly, apart from painfully slow seeking this design is highly prone to errors (one flipped bit might get you out of sync in a way that you can't recover for the complete remaining data due to VLC codes -- you think you just read a 4 bit code but it was supposed to be a 5-bit code, just with an error -- so you'll be one bit off sync and everything that comes is garbage to you)

However, there's a benefit, too: slightly less overhead

I wonder why no one of the MPC lovers has bothered to hack a MPC-in-ogg solution or at least gave MPC some simple/proper container-thingy. Come to think of it: Matroska anyone? It's gotta be possible -- you may need to transform the MPC data to byte-align frames, though.

Sebastian

No More MPC?

Reply #66
Quote
hell, frames don't even start on a byte boundary


Ouch... very bad design I must say.  Almost like "designed for fixed-media storage and one-time full decoding"

No More MPC?

Reply #67
I wonder why no one of the MPC lovers has bothered to hack a MPC-in-ogg solution or at least gave MPC some simple/proper container-thingy.


I think there is MPC-in-mka. But it's not supported anywhere but in foobar2000 and a few other players.

No More MPC?

Reply #68
No there is not. And the horrible structure of MPC was the reason for this.
"We cannot win against obsession. They care, we don't. They win."

No More MPC?

Reply #69
I think there is MPC-in-mka. But it's not supported anywhere but in foobar2000.

OH! I was under the impression that the mpc-in-mka status is still something like "can't be done"

Sebi

No More MPC?

Reply #70
No there is not. And the horrible structure of MPC was the reason for this.


Oh, my bad. Sorry

Anyway, what makes me wonder is that Andree started from a format with a good and stable stream specification - MP2. Why he removed these features, like fixed block sizes?

No More MPC?

Reply #71
Quite a long time ago I asked Matroska developers to implement MPC support. They said it's not possible with current bitstream. It is more then a year and MPC hasn't changed since then.

Btw. do you know something about Speex in MKA?

No More MPC?

Reply #72
MPC is pretty dead, it is only usefull to those who want to use (above) braindead for transparancy and can't afford lossless. It's a shame that all (?) lossy codecs focus on low bitrate transparancy on (avarage?) portables and the likes. I am not artifact trained and i must say that on a random sample i can't abx lame -V 2 (for example) from lossless, but i still stick to lossless for safety. Vorbis (128 kbps or higher) can be nice for radio streaming, but that's about it as far as i can see. Lossless is not extremely big and with proper ripping there is never the need to worry about quality (compated to the source, the source can still be (very) bad).

No More MPC?

Reply #73
Time for some benchmarking. I love benchmarking.

[...]

Vorbis encodes very fast 45% faster than musepack, but musepack is still the king of decoding speed. I really have no idea which MP3 decoder is fastest, so please let me know and i'll add the result. For now it seems that MP3 is quite slow despite it's age and tremendous development effort.

edit: mpg123 result added for mp3 decoding speed, despite being over 7 years old now (!) it outperforms foobar by 13%. Wasn't foobar's decoder based on mpg123 in the first place? Still, there have to be faster encoders out there, right?

I have no experience with the wiki but if anyone wants to add this please be my guest.

My take on Muspack: It's a good format, but i prefer vorbis, because of:
  • Faster encoding
  • Better hardware support
  • Better performance at low bitrates (<128)
I think Vorbis is an all-round winner, decoding performance is not important to me at all because it's all very fast anyway.


Sorry, I just checked and indeed Vorbis decodes faster today with foobar2000 than mp3 on this old Pentium. I should have re-checked before claiming it's slow, because some years ago it really was decoding slower than mp3. Seems like a lot of optimization was done in the last time 

And @rjamorin: Yes, seeking mpc really takes very long on this old machine. Even 3 minutes takes some seconds to complete 
But if one doesn't need to seek very much in-file(Like me, either I hear the track from the beginning to the end or skip to the next one), then he might be very happy with mpc on slow, outdated hardware.
flac 1.2.1 -8 (archive) | aoTuVb5.7 -q 4 (pc, s1mp3)

No More MPC?

Reply #74
Come to think of it: Matroska anyone? It's gotta be possible -- you may need to transform the MPC data to byte-align frames, though.

To make that possible was the main (new) thing that would be worked on when Frank was re-contacted. It would be called Stream Version 7.5 or something. The almost designed SV8 (that would have fixed this and probably seeking) seems canceled. And that's what we mean, there is no development (though maybe some porting and little bug fixing was done).
In theory, there is no difference between theory and practice. In practice there is.