Trackers that do 14-bit sound on 68000?

[ChaosLord]

I don't know, he would have to write his original explanation a little more clearly.  Maybe I misunderstood.

Let me say it another way:
I don't know how to magically cut sounds out of an mp3.

An mp3 is compressed.  You cannot just arbitrarily cut a piece of sound out of it.  The file is compressed in blocks.  At a minimum you would have to cut at a block boundary.

It is a basic rule of computer science that compressed data must be UNcompressed first before you start manipulating it.


Just like you can't magically cut 3 seconds out of the middle of a .lha file.  First you must UNcompress the .lha file into a normal file.  Then you cut the data.

[ChaosLord]

Sorry, but I don't follow your argument.  MP3 encoding is a lossy encoding format, i.e the frequencies that are removed are done so at the encoding stage.

True of course.

  When you listen to an MP3

Nobody listens to mp3s.  You listen to a wav.

Your mp3 player decompresses the mp3 into a wav and then sends the wav to your speakers.

 or de-encode one to a WAV, they should be identical.  i.e. you cannot "get back" lost frequencies by un-encoding an MP3 back to a WAV.

Nobody claimed to get back any lost frequencies.  Any lost frequencies are lost forever.

A 3-second sound clip of an MP3 or the same 3-second clip of this mp3 converted back to a WAV should sound identical.

Yes they will sound identically awful.  They will sound nothing like how they sounded when you listened to the song in its entirety.

Granted, an mp3 is always inferior to the ORIGINAL master wav, but the two 3-second test clips both derived post-encoding process should sound the same.

There is only one 3 second test clip.  Not 2.  You are really making this confusing




Let me try again:
1. Save your .mp3 song file as a .wav (This is so you can CUT pieces out of it, nothing more!)

2. Pick out a kewl sample that you want to use in your new Octamed SoundStudio Remix and cut that out and save it as TestClip.wav

3. Listen to the clip you just cut.  It will sound yucky.

Every time I have ever done the above steps I end up with a sample that sounds really weird and unpleasant.  This is why ppl say "mp3 sux, gimme a FLAC".

[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.

[ChaosLord]

I don't think this is correct. Or rather, I don't believe existing calibrated/uncalibrated cybersound drivers for Paula work this way.

I believe you are correct.

Not that I have ever looked at the code or anything.  So who really knows how it really works.

The channel joining method is just how I assumed it worked since that method automatically seems to provide only 14 bits of resolution.  While ottomh it seemed like if you played real samples on 2 channels at once you would get 16 bit resolution.

According to what I read 14-bit replayers don't using channel-joining technique.

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

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.

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).  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.

[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).

[bloodline]

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).

Would that have worked? If you have a particularly loud transient, that would exceed the sample delta, unless you have a very high sample rate... Which would eat up memory :-/ no matter how you look at it, if you want better than 8bit audio, it's going to cost a lot of memory...

Ahhh, just thought a bit more... You mean Paula would accept an encoded bitstream, so the loud transients would still be 16bit, but the rest of the stream would be 8bit deltas... Yeah that would have totally rocked... Basically HAM for audio

[Ral-Clan]

So....just from a hypothetical perspective then, does a stock 68000 even have the horsepower to do 14-bit audio?

I seem to recall seeing a demo a few months ago posted here on A.org (link to YouTube video) where an A500 was playing an uncompressed WAV off a hard-drive in 14-bit audio.

[Britelite]

So....just from a hypothetical perspective then, does a stock 68000 even have the horsepower to do 14-bit audio?

I seem to recall seeing a demo a few months ago posted here on A.org (link to YouTube video) where an A500 was playing an uncompressed WAV off a hard-drive in 14-bit audio.

The 14bit part is not the problem on 68000, but rather what you want to play. Uncompressed audio is easy, and even some compressed formats. But mixing several channels in software might require too much cpu-power.

[Amiga_Nut]

In a way, whether Jay Miner knew it or not at the time, he has provided you with the same facility he provided the 8bit Atari home computers via POKEY sound chip. You can have 4 8 bit resolution channels or two 16 bit ones (not the same as 8/16 bit samples...think more like Commodore 64 SID oscillators etc vs Yamaha AY/YM style sound accuracy).

So you can have stereo ie 2 channel 14 bit style quality or you can have 2 stereo/4 mono 8 bit quality sounds.

Would be nice to hear a tracker style tune using 2 14bit channels, vs the same audio with 8 bit samples to hear the difference (the samples being created digitally from a 16bit source in both cases of course).

[psxphill]

The 14bit part is not the problem on 68000, but rather what you want to play. Uncompressed audio is easy, and even some compressed formats. But mixing several channels in software might require too much cpu-power.

Yeah, I think people were overlooking that taking paula's 4 x 8 bit channels and turning them into 2 x 14 bit channels would be a bit of a problem for a tracker.

I'm pretty sure none of the existing 8 channel mixing routines were fast enough for the 68000, but that doesn't mean it's not possible. You'll either clip or lose accuracy anyway with that many channels. 4 channels is probably doable and doesn't lose much.

The locking of channels together isn't really a problem, if they are played at the same period then they should be fetched on the same line as the dma slots are tied to the video horizontal refresh. I'm not sure if the fetching at different times is a problem as the way the audio output works is more complex than just outputting to a dac and it doesn't appear to be synced to loading the register.

[Jpan1]

I am not sure about the technical abilities of 14 bit output on a 68000, but I noticed that the slowdown from Octamed Soundstudio on a Amiga 1200 without expansion leads to less channels for processing. I made this track on an A1200 without expansion, and got up to 6 tracks in 14bit mode. I also used 8 track mode like on Okatalyser but found that I had more processing power over individual tracks with 14bit mode. Including echo and reverb mixing...I actually preferred making Amiga tracks with the 14bit processing format instead of 8 channel splitting between the 4 channels possible.

https://drive.google.com/file/d/0BwAjjiP66Wo2SGRXR2tSTzJxbjQ/view?usp=sharing

[QuikSanz]

Would the Prima Megamix improve this, If it comes out? Does it use any part of Paula?