So if you’re interested in TheLastRipper development join today…

Update: I’m happy to announce that Andreas Langmann is also a project owner now, so that I’m not the only administrator…

• New GUI station selection improvements.
• Using the new last.fm protocol version 1.2 (Skip now works!).
• Additional management features like skip songs already recorded.
• A few other minor details…

This release is largely created by Andreas, since I haven’t really had time for it. Which is also why it’s not ported to Linux yet, though the executables with Windows.Forms GUI runs fine under Mono/Linux, we’d like a GTK# GUI because it’s much prettier. I hope I’ll find time to do a Linux port soon…

Now some might be wondering why it’s called version 1.3.0 and not 1.2.0 – well, what can I say: It’s a “known issue” I think I accidentally incremented it one too much, and since we can’t really delete downloads from GoogleCode it’s going to be version 1.3.0 instead. It would also look weird to have a version 1.2 featured and a version 1.3 deprecated.

Anyway I don’t think the version number thing is so bad either, I think I previously stated that there wouldn’t come a version 1.2.0, because I was going to rewrite the codebase. Because a rewrite would be needed to make a clean, easy portable and extendable backend implementation of the Last.fm protocol version 1.2. I started development of such a clean backend, but it’s still stuck in development, since I don’t have time for it at the moment.

Anyone familiar with the old protocol (version 1.1) knows that Last.fm gave you an mp3 stream, and a place to go if you wanted to request the metadata associated with the music currently playing. This wasn’t very nice, because you had to guess when a new song started, I know that the last metadata response contained information about how long the song was, but you didn’t know exactly when the song was started. Alternatively it was possible to search the stream for mp3 headers, which gave you precise information about when a new song started. But that required some computing. The new protocol just returns an XSPF playlist with mp3s and metadata, now that is very nice.

Nevertheless, I and some other last.fm users have developed an unofficial documentation of the new last.fm protocol version 1.2. I’ll release it shortly, and I’d expect a implementation of this new protocol for TheLastRipper to start rather shortly too. If you want to stay updated on this issue, you can subscribe to issue 63. You do that by clicking on the star.

UPDATE:
Last.fm didn’t drop support for 1.1 protocol it was just gone for the weekend + Monday. Though a minor change in the login scheme caused TheLastRipper to freeze, this issue have now been fixed, and latest release of TheLastRipper works (Version 1.1.1). We’ll still be working on an opensource implementation of the Last.fm 1.2 protocol.

As this seams like a big feature, and as argued by Andreas in the issue tread, it’s probably not a feature for TheLastRipper. Nevertheless it doesn’t mean that the problem should be fixed, just that it should be done elsewhere. This is also good, since you entire music collection doesn’t necessarily origin from TheLastRipper. The solution is to implement this feature at playback level, meaning in your audio player.

For those of us running Ubuntu and using Amarok, this can be done easily. First open Amarok, choose “script-management”, Click download new scripts. This will open a dialog showing the newest, most popular and most downloaded script for Amarok. Just install the script called ReplayGain. Once this is installed you’ll have to install some dependencies with Synaptic. I’ll try to list those I think is needed: python-kde3, mp3gain, vorbisgain, flac, python-xml

If you enter the script-management in Amarok again, you can enable the ReplayGain script. Enable it, select it and click “Settings”, you can tweak the ReplayGain script a little here. Once your done with that leave the settings, and ReplayGain will print a small popup, telling you which optional dependencies you are missing. I’ve probably forgot to list some of them, you may find them in Synaptic if you think you need them. Though I haven’t found “aacgain” or “replaygain” in the Ubuntu repositories.

Well, you don’t need “replaygain” or “AACGain”, unless you, like me, have AAC music. Actually I’ve just bought my first AAC music from iTunes. I haven’t used iTunes before, but I thought I’d give it a try since they started releasing DRM-free content. So I installed iTunes in my virtual machine, and copied the AAC files back to my Ubuntu system after they were downloaded. First I must say, the quality of iTunes plus files are very good, and the files has ID3v2 tags (other mp3′s I’ve bought online did!). It’s sad that iTunes doesn’t run on Linux, Apple could at least offer a web interface for iTunes plus.

Well, if you have AAC encoded music, you’ll need AACGain, it’s not in Ubuntu or Debian repositories. Actually I couldn’t find any .deb packages for it anywhere. So I decided to make my own. You may download my ACCGain package here. Feel free to contact me if you want the source package.

Once you’re done installing dependencies, and have enabled the ReplayGain Amarok script, you can right click in your playlist and choose “Apply Replaygain tags”, I selected “To entire collection using album tags” it took a while but the volume was automatically determined by Amarok afterwards.

• Perfect clipping of songs
• ID3v2 tag
• Support for proxy settings
• Better threading
• International character support
• Many minor bugfixes

These features have been under development for a while and the Windows and Linux clients in SVN already have these features, they will be release as 1.1 very soon too. But last weekend me (Jonas) and Rene of TheLastRipper developer team, decided that it was time to get a beautiful port for OS X. So we started out with the 1.1 codebase from SVN and installed XCode, Mono and CSharpXcodePlugin on a Mac. Then we wrote one of those simple “hallo world” applications in Cocoa#, after becoming a little familiar with Interface Builder and Cocoa#, we started the development of a client using Cocoa#.

And even though the Cocoa# bindings aren’t complete, the weird behaviour of Interface Builder, minor bugs in Xcode and the fact that we wrote most of it during a hangover, the result compiles (sometimes), and works fine too. This version is now being released as TheLastRipper for Mac version 0.9 Beta, once it’s been tested a little more and the last details have been fixed it will be released as stable too.

Now a bit about Mac and Mono based development. First of I’d like to say that I’m not a Mac user and never have been, I’m a Linux user with years of Windows experience, now practiced in a virtual machine for legacy applications. Now getting CSharpXcodePlugin installed and doing the LetterCounter video tutorial is definitively a good start. But it’s difficult to find documentation for Cocoa#, I had to go with what I could get from the assembly cocoa-sharp.dll using Monodocer. The result was that we copied the cocoa-sharp.dll to Windows and added it as reference to a SharpDevelop project to enable intelliSense, since that was basicly all the documentation we could find. But once that was done, developing the actual code on Windows and the interface on OS X was actually pretty easy. Especially with TheLastRipper since all the logic is in a platform independent .dll, which means we only had to write a little clue code. Of course you need to get hang of how Cocoa and Interface Builder works, but once you’ve got that, it’s certainly possible to work with… Even though Mono on Mac isn’t as easy as it is on Windows or Linux.

You can read the discussion between the two different documentation formats in Mono wiki. I’ve chosen a middle path, by exporting my current documentation comments to monodoc. I won’t discuss the process of documenting an application using monodoc, the process is already well documented in the Mono wiki article I’ve linked to a few times. What I will discuss is how to parse you monodoc Xml to WikiMarkup that can be hosted on GoogleCode. Mono already comes with an application to parse monodoc to plain html, called monodocs2html. I’ve made a modification of the application, resulting in monodocs2wiki. If you have your documentation as monodoc Xml you can parse it to WikiMarkup, by doing following:

1. Download: monodocs2wiki
2. Extract the
3. Checkout the /wiki/ directory from your GoogleCode svn repository
4. Run: ./monodocs2wiki -source:./docs/ -dest:./wiki/
   

   Where ./docs/ is the base path of your monodoc xml files (Containing an index.xml file). And ./wiki/ is the /wiki/ directory you checked out of svn.

5. Commit your /wiki/ directory to svn, and view you documentation in you GoogleCode wiki.

The /wiki/ directory of your GoogleCode svn repository, contains all the pages in your GoogleCode wiki. You may wish to change a few things in the template, perhaps using a different label than just Documentation. Take a look in the README file if you what to know more about customization. The current template in the monodocs2wiki application, uses the markup used in the wikies at Google Code. You may modify it, I think it would be easy to port it to another WikiMarkup. Any questions, feel free to leave a comment or mail me…

Well, today we’ve released a Linux version 1.0.2 and a Mac version 0.2.1, those are not very critical. Well the Mac release might be, since I discovered that the Mac version 0.2 didn’t start when the application was launched. It seams there was a typo in the packaging process, I fixed the typo and we’ve released Mac version 0.2.1. Which should be running now, requiring X11 and Mono. The problem with the Linux version was that the menu entry for playlist generation was dead, we’ve fixed, and the Linux version should now be capable of generating playlists. That’s the story behind the latest bugfixes, the Windows version 1.0.1 is still good.