Fresh from the amaroK development squad, comes the first beta release of amaroK 1.4, the 'Fast Forward' series. This generation has a lot of shiny new features and eye-candy. amaroK development has literally been in fast forward mode since November, the changelog is actually one of the longest in project's history. Read on for the new features.

Hot New Features

Since work started on amaroK 1.4, several features have been repeatedly requested, via the amaroK forum, IRC and mailing lists, as being essential to amaroK users.

That said, amaroK now includes the ability to tag (and add to the collection) WMA, MP4/AAC and RealMedia (RA,RV,RM) files.

Another long-standing item from the wishlist is gapless playback, and this has finally been implemented, along with audio CD support (and CDDB lookups) for the popular xine engine.

By far the biggest change in amaroK 1.4 is the reworked media device system. Apple iPod support has been greatly improved (thanks to libgpod), and iRiver/ifp and generic media devices are now supported, although the latter is still a little unstable.

Along with these major changes, amaroK's user interface has been cleaned up and simplified, and much work has been done under the hood to improve performance and stability.

The team now asks everybody to hunt and squash bugs, for your own enjoyment as well as to make 1.4 even more stable than 1.3 already was. A list of known issues is available.

i just discovered that klik works very well for the 1.4 beta! w00000t!! ;-)

just try

klik://amarok-svn-nightly

(first i was scared because it downloaded a shitload of .deb packages onto my suse-10.0 system. but then i was re-assured in the #klik channel that this is ok, and klik would convert the .debs into its own format [i.e. one single .cmg file that is easy to get rid of if the app doesnt work well]. but it __does__ work well, extremely well even! :)

this is truly amazing. just went to the klik site, and had amarok 1.4 beta running within seconds, while still keeping suse's original stable amarok version as well. wish all betas were offered this way.

Definitely amarok is the more featurefull player out there, and impressive how quick it became so. The only issue for me right now is that it takes lot's of ram and cpu. And being on a laptop isn't much convenient ... Let's hope with this relese things are going better performance/resource utilization wise.

You may find that having a large playlist will cause this, using the Random Mix dynamic mode gives you more power and (i find) a more pleasant listening experience than simply loading the entire collection and listening to that. Also, if you have a large collection (currently i believe this means anything above around a couple thousand tracks) using MySQL is the faster option :)

Of course it's approaching insanity to suggest that a lib shouldn't be used just because it happens to be created by gnome developers, but if you really have a problem with it, just think like this: We're using their man-hours! They are programming a library, just to have it snatched up by us for our benefit - and the keep on developing it, the fools, not realizing that our apps benefit from it! Mohahaha...!!

Sort of the same way that TagLib is a KDE library, sure! That was developed for use with the KDE app JuK, but... that doesn't make it an actual KDE library - like for example libkio is :) Don't feed the troll, i know, but there you have it :)

No.
Amarok will have a dependancy on libgpod only if you want the IPod management features. Because gtkpod is a GTK program does not mean libgpod is. But yes, it was created by Gnome devs.
As is glib, which is used by lots of framework libraries used by KDE.

Ever since AmaroK ex-histed, I have always considered alternatives related to the fact that it was unstable. It can simply hang, crash or lose your playlist like a snap. Now allot of releases later, these are still major issues. How is this possible on multiple distributions and over such a long time, such trivial and obvious problems? That and how God aw-full slow changing simply tracks is.

Sorry to sound so critical, but I think features are nice, but a solid foundation would not hurt either. Reporting bugs is nice and all, but I have begun to seriously question the skills behind the project after this long a time. If I was part of the AmaroK team I would feel shame for the stability and speed part. Frankly I consider a book example of how unstable software is excusing itself. At the same time I detect that anyone who would dare criticize speed or stability is likely to be considered a traitor or something. Well, suck it. It's a great app, but what the hell are you guys doing on the stability and speed department?

"Killer app" really refers to a different kind of application that no other system has, I think.

However, in the sense you mean it, KDE is full of "killer apps". Akregator is the best RSS aggregator on any platform; KMail is the best email client; KOrganizer is more usable than iCal but with more features than Outlook's calendar, and combined with KArm, really makes light work of projects; Amarok is probably the best audio player on any platform; Konqueror has some issues and it probably isn't the most compatible, but in terms of speed and usability and increasing my productivity, it's easily the best browser; KPDF is fully featured and faster than Adobe's own PDF viewer; K3b is the best burning software on free desktops, competing with Nero on Windows, and easily crushing Nero for Linux; Adept (in its ubuntu incarnation) is easily the most powerful installation and software management system on any platform... I could go on. Suffice to say, when the day comes that I give up Debian-based distros and KDE-based desktops, we'll be in a totally new generation of software.

Despite the obvious bias of the author, there are 1.4 beta packages at least available for Mandriva 2006 and there is an e-build for Gentoo also. Arch will have a PKGBUILD soon and I'm sure the SUSE aftermarket packagers are working on something.

Could be worth to get rid off the lyrics tab and move it to a more appropriate position. Esp. in some non-english languages and on small screens the upper tab looks bad at first sight and "lyrics" is always bound to a song and hardly in use.

It can be implemented with a "<- Back" link, in the same way that AmaroK already does that with the Artist Related section if you have activated in the last.fm preferences.
See the screenshot below to see what I refer.

The dependency on libgpod is optional, if you want ipod support, you install libgpod.

IT would be a lot harder to make a dependancy optional in order to send a file to the trash, although, I wonder how challenging it would be to do in a script, does kde have a dcop call for movetotrash? anyone know?