On Tue, 2002-10-22 at 22:15, Giuseppe Corbelli wrote:
> On Mon, Oct 21, 2002 at 08:55:40PM +0200, Manuel Clos wrote:
> > >I was already thinking about that. It would not be a big deal to link
> > >against some mp3 decoders. The main problem is that you need the exact
> > >lengths of all tracks in advance when doing DAO writing. So far I know
> > Andreas, can you give us a short explanation why this is needed? is the=
> > TOC sent before the data?
> Yes, the TOC needs to know the size of the data.
Right, the CD TOC is written first and for that you will need to know=20
all information about the tracks, especially the lengths.
> > >the mp3 decoders can just give a rough guess about the decoded audio
> > >data length. I we just take the rough guess we would have to either
> > >pad the end of the track or drop some audio data depending if the roug=
> > >guess was too high or too low.
> > My idea is supporting this from gcdmaster, this is, use gstreamer to do=
> > the uncompression and the send the data to cdrdao.
> I don't know anything about gstreamer, but it sounds like a GNOME app. I
> wouldn't add a strict dependancy to GNOME.
I would also built the mp3 support into cdrdao. This would enable the=20
cut features like we have for wave audio files. For example a long mp3
file of live recording could be divided into tracks like it is currently
possible with wave files. Of course this would require seeking in mp3
files. This is probably supported as mp3 player can also do that but I
don't know about the accuracy (sample accuracy would be best of course).
> > Of course, gcdmaster will take care of getting the exact length by=20
> > decoding it to memory first. So gstreamer will handle wav, ogg, mp3 or=20
> > whatever format.
> Not so simple. You like to know the length of ALL tracks before beginning
> the burning process. And you cannot decode them all into memory.
That's right. There would be no big difference to just uncompressing all
mp3 files in advance. However, I still think that this would be the best
solution in terms of quality (accurace of seeking and lengths) and=20
reliability. If this could happen in background it would be also very=20
user friendly and disk space should not be the major problem today.
> > >Another problem I see is the stability. If the decoder crashes the
> > >complete disk will be wasted.
> > Yes :)
> And the user is aware of this. It's its choice.
I'm not sure if all user would be aware of it. But anyway, it is an
interesting feature, commercial application already do that (so it's
possible) and we should do that, too :)
> > So at this point it will be great if cdrdao will evolve into full=20
> > featured app accepting ogg, mp3, whatever, ... or will just accept data=
> > from another program.
> I'd suggest to support some audio formats natively, by developing an unif=
> decoding layer.
I agree on the decoding layer. I'm not sure if such a thing already=20
exists. If not we'd have to write our own which should not be too=20
difficult. For supporting more uncompressed audio formats the=20
libaudiofile could be used by the layer.
> And would like to know if libdao will be for cdrdao use only or will evol=
> into a full SCSI library.
> Scglib is already a good SCSI library but a bit chaotic and undocumented.
Libdao was never meant as a SCSI interace library. It is a CD recording
library that may use libscg for communicating with the drives. There are
also libscg independent SCSI interface implementations avaibale but I
don't think that they are used because libscg covers them all.=20
I would say that J=F6rg did a good job on libscg. At least the interface
is clear and I think the implementation is also good. I just do not like
the stdio reimplementation which unneccesarily blows up the code and
introduces problems (e.g. when statically linking under Linux).
Andreas Mueller Tel: +49 89 67808848
Ramsmeierstr. 1 Email: andreas@...
85579 Neubiberg, Germany