Lead Thoughts

With the revised ID3 DLL, having not yet re-written the Playlist Editor to use it, I wrote a small application for viewing and editing ID3 tags. It's more or less a wrapper for the DLL, and brings up the view/edit dialogs for a tag.

The application makes it possible to edit tags in files with a simple right click in Explorer, rather than needed to have an application (like the Playlist Editor) open to do it.

After purchasing a TV card, the next thing to be done was to recieve a TV guide email. It wasn't long before I got frustrated with 1) having to run Netscape (or have it running) to see what was on TV, and 2) the email not being in a format that was easy to quickly scan through to find the current hour.

So, I quickly whipped up a GUI application that parses TV Guide emails, and presents the guide listings, by day, in a format much like you'd find in a paper TV guide or newspaper.

Currently it only works with Netscape mailboxes (or any mailer that uses the UNIX mailbox format), and all TV guide emails are required to be filtered into a seperate mail folder.

The application was written rather quickly, amd isn't much to look at, other than the way the guide is layed out.

Having limited online time allocated by my ISP, this was the first attempt of many to write a program to keep track of the online time left per day. At the time, it worked reasonably well, and I used to use it a fair bit.

The program used the modem's log file to calculate the time used and time remaining for the current day. Two problems were encountered however. Windows crashing mid connection would leave the modem log in an inconsistant state, and in which case, make the results not 100% in such circumstances. Which they program handled / warned about whenever was the case. Any calls logged not to the ISP also caused inconsistant results in calculations (obviously). The second problem was Windows 95's modem log file maximum size, which stops logging once the file reached 256kb. This was however solved by moving the contents of the log file to a different file on startup (and having the program parse that file instead), preventing the file Windows used ever reaching the limit.

After moving to Windows 98, I couldn't really be bothered maintaining my modem log file (which is somewhat different than Win95), and I stopped using this program. It was really handy in it's day though.

EAC Fix is a small application that fixes problems with ID3v2 tags that Exact Audio Copy creates.

The main annoyance with EAC tags is that it uses the Encoded By frame to store the Encoder Settings information. The Encoded By frame is intended to store who encoded the file, while the Encoder Settings is intended for information about the encoder that encoded the file.

EAC (and other rippers) may incorrectly use the Encoded By frame because that is displayed in Winamp, while Encoder Settings isn't. Despite the reason, using the wrong frame is simply incorrect. The ID3v2 standard defined specific frames for specific data, there is no reason to ignore that and use other frames. (Otherwise, why have a standard at all???)

EAC Fix looks for the Encoded By frame - if it contains the text that EAC adds, and the Encoder Settings frame is empty (or non existant) the program moves the information in Encoded By to Encoder Settings.

Another slight annoyance is that EAC only adds information about itself, but not the encoder that is used (unlike Audiograbber, which quotes itself, and the encoder used to encode the file). When moving the text to the other frame, the program has an option to append information about the encoder to the end of the frame text. Thus making the Encoder Settings frame actually contain information about the encoder settings.

EAC also NUL terminates the strings it adds to frames, in ID3v2.3.0 tags. I assume this is because it was written primarily with ID3v2.4.0 support, and v2.3.0 support was an after thought. Although it's not an error to NUL terminate text in ID3v2.3.0 tags, it's unneccesary, and annoys me, so there is also an option to remove NUL termination from the tags.

I began writing a HTTP proxy cache in order to do away with Netscape & Internet Explorer's individual caches, and also to make pages avaliable from the cache when there is no internet connection.

The proxy has some subtle issues and I've abandoned working on it for the moment, however, for bothing else, it gave my an insight into implimenting / the issues associated with HTTP proxies.

I originally quickly wrote this program after getting sick of editing playlists once I'd burnt tracks to CD. The original intend was to programmatically edit playlists with 3 functions:

• Extended -> Standard - Winamp extended playlists annoy me, thus the first
  function was to programmatically convert an
  extended playlist to standard format.
• Change File Path - Changes the path of all playlist entries to a new
  path, so that when files are moved, the playlist entries
  didn't have to modified one by one.
• Change CD-ROM Drive - Similar to the above function, but simply
  changes playlist drives. This makes playlists easily
  transferable from one CD-ROM drive or another when a
  system contains multiple CD-ROM drives.

After getting this basic functionality done that, I began adding more functionality, developing it into a fully fledged playlist application. Developing it to supprt adding and removing playlist entries, creating and deleting new playlists, sorting of playlist entries, ID3 support and editing, and ability to play playlists or individual tracks from the program. Lately have also included a search function to search playlists (and ID3 tags).

When writing the Playlist Explorer and deciding to include ID3 support, rather than include it straight to the program, I opted for writing an ID3 dll which could be re-used.

To begin with it began just being able to handle reading the simple ID3v1 tags. Then worked on implimenting an ID3 cache into the library, to cache ID3 tags in files on removable media, such a CD, so that the tags are accessible, even when the media isn't present.

With ID3v1 implimented successfully, I then set about implimenting the more complex ID3v2 standard, which originally seemed a little more daunting than it actually was.

Currently the ID3 library reads ID3v1.0, v1.1, v2.2, v2.3 & v2.4 tags, and can write ID3v1.0, v1.1, v2.3 tags.

Although v2.4 tags can be read fine, there is still a bit of work to do on the v2.4 code.

The library also reads cdplayer.ini as ID3 on audio CDs.


Update: Version 1.00.01.04
As of early 2002, after having the code for v1.0 mostly done, I began re-writing the code, now with an overall understanding of ID3v2 (unlike when writing v1.0, which I learnt as I went).

The code base was based on the first write of the code, but this time with thorough testing and support for things left out in the first write.

The code can now:

• Read all tag versions (1.0, 1.1, 2.2, 2.3 & 2.4 tags)
• Write all tag versions (1.0, 1.1, 2.2, 2.3 & 2.4 tags)
• Convert any v2.x.x tag to any other 2.x.x version.
• Handles compression in 2.x tags.
• Correctly handle unsyncronisation in all versions
• Countless bug fixes

Yet to do:

• Uncode support
• Encryption support (if worthwhile)
• Multiple text string support on 2.4.0

Being sick of there being no decent ID3v2 tag editors, I also created an edit tag dialog. Most ID3v2 tag editors only support the equivilent ID3v1 frames and a few others (URL, Composer, Original Artist. etc.). As a result, the code also contains a edit dialog that supports almost every ID3v2 frame that one would want to use (all the ones I'm likely to use anyway). In the new code base, multiple comments and URL's are supported, as well as addition of lyrics and attached pictures support.

• Added multiple comments support
• Added multiple user defined URL support
• Added Official Artist, Official Audio File & Official Radio Station support
• Added Publisher, Internet Radio Station & Internet Radio Station owner fields
• Added Attached Pictures and Lyrics support
• Added Record Time (update from just Recording Year), Release Time and Original Release Time
• Added data verification (URLs, times)
• Better original media type support
• Added support to convert tag to any version

I'm not sure I started out with a clear intent, rather just wanted to have a try at writing a POP3 server. Once I'd had the POP3 server written, I had the idea to create a system to solve the Netscape Mail "one account at a time" problem. In that one Netscape can only check one POP account. To check multiple accounts from the one profile, I wrote a Pop Collector which downloads email from multiple accounts, and puts them into the one mailbox on the POP server. Netscape can then download the mail from the local POP servern (and optionally filter the mail from the different accounts into different mail folders).

In addition I wrote a STMP server and combined it into the system, though currently can't look up MX records, and thus can only properly deliver mail locally, or use a fully fledged STMP to send external mail.

Although the three components (POP3 server, POP collector & STMP server) are designed to interconnect, all can run independantly.

Currently there are still a few bugs (mainly with the POP collector crashing).

The following are different small applications I've written.

• A small C script for use on UNIX to be used on shell startup which parses
  the user's mailbox, and outputs the number of total emails, new emails,
  old (unread) emails, and read emails.
• CGI programs that read my music collection and bootleg collection databases,
  and produces the HTML pages on this page. I also created CGI's for both
  the Gin Blossoms and Dead Hot Workshop Guitar Archive's that provide
  configurability for presenting the tab pages by accessing a database,
  rather than static pages.

Someone at my ISP was looking for an application that gave a warning when the connection to the ISP was almost up. I quickly whipped up an application that did that, and made it freely avaliable. (No idea how many people ever used / use it though. ).

It quite simply monitored RAS connections, and have a warning dialog at a designated period, to warn that there was only x minutes left on the current call to the ISP. It was configured by default to the ISP's specific settings, but was possible to configure the maximum length of calls and when to give the warning.

Having the sort of ID3 support I wanted with ID3.dll, I was still stuck with the lacking ID3 support in Winamp (no ID3v2.4 support, limited number of frames supported), I wrote the ID3 Tag Reader Winamp plugin.

The plugin provides the same ID3 support in Winamp, regardless of the MPEG decoder input plugin in use. (Nitrane doesn't read ID3v2.4 tags, MAD doesn't read ID3v2 tags at all).

Since the ID3 code base can also read cdplayer.ini as ID3 for CD Audio tracks, the plugin is also written the similarly to read tags for CD audio. This is handy if, like me, you prefer Winamp to use cdplayer.ini rather than CDDB (Nullsoft's in_cdda.dll only uses CDDB) but CD Reader doesn't work great for you (CD reader reads cdplayer.ini for titles, but doesn't work play CD's great on all systems - I'm glad I'm not the only one whose experienced choppyness with CD Reader).

There is also an option to define whether Winamp should use the ID3 tag editor of the MPEG decoder in use, or whether to use the ID3.dll tag editor, which supports much more ID3v2 fields, as described above).

The plugin is an Winamp input plugin, for MPEG files - however it doesn't do any MPEG reading, decoding or playing - it simple reads ID3 tags. The plugin loads and calls the selected MPEG decoder, which is uses as the input plugin used for decoding MPEG files.

NOTE: Re CD Reader - with some messing around, I discovered that messing around with it's settings to a buffer size of 1 sector (vs 128 sectors, which is the default), CD player actually works pefectly. Yaaaaay.

Once I got the hang of Windows programming, it dawned on me what could be done using the Microsoft Windows system. I initially set out to write a program that automatically closed registration nag screens. Hence, Windows Control was born.

After writing this very basic functionality (simply searched for a window, and sent a message (generally WM_CLOSE) when found, I decided that it's use was pretty limited, and went about writing 'macros' to send a succession of messages to achieve more indepth tasks. I initially started out with these "macros" built into the program, and then worked out how DLL's worked / how to write DLL's, and rewrite the macro engine to use add on DLL "macro plugins" rather than having the macros hard coded into the application itself.

At this time I thought of annoying things I could fix with the endless possibilities of the macros. The first to come to mind was to automatically dismiss the AOL Insant Messanger connection error dialog, which is an "always on top" dialog.

• Auto Clear AIM error: Macro that detects the AIM connection error dialog box,
  and automatically presses the "OK" button, as I found this an annoyance.
• Auto Logon AIM: It would get annoying when connections to the AIM server
  would drop out, and you'd have to continually, "Sign On" then clear the error dialog,
  repeatably until the connection was okay. This was written in conjuction with the
  above macro, to never have to manually reconnect. Using this macro was short lived,
  and AOL eventually added "Automatically reconnect" to the AIM software anyway.
• Auto Save IM: Sticking with the AIM tweeks, I attempted to write a macro
  that would automatically save the contents of an IM, so that text would be saved
  on crashes. Development went pretty well, though I started to suspect this was
  causing some AIM crashes, and development ended up falling to the wayside.
• Auto Windows Logon: Given that I have Windows set up to use specific
  profiles, and was getting sick of always entering my password, I went about writing
  a plugin that automatically filled in the username and password and pressed "OK".
  Still find this one immensly successful.
• Auto Log DUN Connection Script: During some annoying modem problems with
  my ISP, everyone was scrambling to see what terminal server they had been connected
  to (one was dropping connections automatically). People complained / and looked for
  something that kept the DUN script window open, or logged it (something I'd always
  wanted to). None existed. So I decided to write a plugin that captured the output,
  logged it to a file, and also had the option of bringing up a "clone" window, which
  unlike the DUN script window, remained opened until explicitly closed, making it
  possible to view the terminal output. As a result, I made Windows Control and the
  Auto Log DUN Connection Script plugin freely avaliable. It's another plugin that
  I always use. Great for hard data to present to an ISP when there are connection
  problems.

I personally didn't find Alphalink Alarm to be that usefully. However, I did have the idea to expand it, beyond the ISP specifics, and use it as an alternative to the Alphalink Account Usages program I was currently using.

Using RAS, it wasn't susceptible to the inconsistant modem log programs that Alphalink Account Usage was. I added functionality to group DUN profiles into "ISP settings", such that the program would monitor total time used for several ISPs easily. It also recorded time used (something that Alphalink Alarm never did, so it could monitor daily usage, rather usage per call as Alphalink Alarm did.

The program started out as Alphalink Alarm 2.0 but then became ISP Monitor as it was no longer specific to Alphalink.

As it stands, it has some bugs that need ironing out. I eventually stopped working on it, but it something I should probably go back to and finish.

Stupid name. I still can't think of a better one. However, this is a client / server solution to the dynamic IP problem. After trying different IP poster programs, I came up with the IP Client idea.

The system consists of a server (which resides at a static address) which stores IP's mapped to username, and a client. The client determines the IP of the client machine, and posts it to the server. Other clients can connect to server and recieve the IP of any given 'username'. The advantage over other IP posters is that the system works on usernames. Most IP posters simply post an IP for the all world to see. With this system, you can restrict who has access to the IP address by restricting who you give your username out.

Although the IP client is manditory to post the current IP, posted IP's can be retrieved via the client program, or via a HTTP interface. Also provides the ability to use the IP server as a redirection to a local web server.

The advantage of the system design is that the server software is a CGI program, and thus will run on any web server, and doesn't require any special privledges to run. Any web server with CGI access is suitible.

I started International Time as a very simply DOS program (which I originally run on my 386 laptop), when I was teaching myself C. It's turned into the first real application I ever wrote. (As compared to assignments / small programs that didn't do much.) It started out as a very simple command line application, which spat out the current time of a given timezone. With this basic concept done, and beginning to understand C fairly quickly, I developed a DOS graphical interface for the program, adding a configuration file, while still keeping the command line part of the program (evolving into 'console mode' and 'GUI mode').

I had made some previous (very unsuccessful) attempts to learn Windows programming. Once I had all the time conversion routines down, I had another crack at working out this mad world of Windows programming, but porting International Time to Windows. Working from an example (quite frankly, pasting my code into a skelton of a working Windows application), I at least got it working. And understood a little (in highensight now seems like very little), of what was going on. But at least had something working. (Which was significantly more than previous attempts!) Initially I started out mainly with 'borrowed' code from the example, but kept working at it, and slowly started nutting out how Windows Programming worked, and the application developed from borrowed code, to more code that I wrote (and understood) myself. International Time For Windows became the first Windows program I wrote.

At which time I scored a nice Pentium II, and stepped into the 32 bit world (Windows 95). It was then that my grasp of Windows programming grew a lot faster. (There's really something to be said for not having to reboot every five minutes). I started to want to learn more and more, and since I learn best through practise, everything I wanted to learn became a new feature in International Time. It also proved good, to learn to write the code portably between Windows 9x and Windows 3x (hence maintaining 16 bit and 32 bit flavors of the program). This was very true of the time related code, which took a lot of work and resource to get the time related code (time() under Win32 is a pain, as a side note ) to work correctly in both the Win16 and Win32 versions (and the Win16 under Win32).

To date, the program boasts the following features: Configurable timezone information, consistant time calculations across both Windows 3x and Windows 9x, Alarms settable by timezone (needs to be redeveloped), Clock Syncronisation (using the Time protocol, over both TCP or UDP), Time Server (using the Time protocol, over TCP or UDP), Calendar, manual time conversion, in program timezone file editing (a long awaited feature), and analog clocks in addition to the standard digital display of times.

Clock syncronisation was added due to my PC occassionally loosing time, and figuring it'd be better to add the functionality to my program, rather than using a differemt application to keep my clock set correctly. By the time I had added this, socket programming was nothing new to me, but was the first time I'd done any UDP programming. Adding the UDP implimentation of the time protocol (in addition to TCP) was simply to have a crack at UDP. The TCP and UDP time server functionality was added, both because it was fairly simple to do, and made testing the time server code easier to do (didn't require connecting to the internet to test).

The other internet based feature, which I dubbed International Weather is a side function which downloads and displays the current weather conditons for any given city (in addition to the local time). This feature is currently somewhat in Beta.

Right from early on, I thought the analog clock option was a cool idea, and years later the initially idea, I decided I want to have a crack at GDI programming, and used implimenting the analog clocks as my learning platform.

The DOS version of the program eventually began to fall to the wayside, as a lot of the features I'd added to the Windows version were more difficult to implement in the DOS version. I think I still have a DOS version that works, but is by no means up to par with the Windows version.