Jerry Tan wrote: > Joerg Schilling wrote: >> Dale Ghent <daleg at elemental.org> wrote: >> >> >>> I don't know what all the rancor is about here... >>> >>> Regardless of the feature facts, it does look like cdrecord already >>> does what cdrdao does, and the differing features could be added to >>> cdrecord. >>> >>> So perhaps cdrecord should be extended instead of adding yet another >>> tool? >>> >>> >> >> Heiko Ei?feldt and I have been talking about the preap of track 0 >> enhancement since some years already. So far no user asked us for this >> enhancement ;-) >> >> >> J?rg >> >> > Hi, Joerg, > Please correct me if I am wrong. > > 1. Cdrdao extract hidden Audio Tracks that live in the pregap of > track 1. > It seems that cdrecord has this feature in its todo list, > but no one request that, it is not a important feature, right?
I wouldn't say it's not important. Plenty of CD's on the list I sent out earlier, right? > > 2. Cdrecord use cue file ,which is much better than toc file, right? > > If these 2 answers are all yes, we have no reason to integrate cdrdao > into Solaris, > since cdrecord can do most of work that cdrdao can do. That's not the point though, is it? What happens if an other project comes looking for cdrdao only functionality? We're long past the point where we're picking different utilities and libraries based on which delivers the best functionality. We're shoving as much FOSS into the packaging system(s) as possible to meet customer demands. Why would this be project be different? Look at the other thread around openproject where we're delivering two different project management programs. Look at all the cases around different media players. (I really need to go count them up...) This project isn't any different in that regards. The only reason we wouldn't want both is if they stomped on each other in some messy fashion. Hell, I'm waiting for someone to try and integrate cdrkit just to make this a real party. (That was a joke Jorg. Really...just a joke....)
