ModPlug Central

OpenMPT => Development Corner => Topic started by: vince94 on June 18, 2021, 20:19:00

Title: Loop points in WAV files exported from OpenMPT
Post by: vince94 on June 18, 2021, 20:19:00
I'm looking at creating a simple python script to help convert WAV files to SNES BRR files using BRRTools. (https://github.com/Optiroc/BRRtools (https://github.com/Optiroc/BRRtools))
BRRTools supports loop points, but you have to specify the start point manually in the command line arguments - it doesn't detect whether or not a loop point is present in the WAV file or not.
The idea I want to make is a simple script that finds the loop point, and calls BRRTools with all the appropriate args in place.
From googling around, I get the impression that WAV files weren't meant to have loop points in them at all, and music programs like OpenMPT kind of do their own thing to insert that data. Is this footer documented anywhere?
(https://i.imgur.com/gUroVGC.png)
Title: Re: Loop points in WAV files exported from OpenMPT
Post by: Saga Musix on June 19, 2021, 12:08:11
I wonder what gave you the impression that WAV files aren't meant to support loop points, because the "smpl" chunk has existed for more than 25 years. It's documented here: http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Docs/RIFFNEW.pdf

Also please note that this is not a "footer". RIFF chunks can appear in any order in the WAV format, so it's possible that e.g. the "smpl" chunk appears in front of the "data" chunk rather than right after it. Any proper WAV reader needs to support chunks appearing at arbitrary points in the file, and not expect them to be placed at a specific byte offset.
Title: Re: Loop points in WAV files exported from OpenMPT
Post by: vince94 on June 20, 2021, 03:02:43
Oh, dang, I had no idea. How should I get the correct offset then?
Title: Re: Loop points in WAV files exported from OpenMPT
Post by: Saga Musix on June 20, 2021, 12:54:02
Maybe use http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/WAVE.html as a starting point.

In summary:
After the 12-byte RIFF header, you have an arbitrary number of chunks which all start with an 8-byte heade: 4 bytes that identify the type of chunk ("fmt ", "data", "smpl", etc.) followed by a 32-bit integer that contains the length of the chunk. Note that chunks with an odd size are padded to an even size. In practice this only affects 8-bit mono samples: If the length is odd, you have to skip another byte after the end of the sample to read the next block.
Typically you'd first create a list of a chunks in a file by scanning their headers, and then look for the chunks you need (e.g. the three chunks mentioned above) in that list.