I last wrote about changes and updates to AMP (the Absolutely Baching Music Player), way back on January 10th.
I thought the start of a new month would be a good idea to catch up on them, particularly as the pace of AMP development is slowing down and the thing appears to have just about reached a final form I can live with!
So Version 1.03 (January 11th) introduced a new command-line switch that allows you to view the cumulative stored PLAYS table. Every time AMP finishes playing a composition, it records the fact in a table within the database it's using (assuming you've opted to use one at all, which is the most sensible way to run AMP). That table is called PLAYS and accessing it in any way, shape or form previously required you to know how to run a SQLite3 client application. Now you can simply run AMP like this:
amp --report --dbname=main
...substituting in the correct name for your database, of course. The output will be something like this:
The output is scrollable in both directions, so up/down arrows both work (and so does page up and down, to get through it more quickly). It's basic, but does let you check your play history reasonably efficiently. If you want to graph or chart things, you're still going to need to get your hands dirty with SQL, though (and I'll write about that more elsewhere and in the near future).
Version 1.04 (released on January 16th) introduced embedded cuesheet capabilities to AMP for the first time. Backing up a little: instead of a folder of 38 files making up the opera Peter Grimes, why not combine all 38 files into a single 'super FLAC' that contains the contents of the 38 files, but stored within just 1. Doing this combining trick is something my Compositions-At-Once script does (CAO). When there's a single FLAC file, however, how do you know where the 'implicit' track 3 started and ended (for example)? Well, you create what's called a 'cuesheet', which describes the internal make-up of the single super-FLAC in terms of what 'virtual tracks' it contains. That's an external cuesheet: a simple text file, that describes the internal structure of a FLAC file. What CAO does, however, because we don't generally like really important files lying around your file system, where accidental deletes and edits can screw things up for you, is to take that external cuesheet and store it within the super-FLAC file itself. So now it's an embedded cuesheet, embedded within the FLAC file whose structure it describes. Some GUI media players (such as DeadBeef) can read these internal cuesheets and display individual tracks to be selected and played and repeated as if they were standalone FLAC files.
The trouble is, whatever the embedded cuesheet says about how many 'virtual tracks' made up the new super-FLAC, there's actually only one physical FLAC file in existence... and when AMP "scrobbled" to Last.fm having finished playing that super-FLAC, it simply reported 'I've just played one track of Bach' (or Britten or whoever) ...and clearly, that would under-play the "amount" of music you were actually listening to. This was brought home to me strongly when a 94-track Handel opera was scrobbled '1 track of Handel'! So version 1.04 introduced the feature that, if an embedded cuesheet is detected in the physical FLAC file being played, the scrobbles are constructed from that cuesheet, not from the physical folder contents. So if your cuesheet says 'this super-FLAC is made up of 94 virtual tracks', Last.fm will be told that 94 tracks of Handel's opera have just been played: your Last.fm scrobbling statistics will remain accurate, in short (assuming you use AMP's scrobbling capabilities in the first place, of course).
Version 1.05 (released on January 20th) brought a new graphical capability to AMP. If embedded Album Art is detected in the first FLAC found to play within a folder, that album art will be displayed by the ImageMagick program in a separate GUI window. You end up with this sort of thing:
It's not terribly subtle: the album art simply appears as AMP starts playing the music, and it stays there until AMP finishes playing the music! If AMP is playing a cycle of selections, the image will be replaced as each new composition begins. The window is a proper GUI window, though, so you can click and drag it around, re-size it and close it if you prefer (but if you close the window, you can't ever re-open it. You have to wait for AMP to start a new composition before it displays a new one).
To be entirely honest, AMP was originally designed to be a very lightweight text-based music player, so this sort of graphical frippery is not part of its core mission! I added it only because it helps make the process of capturing album art for posting to online forums and the like a lot easier.
So, there's a switch to turn the feature off! If you invoke AMP with a --noart runtime parameter, that will switch the display of embedded album art off.
If album art is displayed, it will always be at 900x900 pixels resolution, whatever size the original album art might be.
Finally, note that to make album art display possible, your Linux system needs to have ImageMagick installed... but this is not prompted for by AMP. Most distros, I think, throw in ImageMagick these days, so it's probably going to be there when AMP needs it. But if it isn't, then AMP just silently won't attempt to display the album art at all. Why doesn't AMP warn you that ImageMagick should be installed if it's found to be missing? I'm afraid that's just another clue that displaying graphical things was never really AMP's core mission! If it can display it, it will; if it can't it just won't. It doesn't nag you about something that it doesn't really care too much about, basically!
Version 1.06 (released on January 26th) fixed another problem with working with embedded cuesheets (see verison 1.04!) Basically, the header area of AMP displays how many FLAC tracks it's going to play:
See the 'Playing: X Tracks' notation about three lines up from the bottom of the header area? That's supposed to say 'Playing 38 Tracks' when playing (say) Peter Grimes, a long-ish opera that is made up of lots of separate FLAC files.
But if you've used my Compositions-At-Once script does (CAO) script to create super-FLACs, there is only one physical file present: the 38 'tracks' making up the opera have all been subsumed into the one super-FLAC. Accordingly, AMP would report 'Now Playing Peter Grimes, 1 Track'.
Version 1.06 simply let AMP read the contents of an embedded cuesheet, if present, and display the number of 'virtual tracks' that cuesheet described instead of displaying the physical count of FLACs. If there's no embedded cuesheet, then it still does a physical count of the FLACs present in a folder to determine the number of tracks being played.
When the number of tracks has been worked out from an embedded cuesheet, AMP sticks an asterisk after the number. So my Peter Grimes opera would now be displayed as 38* Tracks. The asterisk tells you a single super-FLAC is actually being played, but the embedded cuesheet says there were originally 38 tracks making it up.
No asterisk in the tracks count means separate, physical FLACs that have not been combined into a super-FLAC are being played.
The second major new feature in Version 1.06 was the introduction of a 'timebar', that prevents music from the same composer being played multiple times within a given time period (the default time period being 6 hours, but up to 9 is possible, and anything down to 0 is also allowed).
The problem is with randomised playback: being truly random, it's perfectly possible for AMP to pick a piece of Handel to play at 9AM and then, when that's finished, to pick another piece by Handel to play at 9.45AM. Actually, true randomness means that it might even choose to play the same piece a second time!
So the time bar concept simply says, 'if I've played some Handel at 9AM, I won't play any more Handel until 3PM' ...that is, until the 6 hour default 'time bar' elapses.
You can adjust the time bar period by adding --timebar=X to the AMP runtime command line parameters, where X is an integer between 0 and 9. If you set it to 0, you're saying there isn't a timebar at all: you're basically switching the feature off, and if that means a morning's listening turns out to be of Handel, Handel and more Handel, so be it! If you supply an invalid parameter (such as -52 or 985738796, then the default 6 hour timebar kicks in silently. Well, semi-silently! The header area of the AMP player will always display what the current time bar it's using is.
Note that the timebar feature doesn't mean the excludes.txt feature goes away. The two work together: a composer listed in the excludes.txt file simply will never be selected for random play, but using a timebar means a composer is temporarily barred from being selected again for random play. It's perfectly fine to mix and match both approaches: currently, for example, I have a permanent exclude on J.S. Bach, and use the 6-hour timebar to prevent overly-repetitive plays of a morning by any other composer.
Also note that the timebar has no effect if you are not using random play. If I play Handel at 9AM with a 6-hour timebar, then Handel will not get randomly selected again until at least 3PM... but there's nothing to stop me cd'ing to a Handel folder and invoking AMP in local play mode. In that mode, AMP plays what it's told to play, and never mind what any restrictions on the randomiser might be! You can always over-ride both the excludes and the timebar by going to a specific folder of music and invoking AMP directly there, in other words.
Finally, Version 1.07, released at the end of January, brought a couple of minor bug fixes and display tidy-ups (particularly when performing a database refresh). There was also a little extra code to stop the PLAYS table in the database (if you're using one) from locking up: this was preventing the occasional play of something getting recorded correctly. I believe the locking issues should now be resolved. So there were no major new features this time, just a bunch of minor tweaks and fixes.
And so, in conclusion, AMP begins February by being completely able to deal with embedded cuesheets, can interact with a database more capably, is less likely to play the same composer over and over again, and can display album art for you automatically. I can't, at this stage, see any need for further major new features... but I've also learnt not to rule anything out!