Winamp doesn't read ID3v2 tags when streaming

[Captain Chaos]

The subject line says it all. In all versions I've tried up to and including 2.77, Winamp ignores the ID3v2 tag and VBR header when streaming an MP3 file over HTTP. The result is a very ugly stream name instead of the proper artist and title, and the wrong song length being displayed.

The odd thing is that Winamp does see the ID3v2 tag (I know because when I look at the file info while the stream is playing, it reports the ID3v2 tag size), it just ignores it for no apparent reason.

It should be easy to utilize both the ID3v2 tag and the VBR header, since they are at the beginning of the file and Winamp sees them both before any MP3 data.

[Huanjo]

Yeah! I agree. And it seems quite wasteful when you consider that the major reason why the ID3v2 tag is located at the front of the file is for streaming purposes.

[DJ Egg]

Please ignore (realized at a later date to be utter bullshit)
Proceed straight to this post,
and ignore all my posts inbetween this and that one.

Thank you



_______________________________________________

[some crap was here]

[Captain Chaos]

Hi DJEgg,

I don't want Winamp to display the stream title, I want it to display the artist and title from the ID3v2 tag in the song like it does when playing the file directly from the harddisk. Anyway, if you mean the 'Include stream name in title' option under 'SHOUTcast titles', it makes no difference if I activate that or not, Winamp displays exactly the same in both cases (the URL the stream is being played from).

My MP3s have correct VBR headers. They have been encoded by MusicMatch and have had VBR headers added with Mp3/Tag Studio. If I play them directly from disk, Winamp does read both the ID3v2 tag and VBR header correctly, but when streaming the exact same file over HTTP, it ignores both...

I don't think the bug you mention applies (since Winamp can play the files correctly when playing them directly from disk), but even if it did, it shouldn't affect the processing of the ID3v2 tag, right?

Regards,
Pepijn

[DJ Egg]

Lord knows ?!?! It works alright for me (with every stream)

Any chance of some url's? (ie. links to the mp3's)

btw, by "stream title", I actually meant the artist & title info from the ID3v2 tag. The v2 tag is at the beginning of the file so it should be displayed instantly (whereas the v1 tag is at the end of the file and won't be displayed until the whole track has been played/downloaded)

I think both options in the MPEG Audio Decoder need checkmarking by the way (especially "Enable title streaming"). These changes only take effect when the track/stream is reloaded.

It could have something to do with the crappy MMJB Xing encoder,
though I'm not entirely sure?
Wish, Peter, sawg, anyone?

Hmm . . . me ponders . . . "stream titles" is possibly just for shoutcast streams (icy headers) and not for standard mp3 streams . . . any chance of some links?
I could upload some mp3's to some webspace somewhere, but currently, I'm on a 56k modem with limited webspace.

[Captain Chaos]

Hi DJEgg,

Hmmm. There very well may be a problem with my files that's causing Winamp to not find the ID3v2 tag and VBR header (I don't trust MusicMatch further than I can throw it, which is not very far, seeing as it's virtual and all). But it finds both of them when playing the files directly, so there must at least also be a problem in Winamp. The tags can't be _all_ bad.

By the way, don't those options you're talking about apply to Shoutcast streaming only? Remember, I'm talking about streaming over HTTP. If they apply to that to, perhaps the options should be renamed to something more generic.

I've put a file online at http://www.chaos.demon.nl/01_Jamiroquai_Virtual%20insanity.mp3
If I play it through that URL, it doesn't show the artist and title or the correct length. (It also skips a lot, but that's because I don't have broadband Internet access.)

Regards,
Pepijn

[DJ Egg]

Hi :)

Cheers for the link.
First thing I noticed (after it connected ok) was the "reading id3" message . . . but, like ya say, it failed and only the filename was displayed. The stream then plays fine.

It's looking like an MMJB Xing encoder bug to me . . . still not sure.
Did you try the vbr fix?
Or there's still a chance it could be the FhG vbri issue . . . again, I'm not rightly sure on any of this . . . it's more in Peter or Wish's field of expertise than mine. Where are they when ya need 'em, eh? ;)

I'm not going to download the mp3 to my HD, but I suggest you try the vbrfix and also try editing the ID3v2 tags in Winamp's editor (Alt+3).
Either that or don't use MMJB p.o.s.
I recommend using either CDex (http://www.cdex.n3.net/) or EAC (http://www.exactaudiocopy.de) with the LAME Encoder instead.

There's still a chance that someone else might come by to either sort this out properly or give some kind of confirmation, but in the meantime . . . good luck! :)

[Captain Chaos]

Hi DJEgg,

Have tried both. VBRFix skips the file, saying that it's already got a VBR header, and I always use Winamp to edit the tag after ripping it, because MusicMatch doesn't set the year or genre fields.

Perhaps you could forward the URL to one of the people you mention so they could take a look at it and tell me if the file is corrupt, and if so, in what way?

Regards,
Pepijn

[DJ Egg]

Oh, I'm sure they'll visit this thread eventually ;)

Keep your fingers crossed :)

I've gotta say it's mightily weird, because all other streams (whether an m3u or pls playlist, or straight mp3) display the ID3v2 tags perfectly ok for me. This is the first time I've ever come across anything like this, not since the old poohey days of no ID3v2 support in Winamp (pre v2.666)

Though, where MMJB is concerned, anything's possible . . .
especially with its st00pid customized fields in the tags that no other players support or can read.

However, thinkin' about it, both Peter & Wish think ID3v2 tags are sh*t anyway and will probably just link you to this page: http://r3mix.net/noid3.htm :D

[Captain Chaos]

Hi DJEgg,

I would be dissappointed if they pointed me to that page, since there don't seem to be any valid points of criticism of ID3v2 on it. It all seems to come down to: "my favourite MP3 player's ID3v2 support sucks, so ID3v2 must be evil..." :)

Regards,
Pepijn

[matthewlmcclure]

I'm having the same problem with Winamp 3. If I load a playlist with extended info, the artist and track name are displayed in the playlist editor until the track begins playing. Then it is replaced by the file name, even though an id3v2 tag is present in the mp3.

http://www.faradic.net/~mmcclure/2001-02-23_-_jack_johnson.m3u
http://www.faradic.net/~mmcclure/2001-02-23_-_06_-_jack_johnson_-_bubble_toes.mp3
http://www.faradic.net/~mmcclure/2001-02-23_-_07_-_jack_johnson_-_rodeo_clowns.mp3

[jreg]

Anything happening with this issue? I've tried both latest version 2 and 3 and it fails with both Winamps. This issue was first raised in June 2000 (http://forums.winamp.com/showthread.php?threadid=23488&highlight=id3), thought it should have been fixed already. :(
If I open my mp3 file (ripped with CDex and Fraunhofer codec) with Windows Media Player 9 (still streaming with http) it shows the correct tag information, just as if I open the file in Winamp as a local file. Please fix!!

[matthewlmcclure]

I reported this in Nullsoft's Bugzilla (http://bugzilla.nullsoft.com:3430/show_bug.cgi?id=2146). There's been some activity, but I'm not sure how to really determine if any action is being taken to fix it.

[DJ Egg]

Hi

Here's what MP3Utility reports for this file:
http://www.faradic.net/~mmcclure/2001-02-23_-_07_-_jack_johnson_-_rodeo_clowns.mp3

Processing: C:\Downloads\Temp\2001-02-23_-_07_-_jack_johnson_-_rodeo_clowns.mp3

Warning: Last audio frame truncated.
Frame 6,762 (bytes 3,533,501 - 3,533,878) short by 144 bytes (expected 522 bytes, found 378 bytes).

Summary: 6,762 total frames processed (3,036 padded, 3,726 unpadded). Bitrate is constant.


From MP3Utilty readme.txt

4) "Ignore warnings/errors in last 1% of file". The real problem here is that a lot of people are tacking on all kinds of junk to the end of mp3 files and I haven't figured out a way to intelligently parse through all the tags and combinations of tags (not to mention corrupted tags) that I have come across. In addition, there seems to be a popular encoder out there that produces mp3 files with a truncated last audio frame (is this in the spec somewhere?). I also suspect that some of the multitude of mp3 tagging utilities available are causing corruption as well. Most importantly, I have found that in almost every case, errors detected in the last 1% of the file can be safely ignored as they in no way impact audio playback. As such, I finally gave up trying to figure this out and simply put in the option to ignore errors in the last 1% of the file. However, I do suggest (at a minimum) that you always listen to first few seconds and last few seconds of any mp3 file (even after testing shows it as ok). This is because there is no way for MP3Utility to tell if the beginning or end of a file has been lost due to a partial download or other error.

In any case, I have given users the ability to turn off the "Ignore warnings/errors in last 1% of file" if they don't like it (but expect a lot of additional files to show up with warnings/errors). BE ESPECIALLY CAREFUL IF YOU TURN THIS OPTION OFF AND YOU ARE USING THE "MOVE FILES" FEATURE OF MP3UTILITY AS IT IS LIKELY MP3UTILITY WILL FLAG 30-40% OF YOUR FILES AS CORRUPTED AND THEN MOVE THEM TO THE "CORRUPTED FILE" DIRECTORY.
___________________________________________________________

EncSpot reports this file as poor quality and corrupt.
Encoder = Blade (one of the worst possible, hasn't been updated for over 2 years)
Last Frame Cut short = yes
Xing Header = No

[jreg]

DJEgg,
What about this file then: http://www.regnstrom.com/mp3db/play.asp?150 It is perfectly correctly encoded (MP3Utility reports no errors) and yet Winamp refuse to show the ID3v2 tag. It detects that it's 255 bytes, but shows the filename (play.asp?150) instead of the actual tag information.

[DJ Egg]

I dunno, maybe Winamp detected it as being A Wham track and puked on it? :p :D

j/k

No, but seriously . . . that url points to an asp file, not directly to an mp3.
So, 1: I've got no way of testing the actual mp3

[jreg]

DJEgg,
It's the same whether I stream it directly as a mp3 file or via the ASP page. What the ASP page does is just to pick up the binary mp3 file, set the mime type to audio/mp3 and send it back to Winamp. I've also tried audio/mpeg, audio/x-mp3 and audio/x-mpeg but it's the same. It's equal to streaming it as a direct file. I have another ASP file which generates a m3u file and as "matthewlmcclure" posted earlier, Winamp reads the file and shows the right tag info in the playlist until the song is actually played. Then it just shows the filename, i.e. "play.asp". If I play the same mp3 file from the local disk it shows the tag info, it's only when you stream with http that this occurs.

The tag info shows correctly if I play the stream with Windows Media Player 9, so the issue is still Winamp ignoring to show the ID3v2 info.

[DJ Egg]

realizationOk, I take it all back. :o

Yes! I've just been experimenting, and you're all definitely right.
Something's definitely gone wrong with the current version of in_mp3.dll

Now, I don't know if this is as a result of the recent Dec 18th security fix,
but Winamp 2.81 is NOT reading ID3v2 tags for any mp3 streams whatsoever.
(Shoutcast radio stations not inclusive, because they use ICY headers).

Tested with various encoders.

Here's one encoded with FhG (L3Enc):
http://[dead_link]/Helios_Creed_-_Bursting_Through_The_Van_Allen_Belt_-_04_-_Alien_Lady.mp3 (112kbps)

All that's in the ID3v2 tag for this mp3 is artist - title:
Helios Creed - Alien Lady

And lo and behold, here's one encoded with Lame 3.92 (CDex)
http://[dead_link]/A_Reminiscent_Drive_-_Flame_One_EP_-_02_-_Leg_show.mp3 (160kbps)

ID3v2 tag is:
Artist: A Reminiscent Drive
Title: Leg Show
Album: Flame One E.P.
Track #: 02
Year: 1996
Genre: Ambient

If you can get any of that to show up in the stream title (by changing title formatting accordingly in in_mp3 config) then you're a better man than me ;)
All I get is the filename, every time!

I also tested streaming mp3's encoded with Xing (new & old), Gogo, FhG (fastenc), and Lame 3.89 (alpha & beta), and in all cases Winamp 2.81 ignored the ID3v2 tag and only displayed the filename.

WMP v8 displayed the ID3v2 tags correctly, and for every file tested!

I now declare this "bug" confirmed & reproduced!

Though maybe it isn't a bug as such, just an unimplemented feature ?!


Comments, thoughts, suggestions welcome.
Over to you Justin.

I'm making this thread a sticky!

Note: those two url's will only be available for somewhere between 24 and 48 hours, then I'm taking them down . . . before the web provider goes postal.

[Lion King]

quick test with older in_mp3 2.72b: it also displays only the filename

so it isn't the security fix's fault

DJEgg: shoutcast and co. don't use id3v2 for title streaming, they add it to the http header: http://forums.radiotoolbox.com/viewtopic.php?t=74

similar discussion: http://forums.winamp.com/showthread.php?threadid=103370

[DJ Egg]

Hmm . . . so are you saying it's always been this way with Winamp? :weird:
If so, I don't remember it. I'm almost certain it used to display the tags . . . or has history been rewritten or something? ;)

Note how earlier in this thread (Nov 2001) I state:
all other streams (whether an m3u or pls playlist, or straight mp3) display the ID3v2 tags perfectly ok for me


I'm aware of using icy-name headers for shoutcast streams and the like, but didn't know it was necessary (in Winamp only, it would seem) for standard mp3 streams as well.

So, either this is by design, in which case it's not a bug, it's a feature / missing feature . . . or something's changed in the code in the past year or two, and it is a bug...


The plot thickens . . .

Someone help me out here . . . please!
Justin?

[Captain Chaos]

> I now declare this bug confirmed & reproduced!

Wow, and only one and a half years after I reported it! ;-)

[DJ Egg]

LOL :D

Actually, I couldn't reproduce it back then, but I can now!

Cheers! :)

(or should that read "sorry" instead?) :o



Actually, I didn't have the means (adsl & webspace) to run the same tests back then, but seeing no-one else from the forums/dev-team came here to confirm anything . . . :rolleyes:

[jreg]

I think this bug easily could go "unnoticed" since, if (as I think most people have) the mp3 is named as "artist - title.mp3" and such, it appears as Winamp shows the "right" information - when it mearly "decodes" the filename, not the ID3v2 tag itself. But it becomes obvious if you have another naming convention or stream the file from a script, such as ASP or Perl.

Good thing the bug is under the microscope these days... :D

[jreg]

Today Winamp 2.90 was released. And of course I checked if the http streaming ID3v2 tag is displayed correctly...but no.
:( :mad: :cry: :hang: :confused:
Wonder how long it would take before Winamp 2 will go from reading and analyzing the tag to actually displaying it also?

[jreg]

Winamp 2.91 is out - still no ID3v2 http streaming fix... :(

[DJ Egg]

And this thread will remain a sticky until it is fixed....

[jcortina]

Encountered the problem detailed and found this thread while searching for information about it.

I had only recently installed Winamp and I know artist/title was showing for streams initially. But then I added a number of plug-ins.

One of those was the Thomson mp3PRO plug-in. And guess what? Disabling it brought back artist/title to display and playlist.

Note that the Thomson plug-in will process the mp3 info through its own dll, so it doesn't seem to be a problem with in_mp3 (and it explains how DJEgg developed the problem midway through this thread if he installed that plug-in or similar).

So, if you have that plug-in (or another which will pre/post process mp3 info) you might want to try disabling/removing it to confirm this.

[DJ Egg]

Hi

No, I don't use mp3pro or any other 3rd-party mp3 input plugin.
I've only ever used the Nullsoft in_mp3.dll

Shoutcast stream titles display perfectly ok,
because they are handled by icy headers.
(though this would also be broken if you installed the mp3pro plugin)

It's only direct mp3 streams where the problem occurs.
Try it. Upload an mp3 with an ID3 v2 tag to some webspace,
then stream it in Winamp.

Make sure the filename is different to the "artist - title" tags
eg.
Filename = aerials.mp3
Artist id3v2 tag = System of a Down
Title id3v2 tag = Aerials

Playlist will only display:
aerials





I'm beginning to think that this has got something to do with the prevention of any harmful code being executed by id3v2 artist/album/comment/url tags.
Therefore, unless a workaround can be implemented, I doubt if this will ever get fixed.

[Arioch]

IMHO it may be realted to streaming.

At my experience ID3 tags may lay at both start and end of file, more so - a number of programs prefer last when they insert id3 tag into tag-less mp3.

IMHO in such a case there may be 2 kinds of mp2 file layouts:

[header][id3][music frames]
[header][music frames][id3]

In the latest tag would be ignored, since winamp do not support downloading portions of file.

[Lion King]

winamp supports only id3v2.3 which doesn't, unlike id3v2.4, allow the tag data to be at the end of the file

the id3v1.x tags can't be displayed because they are always at the end of the file

id3v2 was designed to be located at the beginning of the file with streaming in mind

[Bernt]

Ah! What's why the Cover & Tag plugin don't work for me. I'm also streaming m3u lists over http (using Netjuke http://www.netjuke.org).
Is there a fix for it yet?
Don't want to go back to WMP9.

[IceBerg]

I am having a similar problem.

I am writing a streaming jukebox in php. The ID3 tags are working with everything but winamp. I would be happy to let someone who knows a bit about streaming and ID3's to have a look but I wont post the link since it's still in development and not secure. If I am doing something wrong that CAN be corrected WITHOUT SECURITY issues I would like to so that it is fuly functional. Right now I have tested the ID3 with the following software and it works fine with my current code.

Windows Media Player 9 (windows)
XMMS (Solaris)
XMMS (IRIX)

If you think you can help please drop me an email or a private message.

iceberg@techropolis.com

[Dazog]

Does it happen in Winamp 5?

Cause asfar as I know Support for 2.xx is dead once winamp 5 comes out

5 will replace 2 and thus no more updates will come to 2.

[IceBerg]

Is there a beta of 5 available? I was only aware of 2.9 and 3.0 available for download.

[Sawg]

http://forums.winamp.com/showthread.php?s=&threadid=156829

[IceBerg]

Well it seems to be getting the ID3v2 tag but not displaying it. I installed 5 after removinb 2.9. When I pull up fie info this is what I get:

Network received: 2041386 bytes
Server: Apache/1.3.28 Ben-SSL/1.52 (Unix) mod_perl/1.28 PHP/4.2.3
ID3v2 tag: 1607 bytes
Stream name: nofiles.mp3
Content length: 11102208 bytes

[DJ Egg]

No. Streaming ID3v2 support is still broken / not implemented in Winamp 5.0

And, as stated previously, this thread will remain a sticky until this changes.

[IceBerg]

So is ID3v1 depricated now or does it also not work? Im unclear on that. I have ID3v1 streams that also do not show info. Is it safe to (for the moment) asume my code is of if Windows Media Player reads the ID3 data?

wow 5 is sweet!

[Sawg]

ID3v1 tags are at the end, therefore cannot be read on a streaming files. This is why ID3v2 puts them at the front.

[DJ Egg]

Okay, I lied . . . lol :D

Am now unstickying this thread
and linking to it from two other sticky threads instead:

Known Bugs (http://forums.winamp.com/showthread.php?s=&threadid=156839) thread in Winamp Bug Reports forum
Official 5.x Wishlist (http://forums.winamp.com/showthread.php?s=&threadid=64975) in Winamp 5 Wishlist forum

[airbedman]

Anyone had any info or updates of when this feature is going to be implemented?

[IceBerg]

To my knowledge this has not changed and probably never will based on how shitty the released version of WA5 worked. I gave up on WA, WMP seems to handle everything you throw at it WITHOUT CRASHING!!! Best bet is to never ever again use any winamp product, since the 1.x releases this product has gone downhill and continues to do so, I dont think they care about it anymore. Winamp use to be the standard for mp3 players, now it's not worthy of a second thought, not to mention it isnt even free anymore. That in mind I REALLY expect more, but I am sure it will never happen. For the mostpart winamp is on it's way to the gravbe unless something drastic happens.

[DJ Egg]

hmm, troll alert

[DJ Egg]

5 years later, and...


Winamp 5.3 whatsnew

* Improved: [in_mp3] streaming id3v2 support


Fixed at last! :):up:

[Koopa]

5 years later, and...
Good features need a loooong testing phase. :p

[km42]

I am still not able to get winamp to show the information in the ID3v2 tag when streamping mp3-files using the HTTP protocol.

I am using the newest version of winamp (5.31).
I tried looking through all the settings in in_mp3, without success.

Has anyone succeeded getting the information? I want it mainly for plugins like audioscrobbler (for last.fm) and leoslyrics, but they seem to depend on the id3-tags. Is there any way to get around this problem?

km42

[DJ Egg]

As long as you're using the latest in_mp3.dll (v4.02) and no 3rd-party mp3 plugin (in_mp3pro, in_mad, in_mpg123) then ID3v2 tag support works just fine for mp3 file streams.

It also depends on what your Advanced Title Format string is in: Winamp > Prefs > Titles (eg. if it's set to just show filename, then it will also just show filename for streamed mp3's). And of course, the streamed mp3's naturally need to have ID3v2 tags for them to show (ie. ID3v1 / Lyrics3 / APEv2 tags will not show, only ID3v2).

I have no idea about the 3rd-party audioscrobbler and leoslyrics plugins though.

[km42]

You are right, the title is indeed generated from the information in the id3-tag. The "view file info" option only shows information about the stream itself, not the id3 tag, as it does with local files... Is this how it should be?

How is the id3 information usually transmitted to third party plugins? Obviously third party plugins don't get this information as it is now. Should this be fixed in winamp
or in third-party plugins?

km42

[DJ Egg]

As far as I know, it's a 3rd-party plugin thing, and you'll need to contact the author(s) of said plugin(s).

[jreg]

I don't know how you managed DJ Egg, but I can't get the ID3v2 tag to show up. I have the latest WinAmp 5.31 Lite (in_mp3.dll 4.02) with all default settings (incl. Advanced Title Format) and no 3rd party plug-ins - still the URL shows up, not the tag info. All my files have a ID3v2 tag, so that's not the problem. Also, it does show up in Windows Media Player. :hang:

[Koopa]

Works fine here. Can you provide any example link?

[DJ Egg]

That's because you're using/linking to an active server script (aspx) instead of directly to the mp3 files. Try streaming the actual mp3 url and then you'll see the id3v2 tags.

[jreg]

Well, that shouldn't matter. Regardless if WinAmp opens the URL to the file located on a web server or a script that reads the file (from elsewhere) and sends the file data, it's the exact same bit stream that reaches WinAmp.

Somehow, if the URL doesn't have a .mp3 extension, WinAmp ignores to show the tag info. From the previously attached picture it clearly shows that WinAmp does see & read the ID3v2 tag, since it detects that it's 241 bytes, it just ignores to show it. And as I wrote before, if I load the same URL (with the script) in WMP, it works. I'd say this bug/feature isn't fully working yet.

Update:
I put a test file on my web server, and opened the full URL in WinAmp, e.g. http://www.mysite.com/test/file.mp3 and the file plays and the tag shows. Then I set the default document in the web server to be "file.mp3" and load the URL http://www.mysite.com/test/ into WinAmp. The file plays but the the tag doesn't show, only the URL. This although the file is still in the same place on the web server, no script involved. Clearly, WinAmp ignores the tag if the URL doesn't include ".mp3".

[DJ Egg]

Correct. I'll see if there's anything that can be done about it.

[jreg]

Great!
I hope the rest of the bug doesn't take another 5 years to fix. ;)

[DJ Egg]

@ jreg

The previously provided link (ie. the one in your screenshot) is no longer working. You'll need to provide us withy a working link for testing purposes. PM (http://forums.winamp.com/private.php?s=&action=newmessage&userid=1684) it to me if you want to keep it private.

[DJ Egg]

@ jreg

Can you confirm whether the ID3v2 titles show if you add ;ASPX to the Extension List in in_mp3 config?

[ujay]

Here's a set of files I prepared earlier :)
I've added a .jnk file and one without extension to confirm that ID3 is read only if in_mp3 is used explicitly and not by default.
Also confirms that adding ;JNK to in_mp3 will find the tags.

Rename attached to .m3u

UJ

[DJ Egg]

Yup. Basically the ATF engine doesn't see/use the 'assume file extension of unknown files' setting in: Prefs > Playlist. I'll add this to the internal bugtracker....

[jreg]

I can confirm that adding ASPX to the extension list for the input plug-in (in_mp3.dll) does makes the ID3v2 info appear. Good job finding that one.:up: Still, you shouldn't need to edit any settings for this trivial thing to work, as it already does in WMP. Hoping for a fix soon...

[DJ Egg]

Yes, and as already stated, the fix will be to get Winamp's Advanced Title Formatting to recognize the 'assume file extension for unknown types = mp3' setting.


@ ujay
btw, for extensionless links you can add ?.mp3 to the end of the url, eg.
http://www.ujay.homechoice.co.uk/ejtsic12?.mp3

(or &.mp3 if there's already a '?' in the url)

[DJ Egg]

^

[ujay]

Thanks Egg, that was one of the old tricks getting wma files to stream wasn't it, never thought to use it for mp3 :)

UJ

[ollo]

Nope. Doesn't work for me...

Prefs->Playlist is set to default (mp3), my stream is audio/mpeg, filename is 'http://some/stuff/file_id.mp3?sid=adfafafasdasddasasd' (session id is needed), also doesn't work if i append '&.mp3' to the end of url...

Any ideas?