Hydrogenaudio Forums > No More MPC?

Help - Search - Members - Calendar

Full Version: No More MPC?

Hydrogenaudio Forums > Lossy Audio Compression > MPC

Pages: 1, 2, 3

shadowking

Jun 28 2006, 09:08

QUOTE(gasmann @ Jun 28 2006, 06:54)

QUOTE(shadowking @ Jun 28 2006, 14:32)

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.

GeSomeone

Jun 28 2006, 10:04

QUOTE(shadowking @ Jun 28 2006, 14:32)

.. 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?

Seymour

Jun 28 2006, 10:31

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.

pepoluan

Jun 28 2006, 11:27

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

)

Fandango

Jun 28 2006, 12:56

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.

gasmann

Jun 28 2006, 14:01

QUOTE(shadowking @ Jun 28 2006, 17:08)

[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

HbG

Jun 28 2006, 14:11

Time for some benchmarking. I love benchmarking.

CODE

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.

sony666

Jun 28 2006, 16:11

QUOTE(Squeller @ Jun 27 2006, 19:50)

mpc has ultra slow seeking

This is what killed the format for me, even for PC-only files

pepoluan

Jun 28 2006, 16:31

@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

rjamorim

Jun 28 2006, 16:35

QUOTE(user @ Jun 28 2006, 07:14)

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.

QUOTE(gasmann @ Jun 28 2006, 17:01)

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

guruboolez

Jun 29 2006, 02:29

QUOTE(gasmann @ Jun 28 2006, 16:54)

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

user

Jun 29 2006, 03:57

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.

guruboolez

Jun 29 2006, 04:22

QUOTE(user @ Jun 29 2006, 11:57)

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(Frank Klemm @ Jun 5 2002, 00:20)

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

Squeller

Jun 29 2006, 04:55

QUOTE(Fandango @ Jun 28 2006, 10:56)

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.

guruboolez

Jun 29 2006, 05:20

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.

SebastianG

Jun 29 2006, 05:24

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

Ivan Dimkovic

Jun 29 2006, 05:51

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"

rjamorim

Jun 29 2006, 05:51

QUOTE(SebastianG @ Jun 29 2006, 08:24)

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.

stephanV

Jun 29 2006, 05:54

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

SebastianG

Jun 29 2006, 05:54

QUOTE(rjamorim @ Jun 29 2006, 13:51)

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

rjamorim

Jun 29 2006, 05:57

QUOTE(stephanV @ Jun 29 2006, 08:54)

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?

vlada

Jun 29 2006, 06:28

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?

Madman2003

Jun 29 2006, 11:50

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).

gasmann

Jun 29 2006, 11:55

QUOTE(HbG @ Jun 28 2006, 22:11)

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.

GeSomeone

Jul 1 2006, 16:55

QUOTE(SebastianG @ Jun 29 2006, 13:24)

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).

satorippoi

Jul 1 2006, 18:15

QUOTE

right, but the question remains the same - WHY did they stop the development?..

kurtnoise

Oct 30 2006, 16:09

SV8 is on the way...at least on the r2d branch.

In addition, check out the specs.

xmixahlx

Oct 30 2006, 17:20

shhhhhhhh

Sunhillow

Oct 31 2006, 09:29

QUOTE(xmixahlx @ Oct 31 2006, 01:20)

shhhhhhhh

fear to wake up a comatose patient?

JensRex

Oct 31 2006, 10:00

QUOTE(kurtnoise @ Oct 31 2006, 00:09)

SV8 is on the way...

We've talked about SV8 for a very long time now on HA and it's never going to happen. Move on - MPC is dead.

kurtnoise

Oct 31 2006, 10:21

I move on if *I* want to...

Jebus

Oct 31 2006, 12:25

Well JensRex, there IS development there as of 4 days ago specifically targetting SV8. I'm skeptical too, but there does seem to be some activity.

jido

Nov 3 2006, 11:55

Yep.
http://trac.musepack.net/trac/changeset/81

So SV8 is getting done?

xmixahlx

Nov 3 2006, 12:28

you guys should just sit tight for a few days...

there will be new SV7 releases shortly (mppenc, libmpcdec, xmms-musepack, etc)

SV8 has restarted development

later

skelly831

Nov 3 2006, 21:04

The Sheep of DEATH

Nov 6 2006, 14:25

QUOTE(skelly831 @ Nov 3 2006, 21:04)

I read somewhere at HA that unlike a human being, a software can lay in a state of "temporary death."

But MPC's "death"... yeah, it didn't look temporary.

People said XviD was dead after 1.1 finally came out. But then came a few speed optimizations... And some trellis improvements...and before long, development started on a whole new AVC core, Xvid 2.0 AVC.

So who knows until it's out, eh?

budbrain

Nov 6 2006, 15:07

mpc ftw xDD

sld

Nov 9 2006, 22:12

This is news...

great for people with mpc files, although I guessing a lot will have switched to encoding in another format.

xmixahlx

Nov 12 2006, 14:05

alright, peeps:

here are the SV7 releases - mppenc, libmpcdec, and xmms-musepack on the way:
http://www.hydrogenaudio.org/forums/index....showtopic=50130

later

acedriver

Nov 12 2006, 18:07

thx for the good news

GeSomeone

Nov 13 2006, 07:02

Thanks, for picking up the seeking issue. I had already given up hoping for it

So it seems the stream issue (seeking, Matroska) is addressed now but the encoding/quality stays as it is, am I right?

Firon

Nov 13 2006, 15:41

Yes, the quality is the same. There were a few non-quality related changes though, like some 24-bit bug and reduced memory usage.

user

Dec 4 2006, 13:48

QUOTE(JensRex @ Oct 31 2006, 17:00)

QUOTE(kurtnoise @ Oct 31 2006, 00:09)

SV8 is on the way...

We've talked about SV8 for a very long time now on HA and it's never going to happen. Move on - MPC is dead.

Sorry, that your cat ist dead, according to your avatar 1997 - 2005

chrisbowd

Jan 4 2007, 22:51

This is great news for all of us still using the format.

Is there a way people can support the development?

WaldoMonster

Jan 19 2007, 04:30

Awake from the dead?
SV8 in development and native Nullsoft Musepack decoder:
http://forums.winamp.com/showthread.php?po...684#post2064684
This is great news.

DrO

Jan 30 2007, 12:56

though the in_mpc referenced is just a slight update of the old in_mpc code which was released though i can't remember what was done to it exactly offhand (though i'm sure a lot more work needs to be done to bring it into line with the current mpc sdk code base plus it was only done by the main dev since no one else was interested in doing anything for in_mpc...)

-daz

salpro

Feb 18 2007, 06:33

QUOTE(Andavari @ Jun 27 2006, 18:56)

How can we the end-users call it a dead format? Such claims need to come directly from the Musepack development team for me to even consider such comments as being true, remember CDex had no version released for years - and yet it's alive again. I have over 20 CD-R's full of mpc's, and I'm surely not anytime soon going to re-rip and encode those audio CDs to a different format which in my case would only consist of Ogg Vorbis (aoTuV builds, -q 6), or LAME 3.97b2 (-V2 --vbr-new).

I do realize that there hasn't been a new release for the encoder, decoder, and Winamp plugin in a long time however the format still has advantages and merits:

Gapless. Which has to be one of the most important features without having to result to using high bitrate CBR to preserve quality with a --nogap switch.
Natively supported via foobar2000 out-of-the-box so to say.
Easily supported via Winamp 2x-5x via the easily downloadable plugin from www.musepack.net.
I can't (and I reckon others can't either) tell the difference from an mpc encoded at --quality 5 ("--standard") when compared to Musepack's contenders which are still regularly updated; Ogg Vorbis (-q 6), LAME (-V2 --vbr-new).

This isn't a ploy on my part to say keep using Musepack, although I don't think someone can go wrong in using it.

add another advantage : speed of encoding and decoding

guruboolez

Feb 18 2007, 06:40

...advantage over what? WavPack lossy encodes faster, Vorbis LANCER encodes faster, MP3 Helix encodes faster... only AAC is still slower than MPC.
The decoding speed only matters on portable player. Therefore speed has to be faster on such devices - but is it the case? On computers decoding speed mainly matters for transcoding purpose – and musepack (as well as most lossy formats) is not the most suitable format for such task.

Speed is no longer an advantage for musepack. It's a feature shared by most formats nowadays.

rjamorim

Feb 18 2007, 16:16

QUOTE(Andavari @ Jun 27 2006, 18:56)

How can we the end-users call it a dead format? Such claims need to come directly from the Musepack development team for me to even consider such comments as being true

You won't get NTT to admit VQF is dead. Still, would you claim that the format is alive?

manusate

May 20 2007, 15:50

I for one, no longer encode in mpc. It's been more than 4 years since I encoded an mpc album.

Back in the day when I used it, mpc was perfect for my needs. I listened to my collection basically on a CD player, portable or not. Quality was great, filesize was great, encoding speeds were great, man, those mpcs were sweet.

Plus, as relatively obscure codec, an mpc release on the p2p field was (most of the time) a guarantee that the guy that was sharing his CD knew what he was doing. Most of them were EAC secure rips, and (at least) q5. On the other hand, mp3 releases were incredibly crappy, plagued with bad rips and lousy encoders (Xing, Blade...). Even the LAME encodes were (and still are) CBR 192 most of the time.

But times have changed, and I don't carry around a Discman with a bunch of CDs anymore. I have a DAP nowadays (many in fact, even an iPod), and none of them plays my mpc files. On the other hand, everything plays mp3 now, I wouldn't be surprised if my fridge did.

All my lossy encodes are LAME mp3. It's been like that for quite a long time now.

Enjoy!

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.