How to get Winamp to show id3 info when streaming from the empeg via http

I've installed Mark Lords lagtest Hijack kernel which supports mp3 and m3u playlist streaming via http - which works well.

However, winamp [v2.77] refuses to show the Track info in the ID3 tags in the stream. It shows only 'stream name' i.e. the Fid of the stream being played but when you view the stream info it acknowledges that there is a id3 tag present - it just seems to ignore it.

Interestingly when the m3u file is played initially the Winamp playlist shows up with full title/artist info for each song in the m3u but as each track is played it gets munged to its fid.

This sounds like a Winamp bug to me - I have tried the same on the very latest Winamp [v2.78] or is this something we need to give some feed to Mark about.
[Mark Lord doesn't run Windows so won't be running Winamp 2.X so if he's not giving Winamp what he should we need to work it out and pass the info along rather than expecting Mark to work it out for himself - plus Mark is real busy on even better hacks so its not wise to burden him with this one unless its a hijack issue].

I think the problem is that the MP3 file itself contains the ID3v1 data at the end of the file, and when you're streaming, that data doesn't reach winamp until the song is done playing.

Just for the heck of it, try adding an ID3v2 tag to a file, uploading that to the player, and trying to stream that one. (V2 tags are usually at/near the beginning of the file.)

You can also test this by simply downloading the track and running it, w/o streaming using the .m3u method..

All my MP3s have IDV2 tags filled out and I get the same problem in WinAmp so I don't think this is the problem.

I don't think WinAmp/FreeAmp supports IDv3 tags when it's receiving a stream.
IceCast is a streaming server that WinAmp supports and you have to explicitly tell it what the title and artist is so it can send it out via UDP packets. You might want to check the source though.
- Trevor

I have also played with the Rio Receiver software that lets you stream files from that software to Winamp and I have a strong feeling that Winamp did accept (and displayed) Id3 tag info from the Rio Receiver software.

It may be that the RioReceiver software puts the ID3 tag up front in the stream [or manufactures it from the database information on the fly before it streams the file out.

roger might be able to confirm this point as he is the one who has had a large amount of involvement in the empeg team with the Rio Receiver Software - visit the unofficial Rio Receiver BBS for Rogers posts on this subject late last year.

I'm doing this now with my server app. Don't as me how, as I've made no special effort to send the ID3 data, but when I stream files, it shows the proper information in Winamp.

This might have something to do with me sending "incorrect" headers when I send the mp3 files. Instead of type audio/mpeg or audio/x-mpeg, I send it as application/octet-stream.

Okay, here is what your server is doing:
First, an .m3u playlist:

#EXTM3U

#EXTINF:276,Creedence Clearwater Revival - Susie Q

http://mp3.everonn.net/v2/getfile.php?fid=abe0&playlist=1

#EXTINF:272,Creedence Clearwater Revival - I Put A Spell On You

http://mp3.everonn.net/v2/getfile.php?fid=abf0&playlist=1

...

Hijack also generates m3u files in that format.
But the next step is different:

HTTP/1.1 200 OK

Server: Microsoft-IIS/5.1

Date: Fri, 01 Feb 2002 07:11:01 GMT

Content-Type: application/octet-stream

X-Powered-By: PHP/4.1.1

Content-Disposition: attachment; filename=Ayreon - To The Solar System

Content-Length: 5953956



...........................................

..............................................

That's one strange header for an .mp3 file. Anybody care to explain it to me?

Thanks.

Well I guess that would be me, as it's my doing.

I forgot about that line of code...it seems I DID in fact add the Content-Disposition: header specifically for the purpose of getting Winamp to show me the name of the Band/Song when it's playing. Winamp doesn't read this from the mp3 file itself (same reason hijack doesn't show it, I would imagine). I figured out that if Winame can't display ID3 data, it wants to display the filename, and that's basically what I told it to do (telling it what the file name is, so that's exactly what it displays).

As I said in a different thread, the Content-Type is wrong on purpose, because this script does more than one function. From my app, if you click the disk icon on the file it prompts you to save the file (in all cases I know of). I wanted to force that behavior, instead of letting the browser do what it normally does with mp3 data (in most cases play it, which confused people who just wanted to download the file).

I also added the content-length header. Everything else is generated by the server (IIS/PHP).

Ok I made a slight change, so when streaming mp3 files on my server it should return audio/mpeg as content-type. It doesn't seem to change the behavior of anything anywhere, but at least I'm slightly more correct now. I was hoping this would fix my resume/partial content problem, but it doesn't seem to matter.

As far as the Content-Disposition line, you might want to try doing that also (if you don't see any drawbacks to it that I'm missing). That seems to be the fix that us Winamp folk were looking for. Similar to the way you generate the ext info in the m3u, I just generate on the fly a filename formated as <artist> - <title> and that's what shows up during stream/play in Winamp.

Cool. Okay, I'll add the same "title" line to my HTTP headers for .mp3 data, and perhaps also add an ".mp3" extension to the download, just for good measure. v163, later today.

Thanks!