View Issue Details

IDProjectCategoryView StatusLast Update
0001380OpenMPTFile Format Supportpublic2020-10-18 18:04
ReporterLachesis Assigned ToSaga Musix  
Status resolvedResolutionfixed 
Platformx64OSWindowsOS Version10
Product VersionOpenMPT / libopenmpt 0.5.2 (upgrade first) 
Target VersionOpenMPT / libopenmpt 0.5.3 (upgrade first)Fixed in VersionOpenMPT / libopenmpt 0.5.3 (upgrade first) 
Summary0001380: 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.

Additional Information

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 converted to .WOW that didn't end up corrupted by the converter.

TagsNo tags attached.
Has the bug occurred in previous versions?Yes (tested in OpenMPT 1.28.05).
Tested code revision (in case you know it)




2020-10-18 01:18

reporter (167,813 bytes) (22,429 bytes) (74,541 bytes) (133,748 bytes) (247,533 bytes)
Saga Musix

Saga Musix

2020-10-18 10:23

administrator   ~0004474

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.



2020-10-18 10:49

reporter   ~0004475

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.

Saga Musix

Saga Musix

2020-10-18 14:54

administrator   ~0004477

Last edited: 2020-10-18 14:54

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.

I put far more effort into this silly MOD variant than it's probably worth :(

You helped solving a long-standing mystery. It was worth it. :)

Saga Musix

Saga Musix

2020-10-18 18:04

administrator   ~0004478

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. :)

Issue History

Date Modified Username Field Change
2020-10-18 01:18 Lachesis New Issue
2020-10-18 01:18 Lachesis File Added:
2020-10-18 01:18 Lachesis File Added:
2020-10-18 01:18 Lachesis File Added: into the
2020-10-18 01:18 Lachesis File Added:
2020-10-18 01:18 Lachesis File Added:
2020-10-18 01:18 Lachesis File Added:
2020-10-18 01:18 Lachesis File Added: this is just a
2020-10-18 01:19 Lachesis Description Updated
2020-10-18 01:19 Lachesis Additional Information Updated
2020-10-18 01:35 Lachesis Description Updated
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 / libopenmpt 0.5.3 (upgrade first)
2020-10-18 14:54 Saga Musix Target Version => OpenMPT / 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
2020-10-18 18:04 Saga Musix Note Added: 0004478