It's interesting -- with talk of Longhorn in the air, I thought AudioMan was doomed. The database that AudioMan maintains is essentially a layer of metadata above the file system accessible to one application: AudioMan.

WinFS, the proposed database-based file system for Longhorn has actual metadata built into it. Sure this may not be at the file system layer we are familiar with today, but it will be the file system abstraction that a Longhorn developer is presented with. This metadata is accessible by any program in the system, not just one. D'oh!

But then Longhorn got delayed, and WinFS got pushed out and initially I breathed a sigh of relief. AudioMan was safe. But just recently I've been thinking: what exactly is AudioMan supposed to do?

Players fill a defined niche, and collection browsers have become part of these players. It doesn't make sense to make another collection browser because they are already well done in players like iTunes and WinAmp. People aren't going to move away from the established players, and once they are using a player they don't want to have to exit that interface.

The angles of AudioMan that I liked were:

1. Complete collection management

Where are all of my files, not just the ones that play in iTunes because of DRM or Windows Media Player because of DRM or Real Player because of .... yep, DRM. I want a list of them ALL. There isn't a single player that displays all of your files because there isn't a single player that will play all of your files. Because of DRM, I doubt there will be in the near future. Competition will not allow it.

Collection management also includes backup management, a severely needed feature in not only music players (that pass as collection managers these days) but for the entire operating system! Sure hard drives are getting bigger, but so are backup media like writable DVDs. People want to know what's on ALL of their backup disks without having to load each one individually. Future operating systems will keep track of our backups for us, mostly so we can search all of them while they aren't in the disc drive and find our stuff!

2. Metadata

Complete metadata is the holy grail of data mining. In order to search for and find songs they have to be properly labelled. The bad thing is that labelling is a time-consuming and sometimes manual process. The situation is getting better because of services like CDDB, freedb and Musicbrainz, but it's still far from perfect.

Bottom line here: automate or the user won't take the time to do it. In other words it better be free, as in no effort. Without good metadata, searching is spotty and collection management becomes seriously hard.

I see two main issues in this space:

a) Identifying the actual audio in the recording and getting all of the information you can about it automatically.

b) Labelling the metadata and file name the way the user wants, so that the whole collection is consistent. This may also include moving files around into an established hierarchy, though with better searching technology well structured file system hierarchies are becoming less important.

3. File and tagging types

A tool that supports multiple file types has to support all of the file types' variations on storing metadata. It has to be able to read and write this metadata. Adding new file type support should be relatively straightforward (think of an Eclipse plugin-type model) but writing the support WELL will be the hard part. The emphasis should be on data integrity, with effective testing being paramount to just about everything else.

4. GUI

AudioMan's current user interface is better suited to browsing than organizing a collection. This is obviously a problem, because it puts users in a certain frame of mind. Users have associations with the iTunes interface that are hard to drive out.

It's like tools that copy the Windows Explorer interface, modify it slightly and wonder why people have problems managing the variations it introduces. It's seems to be more of a disadvantage than an advantage in being familiar, as it can severely limit development. You find yourself not wanting to stray from the legacy GUI when you add a few feature -- just for the sake of looking and feeling familiar -- and this is bad.

---

No regrets with AudioMan though, I think it's a pretty good little app. It's definitely not targetted for an audience, which is why it's not being used. Doesn't take a rocket surgeon to see that. :)

I will still use AudioMan as a platform for improving jid3rL and also to manage my own collection. Other than that I wouldn't expect this version of AudioMan to get any new features, it's a bit of a dead end. It's not as unfortunate as it sounds, really (if at all).

This project tought me a heck of a lot about project management, release management, quality, multi-threaded GUI applications, test driven development, the Java Collections framework, Java itself, Eclipse, SWT, code coverage and the list just goes on and on.

My main goal with AudioMan was to have a platform for discussion about software engineering. In that capacity it excelled. As a project however, it failed: there are only two people using it today. Software that's THAT custom isn't worth the time it took to develop it, but AudioMan was worth it because I learned so much from it.

Thanks to everyone that supported AudioMan over the past 2 years or so, especially the group that helped to start it all with me: Peter, Karen, Jim and Trevor. Here's to more learning and discussion in the future. Prost!