When I first started using Linux way back when, I had only MP3s, and Juk was the perfect simple interface for me. Then I started to acquire a good amount of AACs and seeing that m4a support was a long way from taglib, I was forced to switch to Amarok. For a while I bathed in Amarok’s advanced feature set, but at the end of the day, I always longed for my simple Juk interface. For a while I even used GogglesMM, which is a wonderful project written in FOX. But alas FOX was ugly and didn’t integrate with Qt/KDE, so I’ve stayed with Amarok. But finally in the latest KDE SC beta, Juk supports AAC, corresponding with taglib 1.6′s optional addition! Everyone admire:
It’s pretty and works well. I haven’t tried it out tons yet, but so far as I can tell, Juk does almost exactly what I want a music manager to do for me, or what I wanted it to do for me when I was 14 years old.
The system tray has issues, there’s no support for the disc number, there are some issues with the search filter and multiple fields, I haven’t tested the file renaming capabilities, collection scanning is odd, it still relies on Qt3Support, there is no shortcut handler for scrolling to the current track, and it’s got a lot of unfortunate tiny quirks. But all of this is to be expected of software that’s been basically forgotten about since KDE 3.4.
So after exams are over, I’m going to start investigating Juk’s codebase and seeing if it’s worth it to whip this great player into shape for the prime. It looks promising so far, though I haven’t tested it very completely yet.
Juk’s not completely forgotten, but the two developers who know the codebase have been busy with other things for awhile now. Scott Wheeler is running his own company and I’ve been busy with the Navy and More Important Things(TM).
However I’d love to introduce you to the source code if you want to look into pitching in that way JuK gets more than 1 feature per release cycle.
Awesome to see another dev!
I really love Juk, but it really has quirks (does MusicBrainz support work for anybody, for example?)
I love Juk, too. Musicbrainz worked for me only in KDE 3 times when I compiled from source (it never worked out of the distributions’ box for me). For example, it still does not work in Kubuntu 9.10 – tested that yesterday. For tagging and renaming Juk is an extremely nice tool. However, it took a long time in the past to load a few 1000 mp3c (that might have changed in KDE 4 though).
I always wanted to use Juk, but for my collection it is just too slow. It takes almost 10mins to start and while using it i have >10sec latencies so i use ncurses audio player moc.
Basically the only reason JuK has AAC support is because Amarok devs recently worked on integrating it into Taglib.
Of course the only reason Amarok has Taglib is because of JuK.
Juk would be the perfect testing ground for a massive feature left out from Amarok that would be great.
A Nepomuk media player.
A music player that can retrieve its library from the Nepomuk database, tag music files from there, and feed Nepomuk with reviews, lyrics, and more contextual information. Nepomuk can do it, and Amarok 1.x tried to do it before without Nepomuk. Maybe Juk is up to the task, and the result work may be back into Amarok to have a great ecosystem.
Even better, unify the media expetience and do the same with videos.
Sounds interesting. I don’t see Juk using anymore an outdated and separated sqlite database.
See Bangarang (http://bangarangkde.wordpress.org). It is almost exactly what you describe.
You mean http://bangarangkde.wordpress.com
Long live bangarang! juk is a bit outdated and instead of re-writing things like qt3Support man-power should go to bangarang which is new uses nepomuk has a clean interface just like juk and it’s a very promising project!
in kde4 i cant be comfort with amarok and i searched an alternative application. I ve discovered Juk and i cant do with out its flexibility and simplicity. I like the feature when i type in the search bar it classifies the playlist something that i cant do with amarok
Bangarang has a beautifull window but is not ergonomic as Juk
Just a small tip about disc numbering that I picked up somewhere. Try numbering the tracks 101, 102… for disc 1 and 201, 202, 203 for disc 2. It’s pretty simple, easily identifiable and works in lots of places where disc number support is lacking.
JuK is almost perfect: light, simple, streamlined. But some updates would be nice.
Some issues:
-Slow startup. For some reason, JuK takes longer than other applications to load.
-Keyboard shortcuts don’t stick. I can configure them in the shortcuts dialog, but they disappear after JuK is restarted.
Nice features to have:
-Automatically scroll to the current track.
-Automatically clear the search box upon hitting the ‘enter’ key.