El Wednesday 30 September 2015, a les 05:33:20, Boudhayan Gupta va escriure: > 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.
I'd miss the ripping habilities of kio-audiocd personally, maybe we can merge it with kaudiocreator and make them share code? Cheers, Albert > 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
