Hello! ^_^ Here's the nice news for everybody who wanted to use ModPlug's engine as replacement of "native" in_mod.dll based on outdated and buggy MikMod's engine: I've asked my fellow coder w8m to make a wrapper for libmodplug, so here it is.
(http://wks.arai-kibou.ru/download/soft/modplug/modplug.png)
Win32 builds: http://wks.arai-kibou.ru/soft.php#modplug
GitHub Repository: https://github.com/dsp2003/in_modplug/
Current version: 0.2b x86 | libmodplug v0.8.8.2
All file formats supported by libmodplug (except for MIDI files) are playable. The plugin is also capable of mo3 playback (if unmo3.dll is present in the Winamp's plugin directory).
Notice though those are my own builds with several minor tweaks, so they are slightly differ from the w8m's "vanilla" version (which is no longer in development).
There's no configuration dialog implemented yet, so please use in_modplug.ini to configure. The song dialog, on the other hand, is implemented and working well. ^_~
P.S. Due to obvious reasons, this plugin is incompatible with in_mod.dll, so please remove it from the Winamp plugins directory before installing in_modplug.dll.
P.P.S. No VST or DirectX effect support, sorry.
P.P.P.S. This plugin is no longer in development, thanks to nearly zero feedback and lack of interest.
Including support of vst's?
Quote from: dsp2003 on June 13, 2011, 16:15:34outdated and buggy MikMod's engine
Well, libmodplug was probably not the best choice then, either...
Quote from: Rakib on June 13, 2011, 16:42:43Including support of vst's?
libmodplug never had support for VST plugins.
Jojo, sorry to dissapoint, but the Winamp's in_mod is based on heavely outdated MikMod (the version back from 1997th with minor bugfixes), so the 0.8.8.2 libmodplug is way better.
Just check how both engines are playing very tricky pieces like "A Synthetic Device" by Reed Richards (search it at ModArchive.org).
This plugin was made in our spare time, we've just done the thing for own enjoyment, so it might look rushed, yet about 97% of the existant songs are playing identically to OpenMPT.
Concerning "not the best choice", since you are current MPT maintainer, you can always write your own wrapper plugin "with Go and Geishas", if you want of course. ^_~
dsp2003, sure I know about the bad playback quality of in_mod, but that doesn't make libmodplug any better :) If I was still using Winamp, I'd rather long for an updated version of in_bass - or well, maybe in_openmpt. ;)
Jojo, again, why not BASS: the BASS itself is incompatible with Winamp's output system - the only implementation of in_bassmod I saw was merely a hack with zero configuration, very ugly playback with noticeable "dirty" sound, it crashed the application a lot, and wasn't even capable to display the Song information.
So, except for OpenMPT's engine, libmodplug is really the only simple and highest quality solution for module music playback available. ^_^
That's why I said I wanted an updated version of in_bass. ;) And I'm sure it could be done in a better way too, when using a decoding stream / device. It didn't crash when I used it, but it was enough reason to get a real audio player (http://www.un4seen.com/xmplay.html). ;)
And btw, I'm sure the other popular mod playback libraries (xmp, dumb, etc) would be equally easy to implement - don't get me wrong, I really appreciate your effort, I just say that libmodplug is far from perfect as well (but so is f.e. xmp...).
I also prefer xmplay over winamp with any in_ plugin. I just haven't seen a player to play modules better than xmplay does. It even has some hacks for older modplug tracker version's features, like basic directx plugin support.
To tell the truth, I liked the XMPlay too, up until the moment I've met some "tricky" files, which weren't normally playable - the way XMPlay/BASS handles volume control/normalisation and several effects is unacceptable.
There's also BeRoTracker's engine as input plugin available, which plays some files way better than XMPlay, yet again it's not configurable. ~_~
// ( Why do I get the feeling nobody actually cares about configuration thing at all?! >_< )
See, that's the great thing about XMPlay - you can store settings for each individual file (something you can't do with Winamp that way, and this is really a key feature of XMPlay for me). For example if you take brejle_a.xm from the BCC8 votedisk, the second part in it will sound distorted in XMPlay by default (because only one iteration of the module is used to determine the loudest peak) - but you can manually decrease the amplification and store it as a file setting, and it will sound correct forever. BeRoTracker has good module support but I think it doesn't support DNA settings in the IT format (at least the tracker itself doesn't) - something that will make many IT files sound wrong. And BTW, if you tell Ian about a bug in XMPlay, it will most likely get fixed within a day or two. ;)
...OKAY!!! After years of inactivity to this forum, I have something Winamp actually plays better than the ModPlug engine: This song, in OKT format (http://old.exotica.org.uk/tunes/archive/OKT-Oktalyzer/OKT.Dream.lha). Dream by Mohr! Play it in Winamp first, then play it in ModPlug and let me know how weird it sounds! ;D
(You think lack of a proper intro's the only symptom? Give the song until 45 seconds in, to see what I'm REALLY talking about! ;D)
P.S.: I found this song over 10 years ago, and I didn't notice this until a couple years later, I played it in DeliPlayer, then Winamp. The latter actually could pass for a DeliPlayer performance, the in_mod plugin's that good! (shuts up now)
P.P.S.: Forgive me for steering way offtopic...
Quote from: JFD62780 on August 02, 2011, 05:27:56then play it in ModPlug
...in exactly
which ModPlug product? OpenMPT has a completely rewritten Oktalyzer loader and plays the module correctly. ModPlug Tracker (which has been superseded by OpenMPT) doesn't play it correctly, but then again it hasn't been updated since 2003 (afterall it has been replaced by OpenMPT). libmodplug is developed independently from OpenMPT, so they do not share the same replay code. ModPlug != ModPlug.
I meant the Winamp plugin mentioned in the topic, of course, as well as the standalone ModPlug Player. Which hasn't been updated in YEARS, BTW! :P
...Would it be too much to ask for a brand new standalone OpenModPlug Player, in addition to your dream in_openmpt plugin? ;)
Quote from: JFD62780 on August 05, 2011, 23:09:37...Would it be too much to ask for a brand new standalone OpenModPlug Player
Yes. Seriously, why another player if there are already perfect players like XMPlay out there? If anything, I'd rather write xmp-libopenmpt, but even that's something I don't have time for.
Edit: Yay, here we go, 4,000 posts! :nuts:
Quote from: Jojo on June 13, 2011, 18:54:38
BeRoTracker has good module support but I think it doesn't support DNA settings in the IT format (at least the tracker itself doesn't) - something that will make many IT files sound wrong.
This issue is fixed now :)
This version of the plugin is useless if you want the complete list of mod playback.
You removed It's most useful feature!
OCTAMED playback !!!
I only use it in Winamp to play Octamed files, and to add other missing formats to XMPlayer.
This plugin is retarded (in a completely literal sense).
What's wrong with you? This plugin is very incomplete. It won't even play Digibooster DBM files.
Here is what the old version supports.
The following file types are supported in the current version:
- *.669: UNIS 669, 669 Composer modules.
- *.AMS: Velvet Studio AMS 1.x modules.
- *.AMF: Asylum / DSMI modules.
- *.DBM: DigiBooster Pro modules.
- *.DMF: X-Tracker modules.
- *.DSM: DSIK internal format modules.
- *.FAR: Farandole Composer modules (beta).
- *.IT: Impulse Tracker modules.
- *.MED: OctaMed modules.
- *.MDL: DigiTracker 1.x modules.
- *.MOD: ProTracker modules (4-32 channels, 15/31 samples).
- *.MOL: Module lists, compatible with MOD4WIN.
- *.MTM: MultiTracker modules.
- *.NST: NoiseTracker modules.
- *.OKT: OktaLyser modules.
- *.PSM: ProTracker Studio modules.
- *.PTM: PolyTracker modules.
- *.S3M: ScreamTracker III modules.
- *.STM: ScreamTracker II modules.
- *.ULT: UltraTracker modules.
- *.UMX: Musics from Unreal and Unreal Tournament
- *.WOW: Grave Composer modules.
- *.XM: FastTracker modules.
- *.WAV: Wave Files (smaller than 16MB).
- All the above when zipped (*.MDZ, *.S3Z, *.XMZ, *.ITZ, *.ZIP).
- All of the above then compressed with RAR (*.MDR, *.RAR)
- All of the above when compressed with LHA (Amiga archives)
Why get rid of all the useful extra formats?
I have gone back to the original, and again have full and complete access to all the mods I have.
I apologise for seeming harsh, but this plugin is worse than useless,which makes it worse than the original.
Quote from: Dr.Flay on February 23, 2012, 21:52:27
I only use it in Winamp to play Octamed files, and to add other missing formats to XMPlayer.
This plugin is retarded (in a completely literal sense).
Calling someone or something "retarded" is probably one of the most harsh and unfitting things you can do to hurt a person and it's hard to apologize for something like that, so stop acting like a pubescent kid and consider yourself warned. Also, a thing cannot be literally (http://theoatmeal.com/comics/literally) retarded.
QuoteWhat's wrong with you? This plugin is very incomplete. It won't even play Digibooster DBM files.
I checked the sourcecode of in_modplug.dll and it still contains all the player code for Oktamed / DigiBooster / etc. formats. I don't know how Winamp handles file type recognition, but if it merely does file extension checking, it probably implements one of the worst ways to check whether a file is actually supported. Line 595 in in_modplug's main.c should be changed from
"mo3;mod;stm;s3m;it;xm;mtm;ult;669;far;amf;okt;ptm\0Music Modules\0",to
"mo3;mod;stm;s3m;it;xm;mtm;ult;669;far;amf;okt;oct;ptm;dbm;ams;amf;dmf;dsm;med;mdl;nst;m15;psm;umx;wow\0Music Modules\0",Anyway, a good player shouldn't rely on file extensions, so this is really not the fault of the in_modplug coders but rather a misconception in Winamp.
Like I said I am sorry for seeming harsh (my programmers get nothing less), but I do not unfortunately use the word "retarded" lightly.
I do not mean it in the way that Americans seem to miss-use the word. I mean it in it's literal sense of backwards/regressive/retarded etc.
This plugin is a step backwards, not forwards. What else do you call that?
No matter how Winamp employs it's file recognition, this plugin is for Winamp, yet removes several useful formats, compared to it's predecessor.
Unfortunately we are not living in an Amiga world, where file extensions are unimportant, so the coders oversight there is completely to blame.
What OS is Winamp for? and what OS is most picky about extensions?
Luckily XMPlayer does not care about file extensions, so why when used with this plugin do I lose all the same formats that I lose from Winamp?
The plugin is the lowest common denominator here.
I suggest that it is broken/incomplete and gives less than you had before.
I have had programmers and designers dragged into the office for less (though obviously this is a free product, but the standard should be the same).
This is Beta or Alpha status and should be labelled as such, with a clear statement that using this plugin to fix certain issues comes at the cost of format support.
How many other formats this plugin will not play I do not know, as I put the old one back without much delay.
This will need testing and adding to the description.
Quote from: Dr.Flay on February 26, 2012, 23:18:30
What else do you call that?
A regression. You should know that term if you talk about "your programmers".
Quotethis plugin is for Winamp, yet removes several useful formats, compared to it's predecessor.
I am absolutely convinced that this was in no way intended by the plugin authors and that they simply didn't know that Winamp needs a list of supported extensions to let a plugin handle a file.
I have no doubt that the author "Shy Artist" did not intend to cripple this plugin, but upon further investigation, it seems that even the full OpenModPlug Tracker will not open the same files that both XMPlay and Winamp can no longer open.
I suggest this is a deeper "core" problem, that needs addressing :-(
Aminet is a fine source of a variety of mod types.
Every re-build should be tested on at least 2 of every format it is supposed to support. Loading and saving (annoying but necessary).
Yes I've had run-ins with "my programmers" (and they all still love me, honest) but they have all progressed into makers of tightly optimised code, that "does what it says on the tin".
I can supply the non-loading files.
And it has nothing to do with file extensions, as they were corrected anyway.
Quoteit seems that even the full OpenModPlug Tracker will not open the same files that both XMPlay and Winamp can no longer open.
Please provide the files in question. I cannot fix anything that I'm not aware of. Protection against buffer overflows and reading from uninitialized memory have been strenghtened in some module readers lately, so it's possible that they f.e. won't load broken files anymore that loaded in older versions. I've also removed one loader that was totally broken anyway, so yes, there are justified reasons why some files don't load anymore.
QuoteEvery re-build should be tested on at least 2 of every format it is supposed to support. Loading and saving (annoying but necessary).
If that amount of unit tests was that easy to write in someone's spare time, it would probably already have been done (there are, however, unit tests for XM, IT and MPTM files). And two files per format aren't even nearly enough for many weird module formats, and it happens
very often that 100 files go well and the 101th file doesn't load properly. I've had it often enough, and not a single unit test that the other 100 modules would have passed would have helped there (e.g.: Boobiesqueezed .XM files).
Jojo, thank you very much, you are totally right - Winamp relies on file extensions reported by plugins for file format detection routine to be executed in the first place. On the other hand, libmodplug's documentation regarding supported playback formats is... well, really incomplete.
Anyway, I've uploaded the new bugfixed and improved build v0.2b. See the first page of this topic. ^_^
See Version.txt for complete list of changes.
P.S. I really don't care about criticism, especially when it comes from such entitled persons like Dr.Flay who can't even recompile plugin with one line change and prefers to rant aimlessly instead.
Good to hear it's fixed.
Quote from: dsp2003 on June 13, 2011, 16:15:34P.P.P.S. This plugin is no longer in development, thanks to nearly zero feedback and lack of interest.
Don't expect praise and glory from developing "yet another module player plugin". There are too many of them, and there are too little people to appreciate them. Hell, I don't even get daily love letters for developing OpenMPT. :( ;)
But really, "nearly zero feedback" is much better than no feedback at all, it tells you that some person somewhere in this world thinks the stuff you do is cool and useful.
The complete source code for the plugin is now available here:
https://github.com/dsp2003/in_modplug
Sorry it took ages to put it somewhere in the public, because I didn't had stable connection which would allow SVN/GIT to function properly. т-т
As much as I appreciate your effort, I'd also like to point out that there's an up-to-date Winamp input plugin (http://lib.openmpt.org/libopenmpt/) based on libopenmpt. Contrary to libmodplug, this is actively maintained and much more compatible with many formats.
Thanks. I really had no idea such plugin ever existed... or wait, you've made it after I posted this one?
I'll leave this code public anyway, for historical reasons.
P.S. Are you SANE? libopenmpt_settings.dll written in C#? 400 Megabytes of useless .net libraries just to run a simple dialog window?
Quote from: dsp2003 on February 04, 2014, 09:45:01
Thanks. I really had no idea such plugin ever existed... or wait, you've made it after I posted this one?
libopenmpt has been released last December, so yeah.
Quote from: dsp2003 on February 04, 2014, 09:45:01
P.S. Are you SANE? libopenmpt_settings.dll written in C#? 400 Megabytes of useless .net libraries just to run a simple dialog window?
You're welcome to rewrite the settings dialog using native WinAPI. We are well aware that the current solution is not optimal, but we found it to be a better solution than not having a settings dialog at all, and writing the dialog using .net was the quickest way to realize it.
Besides, there's so much .net software these days that it's become relatively unlikely that the dependencies aren't installed already.
This is getting off-topic, but I'll write anyway.
The libopenmpt (or at least the Winamp plugin) outputs heavy static noise. Here's the file I've tested it with (http://"http://wks.arai-kibou.ru/download/music/remix/20110809_gentle_jena.7z").
It happens when Winamp's Equalizer is turned on. Tested against version 5.53.
P.S. If interfaces of libmodplug and libopenmpt are the same, you are free to take the file info dialog, as well as the current ini file config mechanism from my plugin. At least it's better than dealing with .net.
P.P.S. I don't use SSD, and each time the .net application starts the system freezes for 5-8 seconds before it will read and load all required libraries. I know I have an old machine, but this is definitely cannot be any good.
Quote from: dsp2003 on February 04, 2014, 12:16:28
The libopenmpt (or at least the Winamp plugin) outputs heavy static noise. Here's the file I've tested it with (http://"http://wks.arai-kibou.ru/download/music/remix/20110809_gentle_jena.7z").
It happens when Winamp's Equalizer is turned on. Tested against version 5.53.
DSP plugins (and the Winamp equalizer) should now work correctly since r3654, please try http://buildbot.openmpt.org/builds/auto/libopenmpt-win32/libopenmpt-win32-r3656.7z (http://buildbot.openmpt.org/builds/auto/libopenmpt-win32/libopenmpt-win32-r3656.7z).