Go Back   Winamp & SHOUTcast Forums > Winamp > Winamp Bug Reports

Reply
Thread Tools Search this Thread Display Modes
Old 1st December 2012, 13:15   #1
jschultz
Junior Member
 
Join Date: Dec 2012
Posts: 13
in_mod: XM files made with OpenMPT won't load correctly

It has come to my attention that Winamp still won't load some XM files, even though they are perfectly valid. First off, let me say that this is not a problem with OpenMPT but with mikmod, because XM files made with OpenMPT load just fine with about any other player I've tried - including Fasttracker 2. The problem is that mikmod seems to ignore the XM header size when loading XM files, which breaks stuff when header sizes are not the same as the defaults.
OpenMPT has adapted a trick from BoobieSqueezer, a utility to create tiny XM files by removing unnecessary information from such files. In this particular case, OpenMPT does not write the full 256-item order list in the file header, but only writes as many orders as necessary, and thus reduces the "header size" field as much as required. By default, the header size is 276 (20 bytes + 256 order items), but in reality it just needs to be 20 + x, where x is the number of orders. Since Renoise had the same problem with XM files, I have reported this issue to the Renoise development team here and it has since been fixed. I hope that the information posted in that thread will help you fixing this bug. If not, feel free to ask me about more details here. These test cases (plus the ones from the issue tracker link) should help you with verifying the bug.

Now, I still think that Winamp's age-old mikmod is rather abysmal and I know that you don't really fix anything but security-related bugs in it, but this is such a basic thing that it should really be fixed, since OpenMPT is actually a quite popular tracker and many people use it to create XM files. I don't want to be blamed every now and then that my application writes out "broken" XM files that Winamp can't load, since it's really Winamp's fault.

I had a look at the libmikmod-3.1.12 code, and I think you should replace
code:
_mm_read_UBYTES(mh->orders,256,modreader);

with
code:
_mm_read_UBYTES(mh->orders,min(mh->songlength,256),modreader);
_mm_fseek(modreader,mh->headersize+60,SEEK_SET);


in load_xm.c.

By the way, this bug is fixed in the latest libmikmod (libmikmod-3.2.0) already. Their fix was to change the line to
code:
_mm_read_UBYTES(mh->orders,mh->headersize-20,modreader);

which should work just as well, but I'm not sure if it is as secure.
jschultz is offline   Reply With Quote
Old 2nd March 2013, 15:50   #2
jschultz
Junior Member
 
Join Date: Dec 2012
Posts: 13
Any news on this? Are you going to fix this?
jschultz is offline   Reply With Quote
Old 2nd March 2013, 17:11   #3
DrO
 
Join Date: Sep 2003
Posts: 27,880
in_mod needs to be completely re-done but i doubt it's ever going to happen (is just no financial return). seeing as in_mod is based on a massively old version of mikmod, what you've posted isn't applicable anyway. it's known that in_mod is crap, but there's little that can be done.
DrO is offline   Reply With Quote
Old 2nd March 2013, 17:16   #4
jschultz
Junior Member
 
Join Date: Dec 2012
Posts: 13
Well, knowing that mikmod isn't rewritten from scratch every other day, my one-liner fix should still be applicable to at least make in_mod load a huge bunch of XM files that otherwise wouldn't load. Even if in_mod uses an older version of mikmod, it should still work. If you happen to know which exact version of mikmod is being used, I can dig into the mikmod code and check what has to be done. I know in_mod is old and crappy, but even then it would be better if it at least loaded files made with widely used trackers.
jschultz is offline   Reply With Quote
Old 2nd March 2013, 17:20   #5
DrO
 
Join Date: Sep 2003
Posts: 27,880
there is no specific version i can attribute the version of mikmod used to being. i know you're trying to help, but in_mod is such a mess that it's unlikely just copy+pasting things in will work.
DrO is offline   Reply With Quote
Old 2nd March 2013, 17:35   #6
jschultz
Junior Member
 
Join Date: Dec 2012
Posts: 13
I can recall in_mod being updated a few years ago, so there's still hope. I'd just like to hear from the actual developers if they're going to do something about it or if it's going to stay as-is - if the line I quoted in my initial post has been left untouched in mikmod for long enough (which I would guess to be true, since there aren't all that many ways to read an orderlist in mikmod), there should be no problem at all with applying my fix.
jschultz is offline   Reply With Quote
Old 2nd March 2013, 17:50   #7
DrO
 
Join Date: Sep 2003
Posts: 27,880
as you have already pointed out, all of the recent in_mod updates from the last few years have been security fixes.

based on the details i have (what with having source access), there have not been any large updates to the plug-in in over a decade. especially as there is no reference to modreader in any of the code - this is still the same as a the version shipped with Winamp v2.x (with the security fixes).

either way, i'm not going to touch in_mod even if those fixes might be viable (which i doubt based on the code i'm looking at) as i don't have the time to go through and making sure it doesn't break other things (and never really using the plug-in anyway, i don't have a basis to work from).
DrO is offline   Reply With Quote
Old 19th November 2014, 02:25   #8
MSoles7
Junior Member
 
Join Date: Nov 2014
Posts: 2
Sorry for bumping an old thread but I know a way to fix this issue, that is to download the in_openmpt.dll plugin for Winamp (which is in libopenmpt-0.2.4259-beta7-bin-win32.7z).

http://lib.openmpt.org/libopenmpt/

Installation instructions.

1. Uninstall the in_mod.dll plugin.

2. Unzip the in_openmpt.dll into the plugins folder.

3. Unzip the libopenmpt_settings.dll into the main winamp folder (Not the plugins folder)

And that should solve the xm error problem and greatly improves the sound quality for all types of mod files since the plugin is based on OpenMPT.
MSoles7 is offline   Reply With Quote
Old 19th November 2014, 02:53   #9
DrO
 
Join Date: Sep 2003
Posts: 27,880
will have to look into the plug-in if the claims made are true (especially as the license appears to be permissible with Winamp's).
DrO is offline   Reply With Quote
Old 19th November 2014, 08:16   #10
jschultz
Junior Member
 
Join Date: Dec 2012
Posts: 13
Quote:
Originally Posted by MSoles7 View Post
Sorry for bumping an old thread but I know a way to fix this issue, that is to download the in_openmpt.dll plugin for Winamp (which is in libopenmpt-0.2.4259-beta7-bin-win32.7z).
Obviously using my own player routines would make things better for me (if I was still using Winamp). However I'd want this to be fixed for the general audience. Since we have found a couple of more (older) applications which have problems with the way OpenMPT writes outs XMs, there is actually a way now to generate XMs again which will load fine in Winamp, but that won't change the fact that there are already plenty of XMs out there made with older versions or with some other programs which use the same tricks.

DrO: libopenmpt/in_openmpt is BSD-licensed, so in theory it could probably be used with Winamp I guess? I don't know if the plugin in its current state would be useful for inclusion (in particular I don't remember how well looping works, and how it works in in_mod), but if there's anything that should be changed, there's of course always the possibility to fix it (patches welcome ).
jschultz is offline   Reply With Quote
Old 19th November 2014, 11:37   #11
DrO
 
Join Date: Sep 2003
Posts: 27,880
Quote:
Originally Posted by jschultz View Post
DrO: libopenmpt/in_openmpt is BSD-licensed, so in theory it could probably be used with Winamp I guess? I don't know if the plugin in its current state would be useful for inclusion (in particular I don't remember how well looping works, and how it works in in_mod), but if there's anything that should be changed, there's of course always the possibility to fix it (patches welcome ).
BSD is fine and we've used BSD licensed things previously. at the moment it's just a possible thought since if it's meant to be more reliable (and that you've got a working plug-in showing it in use) then it's probably less work for us (well me) to modify it to add in the things that native plug-ins need to provide compared to trying to go though the mess of the existing in_mod and re-work that.

though without some proper research (as mikmod has been mentioned as being crap in your ticket but i'd need a bit more on why it's crap compared to your solution or any others), i don't know if it's the better option or not or we instead look to just update to a recent version of mikmod and keep that historical usage going (seeing as both projects appear to be actively developed at the moment).

[edit]
from a quick scan through a few posts / forums, i'm undecided since it's all relating to the blatantly old version of mikmod used and doesn't seem to help see if the newer 3.x branch is better or not. i guess there's no distinct (and ideally somewhat independent) comparison between the different engines ?
DrO is offline   Reply With Quote
Old 19th November 2014, 13:58   #12
jschultz
Junior Member
 
Join Date: Dec 2012
Posts: 13
Most module enthusisasts would probably be very grateful if you switched away from mikmod - it may have improved but as far as I know it's still dodgy (see below).

libopenmpt has the advantage that it's based on the playback engine of the same tracker that's used for writing a majority of XM and IT files these days, and generally has a very faithful reproduction of these formats also compared to their original trackers. mikmod's development is also not all that active in terms of playback fixes - just look at the commit logs to see that most of the commits are more about the build system and other supporting structures.

I don't want to badmouth mikmod or anything, but I just threw some of my own ITs at the latest mikmod release and they all had the same problem: No stereo samples, no filters, no note fades. They just sound completely broken. Even the old libmodplug plays them better.

I encourage you to take a look at the in_openmpt sources and build upon them, and hopefully also give back the modifications to the project in case you make any useful changes to it.
jschultz is offline   Reply With Quote
Old 19th November 2014, 14:08   #13
DrO
 
Join Date: Sep 2003
Posts: 27,880
is there a decent set of test files i can use for comparing against ?

if anything does happen, where feasible i'd provide the code changes back (though it'd all be aimed at a Winamp 6.x install).

btw, what's with the external libopenmpt_settings.dll ? i've not yet installed / looked at the code but i see that in the archive and it seems a bit weird to have a supporting dll just for settings or am i missing something ?
DrO is offline   Reply With Quote
Old 19th November 2014, 14:34   #14
jschultz
Junior Member
 
Join Date: Dec 2012
Posts: 13
Quote:
Originally Posted by DrO View Post
is there a decent set of test files i can use for comparing against ?
That's of course pretty hard to compile, especially since it is well possible that mikmod may be able to play a few obscure formats better, but I will try to highlight some mods where I found some significant differences between how mikmod and some more acclaimed libraries like BASS or libopenmpt play them:

Let's start off with a pretty objective test suite, which is focussed on accurate IT playback. You will see that mikmod fails most tests:
http://schismtracker.org/wiki/Player%20abuse%20tests
It's been a few years since it has been updated, but I don't think much has been done about fixing these since then (on the other hand, there have been a lot of fixes in e.g. xmp and OpenMPT).

And here are a few more personal observations:

http://modarchive.org/module.php?34082 - At the start, mikmod plays something on channel 10 even though it's supposed to be silent until about half a minute into the song.

http://modarchive.org/module.php?174568 - one of my own tracks, highlighting the various problems mikmod seems to have with IT files (which is sad, since IT and XM are pretty much the most widespread formats these days)

http://modarchive.org/module.php?54250 - A classic module, and also a classic S3M peculiarity that many players including mikmod (but also BASS) ignore. There's a hanging note at 1:00 which is not supposed to be there.

http://modarchive.org/module.php?155873 - Another peculiarity, but in ScreamTracker 2 - mikmod plays arpeggio just like in other trackers, but it should retain the final frequency of the last tick of a row where arpeggio occurs until a new note is triggered. Differences can be heard at around 3:38. Also, just by looking at the code I can already see that mikmod doesn't handle the tempo in STM files correctly, which works a bit different from how other trackers do it.
jschultz is offline   Reply With Quote
Old 19th November 2014, 14:40   #15
DrO
 
Join Date: Sep 2003
Posts: 27,880
k, just wasn't sure what was out there or not since i've not really been into such music types for a long time. thanks for what you've provided, has given me some things to look though / try out which is better than the position i was in yesterday
DrO is offline   Reply With Quote
Old 19th November 2014, 15:28   #16
jschultz
Junior Member
 
Join Date: Dec 2012
Posts: 13
Oh, and about libopenmpt_settings... this is mostly a necessity at the moment since the config dialog uses MFC, which makes the initalization stuff slightly complicated. Of course it would be nice to just use pure Win32 code for the config dialog (and a possible info window à la in_mod, which doesn't exist yet but could probably be ported over), but so far this was not a priority for us. If you're interested in making in_openmpt an official replacement for in_mod, re-implementing this would probably be a good first step.

(Another advantage of libopenmpt_settings is that we can plug it into our other player input plugin, xmp-openmpt, without having to change any code)
jschultz is offline   Reply With Quote
Old 19th November 2014, 15:43   #17
DrO
 
Join Date: Sep 2003
Posts: 27,880
rightio will have a look through things in a few days. though the config being MFC based would mean we'd need to re-write it anyway (generally avoid it like the plague but then i prefer just working in native win32) as we try to keep any external dependencies to a minimum, hence the crt bundling for what Winamp needs instead of installing things globally.
DrO is offline   Reply With Quote
Old 19th November 2014, 15:46   #18
jschultz
Junior Member
 
Join Date: Dec 2012
Posts: 13
Yes, getting rid of MFC would be exactly my own advice as well - mind you, we first used .net for the config dialog just to have a dialog at all, but that was ugly, so we switched to MFC, which is only a little less ugly but works better. It's by no means perfect. Keeping the dialog separate from the rest of the plugin would still be a good idea (so that it can be reused in xmp-openmpt), but generally it would be nice if it was pure Win32, of course.
jschultz is offline   Reply With Quote
Old 19th November 2014, 15:48   #19
DrO
 
Join Date: Sep 2003
Posts: 27,880
well we'll see what comes from when i have a proper look into things and make a decision on what should be done regarding in_mod going forward
DrO is offline   Reply With Quote
Old 22nd December 2014, 02:36   #20
DrO
 
Join Date: Sep 2003
Posts: 27,880
i've finally had a chance to have a quick play with the plug-in (using 0.2.4667-beta9) and the playback reliability and quality seemed good to me.


building isn't quite as clean as i've only got VS2008 on here. the core libopenmpt built ok from what i could tell with the project in the build\vs2008 folder. the final plug-in dll doesn't at the moment due to differences in the stl (as i see it's aimed at VS2010), but i've got something that vaguely builds to the point i can check dependencies, config dialog, alt+3 but not playback at this time of night. (though for Winamp in general, we need to move on from VS2008 sooner rather than later).


with the officially built plug-in, the only things that jumped out immediately is the alt+3 info handling (where it just dumps it all into a messagebox) which would need to be changed to the common alt+3 handling added in Winamp 5.5. and then there is it writing it's settings into the registry whereas all native Winamp plug-ins use the settings folder and avoid the registry unless needed in-order to be able to portable. that is the most obvious difference that would need to be changed (or it could be maintained and disabled if Winamp is in a portable / no-registry mode as it can also be configured to run in).


so based on what i've seen so far, i think it's something i will look to do a bit more work on to see if there's anything else / what will need to be implemented to make it comparable to the existing in_mod functionality (which from a quick check is transcoding support, some metadata api support and whether to provide the means to control which loaders are enabled like in_mod does).


as such, i think i can say that at some point in the 6.x release there should hopefully be a an in_mod v3 based on libopenmpt in place of the existing mikmod based version.
DrO is offline   Reply With Quote
Old 22nd December 2014, 12:54   #21
jschultz
Junior Member
 
Join Date: Dec 2012
Posts: 13
I'm glad to hear about the news. I guess if it can be easily done, the existing in_mod Alt+3 functionality should probably be transferred over to the new plugin. Everything that is currently shown in that dialog should be easy enough to retrieve from libopenmpt's metadata facilities.
jschultz is offline   Reply With Quote
Old 31st December 2014, 02:12   #22
franpa
Junior Member
 
Join Date: Feb 2007
Location: australia, brisbane
Posts: 49
Send a message via Yahoo to franpa
It seems the configuration DLL file is no longer needed for Winamp (this still mentions installing it though). I don't really want to register on yet another forum/bug tracker just to post a feature request but seeing a numerical value for what the pan and gain slider settings currently are would be nice.
franpa is offline   Reply With Quote
Old 31st December 2014, 12:38   #23
jschultz
Junior Member
 
Join Date: Dec 2012
Posts: 13
That is correct, and DrO most likely found that out already (we managed to make MFC work without the need of a separate DLL). The notice on the download page will be updated shortly.
jschultz is offline   Reply With Quote
Old 3rd January 2015, 18:54   #24
Koopa
16-Bit Moderator
 
Koopa's Avatar
 
Join Date: Apr 2004
Posts: 4,336
Quote:
Originally Posted by jschultz View Post
the existing in_mod Alt+3 functionality should probably be transferred over to the new plugin.
I think using the unified tag editor would be the better choice, he already showed us in the past with his SNESAmp Wrapper, that it's possible to use it with more 'special' input plug-ins.

I'm glad to hear that in_mod will be updated, I always thought that it will be removed, so keep on your good work. Maybe this will auto fix some of the bugs in bug tracker and maybe I can try to add my mod files to the library again (which always resulted in crashes with the current in_mod based on MikMod)
Koopa is offline   Reply With Quote
Old 4th January 2015, 19:54   #25
DrO
 
Join Date: Sep 2003
Posts: 27,880
using the unified dialog goes without saying for anything native (though obviously that was not done in all cases previously, just for the main formats at the time).

it would be best to see if the in_openmpt plug-in works better for you as-is before anything formally is done to migrate things over between the two plug-ins.
DrO is offline   Reply With Quote
Old 4th January 2015, 19:59   #26
Koopa
16-Bit Moderator
 
Koopa's Avatar
 
Join Date: Apr 2004
Posts: 4,336
Quote:
Originally Posted by DrO View Post
using the unified dialog goes without saying for anything native (though obviously that was not done in all cases previously, just for the main formats at the time).

it would be best to see if the in_openmpt plug-in works better for you as-is before anything formally is done to migrate things over between the two plug-ins.
Will test it during the next days, though I wonder if it already has some kind of library support.

I'll report back, how things worked.
Koopa is offline   Reply With Quote
Old 4th January 2015, 20:02   #27
DrO
 
Join Date: Sep 2003
Posts: 27,880
i don't think it does (cannot check at the moment), it's more about looking for any playback issues at the moment (though i doubt there should be any compared to the existing in_mod).
DrO is offline   Reply With Quote
Old 6th January 2015, 17:54   #28
Koopa
16-Bit Moderator
 
Koopa's Avatar
 
Join Date: Apr 2004
Posts: 4,336
Here are the results of my first tests:

+ doesn't crash with lots of files during playback like the current in_mod does
+ smooth playback of all files I've tested so far with

- no 24-Bit support
- no transcoding/library API support (that is a known thing)
- no global playback settings support (could be updated to use the global settings)
- no settings to disable loading of specific loaders with the interesting info provided by the current in_mod (can be re-added)
- terrible file info dialog popup

From my tests it does a much better playback job, than the current in_mod does, because it is less crashy.

I think most of the stuff from my - list could be addressed and the used lib seems to get much more updates than MikMod.

I will do lot of more testing and will report my results here, though really interesting would be basic library support, this is where the current in_mod totally fails.
Koopa is offline   Reply With Quote
Old 6th January 2015, 18:01   #29
jschultz
Junior Member
 
Join Date: Dec 2012
Posts: 13
libopenmpt does have 16-bit and floating-point output. The latter could of course be added to the plugin as well and be converted to 24-bit integer, but I really do hope that there is a bit of sanity in Winamp left and it doesn't use 24-bit as its native sample type. (FWIW, 32-bit floating point is equivalent to 24-bit fixed point, except that it has headroom above 0dB.)
jschultz is offline   Reply With Quote
Old 6th January 2015, 18:04   #30
Koopa
16-Bit Moderator
 
Koopa's Avatar
 
Join Date: Apr 2004
Posts: 4,336
24-Bit is disabled by default in Winamp and if you enable it you get a warning message with limitations etc.

I also miss the ability to control the playback priority.

I think most of the things can be addressed and it would be worth to use it as replacement for the current in_mod based on MikMod.

So DrO I think it's not possible to bring the current in_mod to a state where it is crash free, even if MikMod would be updated. The plug-in is nearly the same plug-in used in Winamp 2.x (with some library API support added later) and that's probably the main issue with it.

Here you would get a much better base for an input plug-in with a library which seems to be actively developed.

Just my 2 Cent.

More testing results will follow later this week.
Koopa is offline   Reply With Quote
Old 6th January 2015, 19:18   #31
DrO
 
Join Date: Sep 2003
Posts: 27,880
all of the points raised are things i'm aware off i.e. all of the 5.x-ifying of things (as what's provided is very much of a 2.x era plug-in) and know would need to copied over / re-implemented as part of getting it up to the spec needed.

the main thing from my view point is that playback is good and that it doesn't have the obvious crash issues like what we've been using as i'm fine to drop things that have been kept historically if it means it's better in the long run. plus the setup of building is a lot easier than the mess of how in_mod is currently built so that wins for me as well. as i could have tried to go and update to the latest mikmod but what we're using is so old that it doesn't match up and if anything, going from this one and porting back the things as needed is a lot less work than trying to update the exiting in_mod.

as for the 24-bit playback, i'd have to double-check what's going on (i've never really paid much attention to the audio engine aspects) though its not like a lot of plug-ins support it anyway (even with the native plug-ins as-is).
DrO is offline   Reply With Quote
Old 29th May 2016, 20:18   #32
jschultz
Junior Member
 
Join Date: Dec 2012
Posts: 13
Since it's been over a year since the last update in this thread, I wonder if any progress has been made?
jschultz is offline   Reply With Quote
Old 30th May 2016, 02:05   #33
DJ Egg
Techorator
Winamp & SHOUTcast Team
 
Join Date: Jun 2000
Posts: 35,739
You'll be happy to know that we've replaced the old in_mod with a new one based on OpenMPT for Winamp 5.8, so all those xm files will now play.... once we release Winamp 5.8 that is, heh. Hopefully we can get a public beta out soon....we shall see....
DJ Egg is offline   Reply With Quote
Reply
Go Back   Winamp & SHOUTcast Forums > Winamp > Winamp Bug Reports

Tags
mikmod, openmpt

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump