I can't understand this. According to Dibrom:

- MP3 is crap at > 16khz and even if one could hear it the quality is likely to be bad.
- Despite this, VBR (APS) enabled HF content at the risk of bitrate bloat.
- One may lowpass at 16000 or better use the experimental -Y to get around this issue.
- Something like -Y is already operating at ABR / CBR and with non LAME VBR encoders ?

I found:

- Some tracks are not transparent with -V3
- There is nothing wrong with V3 as V2 -Y has the same issues almost always.



Which is the right quality ?

To from a design POV -Y is the correct quality / bitrate. What is happening with the bloating is an illusion of transparency - because the overcoding is going UNDER 16khz and it shouldn't !!.. Metal / rock songs real quality / bitrate is 170 ~ 185k not 220..290

How V2~0 works seems like a hack ? - I prefer V3 as V2 -Y isn't much better. So my gut instinct tells me APS -Y / V3 is flawed (its mp3) and the bloat of normal V2 sometimes increase quality. I don't like that idea at all because it has nothing to do with psychoacoustics but a flaw and hacks.

So when Dibrom designed APS etc, HF encoding wasn't done to * maintain transparency below 16khz *, But from a theoretical POV of a listener that would hear above 16khz .

Well I am now discovering that the bloat doesn't always increase quality. I have a track by Withing Temptation (jane doe) V3 is 174k and V2 is 219k and still has preecho artifacts. So the bloat issue is insane as mp3 HF quality will always be poor, hardly anyone hears ultra HF in real music.

Or another supposition is that it might be a probem with short blocks not being short enough and/or with the frame payload being capped at the equivalent of 320 kbps (sadly, that's 320 kbps little extra allowed from bit reservoir because of a fix for, IIRC, the FhG decoder installed in most Windows installs that failed to decode 320kbps + full bit reservoir properly - yes, see LAME Changelog 3.98 beta 1 for details).

Perhaps the mp3x graphical frame analyzer (usage info) can shed some light on this problem sample. It's not included in most current LAME bundles, but I have used it in an old version of LAME many years ago. Gabriel has a version from 2004, which requires GTK libraries to be installed, here. You need to convert the frame size to its effective bitrate yourself, IIRC.

If it IS the 320kbps limit, that would only apply at the location of the pre-echo, but the bitrate elsewhere would bloat the overall filesize/bitrate unnecessarily with no benefit to the pre-echo part.

This is just me offering another possibility. I'm not claiming this is the correct answer.

It is possible to compile Lame 3.98.2 with and without this limitation, and compare results.