From what I have gathered in this forum about mp3, I have come to the understanding that mp3 is inferior to mpc because it is more susceptible to artifacts, most notably pre-echo, and this is because of adherance to the ISO specifications, whatever these are.
Am I correct? If I am not, please enlighten me otherwise.
If I am, then I can suggest that the LAME developers create an encoder optimised outside the ISO specs (if these are really encumbering the standard)
I hope I am not typing rubbish.


edit: sorry, I meant SEPARATE encoder, besides the 3.x versions of LAME we have now.

If you deviate from the specs it wouldn't work with MP3 decoders, so what would be the point?

Lame --alt-preset standard is really excellent and very rarely trips up. If it does, it's not usually too bad, so don't hesitate to use it if you need MP3 compatibility for portables etc. Problem samples that still affect Lame APS badly are now very rare or have only very subtle artifacts. In this forum we're looking for them and we're very critical so you could get the wrong message.

A few options let you go outside the spec while remaining compatible with some decoders (e.g. --freeformat allow bitrates above 320 kbps and is not limited to the same bitrate steps as compliant MP3, IIRC)

Sure, MP1, MP2 and Musepack .MPC have better time resolution - good for transients, and Musepack is more efficient.

As I understand it, Musepack was developed to get around the limitations of MP3, MP2 etc., as you suggest, so in a way it's already happened (although it uses a different method of encoding - it's not an MDCT-based hybrid codec like MP3 but works more like MP2)

Time resolution is improved and the sfb21 issue isn't a problem, and VBR is better supported (native timing and seeking information without needing a Xing tag). MPC is also gapless - matching the exact number of samples in the original WAV, and it's more efficient (lower average bitrates at the --quality 5 --xlevel than Lame APS). But it needs a different decoder to MP3.

(Use the search button if you want to know why these things are problems in MP3)

Ogg Vorbis attempts to solve it without using any of the known patents that impede MP3 and MPC. It's amazing at low bitrates and I have high hopes that GT3 will come close to MPC quality and bitrates in the transparent quality/safe joint stereo) range of q values.

MPC (as for SV7) doesn't store any seeking info (and seeking works by bruteforce walking through stream data).

Mp3 has some design flaws mainly because of political/economical reasons inside the iso comitee.

Creating an encoder removing those limitations would break compatibility with mp3 players.
But there is another standard removing the mp3 limitations, while still beeing very similar. It is called AAC.

So if you want to break the mp3 limitations, just use aac instead.

Hmmmm... http://www.audiocoding.com/wiki/index.php?...cal+Information

I also realised that mp3 in VBR only has typical specific bitrates eg 96, 112, 128, 160, 192 etc. This is unlike mpc where the bitrate for a VBR file rarely goes out of the range of about 30 kbps between the highest custom bitrate and the lowest custom bitrate. Is this another limitation of the mp3 format due to the specs applied on it?

yes, frame size must corrsepond to those fixed bit-rates, but they also can use the 'bit reservoir'
It is most useful in CBR: the exact "size" of a current frame can be somewhat variable, but not so flexible as VBR.
In VBR one can simply assign a higher bit-rate for the frame instead of using reservoir (when it is not enough big),
but reservoir is used sometimes too.



I don't quite unerstand what you are talking about here.
mpc bitrate can be anything from 3.5 to over 1000 kpbs, changing from frame to frame.
You can use the mpcbits program from Case's page:

It is not always inferior and when you use your ears, you will easily understand... I was a great enemy of lossy compression and especially that of MP3, but nowadays I admit I use it daily, because it's easy portable and sounds very acceptable even on vintage equipment. You must just find settings, which will fit your needs. But you hardly find any substantial improvement from --alt-presets; I personally use LAME 3.90.2 by Dibrom with following settings: --alt-preset extreme -Z --lowpass 21 (just to overcome the built-in lowpass setting). In extreme cases I use --alt-preset insane --lowpass 21. It sounds really great; this quality I would never expect from "inferior" lossy compression as I was convinced before...

What I meant was that for mpc, an encoded VBR file almost seems like a CBR file, with the bit frames like fluctuating between 175-200 kbps for a song which is 255 kbps average encoded with --aps.

To budgie: well, I started out thinking that wma was better than mp3, then was content with mp3 at 128 kbps regardless of encoder, then found LAME and --r3mix before stumbling onto HA.org and the ultimate --aps. It's quite an arduous journey, but at least I've been going upwards in terms of encoding quality. B)
I'm toying with the idea of converting to mpc though, I am amazed at the simultaneous improvements in quality with the significant decreases in file sizes.

If compatibility really doesn't matter, then go for it! convert to MPC! I did and have never looked back!

You may mean "switch to MPC" not "convert to MPC". That sounds like transcoding....and that's EVIL

I don't want to be ironic, but can you prove it?

That's obvious, I think... 2x lossy loses more than 1x lossy - doesn't it? ;-)

Well, you certainly gain nothing in quality by simply transcoding from MP3 to MPC, so the only way to gain is to re-rip and encode the original CD audio (or WAV) into MPC.

However, if there's enough safety margin in the first encode (e.g. using 'extreme' instead of 'standard' in mppenc or perhaps LAME), transcoding could potentially be perceptually transparent for most music. I wouldn't trust LAME so much because it is marginal on transients and might smear them further on the second pass. I'm not convinced it's always evil (and won't be without blind testing to prove it), but it's nearly always pointless and it IS dangerous for transparency.

I'd personally be prepared to transcode from MPC (--xlevel --quality 5 or above) to MP3 (APS) if I needed it only for a portable player (I don't own one yet), just as I currently record MPC or MP3 to MiniDisc (SP, not LP) via analogue Line In (fixed input gain) for personal and in-car use with my current equipment, where it sounds very acceptable (except for codec-killers like Fatboy Slim's Kalifornia which is poor on MD even digitally encoded from CD).

Haha!
I recently just re-ripped my few albums into mpc. Cool. I like the way the file sizes are so stable whether the songs are rock, classical, pop...

To kdo: I finally understand why you were confused about what I claimed in seeing how mpc worked...it does use extra small and extra large frames when it has to...forgive me for thinking it worked like mp3. Too bad Foobar doesn't show the bitrate fluctuating as it is... I glimpsed many extra large frames playing the mpcs through Winamp. 400-500 and most possibly higher.

Edit: I decided to switch to mpc from mp3, because mpc is better than mp3, giving better quality for smaller file sizes. Furthermore, I don't own any portable players and only listen to my music on the computer...quite sad. And if I intend to get a portable player in the near future I may as well wait for one with mpc or ogg support since companies like i-river are finally incorporating support for these superior codecs.
(Ok fine from what I read most likely ogg, but not mpc, because of commercial viability and certain ogg ultra-orthodox zealots. What the heck, I love the ogg format too, why can't they love the mpc format?)