Version: (using KDE Devel) Installed from: Compiled sources Allow to rate music files. Keep track of play count and last played information. Add list columns allowing to sort after these.
*** Bug 66304 has been marked as a duplicate of this bug. ***
Also, adding covers to music, like iTunes!
*** Bug 68534 has been marked as a duplicate of this bug. ***
*** Bug 68536 has been marked as a duplicate of this bug. ***
i think much of this stuff is already availbale in by INDUDER's Madman(.sf.net) .. it written in QT and has an outstanding search engine built-in .. also the xml-database ( with backup function!) is rather well thought-throug ... ... also the tree-like playlist manager is way more useable that JUK's .. most positiv is the tasktray integration of juk ..
[cough] The KDE bugs database isn't really the appropriate place for such advertisements...
i feel guilty .. will be hush now
also mp3 encoder information would be nice (i mean version of lame, jointstereo) all coding is already done (its one .c file!) in mp3guessenc - shibatch.sf.net
*** Bug 76461 has been marked as a duplicate of this bug. ***
I think this should wait until JuK will get a plugin system as this isn't necessary for basic use. Cool idea anyway, I'd really love this and I hope this will get implemented later..
oh, btw, not sure how useful this suggestion will be. But it occurs to me that using 2 levels of file identity info would help a lot here to be resilient from filename changes, renames, etc. 1. use the filename/path 2. use a hash of the non-id3 parts of the file, or possibly a known subset of the file (e.g. "from byte 16384 to byte (end-16384)") to avoid id3 areas. (by avoiding the id3 parts of the file, it'd be insulated from metadata changes.) by using both, it would be possible to uniquely identify a file even if it's renamed; when scanning at startup, if one mp3 file no longer exists by the path in the db, keep that db entry aside; store it in a "known but probably moved" list. if a file is later found that has a path that does not have a corresponding db entry, take the hash as per (2) above and see if it matches an entry in the "known but probably moved" list. sorry if it seems a bit obvious, but thought I should pass it on just in case it proves useful.
*** Bug 82792 has been marked as a duplicate of this bug. ***
I think the rating feature would be great for playing music at random. Typically albums have 2-4 songs that are good, and the rest aren't as good. When you play the album (or all albums) randomly, you will get a song that you don't like about 80% of the time. It would be nice to be able to reverse this.
I just want to point out that in mp3's id3 tag there is a value for rating and # of times played. From the comment above will juk be getting a plugin sytems?
Some other meta information I would like to know is: Track year (think best of collections), Album comment, Album Artist (Think compilations). Although it would be re-working the gui can we have them via dcop at least? :D
*** Bug 101328 has been marked as a duplicate of this bug. ***
maybe we should keep juk easy and clean, and let amarok handle people that want an more advanced interface... unless these features can be integrated so good they don't clutter the interface or make the app harder to use.
In fact I prefers JuK even if amarok seems more attractive because amarok playlists handling is a real pain. In JuK we can create smart playlists on the left panel that contains result of searchs, for example. In amarok playlists are not so dynamic and they are very very long to switch from one to another (when we have a big library). And I also want meta-informations... in JuK. I think I'm not alone in this case.
yeah, amarok's interface just isn't as well-designed as JuK's; JuK does an excellent job of dealing with large playlists, in every respect. I switched for a while, then switched back (once I figured out how to get JuK to deal with software mixing ;)
> unless these features can be integrated so good they don't clutter the > interface or make the app harder to use That's in a sense the "acid test" for adding features to JuK. The interface is the first priority. There are a few things that have been added that weren't as clean as I'd like them, but I plan on doing a bit more polish for 3.5 (JuK 2.3) and adding a few things as well. Ratings specifically I played with at one point, but I'm not so excited about the "normal" way of doing ratings, and rather than just adding it without thinking about it, I really would rather come up with a creative way of using them or making it possible to do them automatically, etc. (i.e. analyzing playing patters to try to discover implicit ratings and whatnot)
as a quick point on the automatic-ratings idea -- amarok does have this, as do some other players. I've played around with them, and to be honest I find them a little frustrating; it may seem logical and intuitive, but in practice I'd prefer to be able to select a bunch of songs and say "I think these are 5-star tracks", manually. The automated form is a little annoying as you see your favourite track changing its rating, for no apparent reason, or you see a track you're not too hot about, get a high score just because you accidentally left a playlist playing with the speakers off overnight ;)
Right. And I'm not really happy with the way that amaroK does this or any other players that I've seen. ;-) That said, I don't really like the completely manual ratings that I've seen around either. It really just doesn't scale. Just kind of a little insight on how I personally do development -- there are always a lot of things that I'd like to work on, so things kind of stay in the back of my head until I know how I'd like to do them and then they work their way further towards the top of the queue. Since there are still almost always more things that I know how I want to implement than I have time to actually implement this keeps things going semi-smoothly. ;-)
I would have to disagree with Jos, you can add quite a bit of meta information without cluttering the interface. Such as the number of times a song has been played and the last time a song has been played. Both of these just become another field to be shown (not by default) in the list and can be access in the drop down box of the dynamic/smart playlists.
Does taglib currently support the song play count and song rating id3v2 tag?
I second this wishlist item. IMHO, "compilation artist" ("TPE4" in ID3v2, not in ID3v1) is very important. I use JuK to preview, sort and tag all CDs that I digitize, while the oggs are ultimately used on a mythtv box. mythtv supports compilation artist now, making the artist list a lot less messier - if only juk supported that tag. And another remark, regarding ratings, this is how mythtv does it (I like that): It stores manual rating (1-10, initially 5 for all files, can be modified with a single (increase/decease) keypress while a song is playing), number of times played, and last played time separately. Upon playback usig the "smart random" mode, it then builds a score for each track, consisting of 35% manual rating, 25% each number-of-times and last-played, and finally 15% random. It works quite well, and the actual weightings are configurable. The result is that people who don't know about manual ratings still get their favourite tracks more often, while no amount of repeating can completely ruin your manual ratings. Including last-played-time is cool for integrating newly added tracks.
Personally I ignore track rating. I just use play count, and my biggest problem with JuK is that it doesn't have track rating. For the ratings, though, perhaps you could an option to rate songs as you listen to them. Two buttons, thumbs up and thumbs down. If you click thumbs down it decreases the rating and goes to the next track. Maybe this would add too much junk to the interface, but it's an idea.
How about using something that already works pretty good [ http://www.luminal.org/wiki/index.php/IMMS/IMMS ]? I have used it for some time, and, to be honest, if XMMS wasn't so hideously ugly, unstable and unusable, I would still be using it. The current version claims to have engine decoupled from the XMMS interface, so maybe it's worth a look. The only thing it needs adding (although it's not that vital IMHO) is an ability to override ratings; the ratings are done as an abstract score that only makes sense in relation to other scores, so maybe one could manually throw a forced delta on the rating or sth. Of course one can edit the ratings directly in the db (it's sqlite), but that somehow defeats the whole purpose.
Here is an idea for automative track rating, if a user manually sets the rating, disable auto-rating for that track if the user clicks to play that track add a good value to it. if that track finishes, add another value. (this is for those accidentally clicked files :) If the track just plays because it was in the play list. add a small value to it's rating. Auto ratings should be on a scale out of all auto-rated tracks. (rating / max auto-rated) * 5 manually rated files should be on an absolute scale (1-5) I understand this isn't exactly standard tag friendly. so the displayed rating should be stored in the tag and the auto-rating/manual rated flag in juk's DB.
Right now I would like an kevent to occur when a file starts playing, then one could configure it run run a script. The simplest one would be to either just log the file currently playing or increment the playcount in the id3tag or whatever else the user wants.
being able to run a script on song change, btw, would be key for the AudioScrobbler support idea mentioned at http://bugs.kde.org/show_bug.cgi?id=80849 too.
I perhaps forgot to mention it, but JuK will emit a DCOP signal in KDE 3.5 whenever the track changes. The signal is Player::trackChanged(), which you can listen for in scripts or programs that support catching DCOP signals, including QtRuby/Korundum, PyQt, etc.
I'm trying to think of a "keep it simple" solution that won't clutter things up too much, and here's what I came up with: Keep track of the variables "play count" and "skip count", and "last played" and "last skipped" in the format YYYY-MM-dd HH:mm Let users make their own search playlists based on these values. (Note that this makes the interface simpler and more consistent, as it removes the need for a "History" playlist.) Possible extentions (simplest at the top): Dynamically generate "More recently played", "More recently skipped", "More often played" and/or "More often skipped" rank numbers, for creating search playlists to solve Bug 94866, among other things. Let users insert the placeholders \0 through \9 from the box above, as in konq's find and replace dialogue. Add the track-independent variables "Today's date", "Average play count", and "Average skip count" to the variables in search playlists. These can be matched with trivial regexps like .* to create placeholders for the box below. With that framework, our users can create all the auto-ratings they want. Get them to send in their lists of auto-rating playlists, and maybe by KDE 5 we'll have a rating system we like :P
FYI David Laban all of information is already in the id3v2 spec and has been for along time, so really it is just getting juk around to supporting these extra tags. (right?)
No, it's not, since JuK supports a lot more formats than MP3.
The rating should not be kept in the id3 tag because the song could be shared by many users or the file could be on a read only filesystem. The rating could be kept in an sqlite database. The user should be able to rate a song by simply pressing a key combination like CTRL/0,1,2,3,4,5. Juk should be able to sort songs by rating.
<i>The rating should not be kept in the id3 tag because the song could be shared by many users or the file could be on a read only filesystem.</i> Neither one of these are the common sinerio and currently if you modify a tag it is written back to the id3 tag. It is kind of silly to only write some tags back to the file, but not others. There could be of course a fallback, but it makes sense to write to the file by default.
Just pushing it up again, With kde4's akonadi/nepomuk/whatever, rating could be handled by those service. Not that easy?
I disagree with this bug. This would require Juk to have a database, yet one of the best things about juk is that it's quick, and lightweight. Adding a database layer would significantly increase overheads. If you want something more, use amarok, and help improve it.
That's not the only option, it could be implemented with tags or metadata files.
I feel like it wouldn't make sense to use tags for most of these requests, since they are per-user statistics, so if you have two users with access to the same tracks, they will get screwed up. Also, I don't think it would even be possible to store "last played" info in tags. If you're going to store this data in individual files per track, then you have the same problem as above, AND you have massive filesystem clutter. If you use a single meta data file, then you may as well use a database, since it's cleaner, and easier to maintain. Regardless of how you do it though, you're still going to have big overheads, either in disk IO, or RAM.
What about a custom tag? A tag meant for juk use only with a field name like "juk <user id>" and containing binary data with the user information associated to the file, like play count and last played information. This way there would be two tags for two users, and the data wouldn't be lost moving the file across computers.
Including support for .mp3, .wav(?!), .wma, .ogg, .aac, .mpc, etc? How could you include last played info in tags? If you write in one tag "this was the last played", then you play another song, then you have to change the previous file too. If you want a history of any length, say length n, then you have to change n files every time you play another song. Anyway, Juk already has a perfectly functional history feature. Per user tags: And then what about when you have lots of users, or if you re-install and change your username? Or if you pass the files on to someone else? Eventually the file will just fill up with useless data that can't be removed safely, because you might accidentally remove useful data (ie. another user that still exists). Same problem for per-track metadata files too.
Last played tag, in my mind, meant to store when that track has been played last time, not to store which track has been played for last. The latter wouldn't make any sense to be stored as a tag. Anyway, if the per-user tag has so little pros and so many cons, I'd suggest to enable an optional database. So, if you want juk to stay light, you just won't turn database store on. Don't tell me that juk + database = amarok because I think that equation can be easily proven wrong. To respond to your critics, anyway, afaik, the are libraries to read and write tags for many formats (if you can edit artist field for wma, ogg, mp3 etc, you can also edit any other field). And I think that, after implementing per-user tags, a feature to clean files from tags of different users wouldn't be difficult to implement.
Fair call. I wouldn't have a problem with an optional feature..
I would like to add my vote for this feature. Especially ratings.
I would also really like ratings.
This bug had no activity in 4 years. I still have JuK installed on Kubuntu 22.10 So it should still be maintained, but is this still relevant, is unclear. Can someone post if this is still needed?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!