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..> > 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?> > 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.>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).>The protocol you're talking about is exactly how shoutcast does >it. I've had no problems using shoutcast-style metadata to feed a >current winamp from a current icecast.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 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." 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. -Asym http://rfnj.org --- >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 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 Ione 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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
At 13:00 8/12/2001 -0400, you wrote:>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.ID3 v1 and v1.1 (hardly worthy of it's own version number) is typically the last 128 bytes of a file. ID3 v2 is typically at the start of the file and uses a method they call "synchsafe" to keep it from being interpreted as a valid mp3 frame.>I haven't actually tried to embed ID3 tags between frames in a stream >- you are welcome to prove me wrong.Nor have I.. I'll give it a whirl sometime.>one difference I know about is the interval, which is I believe 4096 >in icecast but tends to be larger in shoutcast.8192 in shoutcast I believe.>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.I'm sending from winamp with the FHG codec.>that comment probably has more to do with the fact that nullsoft has >provided no documentation for their metadata protocol.Yeah that's a huge pain in the ass too.. as I said, nullsoft has never impressed me. ;) --- >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.