Quasar Posted April 5, 2010 TheGreenHerring discovered a wad in the /idgames archive called DIESCUM.WAD which has a very strange oddity about it - its music lump is embedded inside an inner wad file, and the lump entry points to the beginning of the wad rather than to the beginning of the MUS lump. However, vanilla DOOM plays this music normally. This suggests that the DMX library is capable of scanning forward for a MUS header in the data that is passed to it. I have implemented such a forward scan in EE r1084 and it fixes playing the music on this map. I'd recommend this minor tweak to any port interested in high fidelity even for crappy malformed wad files ;) 0 Share this post Link to post
DaniJ Posted April 5, 2010 Thanks for the heads-up! Will address in Doomsday for a future release. 0 Share this post Link to post
Gez Posted April 5, 2010 Dunno what tool was used to generate this file, but it did a very poor job. This is a severely malformed wad. 0 Share this post Link to post
GreyGhost Posted April 5, 2010 The tool's only as good as the user. XWE and SLumpEd will let careless users make the same mistake, though SLumpEd does at least identify the lump as a wad file. 0 Share this post Link to post
Gez Posted April 5, 2010 Yeah but what of the hundred empty lumps that come after it? 0 Share this post Link to post
Quasar Posted April 5, 2010 Gez said:Yeah but what of the hundred empty lumps that come after it? At least the directory is valid though. ;) We're having a lot of trouble lately with wads popping up in the archive which have invalid blockmaps. Evidently the number of them out there is staggering. Virtually all of them have some minor corruption (whether a result of a bad tool or of some type of "bit rot" is unknown) that leads to indexing the linedefs array out of bounds. 0 Share this post Link to post
Gez Posted April 5, 2010 Quasar said:At least the directory is valid though. ;) I'm not even sure about that since the SLADE3 beta doesn't read it correctly. (Why is a mystery to me, the algorithm used is exactly the same as in Slumped, which does read it correctly.) But look at this: Seems to me there are two different directories here... The one that's used is the second. In the first we see the infamous PLATFORM lump. Then there's a long list of null bytes which are interpreted as the offsets, lengths and names of a bunch of lumps, since 111 of them are supposed to exist in total. 0 Share this post Link to post
kristus Posted April 5, 2010 The platform lump comes from Doomed, where it allows naming of the tags. The funnyness of this wad is possibly a result of using it's WAD editor featured in v 4.2 0 Share this post Link to post
Quasar Posted April 5, 2010 Gez said:I'm not even sure about that since the SLADE3 beta doesn't read it correctly. (Why is a mystery to me, the algorithm used is exactly the same as in Slumped, which does read it correctly.) But look at this: pic Seems to me there are two different directories here... The one that's used is the second. In the first we see the infamous PLATFORM lump. Then there's a long list of null bytes which are interpreted as the offsets, lengths and names of a bunch of lumps, since 111 of them are supposed to exist in total. Extra wad directories, which are left over from the insertion of additional lumps into wad files, in this case probably the music lump, are not unusual in my experience. WAD is a very open format which can contain arbitrary data between the offset-referenced portions of the files (the directory and the lumps). The only thing fixed is the position of the header, which should be at offset 0. Directories which are not referenced from the header are only interlump garbage and must always be ignored. Your problem with reading the directory may be because the lump names are empty, which is something that needs to be tolerated - I know for a fact that this is not nearly the only wad with empty lump names in the directory. 0 Share this post Link to post
Gez Posted April 5, 2010 Nah, I've found and fixed the issue already, that wasn't that. :) Because of the way the Slade 3 identification algorithm is written, if loading the MemChunk failed, then the rest of the setup continued with the data from the previous lump... 0 Share this post Link to post
Quasar Posted April 5, 2010 Gez said:Nah, I've found and fixed the issue already, that wasn't that. :) Because of the way the Slade 3 identification algorithm is written, if loading the MemChunk failed, then the rest of the setup continued with the data from the previous lump... Ahh, woops :) Good to hear you got it fixed. 0 Share this post Link to post