Postmortem: LAME MP3 Encoder GUI
Mar 13 2007
Today a friend asked me for a tool to convert from WAV to MP3 (actually, MP3 to WAV too) and I remembered that some years ago I made with my friend Lobo666 a small app with VB6 (yup, I worked more than 2 years with VB6 and ASP.NET before switching to .NET/C#), and I wanted to look at it now and see how I made it.
My friend did the research of LAME command line options, and suggested me the layout of the GUI, and we decided to make it multi-language (english and spanish).
This is how it looks:
The main window, spanish language

The main window, english language
The about window, english language
So, let's get into what I did back at 2001? 2002? (I can't remember exactly, last executable is dated 2002)
What went right
Instant language switching is cool. We planned it from the start and went smoothly and without problems.
We provided all the useful basic and intermediate LAME encoding options in an easy, visual way. It was quite fast configuring the options and encoding an MP3. The presets were also a good add-on.
Part of the code was separated from the forms, in a module. Is well documented, perfectly readable, no bad coding style mistakes (no "i" variables and similar), and I used hungarian notation (which I don't like too much now but it's better than nothing).
Building the command-line text was centralized in a single function, that avoided complex string manipulation issues as it rebuilded the query from scratch every time an option changed.
It worked! Seems funny, but some of my experiments back then ended being either non-functional or non-optimal (for example, being quite slow because of complex calcs made badly and with VB). The application can still be used now.
Intensive testing. Although I didn't know about unit testing at that time, we did a lot of manual testing (we tried every combination of options, for example).
ID3 Tag support. It was not initially planned, but we thought it would be useful to avoid having to open Winamp and setting the text after encoding.
My friend learned a bit of programming in the process. And the scrolling text in the about window looked cool back then :)
What went wrong
I didn't used resource files! While having 4-5 graphics/icons was easy, all the "multi-language" is hardcoded as two functions (which fill the labels, combos and message strings) called when you select a language.
Not al code was detached from the presentation layer (the damm VB6 style of coding logic in the .frm). Too good that I got another job and I started doing 3-tier layered applications :)
Code comments were in english, but variable names were in spanish. Strange mixture :P
No error checking on choosing source/destination files. Also just basic error-checking on the Shell interaction (when launching LAME).
The command-line string building function was called dozens of times... Instead of a having a multiple event handler, I had all optionxxx_Click() repeated.
Conclusion
It proved easy to develop the tool, and while I might not be very proud of the coding, it wasn't bad either. I just didn't had the same knowledge as I have now.
Also, I worked with a "final customer" and experienced what was building a GUI being "directed", playing with the Shell and actually using the tool frecuently.
I would probably now do it in much fewer lines of code and better organized, but it works quite well :)
Maybe another day I'll take older source codes, like my (terrible now) C mini-games and make more postmortems of them... but I don't know if I want to look at them :)