amaroK 1.4 Beta 1 Released

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.

Packages are available for Kubuntu or grab the source to compile it yourself. For more information how to help and where to get amaroK 1.4 beta 1 see the amaroK website.

Dot Categories: 

Comments

by max (not verified)

...or just use the svn-version and enjoy even more bugfixes :-)

http://amarok.kde.org/amarokwiki/index.php/AmaroK-svn

Don't forget to install some *-devel RPMs (or debs) if the compilation fails.

by anonymous coward (not verified)

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! :)

See also http://amarok-svn-nightly.klik.atekon.de/ for more details.

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.

"this is truly amazing [...] had amarok 1.4 beta running within seconds [...] wish all betas were offered this way."
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yesssssssssss!

by doom (not verified)

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.

by Dan Leinir Turt... (not verified)

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 :)

by max (not verified)

On my laptop amarok needs 0% - 1% of CPU.
That's very good!

HowTo:

* Select Xine as output plugin
* Don't use any visualization plugin
* Set the internal spectrum visualisation to 30 or 20 fps (or completely deactivate it)

by mikeyd (not verified)

That doesn't work for me, however, I find switching to arts engine will about quarter the CPU usage.

by libgnazi (not verified)

"featureful"

by JoeSixPack (not verified)

That now amaroK will have a dependency on libgpot? a gnome librarie?

by markey (not verified)

libgpot, yes. The gnome stoner's library. Share and enjoy!

by Ian Monroe (not verified)

Don't spread FUD markey! Its not gnome, its glib. A glib abstraction layer for my pots and pans is just what I needed.

:P

by JoeSixPack (not verified)

I means it was created by gnome developers for the use of GTK

right?

So it is technicly a gnome library

by Anonymous (not verified)

And you are a troll.

by Apollo Creed (not verified)

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...!!

by MM (not verified)

I'm a KDE fan, but Gnome devs are not fools, Sir :-)

by Dan Leinir Turt... (not verified)

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 :)

by ac (not verified)

I means it was created by gnome developers for the use of GTK

k-people being allergic to g-libraries is plain stupid.

How old are we?

If there is a good library around, you are stupid if you're not using it in case it makes sense!!!!!

by JoeSixPack (not verified)

I never said I was against it, read again.

It is naturall for you to atack people w/o understanding it first?

by Matej Cepl (not verified)

Well, I am afraid, that answer to your question is just in Joe SixPack's statement :-)

by Ian Monroe (not verified)

glib as I understand it is just a library adding some OOP-like features to C. Its used by GTK and Gnome but otherwise isn't related.

by mikeyd (not verified)

Erm, it already more-or-less depends on gstreamer.

by Ookaze (not verified)

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.

by mikeyd (not verified)

What's this thing on the playlist tab supposed to be? It's always blank for me. (I'd bugreport but I don't know what it's actually meant to be doing).

by markey (not verified)

It's not yet working for normal playlists, but try it with Podcasts.

by VisezTrance (not verified)

Amarok .. KDE's.. killer app. Looking forward to the stable release.

by ac (not verified)

While I'm sure the parent is considered a troll, boy do I agree.

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?

by SR (not verified)

You were obviously not using the Xine backend. Any other backend turns amaroK into a bloody mess. Especially GStreamer.

by Lee (not verified)

"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.

by ch (not verified)

nice work - most under the hood

thx for the greatest player on all Osses

ch

Both /usr/lib/tunepimp and /usr/local/lib/tunepimp are .4.x. One is .4.0 and the /usr/local/lib copy is .4.02

Debian testing/sid

/usr/local/include/tunepimp/tp_c.h: In member function `int
KTRMRequestHandler::startLookup(KTRMLookup*)':
/usr/local/include/tunepimp/tp_c.h:645: error: too few arguments to function `
int tp_AddFile(void*, const char*, int)'
/home/coolian/tmp/amarok-svn/amarok/src/ktrm.cpp:77: error: at this point in
file
/home/coolian/tmp/amarok-svn/amarok/src/ktrm.cpp: In constructor `
KTRMRequestHandler::KTRMRequestHandler()':
/home/coolian/tmp/amarok-svn/amarok/src/ktrm.cpp:137: error: `tp_SetUseUTF8'
undeclared (first use this function)
/home/coolian/tmp/amarok-svn/amarok/src/ktrm.cpp:137: error: (Each undeclared
identifier is reported only once for each function it appears in.)
/home/coolian/tmp/amarok-svn/amarok/src/ktrm.cpp:139: error: invalid conversion
from `void (*)(void*, void*, TPCallbackEnum, int)' to `void (*)(void*,
void*, TPCallbackEnum, int, TPFileStatus)'
/home/coolian/tmp/amarok-svn/amarok/src/ktrm.cpp: In member function `virtual
void KTRMLookup::collision()':
/home/coolian/tmp/amarok-svn/amarok/src/ktrm.cpp:612: error: base operand of
`->' has non-pointer type `artistresult_t'
/home/coolian/tmp/amarok-svn/amarok/src/ktrm.cpp:613: error: base operand of
`->' has non-pointer type `albumresult_t'
/home/coolian/tmp/amarok-svn/amarok/src/ktrm.cpp:614: error: base operand of
`->' has non-pointer type `albumresult_t'
Error creating ./amarok/src/ktrm.lo. Exit status 1.

ERROR: Compilation wasn't successful. amaroK was NOT installed/upgraded.

Use 0.3.x

by oggb4mp3 (not verified)

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.

by gerd (not verified)

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.

by Ian Monroe (not verified)

You have any ideas of where it should go?

3 tabs doesn't seem too onerous.

by gerd (not verified)

See mockup

Lyrics and the name of the songwriter as simple contextual links

by Janne (not verified)

This proposal gets my official backing :). I would like to see tab-free Amarok. It would make the UI a lot less cluttered. And like the mockup showed, it could be done.

Running 1.4-SVN as we speak, and it works beautifully BTW :).

by Josep (not verified)

I also support this suggestion.
It looks much better than now.
I think that the two tabs: Lyrics and Artist can be integrated in a single one, like this mockup shows.

by Dan (not verified)

This in an interesting concept.

My only question/concern would be navigating after clicking on one of these URL's.

by Josep (not verified)

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.

by Danni Coy (not verified)

That does look good

by Mario (not verified)

Boa is the artist, Duvet is the song!

by Corbin (not verified)

but a KDE dependency so that 'delete' will send the files to the trash instead of it being gone forever is a bad thing?

Yeah that makes loads of sense...

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?

by birdy (not verified)

Why should a dependency on libgpod be a bad thing?
It's a good library with only a few (normal) dependecies. What would be the benefit of reinventing the wheel?

by DanaKil (not verified)

imho the old look for the current track marker was better (more integrated in the UI...)

if you think so... http://bugs.kde.org/show_bug.cgi?id=122065 :-)

by Ian Monroe (not verified)

"old look" doesn't have any meaning. Its gone through a few iterations.