Alphanumericalize: Filename munging music file names in ABCDE

Ripping CD feels a lot more 2005 than 2015. And it was probably already starting to feel old back then. However, I never got round to do a systematic, lossless rip of my entire CD collection. So before it’s too late I have bought a DVD-RW drive that will never get to write a single disc and armed myself with a 1Tb USB drive to hold all the data.

My weapon of choice is ABCDE, A Better CD Encoder, a Bash based CLI tool for ripping that has been in continuous development since before 2002 (!). ABCDE has many advantages over GUI CD rippers, the most obvious being that you don’t need to fiddle with the mouse, you just hit enter. This is important if you’ve got a case of hundreds of CDs to get through.

Another advantage is that the settings file allows you to string a piped line of stream editors together when forming the file name. What this means is that once you have determined how the file names should be formed, e.g. “Artist/Album/Track no. – Track title”, you can further manipulate it e.g. by making it entirely lower-/uppercase, removing slashes and other control characters etc. The genius of ABCDE is that rather than implement these features itself, it simply allows you to use tested and true unix utilities, like sed and tr and whatever else you care to throw at it to accomplish this.

Here I’m going to detail generally how this ‘filename munging’ works and specifically I’m going to show how to get file names that are universally OS-, URL- and command line friendly by only using numerical digits, the letters a-z, underscores (_) and hyphens (-).


Resurrecting imwheel

Xmouse for Windows is brilliant. And it makes a mockery of any linux desktop user’s claim to having the more customizable user environment. Well at least as far as pointers go. What Xmouse does is allow you to intercept any mouse action and translate it into any sort of user interaction, be that simply another mouse action, a keyboard action, interacting with the desktop, starting a new program, a mix of the above or (possibly) something else entirely. It has a huge list of possibilities and options, including automatically switching profiles to match the currently running program.

On linux we have a mess of a wiki page with an assortment of hacks. Googling specfic issues result in a similar cocktail of ancient xorg tools, including xkbset, xinput, xmodmap, btnx, xkbe and many more. Now, I’m not one to disparage using old, true and tested tools (see: devilspie, wmctrl) but in this case I believe, it is just poorly documented hacks as X seems to have added ‘pointers’ as somewhat of an afterthought. Poorly worded howtos, barely understood copy-and-paste suggestions and google results stretching back into the mists of time and linux make this a horrible jungle for even experienced linux users. The google problem is compounded by intersecting interests: Some want their mouse to do keyboard inputs, some want them to do commands, some want keyboard keys to serve as mouse buttons, etc.

imwheel has been brought to my attention before but a) the tool seems to have fallen from grace sometime in the previous decade (for one it was dropped from the official Arch Linux repositories and now only resides in the AUR) and b) the man page isn’t really written from the perspective of a user with a specific goal in mind and c) I do believe the semi-gui configuration helper (somewhat similar to xev) isn’t working in today’s desktop environments. So I know that I’ve tried it before and given up – if I even succeeded in building it – concluding that it was probably dead in the water.

Well, Lazarus just got up and walked. The difficulty (for me) lay in the fact that the command line options don’t really hint at how you would want to use it. You have to create a config file but then you can simply run it with ‘imwheel’ and forget about it. As simple as that. This will allow you to intercept mouse actions and get a mixture of mouse and keyboard output that can be made dependent on the currently active program. A somewhat simplistic Xmouse, then. Without the GUI.


Everything in it’s Right Place 4: Launch and switch

This is the fourth post in a series on achieving an orderly desktop environment in GNOME 3, using no add-ons, only old school hacks. See also the first, second and third post in the series.

Following the first two set of instructions we’ve got static workspaces and windows spawn where they should. That in itself is not terribly convenient as I now have to run up and down in the GNOME workspace stack to find the window I’m looking for – even if I just launched it – or rely on the old alt-tab trot that we know and hate from Windows. To torture this metaphor, we’re going to skip the stairs and install an express elevator thus also justifying the arbitrary choice of the post’s header image.

This is where the final piece of the puzzle comes in: A better way to start applications and switch between them. These two kinds of actions tend to be treated separately. You start up an application by clicking an icon or typing a command and then you find it again later on by different means. Both actions stem from the ‘I need application X now’ impulse. So you should channel that impulse the same way. There is an established way to integrate them, though. Windows 7+, GNOME Shell, and Mac OS X (I believe?) all tie an icon to a permanent process bar and have this work as both process launch and recall. I don’t think this is a good solution for a number of reasons: a) it’s not convenient (read: keyboard-centric) and b) I dislike bars (the taking-up-screen-space kind, not the other one one). The simple solution: Associate one application with one keyboard shortcut and leave it to the computer to figure out whether this means starting the application or retrieving a running instance. Either way it will obviously have to be on it’s proper workspace, see post the second, so we want to come to (move the focus to) the workspace of the window, rather than janking it out of it’s place and having it come to us.

To this end we introduce two tools that will help us achieve this: wmctrl for manipulating windows and xbindkeys for the keyboard shortcut bit. Also bits of Bash for glue. All of these are omnipresent on linux distibutions and should be installable as packages named just as written above. One word of warning, though. This entire series is composed of hacks but the previous ones are so established and solid that it hardly counts. This is where it gets a bit hairy.


Everything in it’s Right Place 3: Setting dedicated workspaces with devil’s pie

This is the third post in a series on achieving an orderly desktop environment in GNOME 3, using no add-ons, only old school hacks. See also the first and the second post in the series.

Dedicated workspaces is a term – possibly – of my own invention. Possibly not. The basic idea was outlined in the first post: “Certain windows belong on certain workspaces”. With multiple workspaces you easily get windows randomly strewn across the workspaces. A browser there, a file manager here, a text editor over there. Because I am pretty goddamn anal this kind of thing bugs me. For my peace of mind as well as for windows being easy to find I need them to be in their proper place. So I devise some sort of order that groups the various types of windows into themes and hierarchies. I tend to group windows into categories like browsers, editors, viewers etc. but the exact nature of my chosen order is not the subject here. The point is that each window has one and just one workspace where it should spawn and where it should stay. It may have that workspace to itself (more easily accomplished with a grid of workspaces) or it may share it with other, similar windows. The technique is the same and utilises just one tool, devil’s pie.


Everything in it’s Right Place 2: Setting static workspaces

This is the second post in a series on achieving an orderly desktop environment in GNOME 3, using no add-ons, only old school hacks. See also the first post in the series.

In the previous post I laid out the requirements for my ideal desktop. In the following I’m going to explain how I go about achieving this within the confines of Gnome Shell. Which immediately begs the question: Why Gnome Shell? There is a ton of alternative desktop environments and window managers out there, many of which may be more amenable to what I intend to do. I will not go into the whole desktop choice debate here. Suffice to say that I still believe that Gnome Shell can be made into a decent desktop environment with the hacks detailed in these posts.

Here’s the plan: First we’ll set static workspaces with Gnome tweak tool (alternatively dconf), then we’ll make various windows adhere to a specific workspace using devilspie and then we’ll set up a way to switch between applications using wmctrl and xbindkeys. This post will focus on getting static workspaces to work.