It sounds like Robert may already have doing something along the lines of what I'm envisaging, which should apply to lead_voice, and I hope to find a bit of quiet time today to test 3.100.a1 on my favourite samples.

BTW, thanks Robert for the info about mp3x. If I get enough down time to take it seriously, I'll probably ask john33 if he can compile it for me on the latest alpha.

With the test version robert gave me lead-voice was close to transparent, a very good result. Guess it's the same thing with the alpha version. We can expect fine behavior also in this respect with 3.100.

It provides -V5+ to -V0+, and lowpass behavior of -Vn+ is identical to that of -Vn.It also provides -V0+eco, but in this case a lowpass of 18.2 kHz is used. Without a lowpass a high amount of unused bits in the file would be introduced.

There are several individual options which are described in an extra documentation file in the context of what the functional extension machinery is doing.

I think I've found a solution for the --lowpass question: keep -Vn's lowpass behavior with -Vn+, but provide a -Vn+eco variant for any -Vn+ level which uses a somewhat lower lowpass and on the other hand provides (with the exception of -V0+eco) a slightly better short block behavior.After all, using a very high lowpass or no lowpass at all is more for the theoretically oriented folks who've read that frequency range should go up to 20 kHz or so. There's also no reason to restrict an eco mode to -V0+. Will go to work with it.

Thanks for posting the "C" version, halb27. I haven't gotten to use it much yet, but so far I like what I'm hearing.

I have one quick question, to help me compare "C" to "Z": what were the effective settings for the new options (--adbr_startshort, --adbr_long_max, --adbr_trans_plus, --adbr_tolerance, --adbr_snrinc_max) for -V0+ and -V0+eco in the Z version?

Recent changes in the strategy of the functional extension weren't too lucky:

I implemented the universal -Vn+eco, but with the exception of -V1+eco I did not get a better listening experience compared to -Vn+, nor could I save bitrate, nor could I get seriously better internal parameters while keeping the bitrate. So a universal -Vn+eco may sound nice but has no real meaning.

As I was doing intensive listening tests I also found a lowpass is necessary for eig. Without it the result even with -V0+ or -V0+eco is audibly worse than when using a lowpass.So I will also give away the nice idea of staying with -Vn's lowpass behavior when using -Vn+. I'll default to --lowpass 18200 whenever Lame uses a higher lowpass or no lowpass at all.

While I will consequently prefer short block behavior over long block behavior I went too far with thinking that long block behavior can be covered by -Vn behavior to a large extent. It`s true as long as we're happy with requiring the somewhat vague 'close to transparency' not to be very strong. But for -V0+eco to me the result isn't really satisfying for 'trumpet_myPrince'. The meaning of -V0+eco has turned a bit into using -V0 internally while keeping bitrate around 260 kbps and introducing only a small amount of unused bits. That's rather techinical and has turned the --adbr_long value low with the consequence that quality isn't totally adequate IMO. I'll concentrate on quality again, and for the lower quality levels of -Vn+ I am very happy with the quality compared to the average bitrate, but in the 260 kbps range I'm not. With the surprisingly good results I got for -V1+eco I will try to reach a better quality in the 260 kbps range based on -V1. -V1 gives more space for improvements due to a higher --adbr_long. If successful this would kick off -V0+eco for the sake of a better -V1+.

@BFG:3.99.5z's default parameter values were 290/220 (-V0+/-V0+eco) for --adbr_long, 310/253 for --adbr_long_max, 440/440 for --adbr_short, 310/235 for --adbr_startshort, 10/10 for --adbr_trans_plus, 30/30 for --adbr_snrinc_max. The tolerance mechanism was changed in order to make the tolerance available in a clear way as a parameter. In terms of --adbr_tolerance 3.99.5z's tolerance value was more like 5 for -V0+/-V0+eco. 3.99.5c cannot perfectly be compared with 3.99.5z since introducing more parameters made me clean up the code as I had to change it anyway. This has a certain impact also on functionality. Especially I give short block behavior a consequent preference now over long block behavior when it comes to keeping bit reservoir large. The machinery has changed a bit, but I think there's only a very low chance that the changes are audible.As for audible effects and the outline of further development: see above.

a) The default lowpass is 18200 now in case Lame uses a higher lowpass or no lowpass at all.

b) Emphasis is even more on short block behavior. Even -V5+'s short block behavior is close to what's possible.

c) There's no -V0+eco any more, just -V5+ to -V0+ which cover the average bitrate range ~180 kbps ... ~320 kbps.-V1+ takes the role of -V0+eco.With the exception of -V0+ and the lowest -Vn+, average bitrate is raised in order to more homogeneously cover the range 180...320 kbps.

I've done a lot of listening tests and I'm happy with what I've heard.

Thanks for the "D" version! Unfortunately, the adbr commandline options seem to do nothing in this version.For example, I tried setting -V0+ --adbr_long 160 --adbr_startshort 260 --adbr_trans_plus 10, and the standard -V0+ settings seemed to be used instead. Only when I changed the -V switch did the output appear to change.

I have enjoyed reading this very technical thread even though I am not in any way a developer of codecs. I have a very tangential question that I pose purely as a matter of curiosity.

While reading about these efforts to more effectively resolve "pre-echo", which reduces the transparency of LAME encoded lossy files, by focusing on how Short Blocks are used by the encoder, I found myself thinking through the explanations for why this problem occurs.

Several posters indicated that the encoder (all MP3 encoders?) use Short Blocks for encoding areas of dynamic change in music - sharp attacks, instant volume surges, percussive sounds, etc., and that the LAME encoder does not necessarily do this as efficiently or cleanly as it could, which thereby causes the "pre-echo" and reduces the perceived transparency of the resultant lossy file. Please correct me if my understanding is not correct.

My question is whether the way a musical selection is mastered affects the encoder's performance in this regard. Would a rock musical selection mastered in the "modern" way, e.g. more compressed, possibly brickwalled, with dynamic range of about 6dbs or so, be "easier" for LAME to encode because of the fact that the dynamic changes within that selection have been truncated relative to a more dynamic selection, such as a classical symphony recording (which may have a dynamic range in the 16-18db area)?

If so, is this the reason why most pop, rock, and country music is mastered in this way nowadays, e.g. because it will sound "better" when ripped to a lossy format? (Don't know if AAC has similar issues)

Sorry. Glad you tested so quickly.I've corrected it as well as some minor bugs in the documentation.The link above has the corrected version.

Thanks for the quick response! The new version does indeed recognize the adbr switches, and I am testing it now.Out of curiosity, why did you decide not to default all long frames to a much lower size (160kbps or similar) as you originally stated? Was it because of the difficulty with the herding calls sample?

Can you wait a bit please with testing? I've just found that there can be improvement with treating an out of data space situation. It won't change things essentially but I'd like to implement this improvement into a further new version. (I know it's a bit too many versions ATM, sorry, but cleaning up the code has made me give special attention to all the special situations, unfortunately not at the same time. I know it's bad, but holding improvement back would be worse).

There was a bug in version d which allowed encoding a frame with bitrate >> targetbitrate in a situation where mp3's channel or granule size restrictions were hurt. Now bitrate is reduced which can lead to a regular situation without violating restrictions.Another criterion for lowering bitrate or not in an out-of-channel- or out-of-granule-space situation is made more natural with version e. With version d bitrate was lowered as long as there was also an out-of-frame-space situation. This often lead to an SNR increase of 0, that is -Vn behavior. Now I reduce bitrate only when there is an out-of-frame-space-situation after reducing assigned bits to the limits of the channels resp. granules concerned thus roughly simulating Lame's machinery to deal with out-of-space situations.

You can see the improved behavior over version d as well as z when looking at the --frameAnalysis print for harp40_1 (supplied in the zip file) for frame #99, #393, #489.Hopefully this is all there is.

What do you think about the quality/average bitrate distribution for -V5+ to -V0+?

Is it better to achieve an average bitrate of say ~220 kbps by using -V3+ as the basis as it is ATM (which means a rather advanced --adbr_long value can be used), or is it better to use -V2 as the basis (and a smaller --adbr_long value)? Answers are related to where to put the most attractive average bitrate for -Vn+, while looking at all the -Vn+.

Except for -V0+ I personally have no real bias. For a start I tried to give a relatively homogenous distribution in the overall bitrate range, but that's not all there is.

If You don't mind here are a few questions to make an idea what to expect.

Which versions have sense to test and which are already obsolete (if any)? z,e,d,c,? What are your general plan and thoughts about your functional extention of 3.99.5? Is it any near to be complete or You are in the middle of experiments? I would like to perform a serie of a tests with limited numbers of samples while there are new versions each weak or so and report the results here if You wish. Once the long term version will be released it will interesting for me to make a detailed test on a large number of samples.

You're absolutely right. I've been too involved in development recently, and providing new preliminary versions again and again is very unlucky, especially for those very welcome users like you who are willing to do real tests. I absolutely feel with you. So please forgive me.

And due to experience ATM I can't say 'version e is it'. So I will do the following: do some more experiments but don't publish any result. After I've cooled down, that is: haven't found anything else that can be improved within a week or so after the last changes, I'll come back with the final result of current development.

There is no -V5+eco. I gave up the -Vn+eco idea (see above).Unfortunately when using Lame (original as well as my variants) you can always append non-numeric stuff to the quality level which is ignored. '-V5abc' does exactly the same thing as does '-V5'. ATM I just look up the last letter and see if it's a '+' which triggers -Vn+ mode. After having realized I'm in -Vn+ mode I remove the '+' and let Lame do anything else for finding out about quality level. So -V5+eco is -V5.

Please wait until I'm finished with current work. I'm working on preventing unused bits. This will have a major influence.A short outline:

Whenever possible I hold a reserve of bits so high that in case the next frame has a short block, it can be encoded with the number of bits which corresponds to --adbr_short.Frame size is chosen thus that targetbits + bits reserved fit into the current frame. Frame size cannot be choosen arbitrarily however, but in steps according to the frame bitrates allowed (usually 32 kbps stepsize [that is 836 bits stepsize for 44.1 kHz sampled music], but 64 kbps [1672 bits] stepsize when going from 256 kbps to a 320 kbps frame). Depending on the chosen frame size the number of bits reserved can exceed the maximum allowed number of bits which is 4088. This way up to 835 resp. 1671 bits can be unusable because they cannot be reached by the next frame. For bitrates way below 256 kbps and values for --adbr_short way below 460 the percentage of unused bits is low so the problem is negligible. Other than that it is very real, that's why quality levels like -V0.5+ blow up bitrate significantly because of unused bits.By intelligently reducing targetbits, bitreservoir requirements, or turn the otherwise unused bits into used ones, all according to what's best in the actual situation, I am about to solve the issue. Though not really needed it has a positive effect for the lower quality levels too.

The maybe most important thing however is that when doing so -Vn+ is very usable also for n between 1 and 0. I do want to have a very good setting that yields an average bitrate of ~270 kbps. That's why -V0+eco formerly, or -V1+ with version e. With the avoidance of unused bits it can be -V0.7+ or so instead.Which allows to put the parameters of -Vn+ so that average bitrate is closer to that of -Vn than it is in version e (with the exception of -V0+). While not too small --adbr_long values help a lot on tonal problems it's not all there is. A lower -Vn and a higher --adbr_long is not necessarily better than a lower --adbr_long and a higher -Vn which yields the same average bitrate. harp40_1 is a sample that shows that -V2 is a good basis for achieving good quality, -V3 is more problematic. I will go into this deeper.