Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
Quasar

MUS Format Recommendation

Recommended Posts

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 ;)

Share this post


Link to post

Thanks for the heads-up! Will address in Doomsday for a future release.

Share this post


Link to post

Dunno what tool was used to generate this file, but it did a very poor job. This is a severely malformed wad.

Share this post


Link to post

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.

Share this post


Link to post

Yeah but what of the hundred empty lumps that come after it?

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post

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

Share this post


Link to post
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.

Share this post


Link to post

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

Share this post


Link to post
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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×