MemSound has a deficiency :)

[SMcNeill]

I'd give it a TYPE value of 0 for size (undefined by our existing syntax rules), but then mem.ELEMENTSIZE could still easily define it as being 3 bytes in size.   Such a change then shouldn't break anything that exists now, I wouldn't think, and if it did, it would probably be the smallest of changes needed to update the user's code so that the end of their code doesn't end in ELSE .... 'It's a float (or whatever other else logic that have which didn't take in a 0 value return as a possibility for size).

Donno if you read my comment But the underlying issue is that the ELEMENTSIZE is dependent on both the sample size and the number of channels. The 24-bit audio could have an ELEMENTSIZE of 3, 6, 9, 12, etc. depending on the number of channels in the audio, and those numbers can overlap with other possibilities. In this case, 24-bit is weird enough you could probably differentiate it for 1 and 2 channels, but it may not remain that way if more formats are added. A theoretical 4-channel 24-bit audio would have 12 byte elements, which is the same as 3-channel 32-bit audio.

Gotcha.

What might be needed is to add a few parameters to the mem type for sound.

m.SoundChannels
m.ChannelSize

Then you could tell if it was 4x12 or 3x16 or even 2x24 which made up the 48 bits.