search

steffest / BassoonTracker

Webbased old-school Amiga music tracker in plain old javascript - Plays and edits Amiga Mod files and FastTracker XM files
http://www.stef.be/bassoontracker/
MIT License
1.02k stars 61 forks source link

tweak clipping of .XM so that it matches ft2(-clone)/milkytracker #93

Open coderofsalvation opened 2 weeks ago

coderofsalvation commented 2 weeks ago

I've noticed that milkytracker & ft2-clone clip in exactly the same way, but bassoontracker not (it has much more headroom, perhaps because of the higher float-resolution?).

I was talking to 8bitbubsy (ft2-clone) about the fact whether there's even something about it in the spec. He said:

"At full amp in the FT2 config screen (32x), one voice equals full volume (0dB, peak). And about clipping, FT2 clamps the final 16-bit value after mixing of all voices is done, right before it sends the mixed stereo stream to the sound card So it has a 32-bit integer mix buffer"

Maybe we can clamp the mix to 16 bit values (and adjust 0db to the maximum value of 16bit?) so that it clips everything beyond that?

kind regards,

Leon

background: some of my modules (and other producers who use daws) use clipping in a musical way (boost transients of a mix to pierce through other sounds, which are shaven off when clipped, to increase perceived loudness).

coderofsalvation commented 2 weeks ago

how to reproduce:

use a normalized sample (bassdrum e.g.) as follows:

image

row 8 and 12 should start clipping (beyond 0db)

steffest commented 1 week ago

Hmm... good point... Internally, because it's using webaudio, all sample data ends up as floats, indeed, affecting clipping. (and other things) BassoonTracker doesn't do any mixing in script, it just hands that over to webaudio, so there's no easy way of clamping that final mixed value to a 16 bit int. I'll have a think about that.

coderofsalvation commented 1 week ago

interesting challenge indeed.

It turns out "JavaScript Numbers are Always 64-bit Floating Point", so at least that's a fixed size which can be worked with (before sending it to WebAudio)..so I guess somewhere values exceeding 16bit needs to be shaven off...and then normalized back to 64bit floating point.