Amarok Blog

So my last blog has been a bit of a teaser. Some of you have guessed it right: 'Fast Forward' is the name of the brand new amaroK 1.4 series. Today we have released the first beta version of Fast Forward. We're excited, because 1.4 has the longest changelog of all amaroK releases to date. You're in for a treat

Let's look at some of the new key features in 1.4:

- Support for Metadata (Tags) in WMA, MP4/AAC and RealMedia (RA,RV,RM) files
- Scriptable lyrics support, amaroK can now get lyrics from ANY lyrics site (if you, or one else, make a simple script-based plugin)
- Switchable Wikipedia locale
- The xine engine now has gapless playback (Needs xine-lib 1.1.1) and audio CD support with CDDB lookups
- Reworked media device system, the Apple® iPod® support has been improved enormously in the 1.4 series iRiver®/ifp and generic media devices
- Moodbar, a visual representation of your music's mood (requires exscalibar)
- And last but not least increased stability by improved under-the-hood code

And to integrate all these new features without making the application too complex, a lot of thought has gone into refining the user interface. I think we have succeeded in making amaroK more powerful, and yet simplified the interface at the same time. 1.4 should actually be easier to use than the 1.3 series!

The first thing that had to go was the fourth tab in the "Context" sidebar. Four is just one too many, this has been obvious to us for quite some time. So we have moved the "Home" tab into a separate Statistics tool with a pleasant interface. Also, we've cut down on useless and confusing options, like the tag recoding features, which had some weird side effects on tagging.

So, ya, it's good stuff. Have at it

This weekend!

I'm a two browser man. Or rather: I used to be. For a long time I have been using Konqueror and Opera 7 more or less concurrently, depending on the task at hand. I've always liked Opera for its polished, intuitive GUI, and the good rendering engine. However, something always made me go back to Konq, it just felt better for some tasks.

So anyway, the other day my fellow developer Illissius suggested I should upgrade to Opera 8.5, the latest stable release. I did so. And boy was that worth it. Opera 8.5 is incredible, it's pretty much the most polished piece of GUI software I've seen in my life.

What's changed from version 7 to 8?

- Incredible, awesome, fuck-me-running rendering performance. The engine is so fast, it isn't funny. Using Opera 8.5 feels like having a new computer. Rendering is instant, memory usage is very low (never any harddisk activity, on a low spec machine), and it's also quite standard conformant.

- Completely overhauled GUI, extremely stripped down. Simple, functional, and a lot like Firefox. Clearly Firefox was a source of inspiration here, it's obvious. There are some issues with the settings dialogs, which are not always completely intuitive. Once it's configured, it's the best GUI you could wish for though. Highly usable.

That's all there is to say, engine and GUI are the two components of a web browser. Opera oozes polish and quality, but the most amazing aspect is truly its performance. I'm guessing that the parallel development of embedded versions of the browser has helped in optimizing the engine.


Renderer: 10/10
GUI: 8/10

One of the features that saw quite a bit of pimping in the 1.4 series is the new Collection Scanner. For the new scanner we had the following goals:

• 
  Support for more media formats. This has been achieved by bundling custom TagLib plugins with amaroK. New supported formats include AAC (MP4) and WMA.
  


• 
  Crash proof. This is a really important aspect, which originally led to the redesign of the scanner code. With the old scanner design, a crash in TagLib would automatically mean that amaroK crashed completely. This could be very frustrating for the user, since effectly amaroK could crash right on first startup, and the user would be unable to ever locate or fix the issue by himself.
  
  TagLib is fairly stable, but with ever growing media collections, the probability of hitting a "bad" file rises proportionally. This is especially true for our new custom TagLib plugins, which are not yet well tested.
  


• 
  No compromises with performance. amaroK's scanner has always been exceptionally fast (a lot of credit has to go to TagLib here, the fastest tagging library available), and this performance should not be hampered.
  

Now, we've reached all of these goals "Everything should be made as simple as possible, but not simpler". Well, this problem required quite a bit of complexity, but I think it was worth it. The new scanner has been implemented in two parts: The core of the scanner, "CollectionScanner", has been splitted off into a separate application. This application takes a list of folders, reads the tags of all files (using TagLib), and sends this information in an XML format to the amaroK process. Part two of the scanner, the "ScanController", is a separate thread in amaroK which receives, parses (SAX2 parser) and stores (in the database) this information from the CollectionScanner. The controller also invokes and monitors the CollectionScanner application.

With this design, we can do some very nice tricks behind the scenes. What happens when the CollectionScanner process crashes? The Controller immediately notices the crash, remembers the "bad" file that caused the crash, and silently restarts the scanner process just where it left off before the crash. Except that this time around we skip the "bad" file. All this is completely transparent to the user - you'll never see that the scanner process has had any problems, amaroK just continues scanning!

When the scan has finished, amaroK shows a "Scan Report" dialog, informing the user which files had to be skipped. And all is well - No crash, no cry.