AUDIOT and IMF limitations

[filipetolhuizen]

Hi,
I've been fiddling around with custom music in SOD using various tools for that (ImfTools and WDC). From what I understand, both ECWolf and Wolf4SDL have the extended limits from Wolf4GW, which allows larger .IMF files. Depending on the used tool, however, I get problems when I include certain music files, such as original playlist getting scrambled, wrong instruments and music out of key. I know this is not a ECWolf bug, but probably rather a limit in the original game. Some of the files I use, however, are not that large (~25kb) but still cause issues in the game when compiling AUDIOT with them. Does anyone know why this happens?

[Blzut3]

As far as I can tell the size limit is 64k (AUDIOT or otherwise). I have no idea why there would be other side effects.

[filipetolhuizen]

According to Adam Biser, the bugged AUDIOT worked on the original SOD exe but not when using ECWolf. He told me to ask if you've ever seen this happening.

[Blzut3]

I have not heard of this before. Can you upload the problematic audiot?

[adambiser]

Hi, the AUDIOT/HED file does play in the original Spear EXE, but not in ECWolf.

When I go to play ECWolf with the attached AUDIOT/HED, I get no music at all. Music is enabled and full loudness. Swapping the files back to the original and running gives me sound.

The attached ZIP also contains the IMF that appears to be causing the problem. It is in music position 12 (0-based, Map 13 - SUSPENCE_MUS) in the enclosed AUDIOHED/T files.

Putting that song in any slot causes all music to stop in ECWolf, but it plays fine in the original EXE (even the song causing the issue).

[Blzut3]

In this case the issue is that the name of the IMF file is too short (you know the stuff put in the MUSE footer) and I had ECWolf only look in the last 64-bytes for "IMF". The reason ECWolf does this of course is so that it can load any AUDIOT without any hard coded constants. I could just bump that lookback to the proper 88 bytes, but I did write more reliable code for another project that I should get around to merging into ECWolf. (The new code will look for the !ID! tags and use them if present. Otherwise it will fall back to scanning the MUSE footer.)

[adambiser]

Why does ECWolf need to worry about the junk at the end of the IMF chunk (the data beyond the IMF length)?
AUDIOT can be loaded without hard coded constants. If I remember correctly, AUDIOHED gives offsets to the chunks, then AUDIOT gives the length of the actual IMF data (excluding the stuff at the end, if any exists).

[Blzut3]

Right, but how does one determine how many IMF tracks there are? The number of PC Speaker, AdLib, and "Digitized" sound can be assumed to be the same, but the number of IMF tracks are unknown. Strictly speaking there's no 100% certain way to detect the number of such chunks, but a tool would have to go out of the way to not include some clues. These include placing !ID! between each section of data (most reliable if the tags exist, but the tags aren't required since vanilla doesn't do anything with them), or the MUSE footer which is only present in the IMF tracks. In other words, numAudioTChunks = 3*A + B, what are A and B?

I suppose one doesn't even need to parse the footer, if the chunk appears to be 88 bytes larger than what the length gives it's probably an IMF, but I'm not sure I feel safe making that assumption.

Is WDC doing something different to avoid having to hard code any of the chunk numbers?

[adambiser]

Is WDC doing something different to avoid having to hard code any of the chunk numbers?

To get the first music chunk with WDC, I scan AUDIOHED and use the first non-zero length chunk (by comparing one offset to the previous offset) after all the zero-length ghost digi sound chunks in there.
As a verification, I also check to make sure the first music chunk I detect is also a multiple of 3.

So far this has worked out.

Side note: My IMFCreator tool adds no extra data to the IMFs it creates. (Or at least I don't think it does.)

EDIT: WDC considers AUDIOT chunks with a length calculated from AUDIOHED offsets of 4 or less to be a digi chunk.

[filipetolhuizen]

Thanks Adam. Since I know mostly nothing about programming you could make it a lot clearer to him. I don't know if it's related to this or not, but the adlib sounds play distorted at the moment the music restarts.

[Blzut3]

AUDIOT loading is now fixed. Adam, I used your method as a fallback if the !ID! tags can't be found, unless the !ID! tags are proven unreliable I feel safer using them rather than assuming the first empty chunk that's a multiple of 3 from the bottom is the end of the "digi" sounds.

As for sounds playing distorted the moment the music restarts. That makes some sense, since I had to change the IMF player to reset the chip when starting the music (some tracks assume clean registers at the start unfortunately). I'll have to look back into that and see if I can prevent it from resetting the SFX channel. I've considered running two emulators to make things easier (possibly allow more sounds to be played simultaneously and give an extra channel for music), but I'm not sure I'll go through with that right now.

[adambiser]

That's good news, Blzut3. Glad that worked and glad to help.

[filipetolhuizen]

The imf now plays in ECWolf, however I get a couple of silence seconds while the imf loops (it comes from Operation Bodycount and I don't remember hearing the silence in the original game). The other imfs still play normally.

[filipetolhuizen]

It seems to be present in the .imf itself. Music is working fine.

[Blzut3]

Yeah, unless there was a difference between ECWolf and vanilla I don't think anything is going wrong there. On a related note, I believe the bodycount IMFs were the ones that showed that the OPL chip needed to be reset.