Hi,

On Wed, 7 Mar 2001, Martin Vogt wrote:
> >You can now simply rip the contents of a complete CD from konqui by simply
> >opening the "MP3/" directory selecting all files there, and copy them to
> >another real directory, which is rather cool.
>
> Yep. This is really nice.
> But should we (in general) put this complexity in an ioslave?

Normally I would aggree with you (to not put that complex stuff into an
IOslave).  The "problem" is, that nice libraries are available to do
exactly what one needs (using the lib as a filter between ripping and data
output), which makes it _very_ tempting to put it into an IO-slave.

The whole rest is mostly IMHO, where appropriate ;)

Additionally in _this_ case it is even conceptionally more correct to put
the compression into the IO-slave (one could have also made a real filter
like kio_gzip or so, but mp3/vorbis only works on specially structured,
gzip on arbitrary data).  After all the compression is the
important thing here, and that it acts like an internal filter (though a
lossy one), so this is operating on files, not on multimedia data (compare
this with e.g. a lowpass filter to see the difference, which very clearly
would not belong to a IO-slave (yes, yes we now have even much more
filters in audiocd, due to MP3 and Vorbis ;) )

> Maybe that sometimes/someone comes to the idea that ripping DVDs
> and encoding it to divx (only for his own use of course)
> should be done with ioslaves too.

Well, here also my above arguments hold, so if _I_ am in favor of the
audio change because of these arguments, then I can't seriously be against
the video change.  So I wouldn't _heavily_ oppose to such a change (a
little bit nevertheless probably, just because the change feels bigger)
Another theoretical argument for doing compression in the io-slave in case
of video is the sheer datavolume.  It anyway needs to be compressed
somewhen, and when one does this as soon as possible, the data shuffling
is smaller.

A good argument against putting such stuff into an IO-slave is the
increasing complexity of parameters.  The more parameters there are the
uglier the process is controllable, when it's done in an IO-slave, and as
Video-compression has much more parameters then audio-compression, this
alone might prevent a feasible implementation of video-compression in an
io-slave (we already have only very rudimentary support for parameters for
audio-compression)

> I think a better way would be to do this with arts.

Yep.  Or at least arts also needs input/output filter for Ogg and MP3 (it
already has them, IIRC, right?)

> Use artsd to read with the help of an ioslave, and then
> connect the output to oggenc.
> (But I think that this requires much more code, so the ioslave
> approach is the "fastest" solution and maybe the best in this
> case.)

Well, more code is not the problem, but also integration to the whole
system.  Right now you can nearly rip a whole CD with two drag&drop
operations (and after all, this is of course the usage pattern for this
functionality).  If this would be done thru arts, I don't know how well
this integrates with e.g. konqi.  Wouldn't I need an extra program for
this then?  I believe, this all is because arts is strictly speaking too
powerfull to be used as an file format converter (which is, what we are
doing here).  Hmm.


Ciao,
Michael.

 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<