Wondered what ConCave is the abbreviation for. Now I know better.

Halb27, you prefer -b320 -h of 3.90.3 over alt-preset insane/3.90.3 and similar -b320/3.97.
That is not being conservative, that is being a little ignorant of the work done by several strong guys and untrusting them, who tested a lot, not only 1 sample, to optimize the higher bitrate ranges. If the simple -b 320 -h would be a good commandline, well, why would the people have invested so much work in improving it ?
And that is even contradicting yourself, as you stated above, you cannot abx 3.90.3 alt-preset insane trumpet from original wave ?! So, api-3.90.3 does not have the problem ?
Can you try again -b 320 of 3.97 ? Would be interesting to know, if -b320-3.97 is worse than 3.90.3-api, because normally these presets should be unaltered, as there wasn't much testing here at that bitrate after the release of 3.90.x.
(btw., answering your previous question, in 3.90.3 you could add ns-safejoint or msfix values to other simple commands.
But all that has been carried out, to find optimized msfix values for alt-preset standard, extreme, insane->nssafejoint, nssafejoint means iirc only a very conservative msfix value with highest percentage of stereo frames, less mid/side) That was a discussion already at the old r3mix forum, so years ago, unfortunately those discussions are lost, no backup of the r3mix forum available at inet anymore, iirc.)

user, I just abx'd 3.97 -b 320 for the trumpet sample: 10/10.

As promised I abx'd fatboy with 3.90.3 -b320 -h: 4/10. But I couldn't really concentrate on this sample (as with many electronic samples I tried earlier). Not of much use.
Apart from that my hearing seems to suffer at the moment. My test yesterday with 3.97 stereo mode and today with -b 320 wasn't that easy as before.
This doesn't apply to the 3.90.3 api test. Stating I could abx 3.90.3 api was a gross memory error, as I could read from my first posting which I did when this new thread was created right now.

It's not a question of trust. I am absolutely aware the devs and testers have done great work. But that does not necessarily mean that things not in focus can have degraded. There were great improvements but they were on the -V2 level (as you say yourself - no much test with 320kbps).

I am a developer myself (database applications) and I do know: if you're improving certain things and you're focussing on actual demands situations come up where this has impact on other things not in focus. These side effects are not always adequately tested (most of the time because impact is not considered important, or because you're not aware of it, or because you decide not to spent time on that having more important things in mind.)

Not to use 3.97 at its current state with 320 kbps reflects current experience.
Prefering 3.90.3 -b 320 over api is not backed up by real argument. Maybe it is a bit of 'not trusting' in it the way: if 3.97's tweaking nspsytune was good for the vbr modes especially in the -V2 range, but not for cbr320, it might be a bit like that with 3.90.3. Very subjective opinion of course.

No need to apologize, I had to try anyway.

I don't clearly understand your reasoning for prefering -b 320 -h over API though. Like you, I can't ABX either so logic would suggest to just use API. Although, if you somehow THINK -b 320 -h might be better, placebo effect might come into play and you should always take advantage of that of course.

I agree that maxing up the bitrate of mp3 isnt really insane in cases where filesize is not a concern. Also the naming of a preset 'insane' seems over prejudicial -especialy when it happens to be one of the best, if not the best sounding preset there is.
--Preset maxkbs would be less presumptious of users judgement but less spunky.
How about --preset 319, with the lowpass brought back down to preset standard level, for the best the abr routine can produce with maximum upward pressure on the bitrate.
With capacities and processing power growing and growing it might be just a matter of time when developement in mp3 will be looking beyond economy of general transparency, to robustness and even transcodability. That seems to agree with your outlook Halb, not alot of use maybe without our own testing or hacking - just a puff of wind blowing in same direction

Filesize is always a concern. Otherwise you'd be using lossless. Hell, or even wav. Using 320kbps with mp3 is what the preset name says: INSANE.


Try thinking about what you just said. I'm sure it will make no sense to you either.

This preference doesn't have any background, and is not based on any listening experience. Just when it comes to decide between two decoder settings, and as far as up to now none of them is to be preferred on an objective basis you have to go the subjective way. But shouldn't be an issue here. My personal opinion on that is not important. Was to be just a side comment.

I was about to say the same to you Im sure your if you put your mind to it, you could think of a circumstance where you need to use mp3 and filesize isnt a concern. Halb even mentioned his own, somewhere - many posts ago.

Re abr 319: In my understanding keeping the lowpass as low as possible helps save bits to throw at problem samples. My own ears prefer hearing music that is audibly lowpassed, its softer and less harsh, thats better for me, but I judge for most people there is no reason to go above preset standards' lowpass, perhaps to preset extremes level - preset insanes lowpass may well be insane but i dont agree not caring a single bit about the filesize is a sign of insanity for eveyone.

Edit: oh i see what you meant now -bit slow, by max upward pressure on the bitrate I mean encoding pressure on the bitrate, not signal pressure. An unusual turn of phrase perhaps.

I personally wouldn't tweak on these things.
Usally I don't like option tweaking at all (in principle it should be optimized by the devs) but as for the things I know now I'm just having a hard time considering using -m j --nssafejoint with 3.90.3 -b 320.

I have read devs say that lowering the lowpass is a safe tweak for personal use and confirm that it reduces the pressure on bitrate -improving performance on some problem sample types. Loose talk like this can get the hard shoulder though

Edit: signal "pressure" that is

IMO there's nothing wrong with your reasoning. Lowering the lowpass should be safe. You should do it if listening to the music is more enjoyable to you.
And in principle it can improve on problem samples. However I wouldn't care much about it. Extreme high frequency is usually rare within real music (except for metal or certain electronic music) - at least the way it comes from CD.

You could care about lowpass, not using one (switch -k) turns many tracks into artifact producing problem samples. Using an inaudibly high one is pointless. If you are concerned with the possibility of coming across artifacts and want to use a higher bitrate like extreme, 319 or 320 but are satisfied with the sound of preset standards lowpass, it can only be counter productive to default to those bitrates higher lowpasses.
What I was saying is if you have a sane reason to use the 'insane' bitrate you dont have to use the 'insane' lowpass settings, in fact your extremely marginal advantages will be optimised by keeping the standard lowpass, unless the low lowpass is why you want to go 'insane'

la la la...

nightie

No, I can't. He mentioned an mp3 player iirc, but almost all mp3 players can also play wav files. So if filesize truly is not a matter...


Bitrate pressure? What??

Correct reasoning imo.
As is everybody I'm just used to my habits.
Will really reconsider it.

This is not respecting other peoples needs.
I can absolutele assure you my 320 kbps mp3 archive fits perfectly on my 40 GB player, with a lot of disc space being left for the future.

And this is bs. With wav 40 GB are not sufficient. At the moment I could use lossless (very attractive), but this would leave too low a reserve.
Very high quality wavPack lossy is still in the race, and I'm very curious about battery life with this (I'll perform a test within the next days).
Anyway I prefer hiqh quality mp3 because of overall easy handling and usability.

BTW: time is not on your side as far as practical mp3 usage is concerned.
If you're just sporting for -V2 improvements in its own right: go ahead forever.

I think this guy either simply doesn't get it, or is trolling.

He was told already in the beginning of the thread that MP3 is not for what he wants to achieve. That lossless is for archival, and that a hybrid-codec would be the "middle-way" to create lossy encodings which have almost no problem-samples, yet are smaller than pure lossless.

Those simple facts were just repeated over and over in the thread, and i'm affraid, the facts didn't change and will not change. This thread is a waste of resources - the necessary info for him to make a decision is there... either he accepts it, or he should just do things as he likes without annoying others with his weird logic.

I understand halb27 needs. 320 kbps fits 4 times more data than 1400 kbps uncompressed wav, and this is a valuable difference. If it wasn't, lossless compressors wouldn't have sense. And mp3 is still the universal DAP format.

Yes, for many members there seems to be a rather universal paradigm about these things. Everybody is used to his habits and that's why I understand that my approach has an emotional impact on some people.

However if you are so deep within this paradigm that you feel yourself annoyed think about this:
You keep yourself away from the chance of learning unexpected new things. Also from the chance of improving things on the issue (which can mean coming up with a sample easily abxable with 3.90.3 cbr320).

Repeating the paradigm isn't helpful. We all know it.

You simply dont get it - no matter how much you want or need it, it doesn't exist! Live with it or believe in what you want to believe - but stop wasting peoples time. You got the info on which choices you have available and know the pros and cons of these - if you still cannot decide and want something which doesnt and will not exist, then thats not other peoples problem.

So for the last time:
mp3@320kbps: compatible with DAPs, but there will always be problem samples
wavpack lossy: almost no problem samples at around 450kbps. Good to transcode from. Still smaller than lossless. Does not play on most DAPs.
lossless: perfect for archival and getting 100% quality. Filesize is quite high. Unsuited for DAPs.

Besides that repeated advice to whomever, and the dubious assertion that the mp3 format will never be encoded to free of problem samples, I found the discussion of efficient maximum bitrate encoding interesting.

CBR 320 has alot of purely wasted bits of course, because often the very best quantisation -even beyond pyschoacoustic economies do not fill a full 320kbs frame. I think there have been some projects to repack the cbr stream losslessy to vbr which demonstrate this waste.
On the other hand preset extreme, i think, is using vbr mode which will never spend more bits on a frame than it discerns as an audible improvement, even if there is a seemily inaudibly more accurate solution of the waveform to spend more bits on. With this type of quantisation selection the encoding accuracy can never surpass its psychoacoustic modelling. Some past presets have tried to improve performance by enforcing a minimum framesize, but with the vbr-new routine this doesnt affect the bits actualy utilised just their packaging.
The ABR routine can press towards a desired average bitrate, when set to press towards 319 kbs the psychoacoustic model is (somehow) encouraged to spend as many bits it can on representing the waveform without compromising its virtual estimation of how well the encode will sound.
I found --preset 319 mp3s to result in ~280kbs encodes (it cant get near 319kbs because too many frames are most accurately represented by smaller framesizes and they cant be averaged out by framesizes above the 320 kbs format limitation)

Halb, I read the abr and cbr quantisation routines are similar, but its because of cbrs necessary padding i recommended preset 319. Cbrs padding is probably the foundation of its naming as 'insane'

hth

Thank you, ChiGung.
I also thought of cbr320 being overkill and considered abr 256 or similar an interesting setting. However I don't care too much whether it's 256kbps or 320.
I have to admit I don't understand you very well in each detail. I think you consider --preset 319 because this ensures the same quality as cbr320 while keeping average bitrate down to about 280 kbps. Sounds very reasonable.
But what is cbr padding?

Just a personal question if you like to answer. In your first posting here you made yourself a bit small (at least this was my impression), and in this posting you come up with details that show that you have been digging pretty deep (apart from your suggestions sounding very intelligent to me). What's your background? Which way are you encoding?

Besides: I like your la, la, la. Remembers me of a chinese student we had in our company last year. She is a very kind person, and often she started to sing her little 'la, la, la'. Nice that.

Just checked, instead of --preset 319, --abr 320 works as well, its what i meant really, just to avoid defaulting to cbr at preset 320 (the preset system does this). Depending on how similar the encoding mechanics are for abr and cbr, the difference in using either one, might be purely in the packaging - to do with the cbr 'padding'
The best way to express (in mp3 ~math) a section of waveform, will require an ever varying number of bits. During the encoding process different expressions of the waveform are generated, and examined to discern what size they will compress to and how well they should sound like the waveform. Depending on the encoders priorities and methods, the best expression is selected according to how well it should sound against what size it compresses down to. There is so much potential variation in the numbers that sometimes very concise expressions of a section (frame) of the waveform are possible which is better than all poseable larger expressions (compressed quantisations) -and sometimes not a single acousticly acceptable expression can be found which fits the available framesize and 'damage limitation' routines would have to be resorted to. Theres different ways to render the system, but thats all to say that filling up every frame to the brim with information is almost never possible (only with weird synthetic test data) - and so cbr 320 will contain a lot of empty space even if it is trying its best to utilise every bit. The space is 'padding'

phew, i know it reads obscurely, but its the only way i know to describe.

Heh, thats the first time ive been asked my background in a technical forum so im pleased but i think i should keep it brief
Ive picked up a little bit of insight into lames program, just from casual lurking and posting.

My HDs are always nearly full of 'recieved media' (the tiniest fraction of which I ever listen to) so I dont do lossless but i definitely would if I had the space and material to archive. Its true even these high bitrate mp3s are not good for transcoding. But for filling my little mp3 player I do use foobar to normalise and re-lowpass while transcoding mp3s to experimental settings, sometimes max bitrate, sometimes I hear problems, sometimes not I dont pay that much attention.


Now Im thinking that la la la thing is chinese too - dont know why. I Hope you never hear from me on a bad posting day, I can be an absolute fiend and ignoramous online *shudders* No warnings here yet though 'touchwood - thats a testimoney to HA's cold blooded moderation

cheers'
andy, NI/UK

halb27: you of course know that having the worlds coolest dap (h140) you have currently a choice of three lossless codecs (flac, wv and alac) as well as wav which are all supported by the rockbox alternative firmware? and that, since recently, it supports musepack, which is a codec tuned for higher bitrates - exactly what you're looking for, aren't you? and even without rockbox your iriver plays ogg vorbis files that i guess you couldn't abx at q6, and it goes up to q10 (which at 500kbps is kinda pointless)?
you have found *one* problem sample for the new lame encoder, and you're either trying to prove it's worse than the old one (even tho it works a gazillion times faster, and handles gazillions of problem samples better than the old versions and in the stable release might even bring world peace) or you're trying to find the PERFECT solution. it has been stated before - mp3 never was, and never will be perfect. perfect = lossless, lossy < perfect and that means you have to compromise.

six pages about one sample?

Shouldn't this discussion be complemented by more samples?, I mean, at the bitrates with wich halb27 wants to encode, the number of problem samples would be minimal, regardless of encoder version, and to try to avoid as many of these as possible would probably be audio-paranoia and would most likely lead to various health problems.

@ halb27:
As [solid] said, considering you own an h140, adding Rockbox firmware to the equation, the windows open for more powerful formats. You should really give other formats a try, if quality is what you are after, MPC would surprise you i think, it works amazingly well, Vorbis too, and AAC. You shouldn't limit yourself.

EDIT: My post started the sixth page.

Sure I know. Was talking about that. Bought the H140 for this very reason.
Highly appreciated vorbis is out of the race (battery life with q8: not much better than 14h, with 320 kbps lame: nearly 23h, both with iRiver firmware).
I'l begin using rockbox firmware from this evening or tomorrow.
Lossless filesize is too big. The most interesting approach to me on quality only demands is wavePack lossy at something like 450kbps. Really consider that. Curious about battery life.
But besides quality demand I appreciate the universal usability of mp3. When I will buy a new car radio for instance I can have one for using with my mp3 archive. I can avoid transcoding. Also I don't need perfect quality (sure I take it if it's for granted). As for overall quality I'm happy with -V3 (or may be even lower).
But as this sample comes up I want a bit more security. I see gray scales in the 'there will always be problematic samples' sentence. This means going something like 320 kbps which is no problem.
Didn't expect this thread was going to be so long.
Anyway all those who are not interested in this stuff can keep out.
To me very interesting things did come up, and there were people contributing in a constructive way even when they appeared not to see much sense in my approach. I'm very thankful for that, and with respect to the last sentence special thanks goes to sTisTi and user.

No need to thank me. I have to excuse, i haven't even had the time to listen to trumpet sample, writing here from pc at work.
So, for the trumpet sample, we can take it now as fact, that api-3.90.3 is ok, not abxable so far, at least not annoying on the trumpet sample.
And it is a fact, that with -b320-3.97b1 the trumpet sample is abxable, not only by 1 person, and the artifact is annoying ?

hm, then I am of course wondering, which changes have been done to the 320k optimized settings from 3.90.3 to 3.97, as iirc, no testing has been carried out at 320k ?
or was the 320k setting at 3.97 changed by settings, which work for the mid-bitrates, settings derived from the -Vx tuning ? A so called "extrapolation" ?

I encoded a track using three different 320 kbps LAME version/setting combinations. Here's what Encspot shows:

LAME 3.97b1 -b 320 (= --alt-preset insane)

LAME 3.90.3 --alt-preset insane

LAME 3.90.3 -b 320 -h


Besides the psycho-acoustic model and stereo mode differences I found these:


I didn't know the bit reservoir was even possible at 320 kbps. Why Encspot displays it for 3.90.3 files? I tried HA forum and Google searches, but found nothing about this.

Edit: added ATH type to the table

3.90.3 cbr320 (no matter which way) is not abxable, not a question of annoyance.
3.97b -b320 is abxable, but as did stephanV I wouldn't call it annoying. (Brute force does help here too. However with something like -V2 it's really annoying).

Very interesting. Hope comes up that things will get OK with 3.97+.

Note that I have a very high annoyance threshold, I am perfectly fine with Vorbis q1 (but maybe this is due to my lousy 5€ headphones... )

Same for me. When I encoded abr104 for my mobile phone and tested it on better equipment I (not abxing, just careful listening), I used to think 'its quite good for overall use'. Great work by the devs. It's just because of more security that I ask for more. Maybe this is one of the reasons why the trumpet sample is so outstanding to me (don't dare to try it on abr104 - it's unbelievable).

Considering your suggestions I found my own kind of obeying paradigms.

If I'm really out for optimizing worst case behavior it's a MUST to do your lowpass filtering. I have always been happy with -V2's or -V3's HF behavior, so why shouldn't I lowpass that way? Whether it helps a lot or not - I will do it. There's nothing on the downside.

As for abr320 your reasoning is healthy too. Gambit's thinking is correct when he says it's unsane to use bitrates far beyond -V2 on his background taking the 'there will always problematic samples' phrase the absolute way. It's a waste of filesize. You say the same to me considering cbr320 and abr320 as an alternative. Like you I beleive that abr320 yields the same quality as cbr320, and that abr320 switches back to lower bitrates when it thinks it's appropriate, in a defensive way. So even when the focus is on avoiding bad behavior to the max it would be unsane not to go this way, a waste of filesize.

I just encoded some files to figure out what this means in praxis. Unfortunately the savings were small - about 1 to 2 percent. With Encspot things look better on some samples (I switched from the console to the GUI version now and see a lot more informations) bringing 320 kbps frames down to 95 percent in one case. But even in this case filesize decreases only about 2 percent.
I like your kind of thinking, but here the advantage is very small.
So in case I will use abr, I will reduce average bitrate a bit more to something like 256 kbps. I don't care much about such bitrate differences, but the same goes for the filesize. So this is not very important to me and I don't decide on that right now.

Anyway thanks for your ideas. I will use --lowpass 18000.

Encspot found some differences between abr and vbr btw. Encouraged by Alex B's posting I looked at the Reservoir values. On the samples I tried your ideas with Max. Reservoir with abr is about 25 percent higher compared to cbr, wheres Av. Reservoir is up to ten times higher with cbr. I know the basics on bit reservoir, but what is EncSpot showing up exactly? Is 'Av.' 'Average'? Does this adress the number of bits in each frame available for the bit reservoir? Does it cover usage of the bit reservoir or is it just about the size of the bit reservoir no matter if or how it's made use of.

Can somebody help me please? EncSpot unfortunately doesn't explain much.

I looked into many threads here on HA last night and this evening.
The FAQ on stereo mode is a good start as is searching and the upload pages.

Most interesting was: there were discussions quite similar to this one about three years ago (funny: dibrom used the phrase 'brute force' then).
From these threads I learned quite a a few things:

- in the old days people did perform tests on api.
- as time went on members lost more and more interest in cbr320 (look for instance at the version comparisons).
- in the old days when problematic samples were tested with very high bitrate behavior improved significantly most of the time when going from aps or ape to api, up to the case that api became transparent.
- There were listening tests on several encodings considered very ugly. Unfortunately the samples are not available anymore.
- joint stereo has an issue when not implemented thoroughly. There went a lot of tuning into the --alt-presets to make it safe. (user reported on that already, but there were quite a lot of threads on that).
- As for 3.90.3 api performance compared against later versions I found just one thread (against 3.96beta). 3.90.3 was prefered.
- I found nothing about 3.90.3 -b 320 behavior. Everybody used api.
- There is some evidence (based on moderate bitrate samples) that (as suspected by me in the beginning) it is nspsytune that is to blame for bad behavior on the extraordinary bad encoded samples. Listening tests pointed in this direction with dibrom always holding up the nspsytune way in replies.

As for the samples at least I found some comparable to the one I presented here.
On www.hydrogenaudio.org/forums/index.php?act=ST&f=16&t=3594 KikeG used another trumpet sample from www.pcabx.com. KikeG, did you test in this thread on that sample? The sample is there, and KiKeG's results were: aps, ape quite easy abxable, api not abxable (all 3.90.3 I assume).
On a rather new upload page from shadowking www.hydrogenaudio.org/forums/index.php?showtopic=36730 he presented two rather ugly samples. The first of them (an electronic sound some way between an accordeon and organ) shows an artefact similar to the trumpet sample.

What does these threads tell me and maybe other members:
- Most important:
While the sentence 'there will always be problematic samples' is true, deriving 'so don't care about anything beyond say -V2 because it doesn't improve things' is proven to be wrong. Everybody who wants to improve security can do so effectively by using api.
- There is very strong evidence that 3.90.3 api should be prefered over later develepments. The background for this seems to be the loss in interest for api as well as with the users as with the devs.
- I will use joint stereo only with 3.90.3 api. Doing so with -b320 will bring me away from safe ground.

Yes, the PCABX trumpets1 sample. I used 3.90.2 with and without -Z, so same as 3.90.3. I haven't tried with 3.97.

Ok, so we have 1 sample that is problematic for 3.97 @320kbps. This is interesting, but this sample feels a little lonely.
Statistically, you can not deduce from 1 single sample that 3.90.3 is better that 3.97, considering the huge number of transparent samples. This would be flawed.

This sample can be used for developers working on Lame. But to claim superiority of 3.90.3 vs 3.97 using --api, you have to provide other samples.

This morning in bed (you know where I'm thinking) I found I didn't give adequate weight to 3.90.3 api.

When reading so many threads on that I feel that there was a lot of effort, struggling and testing for the best of 3.90.3 api. I was told that here before, but it's a different thing when one can feel what that means when reading the details of how so many people contribute in these efforts.

So I will use 3.90.3 api.

I still care about the potential issue with nspsytune on ugly samples which was also backed up by my readings, but there is no good reason to give it the same weight as to api's proved merits.
And the essential message 'cbr320 does significantly improve problem sample behavior' is based on 3.90.3 api experience. (This may be true for -b320 as well, and my own experience says so, but common experience is with api).

So things are clear now. I will use 3.90.3 api together with ChiGunq's lowpass proposal.

As for the Lame recommendations, for the best of the people who want to use 320 kbps, the recommendation imo should go to 3.90.3 api.
After all it's quite obvious that there were not only no improvements on 320 kbps after 3.90, but it even happened that quality degraded remarkably (presumably due to loss of interest which I know what it means to developers). There is not a lot of experience with comparing 3.90.3 api against later versions I admit, but there is more than just this trumpet sample. All the available results go for 3.90.3 api.

3.97 should really not be recommended for 320 kbps.

Only your recommendation to yourself
Wrong. I am also wondering how this can be "obvious"

On a sample, yes. However, I am still waiting for other samples that could be usefull, and provide statistically valid data.


You should not presume about things you have nearly no input data to support presumption.

Can you please point to those results?

Sure all just my opinion. And it's not me who does the recommendation of course.

But I think there's nothing wrong giving proposals on that.

As for more samples I really should have recorded the threads I found. I focused on information on 3.90.3 api opposed to -b320 usage as this covers most my actual needs.

However that's no problem. I'll go into that this evening and find and record these tracks.
I found your erhu sample btw which also belongs to the ugly samples (not speaking about 3.97 right now).

I'll come up with these threads. As I said there is not a lot of experience out there, and you can easily say: well, there are a bit more than one sample, but that is still not statistically significant. And while this might be correct in an absolute sense: also with only few samples if they all point towards prefering 3.90.3 api I wouldn't call it a clever tactic to prefer 3.97. But let's wait.

As for the samples I showed yesterday: can somebody please do some abxing to get more insight about 3.90.3 api and 3.97 -b320 behavior?

I will do it. I just did a short start with 3.97b1 -V3, and while I can hear the problems, they are not as ugly to me as with the trumpet sample. Will be a hard time with 320kbps for my 56 year old ears.

Can somebody with better hearing bring some insight? KikeG, can you think about trying 3.97 on your sample?

I agree.

You can easily bring more insight if you would talk about such improvements.
It would help me and other members. If I'm wrong I like to be shown that quickly and correct my opinion.
Why don't you do it?
You take a very defensive position here showing up the rather formal points which might not be ok with my reasoning.
But you did not provide constructive statements so far telling us something about 3.97 api behavior.
Why don't you do it? You expose yourself to be suspected that there is a reason why you are so quiet about 3.97 behavior.

Between 3.93.1 (which was the last revision based on the 3.90 source code) and 3.97, there are nearly 3 years of development:
http://cvs.sourceforge.net/viewcvs.py/*che...y.html?rev=HEAD

Changes are countless, that is why I can not reasonably list them.
However, source code is publically available and lists all changes:
http://cvs.sourceforge.net/viewcvs.py/lame...y_with_tag=MAIN

The problem is that I am probably not much helping you by pointing to source code.

Thank you first of all.

I found 2 issues adressing abr/cbr presets and 1 explicit for 320 kbps ('fixed padding when encoding to 320 kbps').

I found a few issues explicitly adressing cbr, all about the use of X9 for selecting abr/cbr quantization selection.

Not so much help. Doesn't say 'there was a lot of explicit efforts on api'. Doesn't say the very contrary either.
Hoped you could for instance remember some explicit testing on api.
Sure I know this is easier said then done. If somebody would ask me to talk about some aspect in my own applications which is not so much in my focus and is about the develepment of the last three years I would run into some trouble too. Hope I would try to help.

[Sorry for my editing problems. Have some trouble with my PC too.]

From memory, 320kbps as been impacted in at least:
*ms/lr switching threshold
*masking adjust for long/short
*lowpass
*quantization selection
*analog silent detection in psfb21
*ath auto adjustment
*ath base level
*ath shape
*...
There are also the numerous fixes in psymodel since 3.93.1

There are many changes, but would it help you to know them? I do not think so, except if you intend to develop Lame.

I guess most of these improvements are not specific to cbr320.
You did a great job improving especially the vbr modes, and I am convinced you focused on exactly these (as long as you don't give an explicit other statement).
This doesn't mean you neglected the other modes and I have seen work on that.
But the usual thinking when going this way is 'these improvements are helpful too for the other things'. Which usually is correct. But not necessarily.
I remember dibrom mention in one of these old threads the high interactions between vbr and the psy model. Maybe tuning the psy model towards vbr might have a bad impact on cbr320. All just guessing.

Anyway within these old threads on 3.90.3 api I could get a feeling about the explicit efforts on api. I do not get that for 3.97. I read quite a lot of threads for the newer versions, but as I said interest must have gone from api.
Words and phrases are powerful (hallo Chigung). Maybe this loss in interest is due to the name of the presets 'standard' and 'insane'.

As so far thank you for your help.

For vbr we focused on vbr, but for abr/cbr we focused on abr/cbr.
VBR is mostly about having a good psymodel, while CBR/ABR are mostly about quantization selection and bit allocation, so while some parts are common, you have to work on them in a different way.


That means that current developements are not occuring here (HA).

... 3.97 was a bad short reference to the api development after 3.90.
I learned to know here on HA about the interaction between highly motivated users and listening experts like famed guru and the develeopers.
And that's the great thing with non-commercial software development.

Have to go to work now.

As promised I searched through the threads again for a listening test 3.90.3 api against later version api and came up with the Lame 3.96 vs. 3.90.3 thread I found yesterday: Lame 3.96b2 vs. 3.90.3.

owowo performed that test with 3.90.3 being the winner.

I continued my search but again couldn't find another comparison on cbr320.

I just abx'd the samples I showed up yesterday, but I couldn't abx them, neither with 3.90.3 nor with 3.97b.

However the fact that we are lacking api comparisons here on HA, more precisely we're lacking listening experience with api on the versions after 3.90.3, is meaningful as such experience is available for 3.90.3 api here on HA.
Yes, this is the now historic debate 'shall we recommend on HA another version? Is there enough experience, compared to 3.90.3'? For 3.96+ cbr320 no such experience is reported apart from the comparison thread given above AFAIK. For 3.90.3. you can read a lot of experience on api here on HA.

Anyway may be the phrase 'strong evidence' in 'There is very strong evidence that 3.90.3 api should be prefered' is way too strong.

Btw the statement that Lame development is focusing on the V2 range is backed up for instance by dev0's words when he introduced to the 3.90.3 vs. 3.96 test.
Same goes for JohnV's version history Lame version history.

for anyone wanting to update this, lame 3.95.x is missing, and the reference to "all future alphas" should simply reference "all alphas"


later