English Amiga Board (http://eab.abime.net/index.php)
-   Coders. Asm / Hardware (http://eab.abime.net/forumdisplay.php?f=112)
-   -   Amiga "14-bit audio" refuted (http://eab.abime.net/showthread.php?t=105355)

 orangespider 08 February 2021 20:52

This might be stupid or already refuted in some way, but kill me if I know why it wouldn't work.

Why not go with volumes 64/63 instead of 64/1?

It gives you 28480 combinations instead of the 16384 you get from the 14 bits and the lowest value you can send compared to peak signal is almost twice as low, as seen below:
14 bit variant:
min = 64*0 + 1*1 = 1
peak = 64*127 + 1*63 = 8191
lowest/peak = 1/8191

64/63 variant
min = 64*1 - 63*1 = 1
peak = 64*127 + 63*127 = 16129
lowest/peak = 1/16129

I know the conversion has to use a lookup for 64/63, but shouldn't it give better quality? Or is there something in the hardware that prevents this working?

 ross 08 February 2021 21:09

And apart from a sample with a loud volume you would get nothing but an 8-bit quantization (and some distortion) :)
A x-bit DAC work properly because it use a linear quantization (that exactly the problem to get it with Paula, the two summed channels are somewhat non-linear).

 orangespider 08 February 2021 21:18

Quote:
 Originally Posted by ross (Post 1460502) And apart from a sample with a loud volume you would get nothing but an 8-bit quantization (and some distortion) :) A x-bit DAC work properly because it use a linear quantization (that exactly the problem to get it with Paula, the two summed channels are somewhat non-linear).
Why? Is it not possible to mix a negative and a positive signal to get smaller output values?

 ross 08 February 2021 21:31

Quote:
 Originally Posted by orangespider (Post 1460505) Why? Is it not possible to mix a negative and a positive signal to get smaller output values?
Sure, but what do you do for the negative 'main' sample?
It simply generates the same inverted 8-bit value with some distortion (as long as they are in phase, otherwise..).
Try to make a complete table for the values, you find that there is no linearity.

EDIT: the truth is that here I (half asleep) had completely missed the part of the 'subtractive' method :D

You absolutely need to 'spread' the values as best as you can.
I wrote a message in this same thread about the boost of the L channel, the more you turn up the volume the more you lower the quantization bits.

 orangespider 08 February 2021 21:36

Quote:
 Originally Posted by ross (Post 1460509) Sure, but what do you do for the negative 'main' sample?
For a negative sample, you can add a smaller positive value to the larger negative value to get more precision.

edit: Or even add 2 negative values in some cases. You really don't care what you add as long as the result is the number you're looking for.

Quote:
 Originally Posted by ross (Post 1460509) It simply generates the same inverted 8-bit value with some distortion (as long as they are in phase, otherwise..). Try to make a complete table for the values, you find that there is no linearity.
I did. In the value range of -12350 to 12223 every single value is covered by a combination of a*64+b*63, you start to get missing values outside of that range. Note this range is still larger than the -8192 to 8191 of a 14 bit signal.

I still don't understand why this wouldn't work.

 ross 08 February 2021 22:16

Well, even this could be tried, maybe buggs (or Thomas or others..) has already thought about what can happen.
But Paula cannot mute itself with inverse polarity channels (due to phase difference).
Instead for same sign signals volume difference is small from the H channel and can somehow be calibrated.

I am terribly afraid that a strongly distorted signal will come out and at most 8-bit quantization /dynamics ... who knows maybe you are right and I am completely wrong.
And I wouldn't mind, any idea is a good idea if it works ;).

 Photon 08 February 2021 22:44

Well, this thread was not started to generate ideas, but to refute a claim that is not generally claimed, since 14-bit is not CD quality.

Now, the Amiga had sound cards available to add, and CD players built in, that could surely play high-quality audio.

The point about 14-bit audio was to generate high-quality sound without having to buy a separate sound card. And that, the Amiga can certainly do, and the PC certainly can't. Well, in the last decade it can, because PC mobos got chipsets approximating the name, and now most come with built in sound chips. :)

My experience with 1990s Soundblaster is that since it was unshielded, it picked up electronic interference from the other components in the case, making the PC useless for recording music. This did not change until 2003, when I bought my first gaming PC. So \$1500 -> \$3000 PC fixed it, and now we have external sound cards. The good ones don't pick up the dut-dut-dut interference from mobiles anymore. :great

 robinsonb5 08 February 2021 22:59

Quote:
 Originally Posted by orangespider (Post 1460511) I did. In the value range of -12350 to 12223 every single value is covered by a combination of a*64+b*63, you start to get missing values outside of that range. Note this range is still larger than the -8192 to 8191 of a 14 bit signal. I still don't understand why this wouldn't work.

It's got to be worth trying - even if it doesn't improve the sound quality over the existing 14-bit mode (or even if it turns out to be slightly worse) it has the benefit of boosting the playback volume, which for Amiga XM / S3M players is extremely low compared with regular MODs.

 orangespider 09 February 2021 01:45

Quote:
 Originally Posted by robinsonb5 (Post 1460546) It's got to be worth trying - even if it doesn't improve the sound quality over the existing 14-bit mode (or even if it turns out to be slightly worse) it has the benefit of boosting the playback volume, which for Amiga XM / S3M players is extremely low compared with regular MODs.
I did try it now, made a converter and then made a small executable that plays an 19 seconds audio with this system. I don't have access to a real amiga at the moment, but in winuae it works perfectly and has definitely better quality than the 14bit one. Will test it on a real amiga later or tomorrow, because emulators are one thing and the real hardware is another.

EDIT: Tested on A1200. This works! Anyone wants to make a player using this system? I don't have time for an entire project, but I can send you the code to convert from 16bit to this.

 lmimmfn 09 February 2021 02:19

Quote:
 Originally Posted by Thomas Richter (Post 1460035) Whatever you believe. CD audio quality is not possible. I'm out here, I measured what I wanted to measure, and made everything as transparent as I possibly can. If you want to provide better results - sure, go along. But that requires results and measurements, and not stomping on your foot.
Not sure im understanding? CD quality output is 16bit, Amiga output is arguably 11-14 bit, why the comparison with CD output quality when its not even in scope here?

 Bruce Abbott 09 February 2021 07:50

3 Attachment(s)
I made a daughter board for Paula so I can isolate the analog output pins to see what it really produces. I wired two 1k resistors across the power supply to provide a 500 Ohm load referenced to half the supply voltage. This can be applied to either channel via a flying lead.

For preliminary testing I played a full amplitude triangle wave into one channel. Here is the result and my analysis:-

At full volume Paula outputs an analog current that pulls up or down depending on the polarity of the sample, ie. 1 to 127 pulls up and -1 to 127 pulls down. At 0 there is no current so the output is open circuit.

Note that the current output is only linear when driving into a virtual ground at 1/2Vcc. With my resistor divider the triangle wave is badly distorted because current reduces as voltage deviates from 1/2Vcc. This is just an artifact of my termination method. When the filter circuit is connected it applies a virtual ground so the current should be linear.

At lower volumes the current is 'chopped' with a PWM ratio of 0-63 and period of ~55kHz. In the scope trace you can see that the on/off ratio at vol 31 is 50%. The chopping waveform is very clean and should be quite accurate.

Like all analog DACs, errors are expected due to the current generators not being precisely matched. A DAC is generally considered sufficiently accurate if the output doesn't deviate by more than 1 LSb (least significant bit), which guarantees monotonicity. But is Paula that accurate? It probably depends on the individual chip. I doubt that they were laser trimmed at the factory so some may be better than others.

For the next test I will attach an op amp to convert the current to a voltage. This should produce a linear output voltage for further analysis.

 nikosidis 09 February 2021 09:00

This is very interesting :)

orangespider: You might found a new way for higher quality. That is fantastic :)

Bruce: I'm very interested in what you are doing here. Is there a board you could sell that I could fit into my A1200?

 buggs 09 February 2021 09:02

1 Attachment(s)
Quote:
 Originally Posted by Thomas Richter (Post 1460413) Unfortunately with equipment I don't have access to. The aim of this little tool was to come up with a "home-made" experiment that works well enough to allow everyone to measure the difference.
The equipment is not overly important. I did my earlier measurements with the Line-In of a stock MBPro. Frequencies beyond 16 kHz (if attenuated by the receiving end) don't contribute much N to the SNR and as rumour has it, old folks don't hear much there or beyond :)

Quote:
 Yes, that's what I thought, too. Look, believe me, I tested the FFT, that's not rocket science. Yes, I do see the peak, but it's of course spread over multiple bins. However, when summing the error signal beyond the peak and setting this in comparison to the peak energy, I get completely non-sensical SNR values, i.e. there is way too much noise according to this estimate. Yes, it sounds perfectly trivial, I know. You don't need to tell me why the FFT would be the method of choice.
That's why I've mentioned windowing. It's effect of convoluting the frequency response of the relevant signal with the one of the window function is deterministic and more importantly similar enough in effect to warrant the same handling of the actual underlying cause (prominently: phase noise and strictly scientific: AR model vs. MA model). Both causes of the main lobe that can be observed in the spectrum are unrelated to the DAC itself. While phase noise is a relevant system parameter, it's in the way of SNR computation from long FFTs. Therefore, leave the main lobe around the signal center frequency out of the noise term. My script just puts a notch window with a bandwidth 10 Hz over the spectrum. A more adaptive solution could look for the first zero crossings of the first-order derivative of the PSD.

Example (A1200, 8 Bit):
Attachment 70822

Quote:
 I am not exactly clear where the high background noise is coming from. Probably my FFT is too long and numerical inaccuracies just pile up, I haven't tested that. I would probably need to split up the signal into multiple windows and sum over each window, but then what is the perfect window size.
In theory that shouldn't matter which also means that most textbooks won't cover this topic. While some time ago 1k-2k FFTs were commonplace in papers, 8k is a number you see often these days. Something like 8k + Blackman and/or Nuttall window + Bartlett averaging will do fine and you won't have to worry about the phase noise which drowns in the window.

Quote:
 Python is also fine with me, no worries. The FFT would certainly come froma a library, that in native python would be a bit on the slow side. That's also OK.
I'll convert that script to Python (or an iPython Notebook) once I've got a bit of spare time.

Quote:
 The requirements are exactly that: Input file is a wav, user gives sampling frequency (approximately) and playback frequency (approximately), the program or script needs to find the precise frequency (or adapt to it) and compute the SNR.
The computation doesn't need the first two parameters (note: strictly speaking sampling is at a rate, not a frequency) for SNR. It's a nice bonus to print out the detected fundamental, though.

Quote:
 Unfortunately, and that is part of the problem, that the average user has only a PC sound card at home, 16 bit resolution, 48Khz max. sampling frequency, with the potential risk that the sampling is even interpolated, so some inaccuracies are certainly present (such as some mild forms of aliasing). I wouldn't expect super precise results from this experiment - that is not the intent - but a practical experiment everybody can perform at home to measure the equipment.
Aliasing is not an issue. Frequencies beyond 20 kHz contribute very little to the noise term. What I worry more about is the actual capture process. Quite often people won't adjust their amplitude levels properly and get clipping/clamping or lose resolution by low amplitudes.

 ross 09 February 2021 10:18

Quote:
 Originally Posted by orangespider (Post 1460613) ... in winuae it works perfectly and has definitely better quality than the 14bit one.
Without a doubt. WinUAE does a pure, phased math operation for the samples. Even the normal 14bit sounds much better than on the real Amiga.

Quote:
 Tested on A1200. This works! Anyone wants to make a player using this system? I don't have time for an entire project, but I can send you the code to convert from 16bit to this.
Great!
Can you record the 1200 output? And also the one coming out from a normal player calibrated to 14bit.
Use a piece of soft classical music if possible, with the dynamic not too crushed.
Or pass the conversion code to nikosidis and he will record it.

In theory, if this 'subtractive' (and not just additive) method should prove effective, it would also open the way to various other possibilities, given that the two channels theoretically have the possibility of managing 256 different levels each and with volume on the L channel different from 64 you could find levels that are as linear as possible throughout the dynamic range.
The problem is that every Paula (and every system ..) is probably different and calibration would be a nightmare or impossible (for 14 bits it is quite simple for the slightest level difference).

I had already thought about the possibility of managing different levels of volume on the L channel (see message about it some time ago), but I didn't think the subtractive method could work (I was expecting too much distortion) :)

 orangespider 09 February 2021 10:24

Quote:
 Originally Posted by ross (Post 1460663) Great! Can you record the 1200 output? And also the one coming out from a normal player calibrated to 14bit. Use a piece of soft classical music if possible, with the dynamic not too crushed. Or pass the conversion code to nikosidis and he will record it.
I posted the conversion tables into this thread:

So pretty much anyone can make a player that works. I really don't know how to record from the amiga because my PC has some issues with the audio in (have a huge noise on it for some reason).

Quote:
 Originally Posted by ross (Post 1460663) In theory, if this 'subtractive' (and not just additive) method should prove effective, it would also open the way to various other possibilities, given that the two channels theoretically have the possibility of managing 256 different levels each and with volume on the L channel different from 64 you could find levels that are as linear as possible throughout the dynamic range.
I have tested all the volume combinations and 64/63 seems to be the one with the largest linear area (and also the most unique combinations).

Quote:
 Originally Posted by ross (Post 1460663) The problem is that every Paula (and every system ..) is probably different and calibration would be a nightmare or impossible (for 14 bits it is quite simple for the slightest level difference).
My hope is that because we keep both channels at a high volume, we should get less errors compared to the volume at 1. Someone should measure it though.

Quote:
 Originally Posted by ross (Post 1460663) I had already thought about the possibility of managing different levels of volume on the L channel (see message about it some time ago), but I didn't think the subtractive method could work (I was expecting too much distortion) :)
I wasn't sure if it would work either, but apparently it does.

 ross 09 February 2021 10:54

Quote:
 Originally Posted by orangespider (Post 1460665) I have tested all the volume combinations and 64/63 seems to be the one with the largest linear area (and also the most unique combinations).
I'd rephrase as 'theoretical largest linear area' :)

However the feeling is that this method can work well in the 'high' part of the signal dynamics (therefore for 'modern' music that young people like so much :D)

We urge an ABX test and a scope signal check.

 buggs 09 February 2021 12:37

Quote:
 Originally Posted by pandy71 (Post 1460326) btw - if Amiga could properly process signal (proper dither + aggressive noise shaping) then 8 bit samples played with 55420.23Hz sample rate should be comparable or better (in terms of subjective quality) than '14 bit' Paula mode.
I did experiment with 8 Bit dithering and noise shaping (at 44.1 kHz) and wasn't satisfied by the results I got from the Lipshitz approach. In the end, I've combined 14 bit with TPDF dither and 3 tap noise shaping to get a little better perceptive resolution on the lower end.

 pandy71 09 February 2021 13:20

1 Attachment(s)
Quote:
 Originally Posted by buggs (Post 1460710) I did experiment with 8 Bit dithering and noise shaping (at 44.1 kHz) and wasn't satisfied by the results I got from the Lipshitz approach. In the end, I've combined 14 bit with TPDF dither and 3 tap noise shaping to get a little better perceptive resolution on the lower end.
With proper lowpass filter (based on Gerzon-Craven noise shaping theorem we have more than 7..8kHz band free to be used by aggressive noise shaping) this approach should provide better results than 14 bit mode. I made in past some tests using neat utility (noise.zip attached bellow) from Sebastian Gesemann.

Personally i would apply high pass filter (inline with your findings) as a form of pre-emphasis and use external equalizer to cut frequencies above 18kHz (most of us in the age where 18kHz+ signals are usually not perceived unless very high level).

Also adaptive noise shaping looks very interesting (used for example in https://github.com/corrideat/lossywav).

btw there is somewhere on EAB few Copper Audio procedures - perhaps it is possible to play 8 bit samples with periods lower than 64 without DMA.

 buggs 10 February 2021 13:15

Quote:
 Originally Posted by pandy71 (Post 1460725) With proper lowpass filter (based on Gerzon-Craven noise shaping theorem we have more than 7..8kHz band free to be used by aggressive noise shaping) this approach should provide better results than 14 bit mode. I made in past some tests using neat utility (noise.zip attached bellow) from Sebastian Gesemann.
Thanks for the reference. I'll have a closer look at some point. To make such approaches viable for comfortable realtime operation on the 68k (i.e. something like MP3 on 060 + filtering), I'm currently thinking towards adjustments of candidate filters for reduced complexity. Especially a decent resampling from typical rates to 54 kHz is costly (as you also pointed out earlier already).

Quote:
 Personally i would apply high pass filter (inline with your findings) as a form of pre-emphasis and use external equalizer to cut frequencies above 18kHz (most of us in the age where 18kHz+ signals are usually not perceived unless very high level).
So true. In my experience, you will get a significant drop beyond 18 kHz in any case, highboost or not.

Quote:
 btw there is somewhere on EAB few Copper Audio procedures - perhaps it is possible to play 8 bit samples with periods lower than 64 without DMA.
I know about these approaches but that's beyond my scope. I'd like to keep the OS active for hands-on coding while listening to music.

 orangespider 12 February 2021 09:12

Did anyone ever try to compensate for the delay between the channels during 14bit playback?

AFAIK all the players just assume the channels are played at the same time, and this leads to huge quality loss. If you're trying to play an audio at AUDxPER 80, you get pretty huge quality loss. Here is a worst case scenario example (I'm using 14bit unsigned values to demonstrate more easily):
sample 1: 63/16384
sample 2: 64/16384
sample 3: 63/16384

audio channels:
0 at volume 64
3 at volume 1

expected result:
cycles 0-79: 63/16384
cycles 80-159: 64/16384
cycles 160-239: 63/16384

actual results:
cycles: 0-11: 0/16384
cycles: 12-79: 63/16384
cycles: 80-91: 127/16384
cycles: 92-159: 64/16384
cycles: 160-171: 0/16384
cycles: 172-239: 63/16384

This is the worst case scenario, but this will always happen unless the subsequent values in channel 3 are same. The average error will lead to quality loss that results in a quality equivalent to:
left channel: 11.76 bits / sample
right channel: 13.34 bits / sample

Any further problems with the volume and audio hardware imperfections come after this, but this would be the highest quality even with hardware that does everything else perfectly.

edit: The quality loss isn't constant across AUDxPER values, the higher the AUDxPER value is the less quality loss will occur.

All times are GMT +2. The time now is 04:52.