Trackers that do 14-bit sound on 68000?

[Karlos]

@bloodline

IIRC, 14-bit replay requires cycle exact synchronization between the paired channels that are used to play the MSB/LSB halves of your 16-bit sample. I think that the 14-bit routines bypass Paula DMA sample replay all together and give her (registers) a good poking. Either that, or they pre-fill short buffers for each channel and then trigger her to replay them directly.

Either way, I am not sure that trying the replay as channels in a tracker will work. A simple test would be to play a regular sample on a channel and it's inverse on a channel on the same side. If they cancel each other out completely (or almost completely) then your plan seems plausible. Otherwise, even a sub-millisecond latency between two channels is going to sound dreadful.

[Karlos]

It is bit for bit identical.  That is the point.  And it "sounds" perfect.

Now cut a piece out.

Listen to the piece by itself.

It will sound like crap.  All kinds of weird distortion.

When you remove the illusion the distortion becomes obvious to anyone.  Its weird.

It's not that weird. MP3 isn't just about conversion of amplitude/time domain to frequency/phase domain (and subsequent quantization into bands). Even before that, pretty sophisticated algorithms are applied that account for the way in which sound is perceived and also how the ear reacts to sudden changes in volume. Collectively, this is the Psychoacoustic Modelling part of the encoding and it's used to make quantitative decisions about where to discard information about sound you won't perceive well because of the state your ear and auditory cortex will be in given the most recent sounds you have just heard.

For example, when there's a sudden increase in volume, the ear physically responds by tightening the tympanic membrane, which results in a loss in sensitivity. If a quiet sound immediately follows again, your ear takes some time to relax again and the cells responsible for reporting certain frequencies will be recovering too. You won't hear the quiet part as well as you would without being exposed to the previous sound and it may be that you are especially desensitised to certain frequencies for a moment. All of these phenomena and more are used by the PM stage to work out what it can discard that you won't notice.

So, when you take a sample out of the middle of a MP3 track that's had a good PM algorithm applied, particularly if the sample comes from a region following a sudden transient change in volume, pitch change or whatever, without that preceding cue, you are left with audio encoded in a manner your ear is not expecting and you likely will notice encoding artefacts as a consequence.

[Karlos]

No.
14-bit audio works by using Paula's built-in for free Channel Locking function which locks 2 channels together into 1 channel.  1 of the channels provides 8-bits of data and the other channel provides 6-bits of volume control.  They are fed with the normal DMA mechanism, otherwise it would be quite useless.

I don't think this is correct. Or rather, I don't believe existing calibrated/uncalibrated cybersound drivers for Paula work this way. If they did, you have the following problem to solve, for every 14-bit output value you intend to emit:

SampleValue14 = ChannelVolume * SampleValue8

where ChannelVolume is 0-63 and SampleValue8 is -128 to 127.

The problem with this is that there are many ways to factorise the 14-bit value you want or a value close to it. As an example, suppose your target SampleValue14 is 2048 (which would represent an instantaneous value equivalent to 0.25x the maximum positive value). Do you choose

Favouring larger ChannelVolume :
ChannelVolume = 63, SampleValue8 = 32 (2016)
ChannelVolume = 63, SampleValue8 = 33 (2079)
ChannelVolume = 62, SampleValue8 = 33 (2046)

Favouring exact factorisations:
ChannelVolume = 32, SampleValue8 = 32 (2048)
ChannelVolume = 16, SampleValue8 = 64 (2048)

Favouring larger SampleValue8:
ChannelVolume = 16, SampleValue8 = 127 (2032)
ChannelVolume = 17, SampleValue8 = 120 (2040)

In this trivial case, we have 2 exact factorisations we could use and an entire spread of close approximations for the case where we favour larger channel volume or where we favour larger sample value.

You can make a lookup table, of course, but even if you did, how do you decide which pair of values to use for any given target value? Moreover, this model requires that both the channel volume and 8-bit sample values behave linearly, which they don't particularly. Such a table would also be rather large.


As far as I know, 14-bit replay uses a summed approach as follows:

SampleValue14 = ChannelVolume63 * (SampleValue16MSB) + ChannelVolume1 * (SampleValue16LSB/4)

Moreover, this summation is not perfect since the operation divides the LSB by 4 (basically discarding the least significant 2 bits of data) but only multiplies the MSB by 63, rather than 64. However, this can be rectified by replacing the second term with a small lookup of adjusted values that when summed with the MSB give a better approximation of the desired output value. Beyond that you only need to worry about the true factor by which ChannelVolume63 is than ChannelVolume1 and calibrate accordingly to get a close to linear output.

[Karlos]

The channel joining method is just how I assumed it worked since that method automatically seems to provide only 14 bits of resolution.

You probably could, the only issue is in how best to factorize samples into their volume/value pairs and how you cope with the non-linearity of two factors (rather than just one).

According to what I read it plays 2 samples at once, 1 at full volume and 1 at volume 1 (or something like that).

Indeed, that's what I was alluding to. The idea is that the least significant eight bits* of the data are played on the channel at volume 1 and the most significant 8 are played at volume 63 with the channels exactly in sync. The calibration (if performed) takes care of the fact that the most significant channel isn't actually 63x times louder (when viewed linearly) than the least significant one and that the bits aren't perfectly assignable due to this fact. If both the volume controls and DACs were linear and we had 8-bit volume controls (rather than 6-bit ones), we could get a very good approximation of 16-bit for not a lot of CPU time.

*and here's the problem, the volume only goes down to ~1/64th rather than 1/256th, consequently we have to divide the LSB by 4.

The calibration, at least, doesn't result in a large lookup. It's fairly cache friendly on 040 or better.

What I do know is that 14-bit players feel computationally heavy.  They always drag down my cpu.  After reading your msg I guess the 14-bit players have a ton of work they have to do.

The Fast 14-bit modes weren't too bad back in the AHI 4 days. Something happened after then that made everything seem a lot slower.

14-bit players have to take an incoming 16-bit unsigned sample and convert it to signed, split every single 16-bit value into 2 halves (one half goes to one paula channel and the other half has to goto another paula channel).

Well, the 16-bit data will generally be signed, rather than unsigned. What might be more of an issue is whether or not Paula herself is responsible for changing the DAC output by reading from a Chip RAM buffer or whether it's basically PIO.

 Then do all that rigamorale that u talked about in your message.  Then repeat the whole process for the other side of the audio.  Ugh!

Having to do all that stuff 88200 times a second.  No wonder it drags my cpu

I am just happy that Paula allows this 100% perfect down to the nanosecond start-audio-on-2-channels-on-once concept to work.  Whoever designed that chip got a lot of things right.

It would have been even nicer if it supported 16-bit in the first place Or at least support 16-bit output with 8-bit delta encoded input (which can sound very good and would have been affordable in terms of memory use).