Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

@StephanRewind I was surprised yo read about looping issues while it was discussed on the forum with you in the thread. https://devforum.play.date/t/add-note-to-docs-regarding-limitations-of-ima-adpcm-wav-format-for-seamless-audio-looping/7686/26

Was this ever fixed in the playdate firmware? And why is adpcm-xq not a solution?

Yes I know. Unfortunately at the time I assumed it was fixed, but it turns out that I had been lucky in my first few loops, or I wasn’t paying enough attention to the clicks, which can be sometimes barely noticeable.

I always use ADPCM-XQ to convert my wav files, without which it would be a lot worse, but it’s still a roll of the dice. And even the latest firmware doesn’t fix this. I don’t think it can ever be fixed because it’s inherent to the block compression algorithm.

The best solution I found so far is to export all files with a 2 sec (would probably work with 1) buffer at the end, which repeats the beginning. Then I listen to the clicks and slide the loop section by adjusting the parameters, until I find the perfect loop. So something like:

Sample:setLoopRange( 1.1,  Sample:getLength() - 0.9 )

It’s tedious but it never fails. For the future I’m going to write a small tool that plays the file on repeat from  a couple of seconds before the end to right after the loop and let you adjust the loop range with the directional pad by small increments. That way I’ll be able to find the sweet spot quicker.

Good idea, to save time you could loop only 5 seconds around the boundary instead of the whole sample.

Yes that’s the idea :)