[Icecast] Multiple mount points without dynamic reencoding

Tue Jun 28 20:00:09 UTC 2011

Thomas:

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 
length.

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 
"resample":

     <resample>
         <in-rate>44100</in-rate>
         <out-rate>22050</out-rate>
     </resample>

> 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.

--Ray

On 6/27/2011 11:01 PM, Thomas.Rucker at tieto.com wrote:
> Hi,
>
> 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
> misconception:
> 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.
>
> Cheers
>
> Thomas
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>

-- 
---------------------------------------
Raymond Lutz
Cognisys, Inc.
1010 Old Chase Ave., Bldg B
El Cajon (San Diego Cty), CA 92020 USA
Voice 619-447-3246
http//www.cognisys.com