I know the 3.90.3 vs. 3.96.1 vs. 3.97 has been debated to death in these forums. However, all discussions revolve around aps (v2) and ABR 128 (v5) and other optimized settings. For CBR 192 encodes, which is the best version? Or does it matter? Are the primary differences betwen the the 3.9X versions in the 'optimized' settings?

....and yes I know 3.90.3 is the recommended version. That is based primarily on the tested preset settings. I'm wondering if it applies to CBR as well.

If you know that to be true.. Then you should know that you should be using VBR.

Why bloat your files with constant rate? I don't know of any modern (within about the last decade)
that should have any problems decoding vbr.

People that generally rip at 192 CBR are people that don't know any better and are still using Stereo instead of JS.

However in answer to you question besides ABX'ing it for sure, I seriously doubt
you will be able to hear that much if any of a difference if any amongst those though I
gather in the spirit of evolution 3.97 when final would be the best choice.

I use LAME 3.90.3 preset standard. The most tested version of LAME, worked on and optimized by the original development team. There are other reasons to use CBR for certain applications however and thus my interest.

Also, how does the Fruenhofer (sp?) MP3 encoder included with WMP compare for CBR settings only? (it is well established the optimized VBR settings with LAME beat all other MP3 encoders and do not want to open that topic up to discussion!)

2nd gen iPod minis

Actually, there can be several reasons to use CBR over VBR so there's no reason to lecture the guy.

I think I read 3.96.1 is slightly better for CBR than 3.90.3, but you'll probably won't hear much difference. With 3.96.1, ripping goes a lot quicker though. And I don't understand why some people dislike 'CBR' so much, it's not that bad!

I generally think it's because CBR is an inefficient expenditure of space if you're able to use VBR; it wastes bits when the music is easy to encode, and runs short on bits when things get tough. There are, however, a couple of instances where you might need to use CBR, such as for muxing with video in an AVI container. Last I checked, VBR MP3 audio had sync issues when put inside an avi container, so there's one legit use for CBR.

Ezra2323 has been around here a long time, so I'm sure he has a good reason for using CBR. As he already stated, he uses -aps for most of his encoding.

That said, I would error on the side of 3.96.1 as opposed to 3.90.3. Although I am not aware of any ABX tests being done on 192kbps CBR, 3.96.1 seems to be a bit better than 3.90.3 at handling micro-attacks and pre-echo on certain samples I've thrown at it (though I no longer use MP3 at all for my encoding purposes). Again, that's just a result of cursory inspection, and not meant to be taken as evidence. YMMV.

Thanks for the responses. For my CBR encodings, I will use 3.96.1.

Slightly off-topic but responding to an earlier comment - I'm bummed Apple did not fix the stuttering issue with the latest iPod update. I was in the processs of converting my AAC 192 to MP3 APS 3.90.3 (not direct transcode, replacements from Apple Lossless files via dBPoweramp which keeps the tags) but am slowing this process way down as I'm not sure I want all my files in APS if the issue persists. That is not the reason for my CBR question however.

I wonder which will come first?
1) widespread AAC acceptance off of CD/DVD media (car stereos, DVD players, boomboxes, etc)
2) Apple fixes the stuttering issue
3) iTunes/QT VBR AAC

1 would be my preference. I would go AAC exclusive if only it was easier to port.

Well I didn't mean to pick on him... Wait yes I did ..while I'm sure there are a few reasons left to use CBR over VBR
but there becoming less by the day especially at high bit rates unless of course your plagued with one of those
stuttering hardware players or battery gobbling portables.




Short of using a better container like MP4 or OGM, AVIMUX GUI works wonders for muxing VBR with AVI.

I'm aware that your question for CBR is not solely related to the stuttering issue of the 2G iPod mini.

However the following encoding options produce mp3 files that do not stutter:
lame --preset standard -B 256

192 is far more versatile. Try cutting a VBR file with a CUE. all the cutters arround screw the file, headers get messed up, cutting is done on wrong positions...

Is that setting the minimum bit rate to 256? What is the approximate file size (bit rate) that command line produces?

by the way, about 3.96.1... where can the authentic 3.96.1 be downloaded? I have 2 versions that both say 3.96.1 that have different file sizes for the exe and the zip file having different files inside. ???? ones exe says it was made 7/29/2004 the other lame exe 7/26/2004

http://www.rarewares.org/

Which one would be best to be used with eac and with the preset extreme setting? there are a few downloads there all under 3.96.1

Just grab the top one (Bundle: includes lame.exe, lame_enc.dll (ICL4.5) and lameACM.acm (ICL7.1) 2004-09-14) and use the executable.

ok thanks, this is actually one of the versions i have. The other one says its from mitiok in the readme. The mitioks exe is slightly larger and a few days newer... wonder what the difference is. both say 3.96.1

No, it restricts the maximum bitrate to 256, (-b xxx is minimum, -B xxx is maximum, see LAME docs). Usually this is not a good idea, quality-wise. But if it fixes playback problems on a broken player, oh well... and if the player can't play --aps files without problems, i would consider it broken by design.

wondering whether it's worth starting a new thread just to know if there are any differences with lame 3.96.1 from rarewares and mitiok. Does anyone know why the exe sizes are different? I can't seem to find anything on the topic.

Simple. They were compiled using different tools.

Occasionally some odd compile of LAME somewhere will not work 100% as intended, but this is very seldom the case with Mitiok and other folks here.

When considering CBR ONLY, and higher bit rate settings - how does the Fraunhofer MP3 codec included with WMP 10 compare with LAME 3.96.1? I know Roberto conducted the linked test

http://www.rjamorim.com/test/mp3-128/results.html

in which LAME 3.95 edged out Fraunhofer. However, this was at a VBR setting, at approximately 128 kbps, and I'm not sure if the Fraunhofer codec used (from Adobe Audition) is the same codec used in WMP 10.

Please, no discussion of Fraunhofer vs. LAME at VBR settings. Per Roberto's tests, LAME has proven superior.

Well, I think FhG uses plain stereo at this bitrate. At least I have seen this in EncSpot on some encodings. (May have been old encoder) The files were marked as joint stereo, but the graphs showed that no M/S frames was used at all. Lame of course uses real joint stereo switching between M/S and L/R. This doesn't prove anything of course...

After experimenting a bit with LAME CBR 192, I do not find the sound quality acceptable to my ears (unlike AAC 192 or LAME APS). Does anyone have much familiarity with LAME 3.XX CBR 256? Do you find the sound quality transparent on most samples? Theoretically it should be, as my "average" APS files do not reach for the 320 setting on more than 15% of frames.

As stated, I have a need for quality CBR encodes. I use APS for my standard encoding.

On a CBR related note, why are almost all on-line record stores CBR users? Why not use VBR? As far as I know, only allofmp3.com and emusic.com offer VBR files. Everything else is CBR.

I can think of two possible reasons offhand.

1) They are intentionally crippling the quality of the files they offer
2) They play on some unfounded myths that VBR's quality fluctuates and that CBR is superior for quality. They also usually use simple stereo instead of joint stereo for the same reason.

???? I have never seen that myth/argument. Where have you seen that?

If you don't mind some speculation from someone not in-the-know:

Player compatibility is probably a significant enough factor from their perspective.

Then to some extent it's probably also a "dumbing down" of their product to appease the lowest common denominator. As you probably know, a lot of the uneducated masses just don't understand the benefits of vbr encoding, and don't trust in it. They often assume the opposite of the truth: that the sound quality must be fluctuating.

I had an almost 2 hour argument in an IRC channel before where it was me alone vs about 100 other people and everyone thought that when I broght up VBR. I'd say from that that my assumption that it must be a common belief is most likely to be correct.

FWIW I ended up giving up that one. Too hard to try to convince a mob.