Archive for SE12 Python Project

Pretty GUI

Well, not only is it pretty, but it’s functional! The list of files you can see in the screen shot are some of the tags of MP3 files on my machine, and the column headings can be clicked on to re-order the list according to their headings in ascending or descending alphabetical order. Fields can also be edited, although at the moment the changes are not saved, committed to the db and written to the files. But they will be able to be soon, its only a matter of time. It’s very nice to finally see all those little methods being slung together and creating a functional and usable app at last. It’s felt like a long time coming, but there is light at the end of the tunnel!

TIM Screenshot of MP3 Tag list

Comments off    

Fast indexing

Well, today Dan and I were back on the python case in true pair programming mode and made some modifications to the indexing process. For the first time we tested it on a real archive of MP3 files, everything in my collection to be precise. Approx 30 seconds later over 3000 MP3 files had been successfully indexed by the program. This bodes very well for the final application, as the lack of waiting time for the user is important 🙂

Comments off    

First run wizard

Well, the project has made some good progress since my last posting. MP3 files in a target directory are now being added into a database, which also holds a table for application variables, although this is a yet unused. The schema for the database is now compatable with most databases that take SQL, and the queries have been moved into functions which would be easy to edit in case of future changes.

The GUI is slow going, but with the rest of things falling into place this is now the main focus of the project.

The first run wizard idea was a nifty bit of coding that isn’t quite finished yet, but which I started yesterday. It detects your OS, then looks in the default place in your OS for a config file for the program. If it doesn’t find it it launches a wizard allowing the user to select a name and location for the database to be stored, and the root directory to index. A config file is created and the database is created and loaded with default application variables, a blank set of tables, and the users selected directory is indexed into the tables. All this before the program finally launches. At the moment the “wizard” has no GUI, but it will be easy to add a one window GUI for this, and will make the program run quite nicely.

Comments off    

Small Success

Well, not much to say other than the recent issues with decoding integers stored as binary data in the MP3 files have now been resolved in our ID3 tag reader, so that both version 1.0 and 1.1 tags can be correctly, and fully read.

This should mean that writing tags and a much more functional program should quickly materialise, as not being able to read these integers has been holding us up somewhat over the last week. Watch this space for more developments!

Comments off    

Progress and reality

Progress was made today on the road to understanding how to deal with “struct” in order to extract the track numbers and genre numbers from ID31.0 and ID31.1 tags. My feeling is we are nearly there, just have to learn a little more about types of variable that struct can deal with (aka contacting a C programmer I know!) and the snowball effect to success should start.

The db schema needs a little tweaking, but isn’t far off. I picked up some handy tips in todays DB11 lecture which I hope to apply in some small way to make our database that little bit more refined.

GUI wise, despite recent success with the basics, it has become apparent that the going only gets tougher from here with wxPython due to the distinct lack of documentation. Although slightly more limiting for our desire to acheieve true cross-platform compatability, we have decided to run with GTK the 2.0 version of which is reasonably well supported on Windows, and for which there is a vast amount of useful documentation and example files.

Comments (1)    

Going GUI

Recent dablings in Python have yeilded some rather nice looking results in the form of GUI’s. WxPython seems to be quite easily manipulated, and it was only a matter of time before I was able to get methods to be called upon activating a particular part of the interface. “Tool Tips” telling the user what an option does when the mouse moves over it is almost included by default in the syntax structure and so it was working from the word go.

Currently we have a simpl window, with tool-tips, an about option, ability to close the program from the menu, and an option calling a method that loads a diaolgue to load a group of files from a directory. This we should be able to combine with our tag reading code (when it is finished) and database access code, to enable our first test of indexing a group of files and storing their contents in the database all from a GUI. Fun fun fun! 🙂

Here are some screenies for those who like the eye candy….

About box

Main window

In other python project news, the progression for reading the tags is quite slow, even for ID3v1.0. Although we can read in the Strings ok, the numbers stored as binary are causing us some issues. We are getting these slowly though, and with other parts of the project seemingly going ok, we’re not overly concerned about it. When you spend an hour on a few lines though and get few results, it can be a little frustrating!

Comments off    

Tagged up

Had an hours pair programming session with Dan today, just to try and get the feel of reading ID3 tags from MP3s. Well, that was the aim anyhow, we have in fact surpassed that aim, and managed to get a small python script reading ID3v1.0 tags correctly from MP3 files, and also managed to put the building blocks in place to permit operation with ID3v1.1 tags. This is an important step, as once we can read the tags we can index files, and seeing as I have been playing with SQLite extensively, building our first test MP3 library (read-only) could be just around the corner.

With any luck, enabling writing to MP3 files will be completed in an equally short space of time and we can start the GUI and other components. It’s exciting how fast this project has been progressing so far as it opens up the distinct posibility of being able to tackle some of our more interesting (and tougher to implememnt) desirable features 🙂

Comments off    

SQLite sure is light…

I’m pressing on with my tinkering with SQLite and pySQLite, and things are going rather well on the python side. Less so on the SQL though. I’m quite familiar with SQL and it’s workings and how to manipulate tables. Problem is, SQLite is so light it is missing what I would term crucial features.

For example, dropping a column of a table in SQL is a one liner, pretty basic. Getting SQLite to do the same, is actually impossible directly. You have to create a temporary table, move the values in columns you want to keep to it, delete the original table, create the new table, move everything from the temporary table to the permanent one and then remove the temporary table. *phew* And this is an offcially documented method on the SQLite website. Eeep. There is also the slight quirk of needing to VACUUM your database after deleting large amounts of data, as the memory isn’t actually freed until you do so, despite the data not existing anymore.

I’m sure I will get used to these quirks, but it does raise an important point; no commands used to manipulate SQLite that differ from normal SQL should be used in our code. If they are we will be confined to SQLite in the future, when our ultimate aim is to enable the use of more advanced databases. Unless we feel like delving into the realms of DBAL…….

Comments (1)    

Databases; track those files!

It didn’t seem very difficult to break the project down into manageable chunks; Nicks lecture advised as such and it seemed to be a very good way forward. It seemed that the steps translated to the following:-

  1. Produce a command line application to read and write the ID3 tags of a single file as a command line argument.
  2. Design and construct a database to hold this information and a way of adding multiple sets of data to it in a fast fashion.
  3. Create the architechture to enable searching and editing of data in the database, along with updating the files. Statistics.
  4. Wrap a GUI around all of it to make it usable and friendly for the end user.

While this is a good enough list I paid careful attention in my thoughts to number two, as I’m sure other people would be doing after recent DB11 work. SQL is very powerful, and the potential to leverage this power to produce both an extremely functional and fast app are immense. It is however worth noting that going to and fro from hundreds of MP3 files will be very slow. This brought my thoughts firmly to database design, and devloping a good schema.

Each file needs to have an id, and be recorded in the db with it’s id, path and filename. This means all the searches and retrieval of data after the initial building of the index can be done solely with the database, unless new files or added or the user updates tags. So, thats day to day speed of the system, praise SQL.

Thats not the end by far though. What if the files get out of sync with the db? You might delete a song outside of the app, yu might change the filename outside of the app. This will leave “dead” items in the db, so a simple track needs to be arranged that merely checks for the existance of files, rather than reading them, and compares this with the db. Files recorded in the db that don’t really exist (or have had their names changed) need to have their entries purged, and new files need to be added without the need to re-scan the whole collection.

Although a lot of this comes later in the project, it seems very clear to me that a good database design will allow the database to take the strain of the main searching and tagging work, allowing the files to only be operated on when strictly necesary, thereby making the program much faster for the user and ensuring we only have to put in a small ammount of concentrated effort to make it so.

Comments off    

MP3 Tagging Crisis

It seems the choice of SE12 programming project is a wise one; I have recently converted all my MP3s to go nicely on my Linux box. All well and good you might say, after all they sound good, and are nicely ordered in folders by artist, then album and the file names of the tracks include the title and the number of the track on the CD. Problem is, none of that info is in the ID3 tags!

Crisis looms as I am faced with the prospect of having to manually tag well over 10,000 MP3s from hundreds of CDs I have ripped for playing on my computer. All I can say is I’d better get coding in earnest 🙂

Comments (1)    

Next entries » | « Previous entries