This is a list of brief descriptions for some open problem to give you a hint how you could help the MusicMiner project. If you are interested, please contact us on the mailing lists. Also, please do not hesitate to explain your own ideas, whether you can actually implement them yourself, or not. The listed required skills are not mandatory, of course, they can be learned on the way.
The manual is brief due to lack of time. There is a lot of room for improvement. Also, translations of the user manual and the menus and messages inside the program are welcome.
Required skills: writing.
MusicMiner should run on OS X with minimum effort, we simply do not have a tester, yet. First, static binaries of sox and lame are needed. Please send them to us and we will integrate them in the installer. The second step is to test the new installer and check if all the shell unix scripts work.
Required skills: Compiling C source, have OS X running.
Currently only songs are displayed in a table and can be edited in place. More tables to view and edit all artists, all genres, all ratings etc. would be nice. The insterfaces for querying and storing the objects from the database is very easy and does not require database knowledge.
Required skills: Java, Swing.
MusicMiner currently uses the Java based HSQLDB internally. This way you MusicMiner can be install and run with no additional database installation. The database is slow with larger collection, because the database is held in memory completely. Further it needs to be loaded and saved completely at startup and shutdown. Through the abstraction framework Torque other databases could be easily supported as well, e.g. MySQL. Ideally this should be incorporated into the installer as a choice. Further speedup could be achieved by tuning the database with indices.
Required skills: Java, Torque, SQL, ideally strong database background.
More intelligent parsing of metadata. Currently the information from ID3 tags (read with somewhat buggy Java libraries), filenames, and folder names are combined. This function needs some debugging! Additionally, the information already in database could be used to correct spelling mistakes. Adding MusicBrainz support could solve the whole problem by downloading high quality metadata from their server.
Required skills: Java, ID3, XML/RDF for MusicBrainz.
More actions and visualizations around the MusicMaps are thinkable. Playlists can be drawn as routes, playlists can be generated by agents wandering on the map. The songs could be colored by rating, number of times they were played, time since they were played last, etc.
Required skills: Java.
The 2D display of music maps with coloring according to geographical maps gives an intuitive veiw on the collection. Alternatively, an interactive 3D landscape could be displayed with Java3D or OpenGL. We already have some half-working code you could start from.
Required skills: Java, Java3D or OpenGL.
The playing behaviour of the user will soon be stored in the database, by delivering the songs to the player via a small webserver. This playback history could be used to generate new playlists.
Required skills: Java.
Extend basic search functionality to more searchable attributes.
Required skills: Java, Torque, SQL.
Extend the basic XML export and import facilities to support all database fields. Currently missing are the sound descriptions and the information about when the songs were played. Use XSLT stylesheets to transform the XML to M3U, LaTeX, HTML, PDF. Exchange metainformation of songs over the internet.
Required skills: Java, XML, XSLT, ideally Dom4J.
Search and remove orphaned database entries, e.g. artists with no songs. These can appear if you add music with misspelled artists and correct them manually. The wrong name will stay in the database, but is attached to no song. Further, duplicate songs could be searched based on sound descriptions with an offer to delete one version.
Required skills: Java, Swing, ideally Torque.