SoundFont Decoder & File Size

[jbjb]

I've been using the wavetable synthesis library on a Teensy 4.1 and I'm trying to get public domain soundfonts to fit on to the teensy's PROGMEM. I've been doing some research and trying to understand the library and the decoder, but I was wondering if anyone could offer any insights to the questions below.

Why does the a decoded soundfont expand in size so drastically between its 'sf2' version? For reference, I am looking at this rhodes soundfont (https://www.polyphone-soundfonts.com...s/116-j-rhodes), who's samples are 44,1khz @ 16bits. Untouched, its ~13.2mb, and when run through the decoder, the file size is about 4x as large @ 65mb for the .cpp portion.

Why are samples converted into arrays of uint_32 ? Would it not make more sense to use a 16bit data type?

And finally, is it possibly to use expanded 4.1 flash memory to store the soundfont w/o having to modify the playback code?


Thanks!

[manicksan]

Still no answer??
Ok I will try
Using 32bit is surely because the cpu is 32bit
and will then optimize the reads from progmem (better fitting in the cache?)
Also using 16bit access on a 32bit cpu slow things down.

About the size
For every 4 raw bytes
You will instead get

0x00000000,

which will take 11bytes
Which is (11/4=2.75) times bigger

Also if you where to use 16bit

0x0000,

That would be (7/2=3.5) times bigger


Don't really know why it's 4 times bigger
As in theory it should only be around 2.75x

The last question I don't really know how you mean?
* Playback of sf2 file from flash FS ?

[manicksan]

I did also forget to say don't get fooled by the cpp size.
Think the convert tool do have flash usage, that will show how much space that particular soundfont takes, also notice that the current soundfont decoder is outdated and would not include the teensy 4.1 also it do not use progmem to make sure that the samples stay in progmem.

[jbjb]

Thanks Manicksan! This is very helpful.

You are correct the 4x size was strange, so I dug in and noticed that if a sample is re-used for multiple key-ranges inside of the soundfont, the program decodes the sample for each key range, rather than re-use the sample. If I find the time to solve this issue, I will share my updated code.

---

I'm actually using your updated soundfont decoder for the Teensy 4 / 4.1 (https://github.com/manicken/SoundFontDecoder), and I realized my copy was quite stale. I re-ran the decoder after syncing to your repo and here's what I found the various file sizes to be.

Soundfont file:
6.8mb
"Controller" from the decoder size estimate:
5147kb

Decoded cpp
14.4mb
Compiled Info:

FLASH: code:45376, data:5160840, headers:9012 free for files:2911236
RAM1: variables:25280, code:42184, padding:23352 free for local variables:433472
RAM2: variables:44096 free for malloc/new:480192



This is surprising! You are correct, thats an incredible difference when compiled! And much closer than I anticipated to the estimated file size in the decoder.

--
And as to my final question, I was wondering if adding on extra flash memory (https://www.pjrc.com/store/psram.html // https://protosupplies.com/product/w2...sh-for-teensy/ )) could allow for additional storage for a soundfont.