Postmortem: LAME MP3 Encoder GUI

Today a colleage asked me for a tool to convert from WAV to MP3 (and also MP3 to WAV) and I remembered that some years ago I made with my friend Lobo666 a small app with VB6, 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 as of today with VB runtimes.

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).

ID3 Tag support was not initially planned, but we thought it would be useful to avoid having to open Winamp and setting the text after encoding. It proved really useful and every MP3 use/uses ID3 tag info now.

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 all code was detached from the presentation layer (damm VB6 style of coding logic in the .frm). At least I got a job and learned to work with 3-tier layered applications afterwards :)

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 all over the code.

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 we were going to "improve".

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 :)