22 Sep
2004
22 Sep
'04
5:16 p.m.
On Wed, Sep 22, 2004 at 12:50:52AM +0100, Karl Heyes wrote:
My composition-thing will decode previously encoded portions of the
stream, apply manipulations (time-stretch/compress & possible reversing)
and then mix them together with others similarly manipulated.
Additionally, the recording portion of the system will choose a vorbis
quality at random from the range of worst-best for each recording. So,
there will be some effect from the encode-decode cycles. But, even if
that effect is minimal the system still messes with time scale
stretch/compress, reversal of audio data and mixing streams together at
random. Something interesting, at least to me, will come of it. The ogg
vorbis part at least provides a larger pool of previous recordings to
feed back into the system by virtue of saving some disk space.
-Eric Rz.
On Tue, 2004-09-21 at 22:18, Joern Nettingsmeier
wrote:
If you are taking
from svn, then you need the autoconf etc tools, but if
you are using tarballs then the configure script will be already built
so it won't be needed in that case.
Thanks Karl.
Other
than ices and icecast, do both the icecast box and the ices box
need all of the svn packages you list above?
the icecast box does not need the
*-tools. (nor does ices strictly
speaking, but they are nice to have). i described a "bleeding edge"
best-of-xiph.org setup. if you don't want to play with video or
very-low-bandwidth speech streaming, you can omit the speex and
theora packages as well as flac. ices/icecast check for them at
compile time - i wanted all bells and whistles, but if the libs are
not present, those features will be left out with no problems. you may even get away with using your
distro's libvorbis, although i
think ices-kh does require ogg2 and won't compile with plain old ogg.
no, ogg2
is not required, and AFAIK the vorbis codec may not be working
with it just yet. when you do
this, consider that under ideal circumstances, re-ogging
a pcm stream that has been ogg-encoded before will not add new
encoding artifacts, unless you reduce the bitrate.
I don't think you can state
that in general, as the second encoding will
operate on different pcm input. Given the same encoder settings it's
unlikely to loose much.