I'm writing a new LAME frontend to replace the largely unmaintained and somewhat obsolete RazorLame. Source code WILL be made available, once I've got a reasonable 1.0 release ready.

Planned or already implemented features:

* Written in C# using the brand-new .NET runtime 2.0
* Simplified user interface based on guidelines at http://lame.sourceforge.net/lame_ui_example.html
* Automation from Exact Audio Copy, including WaveGain pre-calculation of album scale values and automatic ID3 (versions 1 and 2) tagging.
* RazorLame-style histograms during encoding.
* Multiple threads of execution for hyperthreaded, SMP and dual-core machines.
* New official LAME icons!

Possible features for later addition:
* APE tag support.
* Automation from CDex and/or other ripping apps.
* Other encoders (MPC, Vorbis etc.)

Everything except for the histograms is already complete.. Final version should be out in a week or 2.

Any requests for features please put here... I want every Windows LAME user to use this program! If I don't get any feedback I'll assume there is no demand for such an app.

Edit: Almost done... still need another week or two before release 1.0. Project is now called Omni Encoder and is now a front-end for multiple encoders.

Neat! I´d only like to have "Minimum Bitrate" added.

Have you looked at advalame, the successor to razorlame? It's still in active development.

razorlame and its derivatives are a) written in Delphi, which is non-free, and b) include a ton of options people have no need to mess with.

Also, they can't be scripted from EAC, which is my main reason for developing this.

I've considered it, but first I need a good reason to include it. I'm not including features that only degrade quality or complicate matters... there has to be a situation wherein it would be warranted. If something like that gets included, the uninformed masses will crank it up to 320 just cause it looks higher.

It looks fine. I don't understand one point: WavGain!? Wouldn't MP3Gain be better? Or ReplayGain?

If you plan to add some preference to advanced users (choice of tagging format is an example), you could maybe add one or two harmless options already included in LAME (like noreplaygain or replaygain-accurate). But it's not something absolutely necessary (but worth in some case I would say), so it's not really important.

I'm running a wavegain analysis and then plugging --scale into LAME as discussed in that big thread I started back when. There is no wavegain processing done, just analysis after the entire album has been extracted. This can be turned on or off, of course.

noreplaygain, replaygain-accurate, and the copyright flag (-c) are already in there, i'm way ahead of you

So if you want to replace Razorlame you have to offer something. If "minimum bitrate" is to confusing already just get the simplified user interface working.

I assume I'll be able to save my files wherever I want. As well, I'd like to keep LAME in its own folder for ease of maintenance.
Glad you're keeping it simple. I need a -V slider and a --vbr-new switch.
It's great that you're including WaveGain analysis and --scale. Although I appreciate Wack, I do get tired of editing the .INI.


A good Calgarian would name it "fLAME"... besides, it sounds fast and has edgy cyber-connotations.

How about Lamer....?

"FrontLAME".

I have a problem with the vbr scale (from 10-100% like given at http://lame.sourceforge.net/lame_ui_example.html) instead of the 10 -V values ranging from 0-9.

As improvement i suggest, that each -V value can be selected at a graphical point, where it corresponds to the averaged bitrate. (how the -V level is named in the gui, is unimportant, you could stay with %)

Ie., make the vbr quality scale below the cbr scale, and locate the vbr setting to use at the position below the corresponding cbr-bitrate.
I think, so users get a better picture, how the vbr qualities can be rated regarding expected bitrates.


So, we have 2 scales to select,
either:cbr or abr by bitrate with one slider & bar
or: the quality scale with -V levels with the other slider & bar below.
Maybe it might be a good idea, to add 320 cbr at the outer end of this vbr-quality scale. If somebody wants to go for quality only, he might be confused by the quality scale as suggested above ending at ca. 240 kbit/s (below the cbr scale !), and the cbr scale offering 320.
So, the quality scale should offer the maximum quality also, and that is 320 cbr.


ohoh, big big edit !

I had a closer check a the sourceforge gui suggestion, and it fulfills already what i requested above, besides the addition of max. quality to the vbr-scale, ie. 320 cbr to outer end.

Though, this makes me thinking again,
as i know that gui meanwhile for longer time. That means, it wasn't possible to grasp it easily.
As written above, as constructor I would draw the gui exactly like done. hm, but as enduser looking at the finished gui, I wasn#t able to get the picture, hmhm.
Solution would be, that instead of the percentage scale, the averaged bitrates are written.


2nd edit:

I forgot to mention, that the selection of the default vs. fast vbr mode (ie. about --vbr-new or not) should be solved somehow different.
if somebody reads fast vs. default, he will select default for quality, as he thinks, fast cannot be same or better quality at same time.
But our lame --vbr-new offers this !
Maybe name the 2 options as old mode and quality&speed (fast) new mode
maybe (fast) and new can be left away in this idea.

I like that one. Simple, describes what it is, and sounds nice.

- Lyx

A drop down box with user defined presets like All2Lame has.
That way, I can have:
-b 320 for archiving stuff, and
-V5 --vbr new for my podcasts, and
-b160 -mm for archiving voice tracks, etc.

For the encoding-options, i propose that they only consist of 4 parts:

- Dropdown-menu "Target" with the choices "Quality"(default), "Bitrate-Average", "Constant-Bitrate"

- A slider right to the above where the user selects the quality(V), bitrate-average, or constant-bitrate.

- A checkbox "mono-encoding"

- A button "additional options" which opens a popup-window where the user can enter additional switches. No premade checkboxes here - if the user cannot handle CLI-switches, then he probably also doesn't know how to use them properly.


- Lyx

Yeah, some sort of multi-profile thing would be good. So you could set it up completely for various activities, and then select the profile from a dropdown list.

I really like the way EAC lets you save a complete profile, but also just the Compression profile, or Drive profile. It's possible a similar system may be of use - so that users can just swap compression profiles (as quote I guess) (including LAME location for using different versions) but also a full profile, so that output directories, naming formats, etc. can be swapped.

Are you using a placeholder scheme for file paths, e.g.: "c:\Music\%artist%\%album%\%tracknumber% - %title%"? If so using EAC or foobar's placeholders (or the ability to swap between the two) may be sensible, so that users don't have to learn a new scheme. foobars is at least "readable" (logical to decypher).

Assuming that the new frontend don't allow to end users the access to most LAME swtiches, I would suggest to remove the OLD-SLOW/NEW-FAST option directly from the frontend. If a Preferences menu is available (with some options like wavgain, tags, replaygain), I'd rather put here the choice of  use of vbr-old (legacy, lower qualityy most time). And honestly, I don't think that it would be wise to clutter the menu with unecessary options.
There are now few reasons for users to chose the old VBR mode. Apart for testing, but it seems that most users are not that interested to perform tests on their side.
Just my little opinion on the subject.

I will be happy with APE v2 tag support and ReplayGain in it (alla Foobar2000)...

damjang

Yes. Ape2 tags and replaygaininfo in tags.

@Jebus

If you considered using something like wxwidgets for delevopling instead of c#/.net you could make your app cross-platform and probably make more users happy... (yes, I know about mono...)

Problems with a cross-platform .exe:

* The bundled wavegain.exe, id3.exe and lame.exe are platform-specific.

* I'm using windows IPC for sending messages from the EAC "runner" (which gets executed as the EAC encoder after each track) to OmniLame itself. I'll have to change that for Linux/Mac.

* I'm storing settings in the registry. Not a big deal to change that to a text file for other platforms, but I still have to do it. Not sure if Mono provides a virtual registry.

Having said that, I'm an avid Linux and Mac user myself and i'll probably port it rather soon. I'd like to play with ObjC and the QT libraries anyhow so I might even write native apps. I'm feeling productive for some reason

Fair enough, i'm going to remove that option and add an "additional flags" text box if someone wants to force vbr-old or minimum bitrates etc. Just a quick question though... if someone adds "--vbr-old" to my existing "-VX --vbr-new" will "-VX --vbr-new --vbr-old do something fishy? I guess I can try it when i get home...

In scripted mode (run from EAC) it just uses the path from EAC. In normal "free-standing" mode you can select an output directory... really i see people using this application on an album-by-album basis so there is no mask needed right now... would you want to run a mass encode of hundreds of wav files? That is something to ponder and would necessitate several design changes.

EDIT: pondering complete. I'm going to leave FLame (as I'm now calling it) an album-at-a-time encoder, but since it already has a scripted mode that takes parameters, i'll write a mass encoder wrapper you can use that lets you specify multiple albums. It will just execute FLame in scripted mode multiple times.

Noted. Thinking i might let you automatically select profiles from within EAC using the high and low tags for profiles 1 and 2 as well.

I like it. FLame it is. The F is short for Frontend, after all

They get natively compiled as well, or are in the system... (I don't know about id3 though.) To make compilation easier, you could try cmake. I learnt a bit of it and made a cmake project file for OpenAL (though it is untested beside Linux, as I commited it shortly).



OK, no EAC for Unix. Well, just make a #ifdef _WIN32 or alike...




I don't know whether wxwidgets provides means for storign and retrieving settings...



Well, then you'd have good reasons to make an cross-platform app. Anyway, do what you think is best.

The lack of EAC isn't a big issue, i've written this thing to accept easy-to-write runners for basically any ripper under the sun. Probably would take 5 minutes to add Mac- and Linux-only ripper support.

Anyone graphically-inclined want to make me a flaming lame icon? I'm thinking a 46x46 pixel version of the simple lame "e" logo in png format. I'm not an artist . I'll take care of the iconification and stuff though. You'll get credit in the "About" box!

Dear Jebus,
For a long time, I had been using Razorlame. And since AudioGrabber became free without restrictions, I had been using it as my exclusive ripper and encoder. I had also been using it as a frontend for lame from 3903 to 397B to encode wavefiles. I had also used FB2K when I wanted the HQ resampling facility. Here is my wishlist for a new frontend for lame.
--A simple interface like Razorlame such that wave files can be loaded directly.(Not only from EAC). Should be possible to edit filenames and ID3 tags (V1 & V2) directly in the program, before encoding. Should be possible to have different tags for different songs or different groups of songs. The differences as required for single artist and for compilations should be provided.
--The user interface for lamesettings is ok, but in the end we should know the actual parameters passed on to lame as available in Razorlame. There should be provision to save lame logfile for analysis later if required.
--Should be possible to do high quality resampling, hp, lp, set mode and -Y for special requirements. For all extra parameters in the command line, a general warning in red that there will be quality degradation should be provided.
--In the recommended GUI, a quality scale is given, 10 -100. The first reaction of a new user is to keep the quality at 100. It is not clear what is to be set where to what to get V2 vbr new. There is one 'Standard' in encoding Engine and one 'Stanard' and 'Fast' in vbr mode. For preset fast standard, what should I do? What I mean is that the settings should be clear and intuitive. May be you can keep on the quality scale, one color upto preset Standard as increase in Quality, and after that in red as increase in bitrate.

I vote for fLAME!

--Rigapada

Maybe if the settings are stored in a file, you can make the application portable: in my usb pen I always have EAC, lame, mp3gain (and Foobar, of course), so I can grab some music from friends, with only some little adjustment.
And more: if you must reinstall the application, is simple having al the settings in a file.
Perhalps you can add a "save/restore settings" option.

As has been said before, a dropdown menu with a list of presets (and the option to import others) would be very nice, but with no GUI lock (on some apps when you choose a preset it freezes/greys out other customising options.)
Oh, and something that shows which switches are used within said preset.

I can't answer (Robert or Gabriel may give you an accurate reply).
If you plan to code a small text box which allow to change the commandline, why don't you simply disconnect it from the graphical configuration? I mean: user have then to type the full commandline they wish use (-V5 --vbr-new -b128 -pl -a -c e -b0) and not only the additionnal option.

I made a mockup of the UI example. It doesn't have unnecessary switches anymore, but it allows custom command lines.

The custom command line dialog acts as a display that always shows the actually used command line. It's grayed out when one of the standard modes are used, but still shows the actual string. When the custom mode is selected the dialog allows writing any command line string. The drop-down button shows the last used command line strings.

The VBR mode should use the -Vx --vbr-new command line.



Additionally an option for using named presets could be added. It could have these functions: Save the currently visible command line string as a named preset, delete a preset, change the order of presets and of course: load a preset.

If the LAME developers find this image useful feel free to use it. I can also easily make changes upon request, because I have it in the layered PSD format.

Thanks for your feedback. Here are my proposals (most of which are already implemented):

--FLame will run just fine as a standalone app just like RazorLame. It also has the added function of being able to listen for updates from EAC on a track by track basis. Files can be drag&dropped into the list, and tagged before encoding. Haven't decided the best way to deal with output names yet.
--Yeah i'll add an uneditable box showing the parameters being passed at the bottom of the LAME configuration panel.
-- An editable "use manual parameters (not recommended)" check box will be there, which will make the parameters box editable.
--The gui sliders will default to quality 2 with the caption being "190kbit/s (estimated) - recommended". The tooltip when you hover over it will explain that this is the transparency setting and what that means.

I'm going to post screenshots when I get home so people know where i'm at.

Good call. Added an uneditable text box displaying the current options being passed, with an "override - not recommended" checkbox to make it configurable.

May i propose to not place the editbox in the mainwindow - especially not in a "hidden" state? This would strengthen the "i miss out something"-effect when not using the manual parameter box. As mentioned earlier, a button which opens a popup window would seperate the normal options from the advanced options, while still making them accessable.

It's your app, so the final choice depends on you. I personally dont think that its a good idea to place advanced options right in the viewfield of the main application windows. A user which doesn't intentionally demand those options shouldn't get in contact with them at all, imho.

Another way to look at it: consider what 90% of the users will need. Then make it so that the remaining advanced options do not make up more than 10% of the visible main application windows.

If it's any use in this post I posted my suggestion for the dialogue proposed by the LAME devs for john33's LameDropXP. It makes sense to me to have the radio buttons actually by the settings.

I'm not sure how relevant it is now, but it may help in some way.

Here's my effort.



It's 48x48 as I didn't read your request properly. I only have the built-in Fireworks filters!

I was thinking about a flaming "e" in the calgary flames sense (Calgary native here). But thanks!

Wanna get sued?


Ahem... Slightly less derivative:


BTW I've started an upload thread for proposed logos here. I just found out you can't display them here, though.

Dear jebus,
No entries in Registry please. Should be able to run progran with a copy on cdr.
--Rigapada

Oh yeah, and a check box which will either retain/clear the file list after processing.
...and a "delete source file?" check box too.
Schweeeeet!

You'll be able to. All I'm storing in the registry is your option profiles, and if the key isn't already there it will create it using defaults.

The program will have an .msi installer for convenience, but you can easily copy the program to a CD and run it from there. If you need to clear the registry keys afterwards, just delete hkey_current_user\FLame with regedit.

Here are some screenshots with this thread's suggestions. All of this is working already, I pretty much just need to add the histograms and it is finished.

Normal Operation (RazorLame style):


EAC Scripted mode after 1 track has been ripped. The window opens automatically after the first track is added, then additional tracks appear in the same window as they are completed by EAC.


Option Panels:





Cool?

Way cool! Can't wait to use it.

Very.

Stylin'

You said its developed with C#? How's the resource usage? VB.NET uses insane amounts of resources...

C# and VB.NET both compile to the same bytecode and use the same libraries, so there is really no advantage except syntactic. Well, not much anyway. This app chews up about 7MB of memory, which is mostly the .net runtime (flame isn't all that large). Meh, its worth the trade for easy to maintain code and not having to worry about garbage collection.

LOL. I had never heard of the Calgary Flames. I guess that makes me underqualified.

Go Flames!

Best of luck with this app Jebus. The screenshots are looking nice.

Wow that name works on so many levels! I bet most people here won't catch your home town reference. Spring 2004 was an exciting time .

edit: I guess you gave it away later in the thread. I should have read the whole topic before posting . Well, anyway, cheers to hockey .

edit2: Awesome work on the frontend, IMO everything is designed perfectly. The only thing that concerns me is the all-to-enviting-to-crank-up ReplyGain value. I could see many useres looking at gain as being "the higher the better" . . . or not, I don't know.

could it be possible to also have an option to edit the comment field?

edit:maybe a small comment like 'default is 89dB' will prevent that in some cases.