Tuesday, April 28. 2009From the Post 2.1.0 Git Vaults, Part I: Cd Collection
I think it is safe to say that I don't cope too well with feature freezes. In order to stay motivated I have to have a few forward looking projects. These usually take the form of interesting git branches on my laptop that I hack on while way from civilization (Much of my most interesting code has been written in my parents small cabin in the woods where my wife and I often go to get away from it all a bit. While she reads I hack
In any case, back when we were getting ready to release Amarok 2.0.0, I ran a small series of blogs about some of the stuff I was working on for later releases. I decided that now was the time to continue with this. Quite a few users have expressed that they would like the ability to play audio CD's back in Amarok 2. The reason that it was not initially ported was that none of the core developers use CD's much and also because CD playback in Amarok 1.4.x was sort of a hack, both with regards to the actual code, but also the way it was integrated into the user interface. recently, while discussing a possible Google Summer of Code project, which was unfortunately not accepted, I started thinking about the "right" way to do CD playback. And as I had a little time on my hands, I could not help myself but create a prototype. So here is what is currently possible on my laptop: First off we start off Amarok. Notice the cool new collection headers that Seb have created: Inserting a CD into the drive, Amarok automatically detects it and uses the audiocd:/ KIO slave to get info if possible. These tracks can then be added to the Playlist like any other tracks (as the attentive reader will note there are a few issues with the track information still): It is possible to mix these tracks and tracks from any other collection freely: That is pretty cool I think. But wait, there is more. Since the audiocd:/ KIO slave is all about "ripping" CD's, why not add this feature to Amarok as well. But instead of using the "ripping" metaphor, lets just integrate it with the existing "copy to collection" framework. This not only avoids having a seperate gui and menu entries for this task, but also allows you to "rip" directly to media devices or other writable collections and not just the local collection: After selecting a collection that the track should be copied to, its time to select a format ( advanced options for this can be set in the KIO slaves kcm module which is brought up by clicking on the "advanced" button: And finally we use the target collections organize dialog to figure out where the tracks should actually go: While this is all still at the prototype state ( It will not be in Amarok 2.1.0 ) it already works quite well. There are a few issues left with the implementation itself and some deeper issues with the audiocd:/ slave that affects this, such as audiocd:/ not always detecting when the cd has changed and keeping the CDDB data from the last CD around. Aslo, making this work required some pretty invasive changes to some core parts of Amarok, so its is something that will need a lot of testing as it can potentially break Amarok in interesting ways that are not directly related to CD playback itself. So far it does not seem that I have messed anything up too badly though For anyone really eager to break their Amarok, and not afraid to compile it from source, you can grab a patch that should apply against current trunk here. While feedback is greatly appreciated, I will not offer support for any issues you will have with this patch, so use at your own risk! Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Could this be made such that the CD's are included in the database without copying? That is, could the database be aware that a certain album/music is not available locally and ask you to insert the respective CD if you ask for that music?
While I am sure it would be technically possible, I personally would find it very annoying if selecting a track or album from my collection could potentially mean that I had to run around looking for some random CD. It gets even worse with dynamic playlist where you could end up having to switch CD's between each track. Also, if you know that you want to play something that is on a CD, why not just insert the CD and have the content show up?
In any case, I would like to hear what usecase you had in mind for this!
I think this could only make sense if implemented as a separate collection.
I think the use case is being able to quickly browse/search your CD collection without having to flip through hundreds of disks. It would also allow you to keep track of ratings, play counts and other metadata. It's not something I would ever use, but I see some potential users, especially those lacking the disk space to rip their CD collection to FLAC.
Ok, as a separate collection it might work. It's still, IMO, something of a fringe usecase, perhaps better handled by a dedicated "collection database" app. I am not sure it would be that easy to implement either as you would have to add a system for letting Amarok know that a given collection needed to play a given track is not available ( currently Amarok only understands tracks that are part of a collection that is present ). Of the top if my head I think doing this would prove quite a bit of non trivial work. So its not a feature I see happening anytime soon, if ever. As always though a highly motivated individual stepping up to take on this task can prove me wrong
This is so cool. Please keep hacking on this so we normal users can get it down the line.
Keep on Amarokin'
Would this approach (or at least the interface/configuration) also be used for transcoding from the local collection to portable media devices?
I am not an expert on the media device stuff, but if transcoding gets integrated, it is very likely to have an interface very similar to this as transferring to (and from) a mobile device uses the same "copy to collection" interface as far as I know.
I think transcoding would take too long for many people, but I like the idea of having two sets of files for the same Collection, one in FLAC format the other in MP3, which Amarok 'knows' are the same song and so only shows them once, choosing to use the FLAC files when playing locally, but choosing to use the MP3 files for downloads to portable media devices or over a slow network. The CD ripping would then generate both formats and tag them as the same song. I guess it could be 'faked' with two Local Collections and ripping the CD twice.
Great work - I have seen numerous people grumbling about the lack of CD Playing support in Amarok 2.x, and the Amarok teams "refusal" to implement it (based on a comment from Mark last year which, predictably, these people transformed from "no immediate plans" to "never ever ever - suck it, lusers!!1") is often cited as a reason why the "arrogant" Amarok devs have lost touch with their users/ are doomed, etc.
Of course, once you've implemented this, they'll just forget about it completely and just move on to the next piece of evidence that Amarok devs don't listen to their users etc in a classic case of "What have the Romans ever done for us?!"-ism, but don't let that discourage you; plenty of people will be very grateful for your work on restoring this much-loved feature
I really like the way it's integrated. It's even better than I would have expected, I might have to checkout svn and patch it up for some testing :]
Very nice. I probably will only play from CD once per CD but the ripping feature is very welcome for me. And I really like how it has been integrated. Well done.
I rarely listen to CDs these days, but it is nice to have this feature available for the off chance when I need it. And being able to mix with other collections is a nice feature.
One quick request: could somebody please post here the default file/directory format string being used in this new version for encoding FLAC files?
The reason I ask is that I want to get my dad started on encoding his rather large CD collection to FLAC, but until this feature makes it into a stable release I'll get him going with Audex for the time being. Once I change it over to Amarok I'd like things to remain consistent. Good to see CD playing & ripping support coming back. Will be a lot easier for my dad when he can do everything in one app.
It uses whatever the audiocd:/ KIO slave is setup to use.
There does not seem to be any settings for this in the audiocd kcm module however... In any case, whatever the details of the files Amarok encodes are right now might change any times before final release as this is deep in pre alpha territory.
Despite the fact that it's great to get such an important feature and it's good and all - Brad Sucks, Porcupine Tree, PRR, nice musical taste
Another Idea would be to add the possibility to convert Music already in the Library either directly in the Library itself or when moving it to an audio player. That would enable me to not have to move my flac-files (which do use up wuite a lot of space) and just use vorbis, which will use about a third in good quality.
While this sort of toes the line of what is "Unixy" (in a sense), it's a cool idea and I like it. But just to make sure, could you please ensure a tab is put in the Amarok settings for (that loads the kcm for) encoder options? That was always really confusing for me with KDE3 and how you had to go to kcontrol (Or know which kcm module to invoke).
Other than that, neat stuff is happening, and I'm glad my patience is going to return in spades! Cheers, Wyatt |
Amarok LinksCalendarQuicksearchCategoriesSyndicate This BlogBlog Administration |

