Richard Ash schrieb:
> On Tue, 2008-03-18 at 22:32 +0100, Thomas Holzmann wrote:
>> Thats the point. There are cross-platform tools available. There are
>> cdrtools (a command-line cd recorder software), which are used by many
>> programs under Linux and are also avaliable for Windows and Mac. There
>> is e.g. InfraRecorder which uses the cdrtools very successfully on Windows.
>> The only problem is that cdrtools is distributed under the cddl license,
>> which seems not fully compatible with the gpl. I've contacted the author
>> of InfraRecorder (which is also gpl) and asked him about this issue.
>> I've attatched the email at the bottom.
>> So according to him it would be better to use cdrkit, which is a fork of
>> cdrtools made by the debian developers because of the licensing issue.
>> And because it's just an older version of cdrtools with a few bug fixes
>> and a new name, it should also work on all three platforms and it is
>> interface compatible with cdrtools which means audacity could easily
>> support cdrtools and cdrkit (like k3b does).
>> And I am not sure that if Audacity burnt
>>> CDs we would really have the extensive Windows driver issues that
>>> Richard envisages. Driver issues rarely appeared to me to be behind
>>> user requests for help burning CDs with third party software.
>> I also don't think there should be so much driver issues, because like I
>> want to make it audacity will not be the burning/ripping application
>> itself, it will only use the tools (cdrtools/cdrkit) to do it.
> It may just be the machines where I have tried it, but all the
> cdr-tools-based windows packages I have used have burnt more coasters
> than valid CDs, where as I have no problem running k3b. Being stuck with
> a windows desktop at work and no license for Nero I'm now using a
> non-open-source freeware package based on .NET because it actually
> enables me to create discs without write errors at least some of the
I did never have bad experience with InfraRecorder. I have not used it
very much, but I've installed it on some Windwos computers of my
friends and made test burns and never had problems. They also did not
tell me until now that they have problems with it.
> I also note k3b is 4.9MB of source code, or twice the size of audacity's
> source tarball. OK, so it does more things than we are proposing
> audacity would do, but then I have to keep k3b for things audacity
> doesn't do (like data CD burning). So where do users actually gain? Is
> this not another case where we should be looking more for a bridge
> plug-in (and maybe a .aup project reader) to an existing project or
> projects rather than re-inventing the wheel by trying to construct a CD
> burning system within audacity. Even assuming the back end can be
> provided by command-line tools (which in my experience are non-trivial
> to configure correctly), we still have to provide a user interface.
> What it boils down to is that I'm sure we could add CD burning support
> to audacity. I'm not sure we could make it as good as the rest of
> audacity is, and and keep it working into the future (given that
> portaudio and portmixer are a continual challenge, even with the help of
> an outside project team on the former).
I totally agree. I also don't think that it's necessary for audacity to
be able to burn cd's, because if you want to make it as good as in other
programs, it would be not such an easy task. Therefore I also did not
included it in my initial proposal, I just picked up this suggestion
from the discussion here on the mailing list.
So I think I will reduce my proposal again to CD ripping ( I think CD
ripping would be easier to make on all platforms and also more users
would use this feature; many people just want to take one track from a
CD and want to edit it) plus some of the extra features you've mentioned.
> I can see some extra features making it much easier to use audacity for
> CD mastering and production. Ones that come to mind are:
> * function to arrange a set of tracks end to end automtically, so that
> each starts as the previous one ends (so you can rip a CD, then put the
> numbered tracks into audacity and get the disc structure back)
> * Auto-insert a label (based on the audacity track name) for each track
> transition in the above scenario. This makes it possible to shuffle
> tracks around, tweak levels, and so on, then insert labels to get the
> tracks back out as separate files. Just exporting each track in audacity
> to a file doesn't hack it, because the inter-track spaces aren't
> preserved. You could even mix and render all the tracks down to one, and
> then run the compressor over it to get a consistent high level (e.g. for
> a CD or playlist to listen to on the tube)
> * A means to get all the track meta-data to come through the above
> process and into the CD burner unscathed. At a minimum this means a way
> that the tags of each imported file go back to the corresponding
> exported file. It might also mean a way to push metadata straight to the
> CD burning application if it won't read it from file tags.
> * Option to write a playlist file for an export multiple run with all
> the files and metadata in it - could either go to a CD burning app or a
> media player.
I will think about these features...