Winamp 5.57 by Hotcakes at 3:49 AM EST on December 20, 2009
Am I the only one having trouble with vgmstream and Winamp 5.57? It is no longer showing up in the plugins list. I reinstalled a fresh copy of Winamp instead of installing over the old directory, to no avail. the libvorbis.dll and libmpeg12whatever.dll is in the Winamp directory. Also having trouble with another plugin that is very old (in_med.dll), but not with another (in_sk00l.dll).
Has anyone else upgraded to 5.57?
EDIT: Should mention I have also tried the most recent vgmstream I could find, 721.
I have, like I said I reinstalled Winamp from scratch and so had to replace the dlls manually. I'm also having other issues with Winamp such as the mod player no longer being able to play 8 bit samples, but I seem to be the only person with these strange issues. *sighs*
So with all these troubles and issues, have you considered going back to WA5.56 (or a good known working install) sounds to me WA.5.57 it's not worth the trouble yet, and this is no linux kernel, this is a win32 app haha.
I don't plan to touch anything in my my winamp setup until I read something major (eg In_mod.dll fixed to use inbass or very critical inflac/inmp3/inmp4 fixes be it security or not and even then I'd first try to get the dll alone rather than the entire executable)
Been reading too much issues with 5.57 specially in 'our field'
...At least it sorta fixed Maxim's VGM plugin, and I've only seen one MOD file crash the native plugin. I've not seen anything else wrong with it. Yet. (Meaning PLEASE tell me what's wrong with the .001 increase in version number?)
Installing Winamp 5.57 or 5.571 with Modern Skins support = VGMStream and MGME not being initialized by Winamp. Not installing that feature results in both plugins working fine and dandy.
Also it crashes whenever exiting Winamp after viewing the configuration options for Modern Skins.
Can it handle/emulate Winamp in/ouput plugins and the modern skin support?
Failing that, can it play MED mods, cross fade similarly to the Sqrsoft Advanced Crossfader (out_sqr) and look pretty (need all features of Big Bento as a minimum now)?
Not being a smart arse; if it can actually replace Winamp to full extent then I will happily abandon it. It's become the Windows of media players...
Hotcakes: Winamp input plugins yes, DSP plugins yes, outputs aren't needed since it has it's own writer system. Skins as well, since there's shitload of custom XMPlay skins.
MED sure (and 160+ other Amiga formats), with the Delix plugin.
Truth to be told, I've made the jump at around 2.30, so can't compare to newer Winamp versions, but never felt the need to go back.
Well, 5.71 fixed .mod etc 8 bit playback... but all plugins that use external dlls still fail to load. Hopefully this one will fix that (but I doubt it).
man this delix plugin in xmplay doesn't play all the formats deliplayer does. :( or doesn't SEEM to. i was hoping i wouldn't have to reinstall deli. i hate it.
Lunar: It should play everything except for DigiBooster Pro IIRC. What format are you referring to? Some require adding replayers to the xmp-delix.dat archive.
Seriously, it seems that the Winamp installer screws up the existing dlls somehow. So copy the fresh ones over the existing ones. will have a look into it over the next few days as i'm wondering if the optimiser (is meant to re-base the official dlls for a loading time improvement) is messing with something but need to check it out properly.
and unfortunately 5.57x was a messed up release but 5.572 seems to have been better in general (unfortunately not for emu related areas it seems).
Yeah, it looks like it's rebasing our dlls as well. I don't know enough about Windows linking to know why this would cause it to fail loading vgmstream, but that seems to be the issue. Is it just running on every dll in the Winamp dir?
Hotcakes, it doesn't seem like it touches in_vgmstream.dll at all, or libvorbis.dll from what I've heard, just the libmpg123-0.dll. And Dr0 is going to look into it when he gets the chance. In the meantime there's an easy workaround.
hcs: that's the feeling i've got maybe happening but i need to get my hands on some more of the build system to be able to check that.
Hotcakes: it's never done intentionally to cause breakages, etc but unfortunately it can and does happen in particular with plug-ins that are still designed in the 2.x style instead of being better designed really for a 5.5+ style (so all unicode & newer api compatible).
in most cases it's generally issues in the external plug-ins (not helped that documentation is dire for large parts of plug-in integration) which are shown up by the changes in the client itself (like the change in compile has caused for some plug-ins).
and it's not helped that i've not been active around here for sometime to keep up-to-date with issues (like the v5.51 spectrum vis incompatibility crash which was caught from this forum/irc) as often an issue posted over here will be something many more are experiencing but aren't properly reporting.
either way i'll post back once i've had a chance to check things out and see what the issue is and see if a resolution can be done for the future.
I posted about plugins not working right before, maybe you can prioritize it or something? It's been some time since that post of mine.
----------
Update (5.57 & 5.571 fresh installs):
Installing/updating with "Modern Skin" support selected during the install process, renders VGMStream and MGME input plugins not initializing. Reinstalling without "Modern Skin" support results in the 2 mentioned plugins working fine and dandy.
This is with the plugins and the dll files they depend on, already installed before installing or updating Winamp.
Franpa: that's the first time i've seen your post and no idea why it wasn't looked into (would have been done if i'd seen it).
i've just installed vgmstream and was getting a crash, loaded up a debug winamp.exe and the crash disappeared so not sure what that was (will have to try again).
have re-run the installer on an install with in_vgmstream present and the supporting dlls and the dll rebaser is handling all of the dll as i thought. from working through things, the issue is coming from the rebasing of libmpg123-0.dll. as a workaround, changing libmpg123-0.dll to read-only makes the rebaser ignore the dll though will look into it closer to see why it is happening but at least there's a workaround for the moment.
is there a current link for in_mgme.dll as the one provided isn't working for me.
Also, sometimes when I run Winamp under Windows 7 Home Premium x64, a UAC prompt appears (probably because of MGME?) however the UAC prompt is never given focus. It appears on the Taskbar and flashes and I have to click it to bring it to focus.
Some other times, I get 2 UAC prompts, one with a yellow banner and another with a blue banner, both 1 after the other.
and even still, there are times where there are no UAC prompts.
It's pretty strange. My account is a Admin one and UAC is at the default level.
well i've had a look at things more closely and the issue appears to come from the import table in the dll's internal structure being altered by the rebaser (is using the BindImageEx(..) api and is as such causing the loading issue.
however by using BIND_NO_BOUND_IMPORTS in the api call it appears to rebase the dll it ok without destroying the import table in libmpg123-0.dll & in_mgme.dll.
why it only affects these dlls is beyond me at the moment though i wonder if it's related to how the dlls have been compiled. either way there's the read-only workaround for the moment though will do what we can to patch the installer's rebaser tool which will hopefully be done in time for the next client release.
as for the UAC stuff (though i'm only just getting upto speed on when it's activated in Winamp), it should only be appearing when a registry access is required (often if the restore file associations option is enabled on loading) or when doing things via the File Types preference page or uninstalling a plugin. however the UAC handling as improved in the 5.572 client so it now works consistantly going on what i've seen personally (Vista+Win7 under admin and standard accounts).
The erratic UAC encounters probably do match up with the described situations, is there a way to get Winamp to detect when a plugin tries to write to a INI file in the Winamp or Plugin folder and prompt the user for UAC permission?
Otherwise MGME can't remember configuration after closing Winamp unless Winamp is run with admin permissions...
If you've got problematic plugins like that that you must have, install Winamp in portable mode (add no_registry=1 to winamp.ini) *outside of \Program Files\ (yes this part is important)*
BtEO: that's a poor method of fixing the issue and really plugin's should be using the correct api to get the directory for saving settings which has been available since 2.9x so there's no excuse for winamp plugins to be created without the correct level of compatability nowadays (or really for anytime in the last 6-7 years).
Franpa: basically in_mgme needs to be updated as above. there isn't a built-in api for detecting such an event as saving settings has always been down to the plugin to implement in a correct and sensible manner (maybe doing a foobar2000 option would make better sense but the relucatance of so many plugin's to be built to work properly under 5.x as it's horrible/evil/bloated/etc etc as i keep seeing from comments is no wonder there are the issues being experienced).
back to the original issue and unless i can figure out what is done differently with the compiles of in_mgme and libmpg123-0.dll, they'll just be black-listed from being rebased (though i'd prefer a method which automatically copes with such dlls as i've a feeling there are other cases out there).
Hmm, on the subject of Winamp 5.x, shitty old plug ins, compatibility and source, I wonder if someone could take a look at the source for the MED plug-in:
http://www.theess.com/med-soundstudio.html
I contacted the author who said they're not interested in Winamp or MED any more, so I'm boned. Basically it suffers from the re-basing issue (not a huge deal) and now I can't get it to play anything without crashing (worked pre-5.57). Then again, it was never a very good piece of code, even back in the 2.x days.
So to fix MGME I need to add a player specific hack. Wonderful..... Might as well go the whole bloody hog to support all of Winamp 5's extra functions, heh.
The Media Library decoder functions should be fairly easy, just one (well, two if you count ANSI/Unicode split) to create a decoder instance on a particular file, another to decode from a decoder instance, and then another to terminate it. I think there's a ReplayGain scanner that uses it. I haven't used 5.x recently, so I don't remember if there's also a handier file converter that also uses it.
Also, I think the reason there are separate ANSI and Unicode builds of some plug-ins is because the damn thing defaults to the ANSI functions even if there are Unicode versions exported. They may have fixed that recently, but it's probably worth testing anyway.
Hotcakes: i think that may help me work out what is different in the compile to cause the rebaser to fail.
mudlord: people do it for the foobar plug-ins so why not actually do it for the Winamp plug-ins as well and it's not like it's that difficult (only took a few hours to fix up 64th Note for all of the metadata api and getting it to follow the correct path for saving settings into).
plus using the correct api for saving settings which has been available since the 2.9x series isn't a player specific hack imho (is down to other loaders to ensure that it's offered correctly if they want to work properly).
kode54: the decoder api is used internally for the transcoding (which was sort of taken from the external version provided early on with the ml_ipod project).
as for the ansi/unicode thing, the unicode exports are meant to be the prefered option so if you can give an example where this isn't the case then i'll have a look and get it patched as applicable.
Dr0: Its very simple: XMPlay compatibility. Forgoing all the extra shit would mean I have to make *two* codebases solely because Winamp 5 is being a dickhead unlike foobar2000, which has quite a sane API.
wtf, if XMPlay is so good then why is it re-using Winamp plug-ins and not providing api compatability for something introduced 6 years ago in something that it's trying to replicate.
all i'm trying to do is offer suggestions to help improve the usability of the plug-in in the "dickhead" of a client but if that's the approach (which has been mirrored by other input plug-in authors) then i'll stop trying to help.
and with that response i cba to waste my own time fixing the rebaser when i don't have to - well done.
I ran into this problem, and I have vgmstream working on 5.572 (If someone else posted a fix, I missed it).
I backed up all my plugins that didn't come with winamp, moved the folder to desktop (in case I'd missed a DLL somewhere, and I actually had :P), and also deleted Winamp Detect from /program files/.
After that, I ran the 5.572 installer, copied back the plugins, used vgmstream_external_dlls.zip to replace libmpg and libvorbis, and restarted winamp 5.572.
GCC and MSVC have different defaults that are important when building DLLs. Things like default visibility of functions and even calling conventions. It's great fun to make a DLL that builds successfully on both, unfortunately.
Sorry to bump an old thread, but... by Camo Yoshi at 11:32 PM EST on February 26, 2010
I found that vgmstream r724 doesn't play nice with the MIB files Ford Racing 2 (PS2), r664 works perfect for me though.
Running WA 5.572, Modern Skins support installed, but not actually using a "modern" skin.
I second that, some people I know keep getting a "General Script Failure Error" with their Winamp's and for whatever reason, removing all 3rd party input plugins fixes everything..
I'm going to scream, then migrate to something else if my winamp fucks up seeing how I have a ton of plugins just to play all the music archived on this site.
Also I refuse to update Winamp anymore, I'm too paranoid that Nullsoft's going to fuck up shit even worse.
So, because they use some broken or outdated plugins for Winamp and these plugins cause Winamp to crash/fail, Winamp is at fault and must be blamed and criticized?
Nice logic there.
Also, maybe some of your 3rd party plugins don't work together very well?
Out of nowhere, be it either a Winamp update or even just sitting inactive for days, suddenly some of my friend's winamp refuses to work anymore giving a "Guru meditation error" flashing on the top of their screen. Why? I don't fucking know... but for whatever reason it's always some input plugin, of which I've been suggesting to my friends to play back .SPC, .MINIUSF, whatever, and it's been working fine for me for years... Then out of nowhere it stops working for them.. so I put the blame on Nullsoft for changing something on Winamp 5 that probably shouldn't have been touched, because it would break compatibility with all plugins that I've been keeping up to date as much as I can.
I don't even keep Winamp up to date anymore until a plugin I'm keeping up to date with deems it necessary to update.. since I don't want anything to go screwy.
The problems are probably mostly with poorly written plugins, but the best a user can do is stick with what works (generally an older Winamp). Not everyone can spend as much on backwards compatibility and 3rd party software testing as Microsoft.
There are some plugins I use that aren't even updated anymore. (AdPlug being a example since the last known version for Winamp was 1.8... and it does NOT have OPL3 support at all, and the new DosBOX DRO format is unplayable in AdPlug, as far as I've tested...)
Speaking of Winamp, does anyone know if I can get Winamp3's skin working in Winamp 5 as a "Classic skin"? Since I miss Winamp3's look so damn much now....
@Kaminari: daft comment. Seriously. You -do- know that if the Modern Skins support crashes it throws an Amiga-styled Guru Meditation, right?
"does anyone know if I can get Winamp3's skin working in Winamp 5 as a "Classic skin"?" No, but doesn't the "Winamp Modern" skin look essentially the same? It's been a long time since I ran WA3 obviously but I thought that's where that skin came from.
@Hotcakes No actually, Winamp3's skin as far as I remembered look liked Winamp Classic, only not horribly odd looking, and having a better overall layout and appearance that grew on me.
If I still had my copy of Winamp3 (which was YEARS ago when I still had my Dell before my father comendeered it due to his Medion crashing for reasons unknown to me...) I'd show a screenshot.
I did a Google image search for "Winamp3", and found this, which, at first glance, looks just like Winamp Classic. But you're right, there are a few small differences. Perhaps this is what you're looking for? I haven't downloaded it, or tried it, but as near as I can tell, it should be pretty close to what you're looking for. Hope that helps. Mouser X over and out.
The skin is indeed, Winamp3, but Winamp3 had a darker toned version of this that was selectable as a option I don't even remember now, and this classic skin doesn't appear to have the option to make it that certain tone that I like.
I've known about the "Guru mediation error" ever since reading about it on wikipedia (OH NO!!!!!!!!!!!!!!!!!!!), and I have no idea why Modern Skin Support would be so pissy and unstable.. I don't even make us of it either, I've been perfectly fine with Winamp3's default skin and glad to have it in Winamp5 at long last, thanks to Mouser X's search.
@Kaminari: apparently he did. Besides which -he- brought it up...
@Rukario: The Modern Skins use some blend of Nullsofts Java-like language they invented 'for' Winamp 3 - everything Winamp 3 did used the language but it proved to be slow and unstable, hence the whole build was dropped and they went back to Winamp 2 + Modern Skins support, the only thing they kept from Winamp 3 (well, as far as the end user is concerned anyway).
Since then, code stability does not appear to be something Nullsoft have had in mind... I swear it's just gone downhill since.
The one thing Winamp3 was godly at, was playing back WAV and MP3's FAR better than Winamp5 ever could do.
And by that I mean, the output wasn't bugged or fucked up in any way, and the visualizations never fucked over if the output was Unsigned instead of Signed. (As in Unsigned 8-bit, Signed 8-bit visualizes just fine, Unsigned 8-bit is TOTALLY fucked up..)
Oh and one fundamental aspect, Winamp3 could actually play back MP3's that have a RIFF header instead of what's normally expected for MPEG-3, see games like Freelancer, and a few others, Aliens vs Predators 2 as well.
I'm fairly certain the general consensus is to make a backup of all the DLLs in your Winamp directory, then install Winamp, and replace the DLLs that you need. Winamp's installer "rebases" the DLLs (IIRC), which makes then incompatible with the plugins that need those DLLs.
I installed Winamp 5.5+ (I'm pretty sure there was a 7 and a 2 in there, but I don't remember *exactly* which one it was) into its own directory, and then moved/copied all the "old" stuff back in, as I saw fit. If I know it comes with the Winamp installer by default, I left it. Otherwise, I used the versions from my previous install. Annoyingly, this has posed a few problems, most of which are unimportant (If I attempt to rip a CD with Winamp, Winamp crashes).
Also, I think I'll remove the Media Library. It seems to cause issues with the title/tag display in the playlist. I think this is related to a combination of the Media Library, and having "Advanced Title Support" (or whatever it's called) disabled.
As for the buffering issue mentioned above, Winamp plays 1-2 second files just fine for me, so long as they are not the file I play first (they have to be in the playlist, and Winamp has to reach them as it goes through the playlist). I have my buffer settings at 5-10 seconds. Something really high. It makes the gap between songs much, much less (almost my entire library is accessed from within some kind of archive. I use in_zip a lot).
Honestly, perhaps I'm blind, but I can't think of any serious complaints I have with Winamp. In almost all instances that it's crashed, I've known the reason for it (usually it's my own fault. Often, however, it's crappy plugin. Most recent offender: in_skool/in_oldskool. It plays a ton of Amiga formats. When Knurek posted the Amiga Archive, I installed in_skool to see if it could play them. It plays most of them, but crashes if you attempt to do anything else...). Though, recently, I haven't used Winamp as much as I used to, and I only very recently upgraded to 5.5+ (I was using 5.5<something> previously). Maybe I'm just lucky, for once (odd though that may be). Mouser X over and out.
well, this is a "fresh" system (or close enough), and I ended up installing 5.572, then the plugins...if I'm reading what you wrote correctly, the fix only works if I have DLLs around from a previous Winamp installation?
@Dais! The fix is due to an issue that occurs when either installing Winamp, or running it for the first time (something it does to my mingw32-built dlls). If it still doesn't work for you in 5.572, try installing the fresh dlls (from this site) again. I haven't tested any of this myself, though.
You're welcome! However, looping will have a snag in it due to Winamp's idiocy in stopping the output instead of continuing it, ignoring the end, and seamlessly going back to the start of file when repeat is enabled, their shitfix for that is the "buffer ahead on track change".
If you look CLOSELY in Winamp.ini you can see that the variable for this setting has the word "hack" in it, so yeah, it's just a shitfix that ends up breaking something else along the way...
It's best to keep the buffer as low as you can get it, otherwise, you'll have to deal with serious sound lag in EQ\DSP setting changes (obvious), BUT, also the memory\device viewer in NEZPlug++ and other things...
Well their 'shitfix' is necessary for mp3s due to mp3s being a shitty format. It doesn't pertain to other formats most likely, but Winamp has always been primarily focused on mp3s.
mp3s always have a short gap at the beginning and end of 'em. When you loop it, it is very noticeable. To avoid it you need to wither do some 'correction' in the way of stripping out the silence, or implementing a buffer and db monitor which is obviously a much more beneficial route to take because it open up the way for simple cross-fading for those that like that.