gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Audio > Most recent format specs for tracker modules

#16609 - animension - Fri Feb 20, 2004 9:28 pm

Hey guys,

I've done quite a bit of looking around for file format specs for various mod files. I found myself asking whether any of these specs have been updated more recently than the ones I found. Does anyone have any links to the definite most recent spec I can base my player on?

Also a question about the sample formats that weren't answered by the specs I found (which led me to believe the docs I found might be outdated). According to the XM spec ver. $0104 written in 1994 by Mr. H of Triton, there is no mention of stereo samples or how to store them, nor a bit flag in the instrument headers or sample headers indicating mono/stereo (in fact, the word "stereo" wasn't in the spec anywhere at all). However, I was able to store a stereo sample as a sample for an XM instrument using modplug. The same was true for IT files as well, where the spec said it wasn't supported (although there were flags for it). Is modplug using an implementation specific method to save stereo samples for these formats where there is no apparent support or specification on how they are stored? I would imagine they could be interleaved, but I know that S3M uses a non-interleaved format with separate blocks of data for left and right sides.

A final question: am I to understand that the XM stores its 8-bit format samples as sequential bytes of signed delta values, one for each new sample frame and that each frame's true value is a running sum of every byte up to that sample frame number? If so, that would be a pain to have to work with. (O.o)

Thanks for reading.


Edit: I have been considering writing a conversion tool that will take every module's sample data and just convert it to 8-bit signed PCM data, since there seem to be enough variations in the sample formats to warrant unifying them into one format prior to playback processing.
_________________
"Beer is proof that God loves us and wants us to be happy."
-- Benjamin Franklin

#16626 - headspin - Sat Feb 21, 2004 3:07 pm

Found this on Google, might be helpful

Quote:
I found these definitions in DUMB's source code (presumably put there by Julien Cugni?re who did the XM support):

#define XM_SAMPLE_NO_LOOP 0
#define XM_SAMPLE_FORWARD_LOOP 1
#define XM_SAMPLE_PINGPONG_LOOP 2
#define XM_SAMPLE_16BIT 16
#define XM_SAMPLE_STEREO 32

These values are used to interpret a byte read from the file for each sample. I'm sure you will have found the looping information, so you'll know which byte it is.

When DUMB finds a stereo sample in an XM file, it halves the length, loop start and loop end that it read from the file. When reading the sample data, it reads 'length' samples for the left channel, followed by 'length' samples for the right channel, where 'length' has already been halved. This is all correct with the possible exception of halving the loop points; I do not know if this has been tested deliberately, but as far as I know it has never caused something to play wrongly. If you feel like testing this case, do post here and let me know whether the loop points should be halved. Test with ModPlug Tracker, since I suspect ModPlug defined the 'stereo' flag in the first place. (Halving the length is certainly correct; it is just the loop points that I'm not sure about.)