Hi, I've got a cheap portable player that only plays mp3 or wma. Currently I'm using Lame 3.97B2 and I encode at -V5 for the portible. This quality is fine for this cheap device but I want to try and squeeze a bit of extra music into it by encoding even smaller. I'm pretty sure that in the poor listening enviroment I use this portable that I can get away with lower quality without noticing it.

So I thought about going WMA CBR96 but I'd really prefer to stick with mp3. So is there is there any preferred version of Lame for low bit rates like 96kbps ?

Also I remember reading somewhere that ABR or CBR can be more reliable than VBR at low bitrates. Does anyone know whether it's better to go -V7 or whatever to get about 96kbps or better to go either ABR or CBR 96?

I also had a cheap player supporting only mp3 and wma. It was broken pretty soon, and most of the time I used 3.96.1 -V5 (3.97 wasn't out then).
Out of curiosity I did some listening tests later which included the 100 kbps range. To me wma was better than mp3 when chosing the bitrate oriented VBR method available in Microsoft's WMEncoder 9 (target bitrate 96 kbps). (Real great for the bitrate was Vorbis -q2, but this is another story).
If you accept some lacking of high frequencies mp3 was quite alright to me too when letting the encoder resample to 32 kHz (I think current Lame does so automatically when going for abr 96 for instance). If you care about high frequencies you can try the lowest abr bitrate that doesn't resample to 32 kHz. With my test then that was abr 104, but this might have changed with current Lame. As for abr versus vbr I don't know whether abr is better than vbr in this bitrate range.
FhG mp3 encoders are said to have special treatment for this low bitrate range, but I have no experience with that.

ok, I will tell you what I prefer at 96 kbps. It's Lame 3.93.1 with this commandline: "--alt-preset [cbr] 96 -h" (cbr is optional). I found it somewhat immune against bad artifacts, and you can even use the -k switch to bring the lowpass 1 khz higher (to 16 khz, maximum bandwidth at sampling rate of 32khz) and still don't have too much artifacts.

J.M.

Next to lame I'd prefer MP3pro for 96 CBR...

but if you want lame for that I don't know which version is the best, sorry.

It's still true with 3.97. Even to my modest ears there's a big difference between --abr 96 and --abr 104
{edit}must have been thinking of something else...

It's doubtful his "cheap portable" even has any support for the SBR technology in MP3Pro...

Yeah there's no mp3-pro or ogg support. Yes if I had the choice it would be ogg-vorbis for me at this target bitrate but I'm stuck with mp3 or wma.

Thanks for the tip about ABR 104 not resampling to 32kHz. Ok I've just tested the latest 3.97 version against the older 3.90.3 version, both at abr 104, and I cant tell any difference. So I might just go with lame3.97 at --preset 104 as it sounds quite alright on my portible at this bitrate.

LAME's resampling to 32 kHz should not result in any loss of high frequencies because it does not do it until the lowpass filter is already filtering below maximum possible frequency for the sample rate. Example:



In theory the lower sample rate should improve the quality (which is why LAME does it in the first place) so I am surprised to see that people are saying that it makes the quality worse. I just did a very quick non-blind test between --abr 104 and --abr 103 and I could not hear any obvious high frequency differences.

This is a good point.
I remember that when comparing abr 96 against abr 104 high frequency bahavior was better to me with abr 104. But now I really wonder how I got at this result. I don't remember the version I used but I just tried a lot of versions and it was all as you describe. Lowpass is pretty much the same, also at 96 kbps.
I also did some listening with different versions below and above the resampling border. This confirmed you are absolutely right.
BTW I'm pretty impressed by the quality attained at such a bitrrate. Even my standard real bad samples weren't too bad when resampling to 32 kHz. Regular music is very much enjoyable, so for a portable in poor listening environment I think using abr 96 ... 102/103 (102 in case of Lame 3.93.1 in order to resample to 32 kHz) is very appropriate.

I'm using the --alt-preset 96 and the 3.97b3 provides better quality. The loss on treble is perceptible more than in the 3.93.1 but in this version the sound of plates of battery sounds very worse

Perhaps you should even try another codec at this bitrates (FHG).
Have a look at this post:
2Bdecided in [Discussion] List of recommended LAME settings, V2 (for LAME 3.97)

lame3.97 --abr 104 has a ~15khz lowpass
lame3.93 --alt-preset 104 has a ~16khz lowpass (and I would recomend it over 3.97)

both have about the same lowpass at 96kbps

You might consider trying something like lame 3.93.1 -Z -q 5 -V 9 --resample 44 --lowpass 16 --nspsytune which should result around 96kbps or maybe lower (I've seen averages in the mid 80s with this). Lowpassing somewhere around 18khz can even average out to around 96kbps depending on the type of music (not heavy metal). Try 32khz as well, just use --resample 32 instead of 44. In tests that I have done, averages are usually around 80kbps.

@gameplaya15143

Please refrain from giving custom command lines like yours without pointing to ABX tests to prove superior quality to the original command lines.
Thank you.

Motivated by the FhG proposal I just did a little test with FhG fastenc and alternate.
For some reason my Musicmatch Jukebox 6.1 installation did not work, so I downloaded version 7.00.149 from Oldapps.com and installed it.
This MMJB version includes the "good" fastenc and alternate codec according to ff123's page.
Unfortunately I couldn't succeed in changing the encoder's lowpass when using 'Convert...'. So CBR was unusable as with 96 kbps a lowpass of ~12 khz is used (judging from spectrograms).
With VBR it's different, as fastenc then uses a lowpass of ~16 kHz. I used Option > Settings > Recorder > Advanced: Processing Level: Very High.

With this I was astonished about the robust quality at VBR 25% (~95-100 kbps).
My standard bad tonal problem samples (harp40_1, trumpet, herding_calls) are encoded astonishing well for this bitrate. With respect to trumpet and herding_calls this is very remarkable as fastenc doesn't resample to 32 kHz (which was an essential step for these samples when using Lame). harp40_1 of course still is pretty bad in an absolute sense, but this really was to be expected.
As for general music quality is quite good too to my ears. I could abx 'New kid in town' without a lot of pain, but deficiency isn't so obvious that I would expect it to be heard in an environment not particularly suited for high quality listening.

Because of the robustness of this codec (which by the way was mentioned already a few years ago by ff123) it is sufficient to just take some favourite samples from the musical collection, try some VBR levels and see if it is adequate. With VBR 35% (~105-110 kbps) for instance I could not abx 'New kid in town' any more (using the same amount of effort as I did with VBR 25%).

Hi Halb. Do you know if it's possible to get hold of that fastenc version as a stand alone program of do you have to use it through MMJB ?

BTW. I've found an old version of fastencc (V1.02). I dont know if this version is any good or not.

Anyway I'm trying to figure out how to set up the foobar command line interface plugin to work with this encoder. The command I want is "fastencc.exe source_file destintion_file -vbr 25" but I dont seem to be able to make the cli plugin work with this encoder. Does anyone have any tips?

This encoder is based on old and buggy libraries stolen from Fraunhofer. I don't recommend using it.

Unfortunately: no. I'd also prefer to use it from within foobar.

After having tried quite a lot of mp3 encoders in the 96 kbps range I found I missed out Helix.
Helix can be easily put to work from within foobar, and according to a former test in the 200 kbps range it behaved astonishingly well. All my seriously bad tonal problem samples were encoded at my 'not-at-all-annoying level' with a setting that takes ~200 kbps on the average of 'normal' tracks. Thiis was the best result among all the mp3 encoders I've tested.
I used level's setting from the HELIX thread then which is a bit cryptical. Unfortunately there is no support from the Helix people to provide for user-friendly simple parameters that are optimized internally.
I used the same setting for my test now, just changed the -V setting to get ino the 96 kbps range, and specified a lowpass of 15.3 kHz (default lowpass is pretty low).
So my foobar CLI usage was: - %d -V20 -X2 -SBT450 -TX0 -HF2 -F15300

In contrary to fastenc VBR Helix did resample to 32 kHz and did use joint stereo. Technically speaking this is advantagous.
I enjoyed listening to "normal" music, but as for that I can't state serious differences between all the encoders I tested and within this tiny test. For listening environments where a very good concentration on the music is not the case they are all adequate to me.
As for trumpet, herding_calls and harp40_1: trumpet and herding_calls are of a good quality level, comparable to fastenc. harp40_1 is worse, but this is of relative value as it is pretty bad with fastenc too (as well as with all the other contenders).

So because of this good quality and ease of use from within foobar this is a very good choice too.

halb27: it seems to me that you are using some Lame problematic samples, and only those, to asset quality of other encoders. Of course they are likely to sound better than Lame on those. But you must keep in mind that we do not have a collection of FhG or Helix problematic samples yet.

It is acknowledged that Lame have some problem with some specific samples. Acknowledging about some problems does not mean that there is no other problem with other encoders.

Thank you Gabriel for reminding it to other people. Just a little precision: harp40_1.wav has encoding's issues that are not specific to LAME. This sample is a part of the EBU SQUAM project which seems to be 18 years old.
But trumpet.wav and herding_calls.wav are both samples which were recently discovered by people using LAME and who were badly surprised by the unusualy strong artefacts that appeared with the latest LAME encoders. These artefacts are not only specific to LAME but are also in a manner of speaking true champions in horror (i.e. it's very hard to find so obvious encoding's issues). Even ISO encoders such as Blade don't suffer from the kind of artefacts audible with both trumpet.wav or herding_calls. These artefacts are real problems for LAME of course; they can't be minimized but they can't be generalized too and certainly not be used as only material for any kind cross-encoder comparison. The results are necessary biased (current LAME encoders will always be inferior to all competitors each time)... and useless (an encoder could handle very well these exceptional situations but also be crap on the most usual ones and this small test won't even reveal it!).

I am just about to do listening tests, cause I was aware this morning that I was writing quite euphorical about FhG and Helix encoder. Though I did tell about former Lame experience in a quite positive way this might give the impression that FhG or Lame are better to me.
Apart from your correct statement the plain fact is that I never did a comparative test. I just reported about my impressions when actually testing. And this might give a wrong impression.

So I felt I should do a comparative test.
As for the value of this test: To me all the encoders tested at bitrates of ~100 kbps are adequate for listening to "normal" music in a non-perfect listening environment. Sure there will be a difference between encoder general quality but I am not the one to make such differences clear. As for that the best source available maybe guru's 96 kbps listening test, and as for that Lame 3.97a11 came out better than FhG fastenc vbr 20/30 IIRC. But even guru's test has a restricted scope be alone for the number and versions of encoders tested.

Not everbody might agree but to me codec robustness is important, especially in the case when general quality is quite alright for all the encoders in the listening environment under consideration. I just want to have a satisfying quality even in bad circumstances.
For this I have my three bad tonal problem samples on which I can hear differences easily. I'm quite aware that this is not sufficient to judge about quality in a general sense. Sure I think a bit like 'If an encoder gets by with these samples in a satisfying way there is a good chance that it will do so in hopefully many other problematic situations too'. I'm aware of the limited justification for thinking like this, but I'm also aware of the limited value of any listening experience. It's not adequate to compare my little tests with say the last 128 kbps listening test, but even such a well prepared test with many people participating has a limited value (considering the very good outcome of 3.97b2 and the flaws - sorry I call them flaws - that were experienced later). To me any experience on encoders is valuable, but always in a restricted sense.
As for the character of my samples and it's anti-bias towards Lame: Historically that's absolutely true for trumpet as I ran upon it when using 3.97b1 and was absolutely frightened when hearing it. But while it is (or was) a very special problem sample for Lame it also shows up problematic behavior with other codecs. With herding_calls it's similar, but the scope of being problematic for different encoders is wider. As for harp40_1 this problem sample is not Lame-specific at all, and any codec has some problem with it. Taking it all together I admit the choice of these samples has some anti-Lame bias though it's not very essential to me nowadays with 3.97b3 and 3.98a3+ where especially trumpet has improved a lot. And as for my current little test judging so far it doesn't look like these samples have a negative bias towards Lame at all. herding_calls and even trumpet provide issues for other codecs too, not to say harp. I cannnot continue my test at the moment (my wife is working in the same room again and she absolutely dislikes my listening tests), but it looks like Lame encodings resampled to 32 kHz as considered here are very good as compared to the other mp3 codecs. Especially the difficult first tones of harp are very good for the bitrate when using 3.98a6 -V7 (but there is something wrong with/after the last tone). That's the main problem to me at the moment: The problem with these samples is that the problematic parts are not always at the usual place (usual from what I'm used to at high bitrate). So it's not easy to say which codec is better. But this is all just from a first short listening.

EDTED:
As for the 3.98a6 -V7 statement I mixed that up: Out of curiosity I tried 3.98a6 -V7 and found a tremolo effect with trumpet (of the kind I had noticed with another sample using 3.98a4). As I knew 3.98a3 didn't have this tremolo effect I tried 3.98a3 -V7, and it is with this version that I find the first notes of harp better compared to other encoders but with a strange warbling effect at/after the last note.

To judge LAME or any encoder on 2 samples is wrong and I've said it before. The overall stability is what matters and the non-LAME encoders do some bad stuff on common CD's . I've had problems for a while but too lazy too post them. I will post 1 sample that Helix cannot encode at common 128-192k bitrate - actually the whole album sounds bad and I won't encode it with helix. You will see that with sample its not just 1 second of problems , but 15 seconds.

Sample is from the track 'serpentine' from gothic band Flowing Tears.


http://www.hydrogenaudio.org/forums/index....showtopic=47955

Hmmmmm ... I should really keep from making comparative statements of the kind I'm about to do. This is not my world.

As a final word on comparing the various encoders on 'my' samples at ~100 kbps: they just behave different with no encoder being really on top. Especially fastenc vbr isn't better when comparing directly with various Lame versions.

I began to before, but now that thread lies in the wastelands of the recycle bin. I would provide abx texts for everyone, but I fear they will simply suffer the same fate.

My suggestions are simply suggestions. It is up to anyone interested if they want to try it out. They can make up their own mind if it fits their needs or not.

Give the ABX now then.

As already said, this is not an "oppinion" forum. it is about "facts". That's why we want people probing (spelling?) what they say, if that goes against the *common* believe or statements.

It's up to you to *have* an oppinion, but posting it in the forums is a different thing.

In the end, people here look for knowledge. This can only be achieved if there are facts written, and not beliefs. ABX, problem samples, maths, theory... whatever fits it.

Alright then, I shall prepare a little listening test for you all (er some results anyways)
lame3.97b2 (unless I happen do download b3) -b 96
vs.
lame3.93.1 --alt-preset cbr 96

Perhaps I'll throw in mp3enc 3.1 -br 96000 -bw 15000 as well. (fastenc lowpasses at 12khz so it is disqualified). I will probably lowpass the source files at 15khz to make sure it's a fair test.

If you have any objections/suggestions to my proposed settings, post them quickly, I plan on doing this tonight.

I wonder why do you want to do an ABX test with CBR, when you gave suggestions on using ABR as well as a custom VBR commandline (the latter being mostly the reason of the initial advise on providing ABX results)

I guess I wasn't finished thinking when I typed that

Anyways, here are the results of my little test from a few days ago. Target was ~96kbps.

Test notes/summary


abc/hr logs


MrQ analysis


Enjoy

edit: spelling

Did the test with "scooter_fixed" ( located in the autumn 2006 upload thread )

3.93.1 downloaded from reallyrarewares

3.97b2 downloaed from rarewares (some time ago).

The settings were the same as your 1st and 2nd ( 3.93.1 -V 9 -q 5 ... , and 3.97b2 -V 7 --nspsytune )

listened with headphones ( some sony 7505 , closed headphones ) at a moderate volume. soundcard was only an AC97 included in motherboard ( yup.. noisy... )


It was a fast test ( took 5 mins only ), but while i could differentiate 3.93.1 (as shown by the log), i coudn't with the 3.97 one. The drums sound worse.





MrQ



EDIT : Wooops!!! i realized i used a wrong setting.. I've done a new ABC/HR test with lame 397b2 -V 7 --vbr-new . I focused to another part of the file this time.

The 3.93.1 setting has warbling (clear artifact of "not enough bits" ). The 3.97 --vbr-new had some "clic-like" noises. :



MrQ



I wonder about the " (fast mode) " text on MrQuestionman report.... in the encoding it shows that it is using -qval=3 (see below)


Also, here's the encoding time:



(phew... i hope this is the last edit!)

Wow that's a really long winded command line there, but also a really impressive score for 93kbps audio! Just a few quaestion because I'm not very familar with some of the test procedures. How exactly are those scores (like 4.0 and 4.2 etc) derived? Is is true that they represent how bad the artifacts sound from 1="very bad" up to 5="transparent". Also, are the scores derived from a blind test or do you know what file you're listening to when you rate them?

BTW. Are all those command line options really neccessary are some just for show. Like isn't "-m j" the default value anyway. So I'm wondering if any others are default and what is the minimal command line you'd need to achieve the same result. Can it be simplified?

PS. Thanks for posting the tests results, they're very intreresting.

@uart :

gameplaya is saying that the setting he's suggesting gives better results, while i believe it doesn't ( for once, he's using -p , which basically means there are bits just not used for music, but only for data "verification").

*His* ABC/HR test gives his commanline a preference, while the single test i've done says the opposite. ( and yes.. 1="very bad", and 5="transparent")

For more information about ABC/HR, see : http://ff123.net/abchr/abchr.html
Basically, it is a program to rate, blindly, different samples.

-I don't have the scooter_fixed sample yet, it is on my 'things to get list' though.
-I also have ac97 sound on my laptop which I used in my test.
-Naturally lame 3.93.1 isn't optimized for my choice of settings. But IMO its shortcommings are outweighted by its strengths. (ie use -k instead of any lowpass) I suspect that the problems could be tuned out, since most have been in the latest lame (new lame vesions perform very differently though, particularly with sfb21 at very low bitrates).
-'fast mode' means --vbr-new I think.

4 was 'perceptable but not annoying'. The one that was higher was because it took me an extra listen to figure out which one wasn't the source.


No. I just posted the full commandline that I was passing to lame via dbpoweramp. Ultimately -q 5 -V 9 -Z --lowpass 16 --nspsytune would get the job done. The other ones are just there because I play with them sometimes and I don't want to have to refer back to lame --longhelp to remember the commands.

-p adds about 1kbps to the average bitrate. --strictly-enforce-iso adds a little sometimes as well. -Z can a bit too (seems to increase encoding speed). -q 5 is used instead of -q 2 simply because it encodes so slow (ps. -q 0 bug is obvious, lowers the bitrate though).

here