State of Audio CD support in KDE

[Albert Astals Cid]

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 <aacid at 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