Boudhayan, I think your plan looks good to me. Let me know if I can help in any way.
thanks, Jeremy On Tue, Sep 29, 2015 at 6:03 PM, Boudhayan Gupta <bgu...@kde.org> wrote: > Hi Albert (and others), > > On 30 September 2015 at 04:09, Albert Astals Cid <aa...@kde.org> wrote: >>> In terms of support for Audio CDs in KDE, >>> >>> * K3B can write them. >>> * Phonon the API can play them, with some minor but weird bugs. >>> >>> And that's it. >> >> Does solid offer some support? >> I guess at least it can say how many drives are there >> but maybe nothing related to Audio-CD itself? > > Solid is interesting. It can detect the number of drives in the > system, and it can tell us if the CD inside is an Audio CD. > > We can also subscribe to signals from Solid that notify is the disc is > ejected, but there's no signal in Solid::OpticalDrive to notify if a > new disc was inserted. Maybe it's a small patch that can be worked on? > >>> I think we need to take a long hard look at the state of support for >>> Red Book CDs in KDE and decide: >>> >>> a) Do we still want to support them, and >>> b) If yes, to what degree do we support them? >> >> I'd say we totally want to support them. The question is if there's >> something that can be shared in an library or should it be app specific. >> >> The things i can think of doing with an Audio-CD are: >> >> * ripping it >> * playing it >> * copying it to another Audio-CD >> >> Ripping and playing have some "common" stuff that is: >> * Finding the CD drive that actually has a Audio-CD inside (if you have >> muliple drivers and others >> are either empty or have data CDs) >> * Listing the number of tracks and their info (cddb, or whatever) >> * Extracting data to either feed it to the player or ripper >> >> So I think that having a library that those these 3 basic things is a good >> thing, once we have it we >> can see how to make it used in kio-audiocd, kaudiocreator, kscd or whatever >> cd apps we decide to have. >> >> I can't think of a "common" stuff between copying and and ripping/playing. > > So here's the situation: > > Ripping and playing have some commonality in them, in that they both > need access to raw PCM data from the disc. Phonon seems to have pretty > good playback support (I'll file bug reports for the bugs I've been > mentioning) - so if you have an app that uses Phonon you've got > support for playing back CDs. Let's not reinvent that wheel, but round > it out if there are flat spots. > > Now information and ripping. KCDDB seems to be in pretty good shape > (kdelibs4 though) - for getting data about the CD from CDDB servers. > Whatever work I've done for the libKCompactDisc nextgen branch, I can > extract raw PCM data from the disc and also read CD-TEXT information > to find whatever data is embedded in the disc. > > kaudiocreator seems to be using CDParanoia directly, as is > audiocd-kio. I tried to start a basic port of audiocd-kio to kf5 > today, but audiocd-kio is also trying to do too much, because I've > been looking through the code and it has converters for MP3, FLAC and > OGG in it. > > What I would suggest is: > > 1: Let Phonon do the playing > 2: Let k3b do the copying > 3: Let Solid do all the disc detection > 4: Consolidate libKCDDB and libKCompactDisc into an all-in-one > disc-info and raw-data-from-CD library > 5: Write a new, very small cdda kioslave that just exposes the audio > files on the CD as a set of wav files. We can re-use code from the > current audiocd-kio. > 6: Once the new lib is up, port KAudioCreator to kf5. > > This plan of action will eventually end up removing a lot of lines of > code and reducing our maintenance burden. Right now: > > * kaudiocreator and audiocd-kio both duplicate media conversion code. > * both use cdparanoia, and do the same thing differently > * all of them have their own disc detection code > > Inputs? > > Cheers, > Boudhayan Gupta
