[Icecast] Multiple mount points without dynamic reencoding
raylutz at cognisys.com
Tue Jun 28 20:00:09 UTC 2011
Thank you for your response. (I hope someone else will comment on how to
deal with multiple source files without dynamic encoding, but the
question may be moot if I can get dynamic encoding to work properly). It
was some usefulness to write the response below, so I apologize for the
Perhaps you can correct/ my thinking here.
Reencoding from mp3 to ogg/vorbis will result in reduced fidelity,
because both are lossy encoders and are both assuming they are starting
with the original audio content, and it is well documented that
reencoding mp3 to ogg-vorbis only reduces the ultimate fidelity. In my
situation, we have mp3s coming from various sources, and their original
encoding varies across the map,
but the most common is 64k/44.1. So, we are re-encoding to that as our
standard so that in some cases, no reencoding will be necessary and the
original fidelity will be preserved.
(I find it is essential to have a continuous stream with the same format
and changes from format to format will break the connection with some
players, and some try to play the new data at the old rate, etc. So the
stream MUST be one encoding and data rate.)
It would be great if ices2 would be able to accept mp3 as input and
perhaps reencode it to ogg/vorbis (although in my mind, that is a stupid
thing to do, per the above argument). So my "interest" in mp3 continues,
and the statement that no one is interested in mp3 is ridiculous.
With ices2, the documentation says about the configuration parameter
> When encoding or re-encoding, there is a point where you take PCM
> audio and encode to Ogg Vorbis. In some situations a particular
> encoded stream may require a lower samplerate to achieve a lower
> bitrate. The resample will modifiy the audio data before it enters the
> encoder, but does not affect other instances.
> The most common values used are 48000, 44100, 22050 and 11025, and is
> really only used to resample to a lower samplerate, going to a higher
> rate serves no purpose within IceS.
This implies that we have a PCM input stream of fixed format, and we can
set this just once and be happy. This is not the case in my situation,
because the mp3s are coming from various sources, with differing sample
rates, and obviously are not PCM. Therefore, it appears that ices2 is
not sufficient solution.
On your "source client" comment, I looked these over,
1. mpd is oriented to playing music and is not suitable for what I need
to do. My application pulls in mp3 "podcasts" from various websites and
queues these up for specific time slots during the day. mpd requires a
playlist which I cannot provide since the content may change minutes
before the timeslot arrives.
2. rpld (RoarAudio) -- looks interesting, but is a layer I'm not sure I
need unless I need to interface with other sound input devices. I will
have to research this more since it looks like a good building block,
and may be a good solution for dynamic reencoding. (Of course, some of
these may encounter the same runtime error as ices0.4).
3. liquidsoap -- looks very interesting, but also looks very new and
unstable, and also looks like it is trying to do a lot more than I need
right now, with a complete programming language to learn to boot. The
good news is it looks like there is something going on here, unlike many
audio projects that are largely defunct and abandoned. I see many
outstanding issues before they get to version 1.0, with a stream of
messages and difficulties implying that this might be a bottomless pit
of time if I get started using it.
I'm not ready to take on the big project of adopting liquidsoap just to
deal with this encoding issue.
As I see it, I still have the following options:
1. debug the runtime error that occurs when trying to use liblame to
reencode mp3 using ices0.4. Not sure how long this will take or if I
will be successful at determining what is wrong. This would be a nice
solution but it still relies on the old version of ices.
2. Use a non-ices2 and non-ices0.4 source client that does support
dynamic reencoding, so I can start from an arbitrary source format and
produce a desired result format. From the list you suggested above, the
choice is not clear. I looked over liquidsoap for about an hour and I
still don't know how to use it to fill that need, and even if I worked
on it for a week, I may not understand what is needed.
3. Figure out how to use ices2 or 0.4 to access multiple files at the
same time, so that dynamic reencoding is not necessary.
3a. I am using mp3 now because but it is possible to produce ogg-vorbis
using asynchronous reencoding (using ffmpeg), and then the question is
the same -- if I have multiple sources, can ices2, for example, with
ogg-vorbis input, run two sources simultaneously?
3b. If I continue to use ices0.4 because it supports mp3, then it may be
possible to solve the problem by running multiple instances of ices and
providing a different format mp3 to each, and connecting them to
separate mount points on icecast.
BTW, I went through several versions of re-encoding packages before I
was able to get ffmpeg to work correctly for my needs. I think it is too
bad that ices dropped the ball and decided mp3 was irrelevant just
because they have a vested interest in ogg/vorbis.
On 6/27/2011 11:01 PM, Thomas.Rucker at tieto.com wrote:
> I'll skip the ices0 part of the email as I don't know that software.
> I only dealt with ices2 in that respect. So that is question
> is left to be answered by someone else (though I'm not sure if it
> will still apply).
> And here we arrive also at the most likely source of an underlying
> You do not have to have the same codec for the files as for
> the resulting stream! There are plenty source clients that will
> happily take almost any file format and codec in and encode it into
> a nice ogg/vorbis stream. (Random examples: mpd, rpld, liquidsoap,...)
> Also today's CPUs will happily do that without consuming too many
> of their cycles.
> It just happens to be a limitation of a few source clients that
> do not allow for this (e.g. ices2) that is fuelling this misconception.
> Also note that icecast and the shoutcast directory do not mix due
> to the terms of service of the latter.
> As to your question 32kbit at 44kHz vs 32kbit at 22kHz
> Think of two pictures: 44100x16px and 22050x16px (which is
> only one half of the former) both run through a JPEG encoder at the
> same setting. Which one will look better?
> It depends what you're after. Quality or spectral bandwith?
> When in doubt, try it.
> Icecast mailing list
> Icecast at xiph.org
1010 Old Chase Ave., Bldg B
El Cajon (San Diego Cty), CA 92020 USA
More information about the Icecast