I'm very sorry to have to "criticise" (it's very constructive ;) in my very first post here, but I tend to post stuff I consider really necessary so with the huge amount of compliments here I refrain from adding the hundreth "Great work" post.
My problem with this site and things regarding it is in its clarity or better the lack of it. I really find it hard to understand how people take huge amount of time for testing the various switches, a considerable amount of time posting in the forum and not taking a few minutes to come up with a decent documentation which this really good work deserves. I don't think it's too hard having & mantaining a dedicated page (not just discussions in the forum) where the development of the work is properly documented (what's the current status, respective history and so on). Right now things are only described in the forum and usually only in regards to the past situation so you never get an absolute description but only partial descriptions (taking for granted ALL readers know everything said in the past), which mostly make sense only if you have read everything that preceeded them. I believe we can all agree that this is not very user friendly - even I who have followed this scene for a long time and am quite familiar with it, sometimes find it difficult to get all the info I need to decide exactly what and how to use to get the results I want.

My suggestion therefor is that you put up a page describing your LAME development (and for any other similar project that might be going on here) which would have something along the following lines:

Current LAME compile is: lame_dm_XXX.zip (with links to it, so one can always know which page to check to get the newest available compile instead of hunting thru pages and pages of discussions where links are posted now).

Short description of this new lame compile's properties (absolute!, not relative to the older ones or who knows what).
What's new.
The available presets (switches).
The correct usage of this presets.
Special notes (if necessary).
History (optional but recommended).

Besides this descriptive page a file_id.diz file with the same info should be included in every new compile you release so that just by getting the zip and reading this file one will know what that file really is, what it does and how to correctly use it.

Judging by my experience doing similar stuff this shouldn't take more than 5-10 minutes for every compile but it would really make a lot of difference for the users (the idea behind the presets was to make lame more user friendly, but having such poor documentation of them makes their introduction somewhat pointless). Hope those responsible and able to make this improvements agree with me and will implement them as soon as possible.

I agree that clearer documentation is necessary if we are to start winning the newbies and casual users away from xing and blade.

Problem is that the development has been pretty frantic for a significant period.

With a possible upcoming stable version, what you suggest may be more "do-able"

Perhaps Mitiok and others would agree to a simple read me file with a description of the most common presets and what they might best be used for. This could be included with the download of the lame exe.

I understand your concerns for sure. I stopped cruising the boards for only a short period and came back pretty mixed up. --alt presets and revised compiles etc etc.

I agree that more documentation is needed, and I have been planning for some time to setup some sort of FAQ system and a better guide for what is going on in a lot of areas. In fact, I'm still planning on an overhaul of the entire site sometime.

The problem, which kennedyb4 has pointed out, is that some of the development has been pretty fast paced, and somewhat erratic due to other issues. In an ideal world everything would be smooth sailing, but.. this isn't an ideal world

Once 3.90 hits stable and I get settled from moving (I'll be moving next week, so things probably won't "settle" till sometime into January) I'm going to start working on the "user" side of things more.. so hopefully the situation will improve to be more in line with what you are imagining.

I do understand that much of the discussion about the current developmental issues can be hard to follow.. I do try to do my best with each increment, but the problem mostly being that descriptions are still relative, certainly does make things more confusing for some. Again, this should improve once 3.90 hits.

Part of the problem here is that I've been just trying to get things "done" and tested and into the encoder before the next stable comes out (the lack of a firm date for this, and the erratic pushes for a release and then decision to wait a bit longer has made this difficult). Despite the fact that I realize some people could use more documentation, it's more important for me to actually get things implemented *now* so that they will be available when the time comes. After that point it is much easier to go back and document everything in detail, and is what I plan to do.

And finally... I'm pretty much the only one who is actually doing this stuff, working in this direction. There is not even really a push from the other developers to help this along, and due to the fact that I don't have unlimited time (I also manage this site, and do research for other projects, in addition to the obvious Real Life time consumers ), some areas (such as documentation and explanation) will obviously suffer some unfortunately.

Yeah that's exactly what happened here to me and now try to imagine someone that is completely new to all of this - I presume only a small percentage of newbies is able or has the patience to understand this properly and get the best out of it. I really look forward for the much needed documentation that'll probably represent some more work at first, but then if it's regularly maintained it shouldn't take more than a few minutes with each new release. It doesn't need to be a very detailed description, just the necessary to know what is the file you have downloaded (are about to download), what it does and how to use it properly.

Another thing that may be worth noting here.. all of my work so far has now been included in LAME. The culmination of my entire efforts should now be in 3.90. I've updated the LAME history to specify basically (at a higher level) exactly what all of this stuff does. There's of course, also a very detailed help system in lame --alt-preset help, and I've updated the LAME documentation to include the --alt-preset switches. So at the very least, when 3.90 goes stable, most of the information newbies will need will be readily available.

What is going on here on this site is more for developmental purposes at the moment, so naturally it is going to be more complex and difficult to follow.

If we can just get the alt presets into the dll cvs I can finish my frontend...

Well, first of all Lame comes with an html documentation that should describe most of the switches.

But you should keep in mind that in order to write a documentation, you should know what to document. When you're in development stage and things are changing every 2 days, it would be a waste of time to re-doc each 2 days. Usually I wait for an option to stop changing before documenting.

Some experimental switches are also not documented on purpose, because they are experimental.

The last point is that in the current html doc, presets are nearly undocumented. This is because I plan to do a dedicated page for presets, like this is done for id3 tags.

I more or less totally agree with both Dibrom and Gabriel and completely understand their position regarding documenting. Maybe I didn't make myself perfectly clear (english is not my native language) but what I was shooting for is some clarity on this particular site with the development that's going on here and how to properly take advantage of it, not the exhaustive, comprehensive and up-to-date documentation of the complete LAME project (despite the obvious familiarity between the two).

I just wish there would be a place on this site (a dedicated page, a fixed space on the main page or similar) that would announce the current stage of the work. For example the current version is such and such, get it here and here. This and a short .diz file included in the zip with only the necessary info on the included exe and the available (working) presets (and their correct usage). Nothing more (actually a lot less) than what is actually already available in much more detail in the forum but with the problem that much of this info is burried and scattered throughout various discussions. I don't think implementing this small but important addition would represent a noticable time consumption.

I believe this to be the bare minimum needed for a hassle free use of Dibrom's work that would make happy most users just wanting to make good quality mp3s, without diving in all the technical aspects of mp3 compression. Please don't take this post as me insisting on the subject but only as a further (i think necessary) clarification of my proposal.