Thanks Alexxander.

something like this:
sfb21 bloat is possible with LAME settings -V0 through -V2. Due to faults in the design of the Layer III format itself, encoding audio of 16kHz and higher will cause more bits to be needed than normal. The Heavy Metal genre suffers with this sfb21 bloat problem sometimes. -V3 through -V9 do not have this problem as they have the -Y switch activated by default. This switch basically makes it where if the data above 16kHz will bloat the bitrate it is not encoded.

So, you only use it on the -V0, -V1 & -V2 switches.

If i remember correctly (if not, please correct me) this is "almost" right. The -Y switch does not work like a "lowpass"... its not like everything above 16khz will be cut off. What it does, seems to be that it is much more "selective" in which content above 16khz it encodes - with -Y on, the result typically was that only "significant" content above 16khz was encoded.

P.S.: It may be an interesting experiment for trained golden ears, to check if using the -Y switch actually helps avoiding killersample-artifacts at very high bitrates (V0-2)

AFAIK this switch deals with 'sfb21 bloat' problem. Look at "Scalefactor band 21 problem" here: http://www.mp3-tech.org/content/?Mp3%20Limitations

Also, some google search

Following in line with the -Y questions... I'm getting a relatively large bitrate bloat from -V3 to -V2. A good example of this is the Disturbed album Believe. At -V2 it averages 223 kbps. At -V3 it averages 171 kbps. I've only ripped six records in each... but this seems to be about par for the course.

For this particular sample (spill the blood):



I would give 4.7 (5.0 max) points for this sample.
I failed to abx -b 320

There is no serious distortion but -V 0 3.98b8 is easy to abx on this sample.

Very interesting cause for a long time I used 3.90.3 ABR @ 270kbps and preferred it a lot over ape. VBR is the right thing but it depends totally on the psy model. Weaknesses of the psy model make it into the output quality. There were samples which were so bad when VBR was used that this was a clear decision for me to use ABR (especially as I don't have to care about a bitrate like 270 kbps). ABR was the more robust (though less efficient) kind of variable bitrate usage than VBR. Same was true for me up to 3.97.
Things changed with 3.98 and with 3.98b6 I preferred -V0 over high bitrate ABR.

So I'm very curious about 3.98b8 -V0 and abr 270 results.
I will test my usual samples as soon as I find the time (will take a bit yet cause I'm pretty busy right now).

Just ABX-ed ringing.flac focussing on cymbals or hi-hat at 2.9 sec with lame v3.97 and 3.98b8, both converted with --ABR 200 (195 and 197 kbps respectively). I could ABX v3.97 without doubt but not 3.98b8, and I tried really hard.

As many members here think like 'we shouldn't care about ABR' do you mind providing us also with the results of the corresponding -V mode? Apart from that it would be interesting in its own right, especially 3.98b6 3.98b8 VBR vs. ABR.

Here go some results for ringing.flac with the goal to compare ABR and VBR of v3.98b8, I know it's a small set but there's almost infinite settings to test

v3.98b8 -V 2 (234kbps real) ABX-able but really tough, 8 out of 11
v3.98b8 -V 3 (200kbps real) Easy ABX-able, 10 out of 10

v3.97 --ABR 200 (195 kbps real) Easy ABX-able, 8 out of 8
v3.98b8 --ABR 200 (197 kbps real) ABX-able, 12 out of 13
v3.98b8 --ABR 215 (215 kbps real) ABX-able, 9 out of 10
v3.98b8 --ABR 230 (229 kbps real) Not ABX-able, 3 out of 8

Notice that as opposed to my previous post now I could ABX v3.98b8 --ABR 200, as it seems a break (dinner) did good to my ears (these guitars blow my mind ).

So in this case one could conclude that ABR does slightly better than VBR.

To avoid long posts I only public these two ABX-results (others available on request):

A minor question regarding tests between ABR and VBR:

Are you certain that ABR and VBR do not behave differently, depending on the length of encoded file? What i'm trying to warn about are "practically irrelevant test-scenarios".... so, results which lack relation to how a track is encoded normally, therefore being misleading.

With VBR, i suspect that it will encode the same, no matter how long the encoded sample is. But is this also true for ABR? Is the window-size of ABR smaller than a typically encoded "killersample"?

- Lyx

I have no clue but I just tried this: Encoded a 121 secs song with ABR 200 and this resulted in 196 kbps avg. Then I trimmed the wav file to a 10 secs sample and encoded it with ABR 200 and the result was 192 kbps. I'm not sure which would be correct conclusion.

Hopefully an expert can shed a light on it.

The reason why i ask is the following scenario:

Asume a VBR-encode does not allocate enough bits for a problem-spot. It will do this regardless of sample-length.

Now hypothetically asume, that ABR has a window which is significantly larger than the length of the sample. If we then encode this sample, ABR is forced to allocate the target-amount of bits during the sample. But if the entire track were encoded, the same mistakes may happen as with the VBR-encode (wrong distribution of bits). So my question is: can we be reasonably sure, that when encoding small samples with ABR, that its quality-performance then is representative of encoding entire tracks?

Wish to have AMD Intel compiles too

@lyx: Pending confirmation from the developers, i believe the window of ABR is a couple of seconds, if not less than one. This is not 2-pass encoding.

Thanks for the info JAZ.

I don't think the bits allocated to previous frames actually feedback to adjust bits allocated to future frames like you're thinking with ABR. I'm pretty sure LAME implements ABR much the same as VBR, just with less variation in frame size.

At least thats what the lame site implies:

http://lame.sourceforge.net/abr.php

I think to do what you're thinking effectively, you'd need a two pass encoder like MS's WMA codec.

IIRC from earlier posts misleading abx results can occur for ~1 sec at the beginning of a track.
ABR isn't VBR with a restricted variation of frame size. ABR is CBR (CBR does use variable audio data bitrate) but without the restrictions of the bit reservoir which are immanent to CBR in order to keep frame size constant.

O - generate SSE3, SSE2 and SSE instuctions
W - generate SSE2 and SSE instuctions
K - generate SSE instuctions

john already answered that:

http://www.hydrogenaudio.org/forums/index....;p=557489&#

To those unaware, it is the Intel compiler that is used. As already indicated, that does not limit the target processor audience to Intel, they will run perfectly OK on AMD cpus depending on the implementations of SSE, SSE2, etc.

How do I determine whether or not I need the libsndfile version of the LAME bundle at RareWares ?

Regards,
Madrigal

I have no idea what the "libsndfile" stuff is all about either. I can tell you that if you're using LAME for MP3 conversion with Foobar2000, LameDropXPd, or CDex then you don't need it. Just download from the other link. It contains both the LAME exe and dll files.

Cheers, Slipstreem.

AFAIK it just depends on whether you want to convert from formats not normally supported by LAME (PCM WAVE; MP3; MP2) and supported by libsndfile (of which there are many, incluing AIFF, SND, VOC, and FLAC).

That's absolutely correct. libsndfile supports a whole range of input file types that LAME doesn't, natively, but if you need stdin, then use the normal one.

Mac OS X build available here.

Wow! Its really fast in 64-bit mode, compared to 3.97.



No decent ABX application available for Mac OS X, so I wont be able to compare and post results.

That's because the default VBR routine has been changed. The difference is smaller if you choose the same one.

Please, could someone make a binary compatible with all Windows versions including Windows 95?

The actual binary in Rarewares is not compatible with Win95.

I will appreciate this a lot.

Thanks in advance....

From Wikipedia:
Visual C++ .NET 2003 ... is the last version to support Windows 95 as a target.

Maybe I'll get access to MSVC7.1 or MSVC6 later.
(btw win95 is pretty outdated )

Are you on win95? I hope not!

LAME depends on C-runtime-Dll (is this missing?) and Kernel32.dll only. What exactly isn't working on Win95? I don't think I can get my old Win95 booting again.

I truly do not see the point of encoding to mp3 on hardware that does not support later Windows versions. For example what would the encoding speed on a Pentium 133 MHz with 32MB RAM ? 0.1* realtime ?

The last time I checked encoding speed on my old Pentium 200 MMX W2K PC, it was around 0.7 * realtime. Who knows, maybe he has some GHz CPU running Win95?

So... Here is RAR archive with LAME 3.97 and 3.98 b8. They should work in Windows 95.

Finally I managed to do the listening test with beta8 I wanted to do so long.

I used 'my' usual problem samples: Birds, castanets, eig, harp40_1, herding_calls, lead-voice, trumpet, and trumpet_myPrince.
I added 3 samples from my 'voodoo' set. These are no specific problem samples, but samples that are not perfect to me (though in a very subtle way) even at high bitrate. The problem: though I have managed to abx this kind of problem 10/10 (and AlexB confirmed it) I am not always able to hear the issue (a lack of precision), but when I hear it it's rather obvious and not pleasing to my ears so I can't really ignore it. It's french woman singers that make it into the voodoo state. So I also took 'La Godiche' and 'La Où Je Suis Née' for my test, as well as 'Oh Carol' by the 'Smokies'. Just after 3.98b8 was released I had some CDs to encode, and I used 3.98b8 -V0 right away. To my surprise 'Oh Carol' wasn't perfect: no artefact, but a certain lack of 'vividness' as I'd call it. It's with the drums so maybe it's a pre-echo problem. Using ABR 270 fixed the issue. As with my french singers I can't always hear the issue however.

For a warm up I started using -V3.
Birds is okay to me.
I abxed castanets 10/10, but the result isn't annoying to me.
It's similar with eig (10/10), and I'd call the result acceptable with respect to this very hard mp3 problem.
The harp40_1 (10/10) result is a bit annoying to me, but it also doesn't come as a surprise.
More surprising especially as it is not expected to be a hard problem is herding_calls (10/10): I'd call the result slightly annoying.
trumpet (9/10) also is a surprise: it's pretty annoying to me at -V3 (shame on me for the 1 miss: I was rating the results too fast).
The tremolo of lead_voice (10/10) can be easily heard as was expected due to earlier versions.
The tremolo of trumpet_myPrince (10/10) however is not annoying to me.
I couldn't hear any problem with the 3 voodoo samples.

I continued with -V0 (only those samples that weren't ok with -V3).
castanets (9/10) is still not very hard to abx but I'm totally satisfied by the quality (no obvious issue to me).
The pre-echo of eig (10/10) is better now than with -V3, but the quality with this bad sample isn't very good with -V0 too. I guess I'm more sensitive towards pre-echo right now because with 3.98b6 -V0 I rated the eig result very good (and formerly I had a lot of problems abxing castanets at these high quality levels which actually is no problem at all).
harp40_1 (9/10) is a lot better now and very acceptable.
herding_calls (9/10) isn't a real issue any more though it's remarkable that -V0 doesn't fix it totally.
I couldn't abx trumpet though my suspicion is (backed up by the first guesses which were hits) that it's not totally perfect.
lead_voice (10/10) is still easily abxable, whereas trumpet_myPrince is okay to me now.

I also tried --abr 250 (with all the samples), and the differences towards the VBR test are like this:
herding_calls is no problem any more.
With lead_voice I arrived at 7/10. No fair comparison with -V0 though as it's a mono sample (but it matches the practice for people who are willing to use ABR 250 as a general rule).
Anything else is as it was with -V0, including trumpet which I couldn't abx, but I have the suspicion that it's not totally ok using abr too.

Okay, I am not any ware as astute at the many of the engineering people who really get into the deep and dirty nuances of differences in MP3 encoding settings. I am more of a pragmatist and think about what sounds best to me (depending on the hardware !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!), and size versus quality.

PLEASE explain to me why "floating point" in a VBR setting is a great feature. I ask totally out of ignorance.

Is this about the ability to use something like -vbr 2.5 or 3.5, when one is not sure or you want some a little better, but want a little less size ?? Is that what floating point means. I believe before, one can enter 2.5, but it will really default to 2 or 3, I forgot which.

Also, I rarely use MP3 anymore. I only use to post some audio on my web site, where "usually" the listeners audio client has their MP3 or more hopefully, M3U pointing to an audio player in their file associations.

Personally I encode my audio to either Ogg or FLAC.
I won't use any hardware/software (except for my DVD player, but it plays great Divx), that will not accept superior open source codecs.
My portable media player is a Cowon D2, 74 watts of power and quality wise absolutely blows away the marketing machine of the Apple Ipod.
Cowon natively supports the usual restricted Ipod ocdecs, but it also supports Ogg (up to Q10) and FLAC as well. I will play FLAC on my PC and use for archiving as well and use Ogg to upload to my SDHC card or the Internal flash of the Cowon D2.
For me, I feel that Ogg gives me a "fuller" more robust sound and I have a heck of a time hearing any difference between Q6 and FLAC or even a CD.

As I mentioned, I can't say enough that if one doesn't have the hardware, you might as well encode MP3s at -vbr 6 at best. But with quality output, like the Cowon, headphones that can handle wide frequencies ranges as well as the power of 74 watts, which means a lot more than just being louder, it means a much fuller sound and will allow more to be heard at lower volumes.
I also will plug my Cowon D2 into car stereos, DVD players (I can drive Divx movies from it) or playing music on receivers that output to good speakers.

Sorry that I digressed. BUT ....Please explain about the "floating point" advantage ??
What does occur if I encode to MP3 using 3.98 b8 at -vbr 3.4 or 3.7 or 3.5 ?? And do I understand the floating point thing at all ??[b]

Thanks,

Jon

Yes, 74 watts really would blow away any portable. Helluva battery drain too.

(I think you meant milliwatts).

But, does it go to eleven?

Cowon D2:
SNR 95dB (A-Weighted)
Frequency Range 20Hz~20KHz
Max Output 16 Ohm earphone : 37mW + 37mW