TOPIC: Crash loading SFZ exported with discoDSP Bliss

I don't know. Perhaps Audacity is guessing wrong.
I opened both files (the original you added, and the one I saved after the bit change) from disk and it looks like this:



Also, the size of the saved ones is smaller than before.
This shows that a change has been made.
I don't know where the problem is, but the files I converted with Audacity can be opened in Polyphone 2.2.

I actually hoped Polyphone could do this format conversion silently. Because the software already has the necessary library to do this.
Mr. Bottrop says that Polyphone software version 1.9 is able to open these files (I haven't tested it). So there may be a bug in 2.x version that prevents this format conversion.

Looking at the hex code of the original files at
hexed.it/
and comparing to the spec at
soundfile.sapp.org/doc/WaveFormat/
and
soundfile.sapp.org/doc/WaveFormat/
the files are indeed 16bit and 24 bit. I believe the problem lies elsewhere, IMHO.
Unless they are marked in the header 16 and 24 but encoded 32 ? Getting beyond my paygrade here.
They load fine in other applications, so.... I dunno.

When analyzing the wav files mentioned in this thread, I discovered that the sections "inst" have a length of 7 bytes but then everything was shifted. I searched why and here is a subtlety of the WAV files I wasn't aware of:

sites.google.com/site/musicgapi/technica...ents/wav-file-format
One tricky thing about RIFF file chunks is that they must be word aligned. This means that their total size must be a multiple of 2 bytes (ie. 2, 4, 6, 8, and so on). If a chunk contains an odd number of data bytes, causing it not to be word aligned, an extra padding byte with a value of zero must follow the last data byte. This extra padding byte is not counted in the chunk size, therefor a program must always word align a chunk headers size value in order to calculate the offset of the following chunk.

Next version of Polyphone will include this fix.