View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001380||OpenMPT||File Format Support||public||2020-10-18 01:18||2020-10-18 18:04|
|Reporter||Lachesis||Assigned To||Saga Musix|
|Product Version||OpenMPT 1.29.04.00 / libopenmpt 0.5.2 (upgrade first)|
|Target Version||OpenMPT 1.29.05.00 / libopenmpt 0.5.3 (upgrade first)||Fixed in Version||OpenMPT 1.29.05.00 / libopenmpt 0.5.3 (upgrade first)|
|Summary||0001380: Several .WOW files fail to import correctly.|
A quick summary of this obscure format: .WOW is a strange .MOD variant associated with the Mod's Grave player for DOS. The only thing particularly notable about it is that it has 8 channels but uses the M.K. signature, meaning it's a false positive concern when loading regular .MODs. The only program I can find that creates these files is a 669 converter packaged with Mod's Grave. The documentation for this program is in German but (a bad Google Translate job) suggests that this player is the sole purpose of the .WOW format.
I converted every .669 I have to .WOW while adding support for this format to MikMod and found some odd (but valid) .WOW files that trick OpenMPT (attached).
1) "ACIDFU~1.WOW" and "PURPLE~1.WOW" have an extra byte added by the converter for some reason (easy fix, just clear bit 0 of the result of file.GetLength() in this check).
2) "DARKMO~1.WOW", "into the maelstorm.WOW", "MEXIKA~1.WOW", and "THELUN~1.WOW" rely on counting length word=1 samples in the file length check to be correctly identified as WOW, which libopenmpt does not (sample length is counted after length=1 samples are pruned).
Fixing the latter of those two bugs introduces another problem, which is that this .MOD on Mod Archive gets detected as a false positive .WOW (this happens with both libxmp and libmodplug).
Fortunately there are some more checks that can be added based on quirks of the converter: 1) the restart byte is always 0x00; 2) for every non-zero length sample (including length 1), the finetune byte is 0x00 and the volume byte is 0x40 (669 doesn't support either so these are just defaults). Filtering on either of these quirks prevents the false positive from ponylips.mod. I ran a check on every .MOD file from Mod Archive and couldn't find any evidence of other potential false positives (at least on Mod Archive). These checks both assume 6692WOW is the only source of .WOW files but that seems like a safe assumption.
|Steps To Reproduce|
Load any of the .WOW files attached in OpenMPT. They will be handled as 4-channel M.K. mods instead of .WOW files.
Mod's Grave download link, which includes a player, documentation, and 6692WOW.
Here's the MikMod issue thread where I detail looking into this format. I put far more effort into this silly MOD variant than it's probably worth :(
Finally (for good measure), here's every .669 from ModLand.com converted to .WOW that didn't end up corrupted by the converter.
|Tags||No tags attached.|
|Has the bug occurred in previous versions?||Yes (tested in OpenMPT 1.28.05).|
|Tested code revision (in case you know it)|
ACIDFU~1.WOW.zip (167,813 bytes)
DARKMO~1.WOW.zip (22,429 bytes)
into the maelstorm.WOW.zip (13,430 bytes)
MEXIKA~1.WOW.zip (74,541 bytes)
PURPLE~1.WOW.zip (133,748 bytes)
THELUN~1.WOW.zip (247,533 bytes)
this is just a song.WOW.zip (88,853 bytes)
Wow (!), this is the first time I ever see actual WOW files. This code was never tested and just carried over from old ModPlug code.
I'd never seen them before either until a few days ago—I did a bit of digging around (since .WOW had been listed alongside some other odd alternate .MOD extensions that I'd never actually seen) and got lucky enough to find that Mod's Grave archive. The extension might originate from the predecessor to Mod's Grave, a DOS .MOD player called WOW by the same author (also available on that website). If "Grave Composer" is a real thing I haven't found it yet.
Many thanks for your detective work. I have incorporated the suggested changes in r13685, but also added some basic validation of the first pattern data that follows the regular end of 4-channel pattern data. If it looks like it's malformed (because it's really sample data), the file also won't be treated as a WOW file. This would fix a file like ponylips.mod if its restart position and finetune/volume values were not indicating a non-WOW files.
You helped solving a long-standing mystery. It was worth it. :)
BTW, for posterity, Mod's Grave and WOW were not written by the same person (The Sodomist and Mr. WOW respectively), but according to the manual they were in close contact and the 669 to WOW converter was provided by Mr. WOW. :)
|2020-10-18 01:18||Lachesis||New Issue|
|2020-10-18 01:18||Lachesis||File Added: ACIDFU~1.WOW.zip|
|2020-10-18 01:18||Lachesis||File Added: DARKMO~1.WOW.zip|
|2020-10-18 01:18||Lachesis||File Added: into the maelstorm.WOW.zip|
|2020-10-18 01:18||Lachesis||File Added: MEXIKA~1.WOW.zip|
|2020-10-18 01:18||Lachesis||File Added: PURPLE~1.WOW.zip|
|2020-10-18 01:18||Lachesis||File Added: THELUN~1.WOW.zip|
|2020-10-18 01:18||Lachesis||File Added: this is just a song.WOW.zip|
|2020-10-18 01:19||Lachesis||Description Updated||View Revisions|
|2020-10-18 01:19||Lachesis||Additional Information Updated||View Revisions|
|2020-10-18 01:35||Lachesis||Description Updated||View Revisions|
|2020-10-18 10:23||Saga Musix||Note Added: 0004474|
|2020-10-18 10:23||Saga Musix||Assigned To||=> Saga Musix|
|2020-10-18 10:23||Saga Musix||Status||new => assigned|
|2020-10-18 10:49||Lachesis||Note Added: 0004475|
|2020-10-18 14:54||Saga Musix||Status||assigned => resolved|
|2020-10-18 14:54||Saga Musix||Resolution||open => fixed|
|2020-10-18 14:54||Saga Musix||Fixed in Version||=> OpenMPT 1.29.05.00 / libopenmpt 0.5.3 (upgrade first)|
|2020-10-18 14:54||Saga Musix||Target Version||=> OpenMPT 1.29.05.00 / libopenmpt 0.5.3 (upgrade first)|
|2020-10-18 14:54||Saga Musix||Note Added: 0004477|
|2020-10-18 14:54||Saga Musix||Note Edited: 0004477||View Revisions|
|2020-10-18 18:04||Saga Musix||Note Added: 0004478|