AUDIOT and IMF limitations

Post a reply

Smilies
:D :) :( :o :shock: :? 8) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: :angel: :angry: :beer: :bfg: :chaingun: :cheers: :blergh:
View more smilies

BBCode is ON
[img] is ON
[url] is ON
Smilies are ON

Topic review
   

If you wish to attach one or more files enter the details below.

Maximum filesize per attachment: 1.5 MiB.

Expand view Topic review: AUDIOT and IMF limitations

Re: AUDIOT and IMF limitations

by NeuralStunner » Fri Sep 19, 2014 20:14

It wasn't the highest-quality game to begin with, so I'm not surprised. (One of the few screenshots I've seen of it featured a very obvious Doom former human edit. Heh.)

Re: AUDIOT and IMF limitations

by filipetolhuizen » Wed Sep 17, 2014 23:09

I'm using 2 imfs from BC. The other one doesn't have a silence gap, but I guess I'll have to manually remove it from this one. BC actually has another 4 imfs in common with Corridor 7.
Edit: Just gave a shot at BC, and guess what, the silence gap is there as well. I didn't remember that at all.

Re: AUDIOT and IMF limitations

by Blzut3 » Wed Sep 17, 2014 21:05

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.

Re: AUDIOT and IMF limitations

by filipetolhuizen » Wed Sep 17, 2014 21:01

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

Re: AUDIOT and IMF limitations

by filipetolhuizen » Sun Sep 14, 2014 19:53

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.

Re: AUDIOT and IMF limitations

by adambiser » Sun Sep 14, 2014 1:11

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

Re: AUDIOT and IMF limitations

by Blzut3 » Sat Sep 13, 2014 21:59

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.

Re: AUDIOT and IMF limitations

by filipetolhuizen » Mon Sep 08, 2014 23:13

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.

Re: AUDIOT and IMF limitations

by adambiser » Mon Sep 08, 2014 22:32

Blzut3 wrote: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.

Re: AUDIOT and IMF limitations

by Blzut3 » Mon Sep 08, 2014 22:24

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?

Re: AUDIOT and IMF limitations

by adambiser » Mon Sep 08, 2014 22:09

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

Re: AUDIOT and IMF limitations

by Blzut3 » Mon Sep 08, 2014 22:02

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

Re: AUDIOT and IMF limitations

by adambiser » Mon Sep 08, 2014 20:05

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).
Attachments
AUDIOT.zip
(50.27 KiB) Downloaded 79 times

Re: AUDIOT and IMF limitations

by Blzut3 » Mon Sep 08, 2014 19:41

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

Re: AUDIOT and IMF limitations

by filipetolhuizen » Mon Sep 08, 2014 19:28

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.

Top