From: Denis L. <den...@ya...> - 2004-07-21 06:34:56
|
I've checked in support for Mp3 and Ogg into the gtkmm24 branch, though this targets mainly cdrdao (more work is required to integrate this nicely into gcdmaster thouhg it'll kind of work now). The libraries libmad, libvorbis and libao are used for this. It's of course an optional feature based on the availability of those libraries. Support is done by first converting any mp3 or ogg files specified into a toc file into a corresponding temporary WAV file, stored in a temporary directory (specified with the new --tmpdir option, defaults to /tmp). All temporary files are deleted upon exit, unless the new --keep option is specified. |
From: Marius S. <li...@al...> - 2004-07-23 13:26:07
|
On Tue, Jul 20, 2004 at 11:34:50PM -0700, Denis Leroy wrote: > I've checked in support for Mp3 and Ogg into the gtkmm24 branch, though > this targets mainly cdrdao (more work is required to integrate this > nicely into gcdmaster thouhg it'll kind of work now). The libraries > libmad, libvorbis and libao are used for this. It's of course an > optional feature based on the availability of those libraries. > > Support is done by first converting any mp3 or ogg files specified into > a toc file into a corresponding temporary WAV file, stored in a > temporary directory (specified with the new --tmpdir option, defaults > to /tmp). All temporary files are deleted upon exit, unless the new > --keep option is specified. > What is the advantage of adding this support to cdrdao itself that justifies the myriads of dependencies it causes rather than using a script that calls mpg123/321 or ogg123 to do the conversion or adding it to a front-end like gcdmaster instead. I mean cdrdao (currently) is just a simple application for writing CDs with no dependencies and should be kept as such and as long this approach still requires temporary files I don't see a real benefit of going this way. |
From: Denis L. <den...@ya...> - 2004-07-23 17:45:20
|
Marius, I understand your concern. This feature is of course mainly targeted at gcdmaster, so that i can go into nautilus and double-click on any .toc or .cue files and things "will just work"(tm). It just so happens that the code required for this needs to live in the trackdb library which is used by both cdrdao and gcdmaster. However, the dependencies are mainly for gcdmaster, and cdrdao can live without that stuff. I can guarantee you that the dependencies will never be mandatory for cdrdao. As a matter of fact, gcdmaster will not need cdrdao to have this stuff compiled in at all. Right now, cdrdao inherits this feature "for free" if you compile it in, but it's more a proof of concept than anything else. As far as calling some external scripts being better than including the libs, i completely disagree. There's nothing more britle and unstable than some executable having to fork/exec other stuff. It's the exact same dependency, except it's run-time, it's undocumented and you have no control over where mpg123, ogg123 are installed, how they're compiled, what kind of errors are reported, etc... Still, gcdmaster will probably have that feature in the future, so that you can configure it at run-time to support, say, wma files by entering the appropriate mplayer command to translate them to wav files. But i'd rather have support compiled in, especially with such lightweight libraries as libmad or vorbis. --- Marius Strobl <li...@al...> wrote: > On Tue, Jul 20, 2004 at 11:34:50PM -0700, Denis Leroy wrote: > > I've checked in support for Mp3 and Ogg into the gtkmm24 branch, > though > > this targets mainly cdrdao (more work is required to integrate this > > nicely into gcdmaster thouhg it'll kind of work now). The libraries > > libmad, libvorbis and libao are used for this. It's of course an > > optional feature based on the availability of those libraries. > > > > Support is done by first converting any mp3 or ogg files specified > into > > a toc file into a corresponding temporary WAV file, stored in a > > temporary directory (specified with the new --tmpdir option, > defaults > > to /tmp). All temporary files are deleted upon exit, unless the new > > --keep option is specified. > > > > What is the advantage of adding this support to cdrdao itself that > justifies the myriads of dependencies it causes rather than using > a script that calls mpg123/321 or ogg123 to do the conversion or > adding it to a front-end like gcdmaster instead. I mean cdrdao > (currently) is just a simple application for writing CDs with no > dependencies and should be kept as such and as long this approach > still requires temporary files I don't see a real benefit of going > this way. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > Cdrdao-devel mailing list > Cdr...@li... > https://lists.sourceforge.net/lists/listinfo/cdrdao-devel > |