Recent Posts

Pages: [1] 2 3 ... 10
I actually use the plugin in every one of these 3 players (yes i keep them all arouind, Winamp and XMPlay are for fast previews, because Foobar is too playlist-oriented for that to be convenient) and i never had issues with the Winamp one (FWIW i use it with WA v2.91)
Help and Questions / Re: Winamp fails to load in_openmpt
« Last post by manx on Yesterday at 19:45:57 »
Thanks for the report.
Looks like the documentation was wrong for 0.4 and 0.5. openmpt-mpg123.dll must be placed into the Winamp folder (not the Winamp/Plugins folder as claimed by documentation), in addition to in_openmpt.dll in the Winamp/Plugins directory.

So, yes, probably very few users of in_openmpt.dll. It is not considered dead (yet) though. However, I guess most users use either XMPlay with xmp-openmpt, or foobar2000 with foo_openmpt or foo_openmpt54 (later one is recommended). Also note that newer Winamp flavours already ship either: a rather old and modified in_openmpt.dll (renamed to in_mod.dll) in Winamp 5.8, or a modern and modified in_openmpt.dll (renamed in in_mod.dll) in WACUP.

As a matter of fact, probably as soon as verbatim Winamp (as opposed to WACUP) also starts shipping modern in_openmpt (and updates it regularly), there would probably no reason for us to continue in_openmpt. Until then, it continues to exist, albeit with close to no development effort (as we would rather prefer the Winamp and/or WACUP developers to take over maintainership).

Documentation fixed as of and .
Works for me with Winamp 5.666 on Windows 8.1 Pro, and Winamp 5.666 on Windows XP Pro.

Help and Questions / Re: Winamp fails to load in_openmpt
« Last post by xoft on Yesterday at 19:38:30 »
Ah, found this issue:
And it provided a solution, although inverse. The documentation says "place both in_openmpt.dll and openmpt-mpg123.dll to the Winamp's Plugins folder". For me, this was wrong, placing openmpt-mpg123.dll next to winamp.exe fixed the problem, the plugin now loads correctly.
Help and Questions / Winamp fails to load in_openmpt [Solved]
« Last post by xoft on Yesterday at 19:13:32 »

I've just tried to use the in_openmpt.dll plugin for Winamp, and for unknown reason it fails to load. Is the plugin actually used by someone, or is it long-dead? Am I the only one with the problem, or do other people see similar behavior?

Unfortunately I can't seem to find any debug info from Winamp, so there's only very little info I can add to this report. I tried loading Winamp in MSVC, it doesn't output any debug information (OutputDebugString()), but at least MSVC shows module loads and unloads, I get this:

'winamp.exe' (Win32): Loaded 'C:\Program Files (x86)\Winamp\Plugins\in_openmpt.dll'. Cannot find or open the PDB file.
'winamp.exe' (Win32): Loaded 'C:\Windows\SysWOW64\oleacc.dll'. Symbols loaded.
'winamp.exe' (Win32): Unloaded 'C:\Program Files (x86)\Winamp\Plugins\in_openmpt.dll'
'winamp.exe' (Win32): Unloaded 'C:\Windows\SysWOW64\oleacc.dll'

So it seems it loads the plugin, decides for some reason it doesn't like it, and unloads it again.

I'm on Windows 8.1N Pro 64-bit, Winamp 5.621 (I know there's a newer one, but "if it ain't broke, don't fix it").

I'll try compiling in_openmpt.dll for myself to see what's going on, I just want to know if I missed something obvious.
The files posted in this thread and also in that bug report are now all detected as UNMO3-ed files.
If you do end up updating that special case, it would possibly be safer to just say unmo3 rather than trying to guess the version, unmo3 1.x also wrote 0s, as demonstrated by this disk.
On first sight it does indeed seem like the file from bug report linked above was uncompressed with the same (or similarly old) UNMO3 version. The sample frequencies are all a couple of Hz off compared to the 8-bit version, which is a big hint that this IT file used to be an MO3 file (early MO3 format revisions didn't allow for the sample frequency in IT files to be stored accurately, it was an approximation similar to XM). I will have a more thorough look later or tomorrow, but I'm relatively certain that your observation is spot-on, and we can update our special case for v0.00 files to say UNMO3 instead of Unknown.
Thanks for the heads up... It would've been shocking if I actually had gotten it right... :nuts: Oh well.
Sorry, LPChip, but you are completely missing the point here ???

This has nothing to do with IT sample compression, or with MO3 sample compression (which does not even exist in IT files, but is native to MO3 files). The problem concerns the tracker that OpenMPT detects as having saved the IT file in question. It gets detected as unkown, if this particular old version of unmo3 wrote the IT file (decompressing it from a MO3 file).
This is a wild guess here, and Saga Musix is probably gonna shoot me for this, so take this with a grain of salt (unless I got it spot on, then yay!)

If I remember correctly, IT file does have compression but not using the MO3 format, and that was added later. I wouldn't be surprised if this bit is set for backwards compatibility.
Pages: [1] 2 3 ... 10