Here's a question I've been seeking an answer to for a long time: Is there any Windows audio player out there which actually reads and displays ID3v2 tags at the front of an MP3 file when streaming it from a webserver? (I.e., playing a URL like "http://foo.bar.com/music/snafu.mp3".) I've tried Winamp, Quintessential, and foobar2000, and none of them do it -- they just display the filename and no other info. All these players handle HTTP streaming of other formats like FLAC and Vorbis just fine, reading the tags at the front of the file and displaying them in the player.

Obviously, this is something which would only work with ID3v2 tags, since ID3v1 and APE are both placed at the end of the file, where the player wouldn't be able to read them until it reached the end of the track.

I stream all my music from my webserver, most of it in FLAC and Vorbis, but I do have a few MP3 files tagged w/ID3v2 (only). If I play one of these in foobar directly from the file via a Samba share, all the metadata shows up just fine using kode54's id3v2 plugin, and I can see the tags themselves in the track Properties window. If I stream it via http, nothing shows up at all in the playlist or in Properties. Streaming a FLAC file from the same server, everything shows up just fine in both places.

I currently work around this by using mod_mp3 for Apache (which streams the file as a Shoutcast stream, with embedded artist/title info), but this is an inelegant and clunky solution which I'd rather abandon if I could find a player to handle the tags directly.

If kode54 is reading this, is this something that your id3v2 plugin could be extended to handle, or is it prevented by the internal mechanics of foobar? If it is possible, is this something you would consider for a future version of the plugin?

Thanks!

Dixie,
can you help me play MP3 on Apache? It seems that some of them play/download ok while others would have to be downloaded completely before playing.

Thnaks.

It'd be pretty ironic if there isn't a single program that supports ID3v2 through http streaming, since that's the primary reason the developers of ID3v2 put it at the beginning of the file, ignoring the royal pain writing such tags causes.

IIRC, Winamp does!!

That's what you'd think, but it doesn't, at least not with any version I ever tried...

Sorry!! My stupid mistake

I don't think it is possible. HTTP transfer is not meant for that kind of out of order data movement. It has the ability to do things out of order since it is a packetized system, but only in specific and limited ways. In fact, streaming over HTTP only works because the player can use wait commands to delay the stream (instead of transfering it all at once, which the server would normally do). It is kind of a hack that the design was not intended to do.

For an ID3v2 tag to be sent ahead of the rest of the file you would have to have the server itself understand id3v2 tags. It is possible for the client software to do a http request for specific chunks of a file out of order, but the player would need some foreknowledge of exactly how big the file was and where the id3v2 started.

While, ID3v2.4 does support putting the tag at the end of the file, it is mostly in the front of the file. Therefore when streaming you would get the tag first. I think it was done that way for streaming.

Actually since HTTP's underlying protocol is TCP, streaming works quite well using TCP's flow control mechanism. I wouldn't call it a hack--TCP was designed to do this. There is no explicit "wait" command that has to be sent to the server--the player can simply stop reading from the stream and let the TCP window shrink, thus slowing the flow of data.

xmplay does.

http://www.xmplay.com/

see? it can be done. now why doesn't foobar do it???


FRUSTRATION

This is something I plan to support in Euphonos (on Mac OS X -- guess that doesn't help Windows people), and is one of the influencing factors in the current IO model design I'm working on. I'm still not a fan of ID3v2 though

Out of curiosity, do these players read Vorbis comments under the same condition?

I don't know if this helps, but...

At the server side you could try kplaylist (www.kplaylist.net). It has an option to stream the ID3v2 info and players that support id3v2 should be able to display it.

I know that WMP does.

Thanks, but it looks like it does something similar to what I'm doing already with mod_mp3 -- stream the file as a shoutcast stream with embedded tags which the player can read. What I'm looking for is a way to make foobar read ID3v2 tags from the file itself without needing additional server support to make it work...

Dibrom, yes, both Foobar and Winamp have no problems reading Vorbis tags from HTTP-streamed FLAC or Ogg Vorbis files.

topdownjimmy, thanks for pointing out XMPLay -- it gives me hope for foobar in the future.

First of all, streaming doesn't have to be over HTTP. You can stream over raw UDP for example. TCP is well-suited to streaming. HTTP I guess not so much, but it is still possible.

I suppose using UDP, it is possible that the header won't arrive at the beginning of the stream, but it should still work... as long as the decoder applies the tag info as soon as it gets it.

If TCP is well-suited to streaming, how is HTTP not so much? Remember HTTP is just one layer above TCP... So when you use HTTP, you are essentially using TCP, with some additional information stuck on (in the case of Shoutcast, only in setting up the stream).

http is just designed to retrieve (get) or send (post) a file in a single burst. It is not designed to maintain connections. TCP is a good FOUNDATION for a proper streaming protocol, but HTTP really wasn't designed for that sort of thing.

I think you have misunderstood the way layered models work. Saying "HTTP is based on TCP and TCP can be used for streaming, then why can't HTTP?" is equivalent to saying "A Formula 1 engine is based on Internal Combustion and trucks use Internal Combustion, so why not use an F1 engine in a truck?".

HTTP (an Application Layer protocol) simply uses the services provided by TCP (a Transport Layer) protocol to transfer data without errors over the network. HTTP is designed to be used as a file orientated protocol for the transfer of Hypertext documents. It was never designed for streaming. The only reason anybody wants to stream over HTTP is most firewalls/transparent proxies let HTTP traffic pass through on high priority.

If you look at an HTTP stream, it just sticks on a standard set of headers. That's it. It was designed for use with hypertext documents. There is no reason why you can't take advantage of its standard headers to setup a stream. HTTP was a good choice for shoutcast since it was a good way to exchange the information the server and client needed to setup the connection. Its simple. After the setup, the stream doesn't use ANY HTTP headers at all (its just TCP doing all the work). Its just a binary stream of data. HTTP doesn't do anything special with flow control or anything. Sure, the designers of Shoutcast could have used proprietary headers to setup the stream, but why do that when HTTP already has a predefined fields for such information? Why reinvent the wheel? That's intelligent engineering--keep things simple when possible.

Your analogy doesn't make any sense BTW. I know exactly how a layered protocol works. HTTP is just text headers supplying information about the content of the data or information about a server or client. It is certainly not to TCP what TCP is to IP or IP is to Ethernet.

I've written a Shoutcast player on an embedded system, so I know exactly how it works and how much it really uses HTTP. Before I did that I had designed my own proprietary protocol that ran on top of TCP, that used a request and reply scheme to retrieve the data from a server. As an additional project I decided to implement Shoutcast. I was suprised at the utter simplicity of it. Why not take advantage of TCP's built in flow control? Why not use a standard HTTP header to exchange the data necessary to setup the connection? Very smart.

In response to your statement that streaming doesn't have to be over HTTP, yes. Most of the research that has gone into multimedia streaming protocols and algorithms says that TCP is inherently a bad protocol for many reasons. It offers no multicast support, and it doesn't handle variable bit rates well. In the case of real-time streaming, TCP's network friendly flow control is a bad thing. When low-latency is preferred over totally reliable delivery, TCP is bad.

On an unrelated point, I'm in LA and an earthquake just occured while I was typing this... pretty cool.