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 > MOD format - question about 'period'

#34035 - gbawiz - Wed Jan 12, 2005 10:17 pm

Hello,
Im a bit confused with the subject of periods.
I have been reading about them and the documents say that you should not store the note as period values (even although they are stored that way in the MOD file itself).

What should they be stored as?

Another question is regarding the period values.
When I looked into the file with a fileviewer and interpreted the period values according to the period table also shown in the documents I find that the corresponding note stored is different from that shown in the tracker when I load the file.

for example:
a period value of
254 in the table indicates A-2 but in tracker it is A-5
214 in table indicates C-3 but tracker says C-6
339 in table indicates E-2 but tracker says E-5

They are all showing up in tracker with 3 added (three octaves?)

Why is this, any ideas?

Thanks

#34036 - tepples - Wed Jan 12, 2005 10:22 pm

gbawiz wrote:
When I looked into the file with a fileviewer and interpreted the period values according to the period table also shown in the documents I find that the corresponding note stored is different from that shown in the tracker when I load the file.

for example:
a period value of
254 in the table indicates A-2 but in tracker it is A-5
214 in table indicates C-3 but tracker says C-6
339 in table indicates E-2 but tracker says E-5

They are all showing up in tracker with 3 added (three octaves?)

That's because the note range for Modplug Tracker is bigger than the note range for Protracker was. Modplug can reach C-1 to B-8 or so; Protracker was limited to its C-1 through B-3, which correspond to Modplug's C-4 through B-6.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#34038 - gbawiz - Wed Jan 12, 2005 10:27 pm

Quote:
That's because the note range for Modplug Tracker is bigger than the note range for Protracker was. Modplug can reach C-1 to B-8 or so; Protracker was limited to its C-1 through B-3, which correspond to Modplug's C-4 through B-6.


I am using modplug tracker to load the files.
would they appear different in other trackers?

Im confused as to why the modplug tracker would choose to display this value instead of the one which is in the MOD file.

#34040 - poslundc - Wed Jan 12, 2005 10:31 pm

gbawiz wrote:
Im confused as to why the modplug tracker would choose to display this value instead of the one which is in the MOD file.


Like most composing software, it's designed for people who want to track music effectively, not for people who want to understand or pick apart the internal workings of the file format.

Dan.

#34041 - gbawiz - Wed Jan 12, 2005 10:35 pm

poslundc wrote:
Like most composing software, it's designed for people who want to track music effectively, not for people who want to understand or pick apart the internal workings of the file format.


I 'pick apart' the format so that I can understand how it is laid out in order to create my own 'Converter'.
Its no use trying to create a converter which will create notes which are false.

#34045 - DekuTree64 - Wed Jan 12, 2005 11:04 pm

Yeah, you'll probably want to write your own converter. There's a lot of work to be done, but none of it is particularly difficult.
The exact format of everything should be whatever makes your player easy to write. Granted, you can't really write a player until you have some data to work with, so you'll just have to do the best you can, improving the converter as you write the player.
For notes, I'd suggest converting the period to a note number (12 notes per octave), and make a lookup table of frequencies in Hz for each note.

I'm working on a GBA sound/MOD player tutorial, which can be found on my site here, down toward the bottom. Day 3 is specifically on writing a converter program, so hopefully that can give you an idea where to start.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

#34049 - tepples - Wed Jan 12, 2005 11:41 pm

DekuTree64 wrote:
For notes, I'd suggest converting the period to a note number (12 notes per octave), and make a lookup table of frequencies in Hz for each note.

That won't help with pitch slides (MOD effects 1xx, 2xx, 3xx, corresponding to S3M effects Fxx, Exx, Gxx), which work on period values. You really have to make your lookup table from notes to Amiga periods and then convert your pitch values from Amiga period to mixer frequency every frame (that's about one division for each channel that has a new note or a pitch effect, not too bad even if you use the BIOS divide), or you can use Amiga periods with a little conversion (something like GBC_period = 2048 - Amiga_period * 300 / 256; if it's off by an octave, change the 256) on the GBC tone generators if you decide to implement those.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#34050 - DekuTree64 - Wed Jan 12, 2005 11:56 pm

tepples wrote:
That won't help with pitch slides (MOD effects 1xx, 2xx, 3xx, corresponding to S3M effects Fxx, Exx, Gxx), which work on period values. You really have to make your lookup table from notes to Amiga periods and then convert your pitch values from Amiga period to mixer frequency every frame


True that pitch slides can't be done directly on the linear Hz frequency, but with some mathematical optimization, you can convert Hz to period, slide, and back to Hz only using one divide.
You still have at most one divide per channel per frame, and the more common case of just playing a note can be done with only a lookup.

The final formula is
newHz = AMIGA_VAL*oldHz / (AMIGA_VAL+slide*oldHz)
Where AMIGA_VAL is 3579364 (or 8363*428, or baseFreq*basePeriod). I don't remember off the top of my head exactly how I came to that, but it works, and I'll have it in the next issue of the tutorial.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

#34106 - ProblemBaby - Thu Jan 13, 2005 6:14 pm

DekuTree: does it exist a formula like that for linear freq table?
Now Ive a big LUT (about 32kb) with all possible Periods it works splendid but maybe its a bit of waste!

#34111 - tepples - Thu Jan 13, 2005 6:35 pm

ProblemBaby wrote:
DekuTree: does it exist a formula like that for linear freq table?
Now Ive a big LUT (about 32kb) with all possible Periods it works splendid but maybe its a bit of waste!

Time/space/accuracy tradeoff: You can try cutting down your LUT to 4 KB and using linear interpolation to get the missing values. Or you can try storing only one octave of the LUT and then halving/doubling the inputs and outputs. Or do both.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#34123 - DekuTree64 - Thu Jan 13, 2005 8:48 pm

ProblemBaby wrote:
DekuTree: does it exist a formula like that for linear freq table?
Now Ive a big LUT (about 32kb) with all possible Periods it works splendid but maybe its a bit of waste!


I assume your table is 16 bits*5 octaves*12 notes*256 finetune levels? You should at least be able to chop off the finetune levels and interpolate between notes. The standard interpolation formula is
(a*(256-x) + b*x) / 256
Where x ranges from 0-256. Then you can rearrange as follows to make is faster:
(a*256 - a*x + b*x) /256
(a*256 + x*(b - a)) / 256
(x*(b - a) / 256) + a
Which is only 3 instructions (sub, mul, add w/ shift). Actually, the time to load the second period from the table will be more than the whole calculation.

I think you'll get some slight inaccuracies doing that if you store your table as linear Hz values instead of periods, because of the non-linearness of the periods. Like, half way between 2 periods does not correspond to half way between their frequencies. As tepples said, just a trade of ROM for being forced to do the period-to-Hz conversion every note. Either way should be fine.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

#34325 - gbawiz - Mon Jan 17, 2005 10:25 pm

Hello and thanks guys for the advice.

Im a bit confused with the idea of finetuning.
I read about the case that it is better to store the notes as note-numbers and use these numbers to access a lookuptable to get the amiga period values which are then converted to Hz.

I have a couple of questions:
1. why use the note-number & lookup table method instead of storing period values.

2. I assume that the fine-tune settings are stored in the sample information only but I was wondering how these fine-tune values are applied to the note-numbers which finally result in the frequency to play.

Thanks in advance for any advice, much appreciated

#34332 - tepples - Tue Jan 18, 2005 2:38 am

gbawiz wrote:
I have a couple of questions:
1. why use the note-number & lookup table method instead of storing period values.

Some would claim that conversion to note number is necessary for the "arpeggio" (0xy) effect, although I know how to implement arpeggio without touching "note numbers".
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#34365 - gbawiz - Tue Jan 18, 2005 3:37 pm

Im a bit confused about the finetuning,
looking at a clip of the period table from FMODDOC.TXT shown below, there the finetune is mentioned.
Do these finetunes refer to the value which is stored in the sample information block for each sample?
Also are there any other finetuning settings not in sample (i.e in any effects or song info) and if so then which get priority?

--------------------------------------------------------------------------------------
; Tuning 0, Normal
dc.w 856,808,762,720,678,640,604,570,538,508,480,453 ; C-1 to B-1
dc.w 428,404,381,360,339,320,302,285,269,254,240,226 ; C-2 to B-2
dc.w 214,202,190,180,170,160,151,143,135,127,120,113 ; C-3 to B-3
; Tuning 1
dc.w 850,802,757,715,674,637,601,567,535,505,477,450 ; same as above
dc.w 425,401,379,357,337,318,300,284,268,253,239,225 ; but with
dc.w 213,201,189,179,169,159,150,142,134,126,119,113 ; finetune +1
; Tuning 2
dc.w 844,796,752,709,670,632,597,563,532,502,474,447 ; etc,
dc.w 422,398,376,355,335,316,298,282,266,251,237,224 ; finetune +2
dc.w 211,199,188,177,167,158,149,141,133,125,118,112
--------------------------------------------------------------------------------------

#36389 - gbawiz - Fri Feb 18, 2005 5:23 pm

Hello all,
I have been looking at programming my mod player after getting the mixing stuff out of the way.
I have been reading about the method of creating a period table which generates periods which correspond to all note periods and all notes with finetunes applied.

I have a couple of queries:
1.) how are effects applied when using a period table?
2.) Are period tables necessary, why not use the magic formula instead?

Thanks