State of Audio CD support in KDE

[Jeremy Whiting]

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 <bgupta at kde.org> wrote:
> 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.
> 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