Preparing, fixing, and loading samples for Intellijel Multigrain

Matt Dennewitz

Matt Dennewitz

— 2 min read

Intellijel’s Multigrain is a fantastic module for granular synthesis. However, as of firmware v1.1.0.0, loading custom WAV files can be frustrating. Some files — even when they seem correctly formatted — won't load. After troubleshooting, I discovered the issue was due to subtle structural problems in the WAV file headers. Here's how I fixed the issue with ffmpeg.

tl;dr: Multigrain won't read WAV data when critical structural problems are present in the headers. Use ffmpeg to rebuild correct headers. Scroll to the bottom for the ffmpeg recipe that solved my problem.

I have a collection of samples that I'd like to load onto Multigrain. I copied them onto the included SD card, into the /WAVS path. Multigrain, however, did not recognize them, meaning it was ignoring wave files it felt to be mis-formatted or corrupted.

According to Multigrain firmware v1.1's manual, samples must be:

  • 16-bit PCM
  • 48khz
  • Stereo
  • < 32 sec

The samples I attempted to load were ostensibly compatible:

Metadata:
    encoder : Lavf61.7.100
Duration: 00:00:02.77, bitrate: 1536 kb/s
Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, stereo, s16, 1536 kb/s

For comparison, here is analysis from one of the stock samples:

Duration: 00:00:10.17, bitrate: 1536 kb/s
Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, stereo, s16, 1536 kb/s

So, why won't they load? There was an issue in with how this file's headers are constructed. The WAV files I was trying to load had LIST chunks where data chunks were expected. In a proper WAV file, after the fmt chunk describing the audio format, the data chunk containing the actual sound samples should appear. Some of my files had a LIST chunk (extra metadata) inserted instead, which confused Multigrain’s strict parser. This was confirmed using xxd.

Here are the first 44 bytes from the stock sample I used for comparison:

00000000: 5249 4646 b0f3 0d00 5741 5645 666d 7420 RIFF....WAVEfmt
00000010: 1000 0000 0100 0200 80bb 0000 00ee 0200 ................
00000020: 0400 1000 6461 7461 20ec 0d00 ....data ...

And from the "bad" sample:

00000000: 5249 4646 221d 0800 5741 5645 666d 7420 RIFF"...WAVEfmt
00000010: 1000 0000 0100 0200 80bb 0000 00ee 0200 ................
00000020: 0400 1000 4c49 5354 1a00 0000 ....LIST....

Weird, right?

This can be fixed a few ways with ffmpeg: you can do a full decode and (re)encode cycle, or (as I chose to) a more straightforward header rebuild.

Fixing the issue with ffmpeg

This ffmpeg invocation will ensure compatibility with Intellijel's specs, remove metadata, prevent encoder-specific header additions, and force strict RIFF/WAV compliance. 

ffmpeg -hide_banner -loglevel info \
  -i input.wav \
  -c:a pcm_s16le \
  -ar 48000 \
  -ac 2 \
  -fflags +bitexact \
  -flags:a +bitexact \
  -map_metadata -1 \
  -write_xing 0 \
  output.wav

If that's not working, you can attempt a brute-force correction by decoding and (re)encoding the file:

ffmpeg -i input.wav -f wav - | \
ffmpeg -i - -c:a pcm_s16le -ar 48000 -ac 2 -fflags +bitexact output.wav

Intellijel's v1.1 firmware update expanded the module's ability to read and interpret WAV file headers. Maybe the device will become even more capable with unexpected or bad headers, but for now, this works.

Read more