95raver.mod does not work
perlun opened this issue · comments
I first thought this was #5, but even after upgrading to the latest hxcmod.[ch] versions I am still seeing this bug:
The following file ('95 ravers megamix 😉) cannot be played back with HxCModPlayer: https://modarchive.org/index.php?request=view_by_moduleid&query=62019
The error I am getting is that hxcmod_load(&modctx, modfile, length) for this file returns 0. I double-checked to ensure my local file isn't corrupted in any way, but the md5 checksum as listed on the modarchive page matches so I'm fairly sure this is an issue in the player code.
The file is rather extreme, with a lot of samples etc, so I guess there is some feature being used by the file that is not supported by the player. Nonetheless, it would be incredibly nice if it could be supported. 😄
In fact this file is truncated, 5152 bytes are missing.
You can play the good version on the test page :
http://hxc2001.free.fr/hxcmod/ (95 Ravers Megamix.MOD)
The file : http://hxc2001.free.fr/hxcmod/mods/95%20Ravers%20Megamix.MOD
The files are "identical" but "your" is shorter.
In fact hxcmod check the filesize/samples positions coherency at loading and here there is a problem.
And yes this a nice mod ! :)
Thanks a lot for the reply @fdelnero! I was actually attempting to debug this quite a bit tonight, struggling with trying to replace the data_cartoon_dreams_n_fantasies_mod.h builtin data with the content from this mod, to be able to attach a debugger to it easily and step through it. To get this working, I had to port your bmptoh.c program to Linux (since it uses some Windows-only constructs to handle .bmp files). I almost got it working, but I couldn't find the pack() method implementation - this is the bmptoh.c version I was attempting to convert: https://github.com/xXorAa/hxc-software/tree/master/HxCFloppyEmulator/HxCFloppyEmulator_file_selector/HxCFloppyEmulator_file_selector_AmstradCPC/tags/HxCFloppyEmulator_file_selector_AmstradCPC_V1_0/graphx/converttools/bmptob8 (I presume this is also your program?)
Anyway, big thanks for finding the underlying problem. You are entirely right, I didn't even think about the fact that the file from modarchive could be broken... Interestingly enough, it plays correct in libopenmpt, but it's apparently not as careful in validating the data as hxcmod. 😉
I've now replaced the bad version with the one from your site and now it plays perfectly in our OS's mod player. 😄 chaos4ever/chaos#171
(For the record, I also filed a report with The Mod Archive to replace the broken version with the proper version from your site: https://modarchive.org/forums/index.php?topic=4416.0)
Hi, I'm the ModArchive admin and OpenMPT developer. I think outright rejecting truncated MODs is not a good idea, because there are tons of these files floating around. Emitting a warning instead might be a better choice rather than denying the user to outright play the file.
(@sagamusix Nice to meet you. 🙂 I looked at OpenMPT when thinking about what .mod library to incorporate, but since our use case is a custom OS with a limited featureset in terms of ISO C/POSIX functionality, hxcmod seemed like a much simpler option. It doesn't require any memory allocation and doesn't even require FPU support - which we don't have at the moment... Apart from this, OpenMPT is obviously a much more advanced library with support for numerous file formats, so... I like the featureset but not the (perceived) complexity. 😉)
As for being able to play truncated files: good question you're raising there. I don't know how other players & libraries tend to handle this. What happens if you load one of these broken files into some classic/modern tracker (Fast Tracker 2, others), do they yell or do they ignore the errors and do a best-effort attempt to play the file anyway?
The HxCMod mod replay library is designed to have the least external dependency and to play mods on microcontroller/limited resource devices directly from ROM/Flash space as-it-is without the need to load it into the RAM space. So at "loading" i am checking that the file will not "ask" to read something (pattern/sample...) outside its own memory space to avoid possible crash and also avoid to do these checking while playing the mod. I can add an option to bypass this checking, but this seems to be a bad idea.
Okay, with that rationale it makes a lot more sense to outright reject those files. It's something library users have to be aware about though, as this issue shows - many other players will simply shorten the sample, fill it with silence or (worst case) play garbage. In a perfect world we wouldn't need to do any of that of course, but sadly there are quite a few files floating around where a non-broken version is hard to find or doesn't exist.
Let's close this for now. 👍 My original problem was solved and this issue can hopefully be found if others run into similar issues in the future.