[icecast] Metadata, again..

[Brendan Cully]

On Sunday, 12 August 2001 at 04:33, Asymmetric wrote:
> At 17:05 8/11/2001 -0400, you wrote:
> 
> 
> >you tell me. Works alright here, except in xmms which has a bug in its
> >shoutcast metadata handler. I've submitted a patch at bugs.xmms.org
> >for it.
> 
> Hmm.. well with the current version of winamp and the previous two it would 
> and does skip if I have metadata enabled.. it'll start anywhere from ten 
> minutes to an hour into the stream and then just get terrible.  If the 
> listening client is restarted, it goes away for an indeterminate amount of 
> time, then happens again..

I haven't had this problem, but I will experiment some more. If
someone has posted a patch which fixes this, I'd of course like to see
it too.

> >> the song changes and when a new user connects, at the beginning of their
> >> data?
> >
> >probably not, but nothing would read it.
> 
> How do you figure?

ID3s are supposed to be the last 128 bytes of the file. So I would
expect most MP3 players just jump to the end of the file and grab the
ID3, rather than parsing any interframe garbage they run across to see
if it might be an ID3 tag. Streams of course have no end of file.

I haven't actually tried to embed ID3 tags between frames in a stream
- you are welcome to prove me wrong.

> >> I don't see any reason to send it at a particular interval, just 
> >on-change
> >> from the source is enough I would think.  AFAIK an ID3 tag is simply an
> >
> >not necessarily.
> 
> When would it not be enough?  What I'm suggesting here is that the icecast 
> server interpret the metadata it gets from the source (which it obviously 
> can do or it wouldn't know the song titles, etc) and then instead of 
> sending them out in this same format, it sends them out as an ID3 tag.

alright yes, I misunderstood. This scheme is as effective as the
current scheme. But it's probably a moot point, see above.

> >because the clients skip the "invalid frame"?
> 
> Clients skip "playback" of the invalid frame, but they do parse it for a 
> valid ID3 header.. this is how ID3 works.  The first characters of the 
> frame are ID3 which both simultaneously identifies the frame as ID3, while 
> invalidating it as an mp3 frame for playback (Valid frames are all bits on).

try it out and let me know. Personally I think the way ID3 works is by
being the last 128 bytes of the file.

> I understand that is how shoutcast does it, I'm trying to find out why 
> icecast doesn't do it the same way.  I've used 1.3.11 and it still has the 
> same problem.. If icecast were doing it the same way as shoutcast, then I 

one difference I know about is the interval, which is I believe 4096
in icecast but tends to be larger in shoutcast.

Also what client are you using to send data to icecast? You may get
into trouble if you send MP3 data with garbage in it.

> think it would work better.. and not have that glaring warning in the 
> config file about using metadata at all.. something to the effect of "this 
> doesn't work quite right and probably never will."

that comment probably has more to do with the fact that nullsoft has
provided no documentation for their metadata protocol.

> I'll give it another whirl and see how it goes just for the sake of doing 
> it.. but if anyone remembers that patch they sent me, I'd love to have it 
> again.  It was very simple and worked like a charm.

I'd like to see it too.

-Brendan

--- >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 at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.