Re: [Audacity-devel] CD ripping/burning
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Richard A. <ri...@au...> - 2008-03-18 22:20:31
|
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 time. 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 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. Richard |