Now that we are are no longer holding our breath for a 'Portable' VBR preset, I have a question for ears better trained than mine.

Restriction 1: File size no bigger than ~ 160 kbps

Using Razor Lame, does the 'alt preset CBR 160' sound better or using the RazorLame switches to set VBR between 128 and 192?

VBR takes advantage of 192 when needed but is not 'optimized' like the CBR preset ------ABR is worse than CBR IMHO so don't suggest that!!!!

What do you think????

I disagree that the abr preset sounds worse than the cbr preset... don't have proof or anything but the concept of abr makes it better than cbr. I used --alt-preset cbr 128 for my portable mp3 player, but was informed that --alt-preset 128 (abr mode) would sound better. So i tested this myself and was very suprised to find that it sounded A LOT BETTER!!! (id say at least a 200% improvement, to my ears anyway). It was also slightly smaller than the cbr file as bitrates averaged around 120kbps for me... Experiment further and use abx and you'll hear the quality diference for sure!

Well, I haven't done many tests about that but as far as I know from what I have read LAME --alt-preset ABR is way better than CBR.

The new --alt-preset medium might be what you're really looking for.

ABR is not like VBR, it is not optimized by frame. If you select ABR 128 and you have frames that climb to 192, then you must have an equal number at 64 to keep the average at 128. That can degrade your sound.

But anyway, that is not for this thread - CBR vs. ABR is discussed in other threads. I am looking for feedback on alt preset CBR 160 vs. VBR using the Razor Lame switches with 128 as min and 192 as high.

This is not correct. ABR assigns 80% of the frames to the specified bitrate, lets say 160.

If a frame is judged by the perceptual entropy tables as only requiring 128, a smaller frame will be selected. If on the other hand the bitrate is insufficient and cannot be covered by the bit reservoir, a higher frame will be selected.

Try encoding fatboy with --abr 192. Nearly the whole thing is 320 frames.

Let's try this again. I've refined my suggested medium VBR preset commandline for alpha7. I used the samples in this thread for tweaking the output. I encoded 200 WAVs that I had sitting on my hard drive and the average bitrate came out very close to 150kbps. YMMV.

-V4 --nspsytune --nssafejoint --nsmsfix 2.0 --ns-sfb21 6 --athaa-sensitivity -15 -X 1,3 -Z

If your nose sticks up when you see -V4 try the http://static.hydrogenaudio.org/extra/samp...mples/erhu.flac sample. If the distortion is too annoying when encoding this sample with my commandline, use -V3. Of course, you will have to pay a ~15kbps bitrate penalty. Personally, I think -V4 works out well (given that total transparency cannot be expected at ~150kbps).

Note that this commandline will only work correctly with 3.94 alpha7 (and possibly future iterations).

Also, no matter what you try in the commandline it cannot compare to the optimization of Dibrom's real-time adjusting presets. For example, I selected -X 1,3 because it sounds pretty darn good most of the time. However, there are times when this noise measurement choice is suboptimal. When you do a commandline, you don't have the ability to change settings on the fly. Having a dynamically tweaked medium preset built into LAME would be a step above anything I or anybody else can conjure.

mithrandir, it's not a good practise to recommend the use of alphas for regular encoding outside alpha-threads, that's what I'm trying to teach people for example in this thread..

Are you gonna personally guarantee that there's no horrible bugs, like the -X mode thing in alpha6? Are you gonna guarantee the quality of your switch now (have you done extensive testing) and also in "future iterations"? Do you think it's good that people might start using alphas for regular encoding, the exact what I'm trying to prevent because of very good reasons..

Could be that while you think you are doing people a favor, you are doing the exact opposite. Alpha commandlines should be kept only in alpha threads, and not recommend those for regular encodings. Even if the line would work fine, nobody is gonna guarantee that it's the case in the next alpha.

This is one of the reasons why I'd like to keep the alpha testing in restricted forum or lame dev -list. Do you know how much work it is to me, if people start spreading these commandlines in this forum for regular encoding which work differently in every alpha build?

What's even more strange is that you said just yesterday after finding of that X-mode bug: "Ah, that's helps explains things...and supports why you shouldn't monkey around too much with these alphas".. Are you gonnna explain to every people using or tweaking your line, why it doesn't work in alpha8 because something else is broken..

I'm considering stopping my public alpha testing efforts at HA because of this. I don't like it if HA becomes this place which encourages people to use "wild lines" with alpha-builds for their regular encodings. I would understand the message you wrote better if it had been from someone less experienced, but you are an old timer here, and should know better..

My intent wasn't necessarily to declare "stop using 3.90.2 and start using alpha7 with this commandline" but rather, LAME has been undergoing many quality changes recently and if your current encoder isn't serving your needs, try this. You might like it. Perhaps because I am a software developer by trade I assume people understand that alphas are temporary devices to be used for experimentation only and not for permanent use. And since LAME is not a virus-scanner, firewall, or something that might have security problems (which could lead to financial loss), using a LAME alpha is a tolerable type of risk.

I have a tendency to be nonchalant because of the subject material. Psychoacoustic audio compression is not a life-or-death matter but rather an interest/hobby for most people. If I suggest some commandline with some alpha, I'm doing it because the downside (in the grander scheme of things) is petty. Now some may take issue with such a statement but I'd like to think my three decades of wisdom is serving me well. You are right: I can't guarantee anything. But if something I suggest fails, are people going to be hurt physically, financially or emotionally? No. That's where I'm coming from. My attitude is probably too cavalier but that's only because I do this for pleasure.

Look, John, I don't want you to take any of this personally. The time and devotion that you all make to HA and to all matters psychoacoustic is admirable and I'm jealous that I'm not able to make the same kind of commitment, being that I am out of college, work full time and have a house and yard to tend. There's no doubt that the "official" HA stance places quality, stability and sensibility above other ends and the community really needs a beacon of reason like HA. If r3mix were the only game in town, I don't think any of us would be happy. But I've always been more of an impulsive/hyper person so maybe my appetite for experimentation is at odds with the die hards who place the subjects discussed in these forums as close to their heart as they would political, religious or financial issues.

I'll concede to you that alpha stuff should be kept within alpha threads and we don't want HA condoning the widespread use of experimental encoding configurations.

It's just that:

1. Have you done extensive listening testing with your switch so that you have firm bases to recommend it outside alpha tests? Did you test all aspects (transient/impulse handling, ringing, noise handling, low volume, high freqs, etc. etc.) What tracks you used for testing?
2. Is it ok, if we change our practice and don't care that alpha wild lines appear everywhere. Do you think that the current practice is just nitpicking?
3. Will you do the research, education, and testing if alpha wild lines start appearing, or do you think it's ok to encourage untested alpha lines and then let it be my job to keep HA content even half sensible in the future?
4. If you promise to take resposibility about all above points, then go ahead, but I don't want more work for me in this issue. There's more imporant things to do than trying to desperately convince people that "alphas are not safe", while at the same time you as a senior member give the exact opposite impression.
5. There's gonna be more switches to tweak internal settings of Lame. I really don't know should we keep the testing and tweaking totally public, because it may bring more confusion and work especially for me (have to explain million times why something should not be used).
6. If you want me to continue drive the public testing of Lame alphas, you stop recommending alpha lines in non-alpha threads, unless you personally guarantee and take care of the quality now and in the future alphas, and promise to scan the forums and take care of the possible consequencies in the form of educating why somebody shouldn't use something in future alphas.

In the end, a FAQ would solve alot of problems... Though I would hope that most users are smart enough to realize that alpha builds are meant for testing, not archival.

Perhaps the forum regulars at HA can generally be expected to know the volatile nature of alpha builds, but I would wager that the majority of compressed audio users would not exercise the same kind of care towards the use of untested commandlines, FAQ or not.

There are still people advocating rediculous commandlines for Lame in other forums, and advocating inferior MP3 codecs, and denying the need for listening tests. How many people do you think actually use the --alt-presets because they truly tested them and found them superior to anything else, rather than using them because they were told to? I know I haven't bothered with testing anything other than castanets, drone, and fatboy, so I'm pretty much going on the recommendation of Dibrom and the other --ap testers.

I'm not trying to accuse anyone here, I just agree with JohnV that it's important to keep alpha testing "low-key". Still, I think that public discussion of the alphas is important; probably beneficial, or at least interesting to follow. If it wasn't finals week, I would be testing them myself, although not to the extent that JohnV has gone to.

I'm not always capable of determining how my posts are going to be interpreted. After re-reading my original post, I think I was being reasonable since I didn't recommend anything (just suggested) and I did have a disclaimer about the commandline only working correctly (perhaps "correctly" was a bad word choice) with alpha7. I hope that the kind of user who comes to HA has the ability to ascertain that what I posted is not an official position by HA nor am I stating that my commandline is somehow a preferred, iron-clad setting for current LAME versions. I guess I am making too many assumptions. It would not be a good position to add confusion.

My intention with these posts isn't to increase the burden on the alpha test leaders but rather to spark general interest in the whole process of these frequent encoder updates. Test these alphas on your music, get them on your portables and listen to them in your travels, knowing that you are part of a testing and evaluation process. Will you come across problems? Probably; that's just the nature of the beast. If you aren't comfortable with experimentation, stick with 3.90.2.

I guess I don't like the idea of having alpha testing pushed into a rhetorical room behind closed doors where a small clan people test with problem samples. If LAME were an experimental drug, sure, but I don't think people should be afraid of using an alpha or any other non-official release. It has to do with perspective. I see it as interesting and potentially insightful experimentation. You see it as potential confusion and "bomb-diffusing". I'm not in your shoes so it's harder for me to worry about how some people take these posts. But this is a fairly trivial matter (as it currently stands) so I don't want to spill more ink or involve more time than necessary. I certainly don't want to be the person that puts the whole alpha testing process in jeopardy.

i'd like to add that i understand both points of view about this discussion, but i really hope that alpha testing will stay public. maybe you could have another topic session in the mp3 section, so it goes general, Technicial and Alpha/Beta Testing... and keep a sticky post explaining that alphas are bad etc....

Anyway, just an idea...

Firstable, this is not about purely your setting which may or may not be good (you still didn't give any information what and how you tested), it's about impressions and principles. Alpha use just shouldn't be encouraged for regular encoding, that's what you will hear from every developer.
Secondly, what is also against HA's principles are these lines which are just "thrown" here without any indication what was tested, how the testing was done, how it compares to other settings, nothing. We don't want lines just thrown here unless there's even minimum amount of explanation of the above things. Basically we want justified recommendations based on extensive listening testing (hopefully verified by many people) if you are going to recommend something outside purely testing threads. This is even worse when we are dealing with alphas, which can and most probably will change from version to version.

Then do this in appropriate alpha threads. And anyway, I'm not any "alpha tester leader" although I thought that I should push the testing here, but I also said that it has to be made in a very controlled manner, meaning that alpha testing should be kept stricly in alpha testing threads. Not like this, that unjustified alpha lame lines are just carelessly thrown here and there for people as "good choice".
IMO people should be afraid of the Lame alpha quality problems. Heck, even the 3.93 Final was quite ****** ** release! Alphas have been broken or having some weird issues more times than I can remember.. Dibrom and I would like to keep HA as quality site which is not a source for missinformation or encourage behavior which may lead to very bad experiences quality wise.

Testing in alpha threads is ok, because hopefully everybody realizes, that if one uses something in alpha threads, nobody can really guarantee anything, and it may be totally broken or can be broken in the future alphas/releases.

Mithrandir, would it be possible for you to email me a *brief* description of some specific parameters used in your afformentioned commandline, and your reasoning behind why each was used, and why at that setting, if applicable. If and when you have a moment. I believe I've reached as much of an understanding of these parameters, by reading Lame's --longhelp and searching elaborately through this form, as I can without further aid.

Specficially, the ones which I'm interested in, in order to do some experimenting on my own, are nsmsfix, ns-sfb21, athaa-sensitivity, -X, and -Z. Everything else is fairly obvious to me.

By the way, I found your suggestion in the Alpha6 post to be quite effective as a medium preset iteration (albeit for that obselete version of Lame). On *the few* samples that I tested it on, the generated mp3's sounded notably better than their ABR counterparts encoded by Lame 3.90.2's alt-preset. My initial test sample was successfully ABX'd with greater than 95% confidence.

Disclaimer: I firmly believe in the importance of NOT advocating long, complex commandlines, for reasons which several people have already provided several times over. I am, however, *personally* interested in finding a medium preset (in the general sense) which tends to achieve bitrates between 128 and 160, which naturally goes beyond the current audio quality of CBR and ABR recommended settings within that range. Gabriel's suggestions further this general goal, and Mithrandir's suggestions (and they are clearly new and widely untested) do so also. Customized commandlines of the above nature that I test will never be provided or suggested online, in this forum or any other. My request is simply one of personal interest, such that I can understand the inner workings of specific Lame parameters to a greater degree. For testing purposes only, and not to be shared with the general public.

Thanks.

Heh..now I see this goes from one way to another.. Testing and sharing experiences is more than encouraged. You just have to follow simple guide line - doing the testing and sharing of experiences in appropriate threads... If somebody comes up with good reasons why alpha testing and alpha experiences shouldn't be concentraded on only specific testing threads, I will listen.

I thought your questions were rhetorical since I would clearly be a big liar if I said I performed much testing on my commandline...I generated it less than 24 hours after the alpha came out.

But as I said in my original post, I used the samples in this thread to come up with the commandline. It was basically a matter of "is the output as tolerable as possible for every sample?", tolerable being a subjective term and certainly not the equivalent of transparent. I got to the point where I was "satisifed" with how each of the samples sounded and then I encoded some of my albums for some "real-world" listening. I didn't perform ABX/ABA testing because it wasn't a matter of "is this transparent or not?" but "is this a good compromise?" Of course, I understand that such testing is ripe for criticism since it is not grounded in objectivity/scientific methods.

If 3.90.2 had a built-in Dibrom-esque medium preset, I probably would not have even bothered with this at all. But there seems to be a real need for something in the lower bitrates and I just felt the urgency to share the fruits of my labor. The way things are going in the 3.94 alphas, I don't think Dibrom's presets will work as well anymore (since they were hand-tuned for a different encoder basically) so it's like breaking new ground without stepping over other people's existing work.

I think that's pretty much understood, as long as alpha discussions remain public (i.e. maybe not on the portal page but accessible to all users who search for them).

That's great, except that those samples (except the vangelis which was fixed by improved block switching which hopefully ain't broken in a7 in this case) all deal with one similar aspect of certain quality problem. I personally would test wider range of different problem tracks, before recommending something outside testing threads.

Anyway, I've said more than enough here now.. further talk should go to alpha threads.

I'm no expert, though I'd like to think I know more about LAME's switches than I did a year ago, before I started visiting this site.

--nsmsfix 2.0 = basically it controls the stereo separation. You can save a lot of bits by compressing the stereo image. Of course, if compress too much you lose transparency. So this is a quintessential trade-off switch. Gabriel advocated a value of 3.0 for his medium preset but I thought the stereo separation was too limited. I ended up with 2.0 because it seemed a good compromise between bitrate and imaging. Note that this value is not an integer...you could use 1.93 if you want.

--ns-sfb21 6 = controls the masking for scalefactor band 21. The value is measured in dB. There are better explanations on this site about the pitfalls of sfb21 than I can quickly provide. Basically, if there is too much energy in sfb21, MP3 cannot use scalefactors at all for that frame. This leads to bitrate bloat. By using --ns-sfb21 you are increasing (or decreasing if you use a negative number) the masking for this scalefactor. By using a positive number, I'm basically saying store only the stronger 16KHz+ signals. This will put less information in sfb21 than if you didn't use --ns-sfb21 and with less information the chance of disabling scalefactors for each frame is reduced. I picked 6dB because APS uses 3.75dB...I wanted something a little higher.

--athaa-sensitivity -15 = changes the sensitivity for the ATH auto-adjusting function. The value is measured in dB. Now I don't know too much about this one other than what I can discover through experimentation. It is not the same as --athlower, which moves the entire ATH curve. --athaa-sensitivity seems to control the threshold where the ATH auto-adjust function kicks in. The ABR --preset modes don't use ATH auto-adjusting at all so you could argue that it's not an absolute necessary feature. If you have a track with a lot of silence or low-level information, athaa will increase the sensitivity (bitrate) of the encoder. This is a quality feature because while our ears are not critical of soft sounds masked by louder sounds, if soft sounds are the only sounds present, our ears become more critical of them. Of course, athaa can boost the bitrate needlessly. For compressed pop music, this setting won't have too much of an effect. However, it merits closer attention if you are encoding classical material.

-X 1,3 = controls what noise measurement modes are active (for quantization). This is probably the biggest "voodoo" area and you can really mess things up here if you don't know what you are doing (not like I know what I'm doing ). If you want to learn about the X modes, download this clip. The different X modes have a big effect on the amount of distortion during the clip's peak. With alpha7, -X is either one or two dimensional. If you give one value, you are setting the NM mode for both long and short blocks, If you give two values, you are setting NM mode for long blocks to value #1 and NM mode for short blocks to value #2. I basically went through many different iterations before settled on -X 1,3. This seemed like the best compromise between bitrate and quality. However, this is one area where things can go wrong because -X 1,3 might sound good for 80% of tracks but not so good on 20% of tracks (it basically goes for all the -X modes...there is no "ideal" setting). This is one of the biggest advantages of APS: it changes the -X parameter dynamically as needs change.

-Z = the good old noise shaping toggle. I hate this switch because it's poorly designed. LAME has 2 noise shaping modes: 1 and 2. NS 1 is generally the better sounding because it does not employ scalefactors as much as 2 (too much scalefactor use has shown to produce some artifacts). Unfortunately, -Z means "use the other noise shaping mode". If you don't use --verbose, it's not apparent what is the default noise shaping mode. People often say "use -Z" when they really mean "use noise shaping mode 1". If NS mode 1 is the default, -Z makes this NS mode 2. LAME should really ditch the -Z and include a selectable NS switch. Anyway, I used -Z because LAME VBR uses NS mode 2 by default and I wanted NS mode 1. Note that APS uses both NS modes 1 and 2 (on a dynamic basis) and adding -Z forces APS to use NS mode 1 only.

Oops, you said *brief*. Oh well!

I am opening myself here for the ominous "no, you are wrong" replies, but that's fine if they are warranted.

NOTE: This thread really should be split because it has nothing to do anymore with the original post.

I can't believe what happened to my thread! That the search for advice on how to best use Razor Lame to get a file size as good as possible that is less than 160 kbps!!!! Oh well, it is a good discussion.

I thank Mirthandir for his 'suggestion' and respect John Vs objectives as well. I think I'm just going to stick with CBR 160 for now as nothing seems to be finalized. I am ripping everything to APE and putting it on CD anyway so one day when there is a great setting (whether it be MP3 or OGG or AAC or other) that is playable on all portable devices, I can re-encode with it.

I am also glad to see others share my interest in a lower bit rate optimized pre-set. Let's face it, the best use for MP3s is in portable devices. Otherwise, just play the original CD!!! APS is awesome, but its really only practical if you have a 120GB hard drive!!!!

By "APE" you mean Monkey's Audio not Alt-Preset Extreme, right? If you plan to re-encode your music, make sure the initial iteration is lossless like Monkey's.

that equals for vbr as well if you are tageting the same bitrate ?

or are you givin VBR that advantage infinite bitrates but hampering you abr with a target bitrate when comparring ?
that not just the way to compare things. like compareing to cars with one going on the highway an another in the city a 4 o clock.


If you a average bitrates off xxx and vbr is going higher then xxx then you most also have som values that are lower then xxx
just as with abr.

Actually, the difference is that NS 2 uses more often scalefactor scale (scalefac % in encspot), which means that the scalefactors are multiplied by 2 (more in here), which has several consequensies. It gives better compression (more dynamics in quantization), but with the risk that sometimes psychoacoustics fails (like in liebestod and erhu, and some others) and clear audible noise is introduced, especially when "not too strict noise measurement comparison" (-X mode) is used for long blocks. Because cbr/abr bitallocation rely on perceptual entropy, it's not so prone to this as vbr, where bitallocation rely more on masking curve.

NS 2 may (or may not, depending on the setting) be useful,if it works correctly, especially at lower bitrates cbr, or when you want to reduce vbr-bitrate. For vbr problems are these cases like erhu.

Since with NS1, scalefac_scale is used much more rarely, vbr is clearly less prone to fail with clips like erhu when NS1 is used.

What I would like to see is, that there would be some switch to control a threshold where you could adjust scalefac_scale sensitivity so it could be used a bit more than with NS1 or a bit less than with NS2.


Btw. even if you do know something how some of the switches work in theory, it's still no justification to recommend alpha use outside alpha testing threads. This goes for everybody, Lame devs included. Theory never replaces extensive listening tests.

APE means Monkey's Audio - Losless