Another day of the Gran Canaria Desktop Summit. After yesterday’s post, I got several offers of power adaptors. However, I ended up buying one on my way back to the hotel, along with a bunch of food for lunch today (the lunches here at the university are poor and quite expensive for what they are).

In fact, speaking of food, I had the worst meal I’ve had this week, and one of the worst I’ve had in my life, last night. We went to a Chinese all-you-can-eat buffet. Now, now, don’t scoff. I’m had some good (although never excellent) food at all-you-can-eat buffets. It seems that the Canary Islands is not the place for them, though. This one was so bad that after my first plateful, I was still hungry but didn’t want to eat any more. Avoid like the plague.

This was in direct contrast to the meal I had with the Amarok guys the night before, which was really nice (if expensive) – masses of paella, salad, chips and warm chocolate brownie. It was seriously good.

Today we had more Amarok discussions. So far we’ve discussed:

• liblastfm on Windows
• Playlist synchronisation
• Unit testing
• Whether scripts should be able to respond to Amarok quitting (and potentially slow it down)
• A UPnP collection
• Reorganising the source files
• Playdar
• The UI for dynamic playlists, and context-sensitive information for the area on the left of Amarok (where collections and services etc. are)
• The EngineController class
• Mac/Windows ports

Still to come:

• Media devices update
• The evil “organise files” bug (pro tip: don’t use Amarok 2 to organise your files for now)
• UI clutter

We’ve had a very productive couple of days, and Leo’s been taking photos of the whiteboard, so we have a permanent record of our discussions.  Expect blog posts about the cooler things we discussed.

It’s been a while since I posted. Such is life.

I’m really enjoying my first Akademy. I managed to forget a power adapter to convert between my British plug and the European sockets, but Nuno lent me one for a few days. I now have to find my own, though, as he went home today.

So, the conference. The keynotes on Saturday morning were really good. I recommend watching them when the videos are online (which they may be already). Of course, there is some furore over Richard Stallman’s talk, but I think that was always expected.

Yesterday was the KDE e.v. meeting, which I didn’t go to (not being a member of the e.v.). Instead, I slept in (sleep has been in short supply), went to the beach, and hacked. I put together a small plasmoid (87 lines of javascript) to show some controls for a media player. The idea is that you can put this on an auto-hiding panel on your desktop so that they don’t take up screen real estate, but are easily accessibly just by moving your mouse. The other half of the job, of course, is to do one that displays information. Then you can have the information about what song is currently playing permanently visible, and the controls only appear when you want them.

Today we had a very productive discussion on moving KDE to Git. The aim (if everything goes swimmingly) seems to be to move before KDE 4.4 goes into freeze. Amarok is intending to move very soon, though.

Speaking of Amarok, we’ve been sitting in one of the labs discussing things since the Git BoF. It’s amazing how much gets decided how quickly, especially when you’re used to deciding things on mailing lists. This is particularly true for user interface decisions. I’m expecting great things from the next release of Amarok.

I figured I’d follow Peter Zhou’s lead and ask if anyone is still looking for a roommate at Akademy. I don’t bite, I promise…

So, I was round at a friend’s, and he was playing with Amarok and the Plasma widgets screensaver, and wanted a way to see what was currently playing when his computer was locked.  Of course, I pointed him towards the Now Playing applet, but it was overkill for what he wanted – he didn’t want the buttons, or the sliders – just a display of the current information.  Well, I was in the mood for playing, and it took me about 15 minutes to construct a javascript plasmoid, most of which was spent researching how to use data engines from them.

The code I left him with was:

layout = new LinearLayout(plasmoid);
layout.setOrientation(QtVertical);

label = new Label();
layout.addItem(label);
label.text = 'No player'

plasmoid.dataUpdate = function(name, data) {
    label.text = 'Info:\n';
    for (var key in data) {
        label.text += key + ': ' + data[key] + '\n';
    }
}

plasmoid.dataEngine("nowplaying").connectSource("org.mpris.amarok", plasmoid, 500);

This was in a file called “main.js” in a subfolder called “contents”. In the plasmoid folder (the folder containing the contents folder), I also put in a metadata.desktop file:

[Desktop Entry]
Name=Simple Now Playing
Comment=Now Playing as Matt likes it
Icon=applications-multimedia
Type=Service
X-Plasma-API=javascript
X-Plasma-MainScript=main.js
X-Plasma-DefaultSize=200,100
X-KDE-ServiceTypes=Plasma/Applet
X-KDE-PluginInfo-Author=Alex Merry
X-KDE-PluginInfo-Email=alex.merry [SPAMNO]@[SPAMNO] kdemail.org
X-KDE-PluginInfo-Name=simplenowplaying
X-KDE-PluginInfo-Version=0.1
X-KDE-PluginInfo-Website=http://plasma.kde.org/
X-KDE-PluginInfo-Category=Multimedia
X-KDE-PluginInfo-Depends=
X-KDE-PluginInfo-License=GPL
X-KDE-PluginInfo-EnabledByDefault=true

Now it was just a case of calling plasmapkg -i . from within the plasmoid directory, and the simple widget was installed. This produces the following:

Of course, this will only work with Amarok, and doesn’t respond to Amarok being started or quit. That’s OK, it’s not much more work to deal with that:

layout = new LinearLayout(plasmoid);
layout.setOrientation(QtVertical);

label = new Label();
layout.addItem(label);
label.text = "No player found";

function firstSource() {
	var sources = plasmoid.dataEngine("nowplaying").sources;
	if (sources.length) {
		return sources[0];
	} else {
		label.text = "No player found";
		return '';
	}
}

plasmoid.dataUpdate = function(name, data) {
	if (source == name) {
		label.text = 'Info:\n';
		for (var key in data) {
			label.text += key + ': ' + data[key] + '\n';
		}
	}
}

source = firstSource();

npDataEngine = plasmoid.dataEngine("nowplaying");

npDataEngine.sourceRemoved.connect(function(name) {
	if (name == source) {
		source = firstSource();
		if (source) {
			npDataEngine.connect(source, plasmoid, 500);
		}
	}
});

npDataEngine.sourceAdded.connect(function(name) {
	if (!source) {
		source = name;
		npDataEngine.connect(source, plasmoid, 500);
	}
});

if (source) {
	npDataEngine.connectSource(source, plasmoid, 500);
}

Of course, it’s not much work to only show the things you’re interested in, but this covers the interesting parts of the plasmoid.

Interesting note: it appears that if you replace the line label.text = 'Info:\n'; with label.text = '';, the subsequent calls to label.text += ... don’t work – you just end up with a blank label.

This is a deconstruction of 10 reasons why GNOME is better than KDE, which is pretty obviously a piece of flame-bait. Wallen basically says as much at the start of the article. But I’m in the mood for dissecting arguments.

I would like to say right now that this is not a “10 reasons why KDE is better than GNOME” article. That would be inane. I have many GNOMEy friends, and no intention of trying to convert any of them. Anyway, I’m pretty sure that any one of you can come up with both 10 things KDE does better than GNOME and 10 things GNOME does better than KDE.

Instead, this is an excercise in deconstructing an argument. Critical thinking, if you will. Because Wallen completely failed to come up with 10 reasons for anything.

So, lets start at the top. “1. KDE 4″. I’m not really sure there’s anything to say about this, other than that the entire paragraph is simply a collection of unsupported statements (with no narrative to connect them). He doesn’t provide a single example to support any of his attacks (including ‘KDE was (and is) the first-ever “Microsofting” of the Linux desktop’ and KDE 4 was “painfully worthless”). OK, let’s move on.

“2. Start Menu”. Well, using Microsoft terminology when ‘”Microsofting” the Linux desktop’ was mentioned in the previous paragraph was probably intentional, but not helpful to any argument, really. We get “It should be pretty obvious” and “It should also be fairly obvious” almost straight off the bat. Chalk one down for unsupported statements.

There’s possibly a valid criticism about Kickoff and the lack of KDE 3’s quick menu applets being made in here, but it’s difficult to disentangle from the ad hominem attacks. And he probably has a point about discoverability of things like how to change the menu to “classic” style. Not that I believe such a thing is both possible and discoverable in any other desktop, so I’m not sure it really advances his original argument about one desktop being “better” than the other.

In “3: Nautilus vs. Dolphin”, he actually doesn’t compare Dolphin to Nautilus. He compares Dolphin to Konqueror, and the latter still functions as a file manager in KDE 4. OK, that first statement wasn’t entirely true. He says that Nautilus is Dolphin, but stable (and makes a reference to Dropbox that appears to bear no relation to anything else). That brings the number of potentially valid criticisms in this article up to about 3 (the arguments in section 2 were hazy).

He also says that users will find most of the features of Dolphin useless. And justifies this by mentioning one feature, possibly two if you count rating and tagging separately (Dolphin has more than three features, right?). One black mark next to “generalising from the specific”. And possibly “presenting exaggeration as fact”.

“4: Foundations”. I’m not sure why he picked this title. Qt 4 gets a passing mention (in the first sentence), and the only thing that is said about GTK+ is that there will be a version 3 soon. I guess you’re supposed to infer from context that this will break backwards compatibility. He also implies (but doesn’t say outright) that the port to Qt 4 was largely or solely because of the potential for a windows port. The reason was in fact because Qt 4 had a much-improved API, and Qt 3 was shortly to become unsupported by Trolltech (as was).

This section also has a fallacious comparison between GNOME 2.24, with it’s forward compatibility flags, and KDE 4 (a more sensible, although still not entirely accurate, comparison would be the as-yet-unreleased GNOME 2.30 with KDE 4). The thing is, he could probably have made a decent argument along the lines of GTK+3’s migration plan being better than QT 4’s, but he completely failed, largely by getting sidetracked with the Window port non-issue. Oh, and I’m really not sure what resources he believes are being diverted from the main project to work on the windows port. Or how KDE might go about forcing those people who insist on getting their favourite applications to run on Windows (as they did even back in KDE 3 days) to give up such an unworthy pursuit and return to the warm, fuzzy and – above all – morally superior fold of free unix-based operating systems.

Sorry, I seem to have had a nasty attack of sarcasm there. I’ll try not to let it happen again.

On the other hand, section four is possibly the most well-constructed section in terms of arguments. I had to remove the underpinning (the assumption that the move to Qt 4 was all about Windows) before the rest of the structure of the argument collapsed.

Oddly enough, in “5. Resources”, his one concession to KDE 4 (using fewer resources than KDE 3″ is highly disputed among those who measure such things in KDE. The rest of this section revolves around his decidedly unscientific comparison between the memory usage of KDE and GNOME (given the content of section 10, one has to assume that this means default installs of Fedora 10, but there is nothing to say so). He gets a difference of 10Mb when both desktops use more than 1.25Gb of RAM. That’s a 1% difference in memory usage. Apparently this means that “GNOME requires less hardware to run”. I’m not entirely sure where he intends to buy exactly 1.27Gb of RAM from (which, it seems, will run GNOME but not KDE – providing you don’t launch any other applications, of course). But, seriously, 1% is not a significant difference. Given that his measurement almost certainly includes kernel caches, and is probably based on the default installations of one particular distribution, it is almost certainly completely dwarfed by the error rate.

“6. Clutter”. Half-way there. Showing the desktop folder, it seems, is cluttering the desktop. Despite this being what just about every other desktop implementation out there does. *shrugs*. Let’s play along, then. This is a reasonable argument, but made at the expense of ignoring the facts. The major one is that it takes one click to remove the item he’s complaining about. So, a second argument that required me to actually respond with a fact, rather than dismantle purely on the basis of fallacious reasoning.

“7: Customization”. Again, lots of unsupported statements. GNOME is almost infinitely customizable (how?); KDE 4 locks you down (in what way?). Nowhere does he give even one example of something that GNOME allows you to customise that KDE doesn’t. He talks about mouse menus, but this appears to be a comparison of KDE 4 with KDE 3 (and I’m not sure what he means by “mouse menus”, either). And saying that you can’t change the look of something except by using the very mechanism that allows you to change its look (theming, in this case) is… true. But completely besides the point.

“8: System Tray overkill”. This is a comparison of the default setups on Fedora 10, not of the default setups of the desktop environments in general. So this is an example of generalising from the specific.

Apart from that, not all of the items he lists are actually part of the system tray (the clock, for example, is actually an applet, not a system tray icon). And desktop shells can’t do anything about the system tray other than display what programs offer. The applets, on the other hand, can be removed – both in GNOME and KDE. The one valid argument in this is about the loading time of the system tray. I think that’s 4 valid arguments (that couldn’t be immediately dismissed by stating a single fact) in total so far.

“9: Default applications”. Konqueror has been the default web browser of KDE (although not necessarily of any given distribution’s installation of KDE) since KDE 2, as far as I’m aware. So quite where he got the idea that Konqi has suddenly moved into this role, I don’t know. KOffice 2 hasn’t even been released, so I doubt it’s the default anywhere (although I’ve heard that Fedora can be pretty bleeding edge). And Firefox isn’t the default browser in GNOME, it’s Epiphany. Although that does use the same rendering engine as Firefox. And I’m not sure GNOME really has a “default” office suite. Basically, Wallen is confusing desktop environment defaults with distribution defaults. Repeat after me: Fedora is not representative of all Linux distributions.

So that’s a mix of generalising from the specific and ignoring certain facts.

“10: KDE = Vista?”. I can sum this up as “people don’t like Vista, and I think KDE looks like Vista, ergo KDE sucks”. Unfair? Well, maybe. But saying that you can make KDE look like Vista by installing the right theme (I assume Emerald refers to a theme) does not an argument make. And I know that Vista is famed for being unstable (slightly unfairly, I have to say), but all software goes through an unstable phase (except possibly TeX) and that doesn’t make it like Vista. Or unlike Linux (as in GNU/Linux, not the kernel). And he still hasn’t presented a convincing argument (or an argument at all, for that matter) for KDE 4 not being flexible. Plasma was designed to be much more flexible than kicker/kdesktop, and Wallen has failed to provide any evidence that it has failed in those aims. Not that I’ve presented any evidence it has succeeded in them, but my aim is not to prove the worthiness of KDE 4 but to dismantle Wallen’s arguments.

Finally, Wallen makes the common mistake of assuming that KDE 4 = Plasma. Well, OK, Dolphin got a mention. Yes, it’s probably the most user-visible component of a KDE 4 desktop session, but KDE is primarily a software platform, and includes a desktop shell as part of that. So that’s generalising from the specific again.

Well, I found four reasonable arguments in there, plus a few more that were recognisable as arguments even if they could be countered with a simple fact (I can forgive people for not knowing all the pertinent facts ). But most of the rest didn’t form any coherent argument at all.

I think that’s enough from me. I suggest you all go read about logical fallacies now, so you can give fancy names to Wallen’s arguments.

This has been a public service broadcast on how not to argue your case.

[Post edited slightly at 21:26 GMT 2009-03-31]

Michael Pyne added support for album art to Juk’s D-Bus interface, and modified the now playing dataengine to get this artwork.  The dataengine already supported getting artwork from MPRIS-enabled players, and Amarok has provided album artwork over MPRIS for a while.

So I’ve now added the display of album artwork to the now playing widget:

The Now Playing widget with album artwork

Naturally, this disappears (and the text moves over to the left) when there is no album artwork available, and the image resizes to be as tall as the text when you resize the widget.

Oh, and I fixed the scrollbars to work when you use the mouse wheel on them.  This fix will be in the next release of 4.2 (although the artwork won’t be).

Now I need to improve the functionality of the widget when it’s on the panel.  And any help in generally making the widget prettier would be most welcome.  I really don’t like the scrollbars, and the album art needs a frame.

Now that Amarok can read replay gain tags from almost all the files that it can read metadata from, I feel replay gain support in Amarok is pretty much there.  And, yes, all this will be in Amarok 2.1.

A small caveat: the reading of replay gain tags from MP4 files only works if Amarok was built against libMP4v2.  Amarok uses its own (home-brewed?) code for reading MP4 tags when it can’t find libMP4v2 at build-time, but it doesn’t support freeform tags and I don’t see the point of implementing that support when libMP4v2 does the job.

Amarok 2.1 will support all the file formats that Amarok 1.4’s replay gain script did (and more), apart from Musepack (mpc).  Ironically, this is because of Musepack’s native support for replay gain – rather than abusing metadata tags to store the replay gain information, Musepack has a special field in the file header to specify the values.  However, TagLib doesn’t let us at this field, so we’re a bit stuck.

So the state of replay gain support in Amarok is that, for files in the main collection or elsewhere on your computer’s filesystem (so not streaming media and not portable music players), replay gain tags (both album and track mode) will be read from the following formats:

• MP3 (as written by mp3gain/aacgain, Foobar2000 and Mutagen/Quod Libet – yes, there are three different ways of writing the tags to MP3 files)
• OGG Vorbis (as written by vorbisgain and anything compatible)
• OGG FLAC (assuming the tags are stored in the same way as in OGG Vorbis)
• OGG Speex (assuming the tags are stored in the same way as in OGG Vorbis)
• FLAC (as written by flac [with it's --replay-gain switch] and anything compatible)
• WMA/ASF (as written by the Amarok 1.4 replay gain script)
• MP4 (as written by aacgain and anything compatible, providing Amarok was built with libMP4v2)
• WavPack (assuming the tags are stored in a similar way to how mp3gain stores them in MP3 files)
• TrueAudio (assuming the tags are stored in a similar way to how Foobar2000 or QuodLibet/Mutagen store the tags in MP3 files)

In addition, Amarok will use the track mode tags (or the album mode ones if there aren’t any track mode tags) to adjust the gain during playback.  I haven’t added an option to switch to album mode (or even disable it, if you really want to) yet, but that will come.  I just have to figure out where it should go in the user interface…

Of course, this is only half the functionality provided by the Amarok 1.4 replay gain script.  That also parsed and tagged files in the playlist.  This could be implemented nicely as a script (I certainly don’t believe it belongs in the core of Amarok).  But that’s for another day, and probably another person.

So, after some trial-and-error, I’ve cracked the RVA2 frame format as written by Quod Libet / Mutagen.

• All values are stored big-endian (most significant byte first).  This tripped me up, because this is not true for all data stored in all tag formats.
• If we think of the peak value in terms of the “units, tens, thousands” format you learned at school (only, of course, in binary this is “units, twos, fours”), the first bit is the units, the second is the halves, the third quarters and so on.  Simple, yes?  However, it’s not so easy to infer from the code that parses it.  So I’ve put plenty of comments in the amarokcollectionscanner code.
• Everything else you could wish to know about the format is in the ID3v2.4 frames list, section 4.11.

So Amarok’s collection now has complete support for replay gain tags in Ogg Vorbis (as written by vorbisgain), FLAC (as written by flacenc) and MP3 (as written by Foobar2000 [ID3v2.3 TXXX comments], Quod Libet / Mutagen [ID3v2.4 RVA2] or mp3gain [APEv2]).

Other formats will follow.  As will replay gain support for files that aren’t in the collection, but are on the local machine.

Amarok now reads the tags written by Foobar2000 and by mp3gain (written when you call mp3gain without the -a or -r options) from MP3 files.  However, the final part of MP3 support is tricker: the RVA2 tag in the ID3v2.4 spec.

Naturally, the specification leaves out an all-important detail: the format of the peak volume field.  It tells you which bits represent the peak volume, but not how to interpret them.

Luckily, mutagen, a Python audio metadata library, supports this tag, so it’s implementation can serve as a reference.  However, they try to be clever with their implementation, so reverse-engineering it to arrive at the format of the original data requires some work.

The documentation on the Python class implementing the RVA2 frame support says that the peak volume is a float between 0 and 1.  So 0 is silent, 1 is full volume (digital full scale).  This doesn’t seem right to me, because the replay gain specification points out that it is possible to have a peak volume over 1 in some circumstances in a compressed audio file.  But we’ll leave that aside for the moment.

Let’s start with the code.  data contains the raw bytes, the first of which is a number specifying how many bits (not bytes) of the remaining data is occupied by the number representing the peak volume.

        peak = 0
        bits = ord(data[0])
        bytes = min(4, (bits + 7) >> 3)
        # not enough frame data
        if bytes + 1 > len(data): raise ID3JunkFrameError
        shift = ((8 - (bits & 7)) & 7) + (4 - bytes) * 8
        for i in range(1, bytes+1):
            peak *= 256
            peak += ord(data[i])
        peak *= 2**shift
        return (float(peak) / (2**31-1))

Let’s start with bytes.  This is simply bits (the number of bits representing the peak volume) rounded up to the nearest 8, then divided by 8.  So if bits is 8n + k, bytes is n in the case that k = 0 and (n+1) in the case that k > 0.

The next variable is the shift.  This is the first bit of clever magic, and it takes some time spent staring at it (preferably with a pad and paper to hand) to arrive at the following conclusion:

• if k = 0, shift is 8(4 – n)
• if k > 0, shift is 8(4 – (n + 1))

Then we read the bits into peak.  Remember that if k > 0, the last (8 – k) bits will be junk.  Now we shift it right (shift is always at least 0, because of our contraint on bytes to be at least 4) so that the first 32 bits are all that remains (I assume here that Python is treating peak as an integer).  Then we turn peak into a float and divide it by (2³¹) – 1.  This contant is a magic number, being the largest value that can be stored in a signed 32-bit integer.

Something that might shed light on this is that, when it writes the peak volume out, it simply writes the value multiplied by 2¹⁵ as a 16-bit unsigned integer.  This would make interpreting the value as simple as placing a “decimal” point after the first binary digit (so we get 1 digit before the point and 15 after).  Note that this does indeed allow a peak volume greater than 1 (but less than 2).

I’m left with two questions:

1. Why do we divide the number by MAX_INT_32, rather than simply 2³¹? (I just made up that constant name now, don’t complain that it’s wrong.)
2. Why does mutagen put a 32-bit minimum on the number, and then write a 16-bit number when it writes out RVA2 tags?

Answers on a postcard (or just in the comments).

SVN commit 911684 by alexmerry:

ReplayGain FTW!

Make replay gain support actually do something by
(a) getting the data we stored out of the collection database
(b) using it when the track changes

Also, improve the storage of replay gain tags by storing NULL when they weren’t present on the original track metadata. This allows us to substitute the track gain for the album gain when the latter is requested but doesn’t exist.

This closes the most popular feature request on bugzilla.

Of course, there’s still work to be done.

• Currently, it’s fixed in track mode.
• It only works on files in the collection – it should be possible to extend it to other files on the local computer at least.
• Finally, it only works on Ogg Vorbis and FLAC files (mp3gain and aacgain modify MP3/MP4 files in such a way that we don’t need to do anything special in Amarok for them to sound right, providing you pass either the “-r” or “-a” option). Adding other file types is simply a case of adding the relevant code to amarokcollectionscanner.

But, right now, I’m listening to my music all playing at the right volume (apart from the WMA files, but what can you do?).

[edit] I should point out that it works without moving your volume slider up and down like the Amarok 1.4 script did.  It just works magically and invisibly, like it should.  This part of the implementation (actually changing the volume) was a doddle, thanks to the wonder of Phonon.  [/edit]