I’ve been working the past couple of days on designing and implementing a new cover storage system for JuK. The current system, although it works, has a few limitations:
- It requires the artist and album information for an album to be filled in, due to the way the cover is stored on disk.
- The system simply associates cover art with tracks based only on the artist and album information. This can be useful as it means that you only have to tag one song to get cover art for all songs from that album. But it also means that all songs from the same album must share cover art, which a user may not want.
- Things like compilation albums simply don’t work well under the current system, as you have to store a duplicate copy of the same cover for every track. This also affects things like songs from the same album, some tagged as Disc 1, others tagged as Disc 2.
The new system I’ve designed should be more suited to dealing with those problems. The way it works is, instead of having cover art for an artist and album combination, each piece of cover art is registered with a Cover Manager, which keeps track of each piece of cover art, any data associated with it, and what tracks use that piece of cover art.
What this means is that there isn’t a lot of data that needs to be stored with a track, as each track is basically given a reference to its cover art, which the Cover Manager will use to grab the right file.
All that I’ve implemented so far is basically what we’ve already had, but now the potential for improvement is there (and shouldn’t be that difficult to implement). For example, it shouldn’t be hard to assign a piece of cover art with just an album name instead of needing the artist information, or to allow overriding’s JuK’s choice for a track’s cover art.
I think what we’d need is some sort of Cover Manager dialog that would allow you to manage your covers, drag a cover onto tracks, etc. I’ll have to ask wheels about it.
In other news, now that KDE is in the process of migrating to Subversion I thought I’d let everyone know that an initial port of kdecvs-build to use iswas in KDE CVS (kdenonbeta). I’m not sure of the new layout of kdenonbeta, but it’s sure to be in the shiny new Subversion repository as well.