Since IMMS stores metadata in an SQL database, it is possible to use standard SQL queries to generate all sorts of reports about your music collection. You can execute them with
$ sqlite3 ~/.imms/imms2.db '<query>'
Here are some useful examples:
Favourite 20 artists sorted by number of high rated songs
SELECT COUNT(*) as Tracks, readable FROM Identify NATURAL INNER JOIN Ratings NATURAL INNER JOIN Library NATURAL INNER JOIN Info NATURAL INNER JOIN Artists WHERE rating > 80 GROUP BY aid ORDER BY Tracks DESC LIMIT 20;
Favourite 20 artists sorted by the average rating of their songs
SELECT ROUND(AVG(rating)) as Artistrating, COUNT(*) as Tracks, readable FROM Identify NATURAL INNER JOIN Ratings NATURAL INNER JOIN Library NATURAL INNER JOIN Info NATURAL INNER JOIN Artists GROUP BY aid HAVING count(1) > 8 ORDER BY Artistrating DESC LIMIT 20;
More information on Query Language Understood By SQLite can be found here.
The acoustic analysis part of IMMS has been split out into a separate application as of IMMS 1.2. This made IMMS less tightly coupled with XMMS (aka one more step towards becoming a adaptive playlist framework). IMMS no longer needed to be a Visualization plugin, which means you can batch scan your entire music collection and thus start reaping the benefit of acoustic correlations right away.
The last one can be done using something like:
find /mnt/mp3 -type f -exec analyzer {} \;
Analysis is rather slow - it has to decode the entire file - so it will take a while, but analyzer is smart enough to skip files that have already been analyzed, so you can interrupt it at any time and continue running it later.
There are some files that have id3v2 tags that cause sox to hang. It is nice to see the progress of the analyzer on larger file lists to make sure it is still progressing. Use a variant of the above command:
find /mnt/mp3 -type f -exec echo {} \; -exec analyzer {} \;
Or, to sort the files first so that you have a better idea of how much of your collection is done, and to avoid trying to analyse non-music files:
find /mnt/mp3 \( -name '*.mp3' -o -name '*.ogg' \) -print0 | sort -z | xargs -0 -t -n1 analyzer
Starting with version 1.0, IMMS comes with a little utility called immstool. Although immstool is mostly a debugging tool for developers, it has some functionality that might also be useful to advanced users.
For example, if you frequently add and delete files from your collection, there might be some small performance benefit to be had by cleaning the stale entries out of the database. To do that, make a backup of your database (just in case) and run:
immstool missing > missing.files
immstool purge < missing.files
Since moving/renaming files would put them on the missing list, until IMMS notices their new location and updates the database, purge has a built in safeguard that will only delete files that have been last played over 30 days ago.
Note: simply piping missing into purge will not work, because they cannot run concurrently (they both need to lock the database). If you really want to do it in one command, a cheap hack around that is to throw a sort in between.
To clean up any orphant entries, normalize paths, and vacuum the database, run:
immstool lint
A quick way to see information about a particular file, without using any sql commands is:
immstool identify <filename>
Note that it would be a trivial matter to extend this to allow you to manually adjust the rating of the file as well, which is something I get asked about every once in a while. I refuse to do this on a matter of principle, because I don't believe you should have to, but if somebody sent me a patch that added this functionality, I would consider including it :)
immsgraph is a cool little script that can be used to get an idea of what the distribution of ratings in your collection is like.
immsgraph2 (php version by Niels Andersen)
immsplot.sh (bash/gnuplot version)