mp3packer and inefficiency in mp3 encoders, is this a new frontier for optimizing the mp3 format? Options

[timcupery]

So I just discovered Mp3Packer, and given its frequency of mention in various threads, it seems to be commonly known-about and used. But I was actually quite surprised at how effective it can be.

Now, the fact that 320kbps CBR files can be shrunk by over 10% doesn't surprise me, nor the fact that *some* 256kbps CBR files can be shrunk by a similar amount.

But many CBR files at lower bitrates (iTunes and Fgh-encoded mp3's at CBR 128 and 192, and 160 for iTunes) can still be shrunk 2-3%.

Lame-encoded files, however, don't shrink much at all, whether VBR or CBR.

This implies that two of the three most commonly-used mp3 encoders could use some simple optimization.

My subtitle of "a new frontier" for optimizing mp3 is hyperbole, and especially untrue since Lame encodes do not have much space to be optimized here (excepting high-bitrate -V0 and --preset insane).

[Dynamic]

I believe that regarding Encspot, there was a list of rules of thumb to indicate (best guess) which encoder was used (e.g. no short blocks indicates Xing(old), both M/S & L/R frames in same file suggests LAME but rules out certain other encoders at certain bitrate ranges).

I recall that LAME (at least three-to-five years ago) tended to use the bit reservoir much more than most of the others with both higher average use and higher maximum bit reservoir use, whether in VBR or CBR mode, thereby reducing the use of padding and increasing the encoding efficiency (allowing higher bitrate spikes in CBR or lower bitrate overall in VBR).

Bit reservoir optimisation and conversion of CBR to VBR is key to mp3packer's normal mode. It may be that other encoders like FhG and iTunes aren't totally optimised for reservoir in CBR mode, but have no useful mechanism of allocating extra bitrate (i.e. from the reservoir) than they already allocate (e.g. in response to transient detection), or their developers feel that it would impose an unacceptable encoding speed penalty in return for negligible or marginal quality benefit if they were to force their encoder to put some signal where the padding is currently placed. Their developers have clearly done a good job overall to rank alongside LAME in most listening tests.

This post has been edited by Dynamic: Jan 14 2009, 18:14