The audiocd:/ kioslave was never meant to play CDs. KDE implemented it solely for CD ripping. To prove it go here: http://people.fruitsalad.org/phil/kde/userguide-tng/audio-cd.html#audio-cd-ingredients
In order to play CDs in amarok we have to use this slave and what ends up happening is KDE is encoding the files then passing them amarok. This happens even if you choose the .wav format. Amarok must implement a system like KsCD to play CDs. I recommend this also because it is engine independent. It will work with whatever engine is being used. Hope to see it in 1.3. Also, an integrated CD ripper would be nice. The ripper should be able to be configured to organize the music files for you in format /path-to-music-collection/Artist/Album/File .

Post edited by: sleepkreep, at: 2005/04/07 04:17

sleepkreep wrote:

The audiocd:/ kioslave was never meant to play CDs. KDE implemented it solely for CD ripping. To prove it go here: http://people.fruitsalad.org/phil/kde/userguide-tng/audio-cd.html#audio-cd-ingredients
In order to play CDs in amarok we have to use this slave and what ends up happening is KDE is encoding the files then passing them amarok.

Well yeah, that\'s no news. It would be fine if KIO supported seeking. Which it doesn\'t. Else there\'s no problem with the slave.

Amarok must implement a system like KsCD to play CDs. I recommend this also because it is engine independent. It will work with whatever engine is being used.

There\'s two methods of CD playing: Analog (with cable to the soundcard) and digitial extraction. As for analog, that\'s outdated anyway, we won\'t likely ever support it. Digital extraction is what we do via audiocdslave. As I said, the only serious problem with the whole KIO subsystem is that you can\'t support seeks. I find this situation frustrating too, but can\'t see what to use instead.

We will not implement any sort of special CD handling code. I want a unified IO subsystem that works for all sorts of protocols, like KIO.

I understand where you\'re coming from. Amarok does need to stay versital to adapt to the ever changing KDE. But we are talking about an audio cd, one specific format that will never change and never need adapting. This is one of the few things that once implemented will never need changing or features added. Besides, the audiocd:/ slave doesn\'t work for me. I use the xine engine and arts never really works well for me (crashes constantly). Not to mention it\'s annoying as hell to change engines just to listen to a CD. Now I know I can just use KsCD but I don\'t the cool amarok features

Yes, your probably right. But who listens to CDs anyways? Might as well just wait for KIO to improve then for amaroK to implement something special for CDs.

sleepkreep wrote:

I understand where you\'re coming from. Amarok does need to stay versital to adapt to the ever changing KDE.

Uhm, no, I guess you don\'t understand where I\'m coming from. What does it have to do with "the ever changing KDE"?

Besides, the audiocd:/ slave doesn\'t work for me. I use the xine engine and arts never really works well for me (crashes constantly).

Of course it doesn\'t work with xine-engine. It does not yet offer KIO access. At this point aRts-engine and GStreamer-engine engine have support for it.

Uhm, no, I guess you don\'t understand where I\'m coming from. What does it have to do with \\"the ever
changing KDE\\"?

I simply meant that amarok does need to keep up with KDE and that ioslaves are the best way to do it. If this is not why you use audiocd:/ to play CDs than I apologize, I was mistaken.

But who listens to CDs anyways?

I on occasion listen to CDs. Usually it\'s when I borrow a friends to see if I like the artist or not. But I think I\'m not the only one to ask for this, so I can\'t be the only one that listens to CDs right?

I simply meant that amarok does need to keep up with KDE and that ioslaves are the best way to do
it. If this is not why you use audiocd:/ to play CDs than I apologize, I was mistaken.

I don\'t understand. amaroK does use ioslaves to listen to CDs, that is why we have problems.

Yes, he is explaining that he understands why you use the ioslaves. He understand that a unified IO system is useful, but nevertheless he wishes you would implement something better for CDs.

Thanks kundor, that\'s exactly what I was saying. I believe that KDE apps need to have more of a one-app-for-all mindset. And by that I mean that an audio app (amarok) should handle all audio (well) and a video app should handle all video. I don\'t like having to use KsCD to listen to CDs and the audiocd:/ ioslave in konqueror to rip my CDs. And don\'t even get me started on video appps! I love kaffeine, but man does it have a lot to be desired. Not to get off topic. What makes iTunes great is that it handles everything and does it very well. I like amarok\'s features a lot more (visualization choices, audioscrobbler, etc) and I love the collection manager in amarok, but as far as what it can do with all my audio media, it still has a little ( not a lot) to be desired, CDs being the main one.

I mean, sure amaroK should be able to play CDs. The fact that it currently sucks at doing so isn\'t by choice. But I never understood the purpose of integrating cd ripping. We could just add a menu option to open kaudiocreator.

I was really just saying that integrating cd ripping and burning would be nice, not necessary. It would however give amarok more control over the files. Organization and integration is very important to me and integrated ripping would allow amarok to keep the default music folder organized for the user. I like for my software to be able to do a lot for me. This is isn\'t really for me more than for my wife. My wife uses mac (now broken) and therefor uses iTunes and is used to the functionality of it. A lot more non-technical users are coming to linux and I just think that the software available for it should be ready for them.
I think that the current way that K3b is integrated is fine for me really. That\'s mainly because you do it so well. K3b is called perfectly, everything already setup. I suppose it would fine if you added a way to call kaudiocreator. But why not just use the ripper that\'s already integrated into KDE. Currently when you open audiocd:/ you can select the format you want KDE to encode to. Why not just setup an integrated ripper that just copies the files from say audiocd:/MP3 to a default collection folder with the subfolders organized by the tag info returned from cddb: $default_folder/$artist/$album . This way KDE does all the encoding work for you. To be honest I don\'t even know why kaudiocreator exists. KDE has it all built in.
One last thing. If amarok listens to hal for inserted audiodisks and other media, with an integrated ripper users could configure amarok to automatically start to rip it if the artist isn\'t already in the collection db. Just more convenience.
Sorry for the long post.

Well, kaudiocreator exists because the cd ripping in audiocd:/ is non-automatic (as you noted) and not easy enough to fiddle with tags and such. And really they\'re both part of kdemultimedia so equally \'built-in\' to KDE.

The only things that a CD ripper and a music player have in common is the root collection directory. And given that amaroK can have multiple root directories... so they don\'t even have that.

True, but if you built in a cd ripper that had the option to be automatic, the user could select a default directory to rip to. I like that amarok can search multiple directories. I have my limewire folder that amarok searches and I have my folder that I rip to. I don\'t see the problem with selecting a default folder to rip to. Amarok would view it the same as does now.

...or you could use kaudiocreator which has a directory that it rips to as well. You\'re not providing a reason why integration has any advantage.

Yes, I did. Add listening to HAL and automation can be an option, which is always good. And just for the sake of having integration. Integration is always good. Amarok should be a one-app-for-all when it comes to music. Why have one app for ripping and one app for listening? It\'s pointless and annoying. Like I said, integrating a CD ripper isn\'t THAT important to me, I just think it would extremely convenient. If you want to go through the trouble of teaching how to rip CDs with this app and then listen to them with that app to your wife or teenage son, be my guest. But that\'s one battle I would prefer not to fight. Back to the audiocd:/ slave though. Here\'s the facts:

1) The audiocd:/ slave will never change because it does everything it was meant to do. It was never and never will be for listening to CDs.

2) Since the audiocd:/ slave will never (and has no reason to) change, we need to work around it ourselves.

3) It\'s just proper that a music player play CDs properly. The current way means that it will never change. So lets change it.

4) The audiocd:/ slave is confusing to non-technical users that just want it to work.