WAV file error bad length/truncated file

SDK Get Help
,
1

Hello, I have trouble using one of my WAV audio file. When I try to load it, it gives me the error "Error in WAV file: bad length/truncated file" then it crashes my game with the typical "pdxinfo file not found".
If I don't try to load this WAV file, the games run fine (but obviously, without the sound).

I tried re-exporting my sound, adding seconds of blank at the end but it doesn't resolve my problem.

Here is the sound. Can you spot the problem ?
Sound.zip (263 Bytes)

My code is just this :

local ssp <const> = playdate.sound.sampleplayer

soundMainTheme = ssp.new("audios/MainTheme")

soundSwipes = {
    ssp.new("audios/Swipe1"),
    ssp.new("audios/Swipe2"),
    ssp.new("audios/Swipe3"),
}

soundEat = ssp.new("audios/Eat")

All other sound are working fine.

2

The incredibly tiny length of the WAV makes me suspicious. Are you sure it's being compiled to a .pda along with the rest of the sounds?

3

No it does not. That's the problem.
I tried making the sound longer by adding 10 seconds of silence and re-exporting it but it does not work either.

4

The RIFF header has a size of 154 bytes but the actual chunk is 153 bytes; the parser is complaining because header+154 bytes is past the end of the file. Adding a padding byte at the end of the file fixes it:
Eat.wav.zip (787 Bytes)

What did you use to create that file? I'm not sure whether or not it's in-spec to have the RIFF size off by one like that, but I don't recall seeing this before. I guess 8 bit files aren't as common.. I'll add a workaround.

5

tl;dr:

Technically, this file doesn't match the RIFF spec from 1991, and should have a padding byte added to the end of the data chunk (like Dave did, by adding it to the end of the file)

I'm also curious what software generated the file. Maybe we can fix it or ask them to fix it.

Maybe too much info follows (please ignore if not interesting!):

RIFF spec: https://www.mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Docs/riffmci.pdf (alternate location because it's no longer hosted by MS or IBM)

The spec says this in the "Chunks" section:

ckSize
A 32-bit unsigned value identifying the size of ckData. This size value does
not include the size of the ckID or ckSize fields or the pad byte at the end of

ckData
Binary data of fixed or variable size. The start of ckData is word-aligned
with respect to the start of the RIFF file. If the chunk size is an odd number of
bytes, a pad byte with value zero is written after ckData. Word aligning
improves access speed (for chunks resident in memory) and maintains
compatibility with EA IFF. The ckSize value does not include the pad byte.

As a hobby, I'm trying to better understand WAV files by writing a parser. Looking at this file, it outputs:

      offset id         size summary
          12 fmt          16 PCM (0x1), 1 chan, 8/11025
             |             format_tag : WAVE_FORMAT_PCM (0x1)
             |               channels : 1
             |        samples_per_sec : 11025
             |      avg_bytes_per_sec : 11025
             |            block_align : 1
             |        bits_per_sample : 8
             --------------------------------------
          36 data        117 audio data

And looking at the file in a hex editor to double-check (hexfiend for MacOS has a great WAV parsing script built in), we see the same thing, the size of the data chunk is listed as 0x75000000 --> 117 bytes and the chunk itself is 117 bytes long.

Screenshot 2024-03-04 at 16.26.14
Screenshot 2024-03-04 at 16.26.141830×1170 242 KB

The 117 number is correct, but the actual data in the chunk should be 118 bytes total, with a 0x0 byte appended.

2 Likes
6

Unfortunately I don't know how or when this file was created ! This is a really old file given to me by someone else (with a bunch of other sound with the same problem) and he doesn't know either...

I could resolve this issue by passing it trough an online converter, tho.