Floating Point Samples - richardjwild/arctracker GitHub Wiki
I had now pretty much refactored everything I really wanted to clean up and the project structure was good enough that I'd be happy to take it home and meet my parents, so it was time to start tackling some improvements I wanted to make. The one highest on my backlog was that I wanted to convert the logarithmic samples to linear PCM as soon as the module was loaded, rather than converting them during playback. The reason was that this was a prerequisite for me to make two further changes that I wanted to make:
- Introduce linear interpolation in
resample.c. - Make the gain adjustment in
gain.cwork by linear multiplication.
While the first change required converting the samples to linear PCM, the second change additionally required that the samples would be represented as floats, not integers. This is actually standard practice in professional audio software, to represent samples internally as 32-bit floats, and only convert to 16-bit PCM at the final output. This means that clipping is effectively impossible internally; it is only when the audio signal gets sent to the interface that this might occur.
This felt like too big a change to make all in one commit, so first I converted the 8-bit logarithmic samples to linear floating-point on module load and I temporarily disabled the volume effects because I would need to think about how to make these work correctly. The difficulty was that Tracker and Desktop Tracker volume commands (and sample volumes) were logarithmic, not linear, so simply multiplying the samples by the volume would make things sound wrong (too loud). I also replaced the mu-law to linear conversion table with a new function in mu_law.c that calculated the conversion at runtime.
Next I reimplemented internal gain control while converting the logarithmic volume values to linear gain correctly, which seemed to work okay, although it did not take account of the difference between Tracker and Desktop Tracker volumes (the former ran from 0-255 while the latter from 0-127), so I added back support for that in the next commit.
I then introduced linear interpolation in the sample rate conversion code (i.e. playing samples back at different pitches), which caused a drastic improvement in sound quality. It turned out that the sort of "crunch" quality to the audio playback which I had attributed to the mu-law sample encoding was in fact due to the lack of sample interpolation. I now had a player which could play back tunes much better than a real Archimedes computer ever could.