Icecast - Aug 2004 - IceCast Questions.... ("id3 tags, mp3, Ogg, etc)

Hello, I'm a long time user of Icecast. We currently run 12 streams on
Icecast 1.x (Mp3). I plan to expand this to 20 streems soon. They are all
low bitrate community service.

Recently some friends and myself came across the thought of actually
generating our own content. Music, talk, etc.

I've been running the ideas of the automation setup that would be required
to do such a thing. I used to have a low power FM station (until the FCC
said stop) so I have some knowldge of doing real audio. Plus someone
involved on the project has commercial station experience.

Here are some of the issues I am trying to contemplate, and how to solve
them with Icecast:

First:

Ogg/Vorbis. I've always avoided it because it is still non standard. I
know the mp3 capable Icecast is depreciated. Is Ogg/Vorbis supported in
Windows Media Player 7-8 or newer? By this, I mean either it immediately
works or automatically downloads the codec. Most internet users won't ever
bother to manually download and install codecs. I realize the later Winamp
would support it. RealPlayer? The Apple QuickTime player?

Second:

Trying to cut back and forth between local playlists of MP3s, local live
content and remote fed content seems like a challenge. My current thought
is to have one system that plays audio that is linked to one or more
computers that encode the audio. This way when switching between local
content and remote content, the stream isn't interrupted and the listeners
aren't dumped?

But then comes the issue of the id3 tags. Is there any ways to trigger the
darkice encoder to "update" the text on the player on the fly?

If I had 1 icecast server acting as a relay, connecting to a 2nd one,
could I switch between "2nd ones" and not interrupt the listener?

OOOOOO

Wait. Maybe if we could trick it into hitting a "file" in the playlist
that is being written real time, that could work.....

<p>Anyone have experience trying to push Icecast to do all of this?

<p><p><p><p>--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

On Friday 18 July 2003 11:16, Ethan wrote:
> Hello, I'm a long time user of Icecast. We currently run 12 streams on
> Icecast 1.x (Mp3). I plan to expand this to 20 streems soon. They are all
> low bitrate community service.
>
> Recently some friends and myself came across the thought of actually
> generating our own content. Music, talk, etc.
>
> I've been running the ideas of the automation setup that would be
required
> to do such a thing. I used to have a low power FM station (until the FCC
> said stop) so I have some knowldge of doing real audio. Plus someone
> involved on the project has commercial station experience.
>
> Here are some of the issues I am trying to contemplate, and how to solve
> them with Icecast:
>
> First:
>
> Ogg/Vorbis. I've always avoided it because it is still non standard. I
> know the mp3 capable Icecast is depreciated. Is Ogg/Vorbis supported in
> Windows Media Player 7-8 or newer? By this, I mean either it immediately
> works or automatically downloads the codec. Most internet users won't
ever
> bother to manually download and install codecs. I realize the later Winamp
> would support it. RealPlayer? The Apple QuickTime player?
Icecast2 is fully mp3 capable as well, calling 1.x "the mp3 capable
icecast"
indicates you didn't realise that. It also supports other (better) formats
as
well, of course... By the way, you were looking for the word
"deprecated",
not "depreciated" (which is a real word, but means something entirely 
different). So anyway, you can use mp3 AND vorbis simultaneously with 
icecast2.

vorbis is supported in WMP by external plugins - they're not built in, and
not
auto-downloaded.
There is a real plugin, it will soon (but not yet, afaik) be available from 
the auto-download servers.
iTunes doesn't support it. 

Most of the more commonly used players have support (though how good the 
support is varies). The main lack is iTunes - many mac users use it, and 
there's no support.
>
> Second:
>
> Trying to cut back and forth between local playlists of MP3s, local live
> content and remote fed content seems like a challenge. My current thought
> is to have one system that plays audio that is linked to one or more
> computers that encode the audio. This way when switching between local
> content and remote content, the stream isn't interrupted and the
listeners
> aren't dumped?
That's one approach that requires little support from the software, and
should
work fine. More infrastructure neccesary, obviously.
>
> But then comes the issue of the id3 tags. Is there any ways to trigger the
> darkice encoder to "update" the text on the player on the fly?
This is supported by icecast (it doesn't use id3 tags for this, but most of 
the source encoders get the metadata from id3 tags originally), I'm not sure
about darkice. It's pretty easy to add this sort of thing, all the hard bits
here are done in icecast. 

<p>>
> If I had 1 icecast server acting as a relay, connecting to a 2nd one,
> could I switch between "2nd ones" and not interrupt the listener?
Not precisely. What you can do (with icecast2) is:
    server1: /relay-mount1 <---- server2
           : /relay-mount2 <----- server3

In this setup, you might dynamically add server3/relay-mount2, as your "new
2nd one". Then, you can dynamically switch users from /relay-mount1 to 
/relay-mount2, without interrupting the listeners. Then you can drop 
server2/relay-mount1. 

The above is not well tested, however, and it may interact badly with metadata 
support. If so, this should be fixed.
>
> OOOOOO
>
> Wait. Maybe if we could trick it into hitting a "file" in the
playlist
> that is being written real time, that could work.....
That may also work, depending on your source program (I haven't used
darkice,
I'm not sure of its exact capabilities).
>
>
> Anyone have experience trying to push Icecast to do all of this?
Not on live systems, but I've done similar things on internal tests.

Mike

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Ethan wrote:
> Trying to cut back and forth between local playlists of MP3s, local live
> content and remote fed content seems like a challenge. My current thought
> is to have one system that plays audio that is linked to one or more
> computers that encode the audio.
That is the proper way to do it.  Keep the audio production separate to the
broadcast.  The challenge will be updating the playing now details.  It
should be possible but others will need to help you out with that.  To plug
my own radio automation/live assist software, StationPlaylist Studio
(Windows only) can output the current playing file to a text file in any
format you like (text, xml, html) which could be read by some process on the
PC encoding the stream.

Regards,
Ross Levis
http://www.stationplaylist.com

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

On Thu, Jul 17, 2003 at 09:55:04AM -0600, Jack Moffitt
wrote:
> Please speak to Ralph Giles <giles@xiph.org> about obtaining commit
> access to CVS.  We should check in your debian/ dir into the official
> tree and that way we can be sure to sync releases.  Also people using CVS
> snapshots will be able to build their own debs.
Well...  Thanks!  I've been maintaining my own Subversion repository for
the packaging stuff, but this would certainly make things easier for
bleeding-edge users, and release synchronization is definitely a good
thing.  I've sent Ralph a quick message.
> Are you planning on packaging ices 0.3 as well?
I had not previously, because I don't personally have any need for MP3
streaming, since Ogg Vorbis is working so well.  :)  I've sent a quick
note to a Debian developer who had expressed interest in the past; if he
is no longer interested, I'll make up some packages myself.

Thanks again,

 - Keegan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: part
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/icecast/attachments/20030717/41aef918/part.pgp

On Monday, 04 August 2003 at 10:40, Keegan Quinn wrote:
> On Thu, Jul 17, 2003 at 04:53:46PM -0700, Keegan Quinn wrote:
> > On Thu, Jul 17, 2003 at 09:55:04AM -0600, Jack Moffitt wrote:
> > > Are you planning on packaging ices 0.3 as well?
> > 
> > I had not previously, because I don't personally have any need for
MP3
> > streaming, since Ogg Vorbis is working so well.  :)  I've sent a
quick
> > note to a Debian developer who had expressed interest in the past; if
he
> > is no longer interested, I'll make up some packages myself.
> 
> I've spoken with the other developer, Emmanuel le Chevoir, and he is
still
> interested, but has even less free time than myself.
> 
> We've also briefly discussed some potential legal issues with the
> distribution of ices0 binaries in Debian; we cannot distribute LAME or
> liblame, of course, which I believe ices0 depends on, for MP3 encoding.
> 
> Would it be possible, or would it make sense, to distribute ices0 without
> LAME?  Emmanuel told me that the icecast-client currently in Debian
> (for the old icecast 1) manages to stream MP3s without re-encoding them,
> so I am curious as to whether this might be a reasonable approach for
> ices0 as well.
ices0 works well without lame - it just can't transcode or
reencode. It's still a huge improvement over shout.

-b
--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to
'icecast-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

On Thu, Jul 17, 2003 at 04:53:46PM -0700, Keegan Quinn
wrote:
> On Thu, Jul 17, 2003 at 09:55:04AM -0600, Jack Moffitt wrote:
> > Are you planning on packaging ices 0.3 as well?
> 
> I had not previously, because I don't personally have any need for MP3
> streaming, since Ogg Vorbis is working so well.  :)  I've sent a quick
> note to a Debian developer who had expressed interest in the past; if he
> is no longer interested, I'll make up some packages myself.
I've spoken with the other developer, Emmanuel le Chevoir, and he is still
interested, but has even less free time than myself.

We've also briefly discussed some potential legal issues with the
distribution of ices0 binaries in Debian; we cannot distribute LAME or
liblame, of course, which I believe ices0 depends on, for MP3 encoding.

Would it be possible, or would it make sense, to distribute ices0 without
LAME?  Emmanuel told me that the icecast-client currently in Debian
(for the old icecast 1) manages to stream MP3s without re-encoding them,
so I am curious as to whether this might be a reasonable approach for
ices0 as well.

On the other hand, the confusion of distributing a crippled ices0 might be
more trouble than it's worth.  I'm interested to hear ideas and thoughts
on this matter.

Thanks,

 - Keegan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: part
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/icecast/attachments/20030804/7ae9ee26/part.pgp