IncBin Soundsamples

[Etze]

I'm trying to include some very small soundsamples into the exe of a game but I guess I'm doing something wrong.


I stripped it down to this code which does nothing but a short wait and ends after that:

WBStartup

DecodeSound 1,?snd1
DecodeSound 2,?snd2
DecodeSound 3,?snd3
DecodeSound 4,?snd4
DecodeSound 5,?snd5
DecodeSound 6,?snd6
DecodeSound 7,?snd7
DecodeSound 8,?snd8

Delay_ 50




End

.snd1
IncBin "snd/grau.iff"
.snd2
IncBin "snd/gruen.iff"
.snd3
IncBin "snd/gelb.iff"
.snd4
IncBin "snd/klick.iff"
.snd5
IncBin "snd/gewonnen.iff"
.snd6
IncBin "snd/verloren.iff"
.snd7
IncBin "snd/unbekannt.iff"
.snd8
 IncBin "snd/start.iff"

On Kick 3.2 I get a Software Failure 80000003 Requester when it ends. But ONLY when I don't include Debug-Info. Within my game I can use the sounds without a problem but again, when it ends, I get the Software Failure.
On Kick 1.3 it won't even start and throws an error requester which I can't read (white on white). Even with Debug-Info.


Anything obvious that I'm doing wrong?

[Don_Adan]

Use only samples with even length.

[Honitos]

Are you using BlitzBasic?
I fixed the wrong text colours of the error requester with AmiBlitz3.

I may be a path problem. You could check this with SnoopDOS.

[Etze]

Originally Posted by Honitos

Are you using BlitzBasic?
I fixed the wrong text colours of the error requester with AmiBlitz3.

You're right. I normally use BB2.1. But I just tried it in AmiBlitz. The requester is readable again (Software Error - Task held...) and then Guru.

I may be a path problem. You could check this with SnoopDOS.

Shouldn't be, because the exe doesn't load anything at runtime. But just to be sure I tried it before (even with SnoopDos 1.7 under Kick 1.3): nothing.

[Etze]

Originally Posted by Don_Adan

Use only samples with even length.

Aha! Is it the filelength or only the raw data? I don't know anything about iff-Sound.



And how do I make sure the samples have the correct length - how do I "correct" them?

[Honitos]

What a dumb hint from me with SnoopDOS.
Obviously there is nothing to load with the samples linked to the binary :-)

But there should be no crash with activated debugger. Is it turned on?

[Don_Adan]

Originally Posted by Etze

Aha! Is it the filelength or only the raw data? I don't know anything about iff-Sound.



And how do I make sure the samples have the correct length - how do I "correct" them?

The best both. You can use any IFF sample editor. Add null (empty) byte at end, or remove last byte from odd even length sample(s).

[Etze]

Originally Posted by Honitos

But there should be no crash with activated debugger. Is it turned on?

Correct, no crash with debugger.

[Etze]

Originally Posted by Don_Adan

The best both. You can use any IFF sample editor. Add null (empty) byte at end, or remove last byte from odd even length sample(s).

Thank you very much, I got it working! I just cut a little bit of the samples in the hope that it will be even length. That worked out and now I don't get a Guru anymore .

[carrion]

please try to put the keyword "Even"
after each IncBin to make start next sounds from even addresses.
like this:

.snd1
IncBin "snd/grau.iff"
Even

[Daedalus]

Yep, sounds like an alignment problem alright - that error probably wouldn't happen on a 68020 or above in that case. The Even keyword can be used as suggested to control the alignment of data in memory. You can also put it before the first Incbin, just in case the previous code or data ends at an odd address.

For reference, the sound data itself from an IFF-8SVX file should always be even in length, and all IFF hunks (headers etc.) should also be even in length, but it's possible that whatever software created the sample didn't entirely follow the standard.

[Etze]

Thanks. I had used Audacity to create the 8svx files. Loading and just saving it with Samplitude didn’t help, so I cut a tiny bit and saved it again. That worked. Next time I will test it with the Even keyword.

[E-Penguin]

You might want to force them into chip ram too - you can do this in Amiblitz3 with the chip keyword before the first sound entry. An alternative is test the address and copy into a chip buffer if the returned address is above the chip range.