14.57731 bit audio

[orangespider]

Originally Posted by Gorf

For the 0+3 channel @54kHz playback we could maybe take the following approach:

You're overcomplicating it. It's quite easy to convert 55khz to 55khz if the delay is known. For a 3/32 you can do:
x = (32b - 3a - 26c) / 3
y = (3a + 32c - 32b) / 3

Where: x - value for channel 0, y - value for channel 3, a - previous value for channel 3, b and c - current and next values in the 55khz audio.

Originally Posted by Toni Wilen

I think it can be reset manually by doing this:
1: Make sure audio channel is idle.
2: CPU/copper write to AUDxDAT. Volume counter is reset. (Probably needs copper to guarantee correct timing?)
3: Switch DMA on. DMA mode "starts" and volume counter is not reset because state transition from 5 to 2 didn't happen.
4: Audio continues in DMA mode with original AUDxDAT position "synced" volume counter.

Wait, are you saying if we reset the AUDxDAT delay manually it will then keep that delay? Does this mean we can put the 2 channels completely out of phase? I know we can't put it in phase because we need to write to them separately, but maybe we could get better x2 frequency?



Anyways, assuming we don't find a way to change the delay, here is the best I can do to get 55Khz-ish audio. This version compensates for the 1/32 delay between channels 0 and 1 and for the 3/32 delay between 0 and 3. It is a bit more complicated now, but at least I managed to get it into a single pass filter that doesn't need future values, so it can be used for realtime conversion:
http://s000.tinyupload.com/index.php...03843381162848

[ross]

Hi Toni, it's the image of the message http://eab.abime.net/showpost.php?p=...9&postcount=57
congruent with the 4 CCK delay found by orangespider in message http://eab.abime.net/showpost.php?p=...&postcount=113 ?

Unfortunately I do not know the conditions in which you had done the test in 2012 (from the picture it is not clear how much delay it is)..

Thanks.

[Gorf]

Originally Posted by orangespider

You're overcomplicating it. It's quite easy to convert 55khz to 55khz if the delay is known. For a 3/32 you can do:
x = (32b - 3a - 26c) / 3
y = (3a + 32c - 32b) / 3

Where: x - value for channel 0, y - value for channel 3, a - previous value for channel 3, b and c - current and next values in the 55khz audio.

But that is just a linear approximation - depending on your source material the real value at that point in time might be quite different.
(also a good upscaler uses probably better math than just linear ...)

[orangespider]

Originally Posted by Gorf

But that is just a linear approximation - depending on your source material the real value at that point in time might be quite different.
(also a good upscaler uses probably better math than just linear ...)

That is not an upscaler. It converts 55khz audio to 55khz audio. The difference that the source signal is like this:
bbbbbbbbbbbbbbbbcccccccccccccccc

and the destination signal is like this:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
aaayyyyyyyyyyyyyyyyyyyyyyyyyyyyy

So all you need is to convert the 55khz audio into the 3 channels that have a 3/32 delay between them.

If you invert the equation I wrote and then average out for the first 16 values, you will get b and for the second 16 values you will get c. So it's a way to play 55Khz audio on c0 and c3.

[Gorf]

Originally Posted by orangespider

That is not an upscaler. It converts 55khz audio to 55khz audio. The difference that the source signal is like this:
bbbbbbbbbbbbbbbbcccccccccccccccc

Is it??

that depends totally on your source material!

If you are coming from a 384kHz PCM file that you would want to resample it to 277kHz and pick the values like I suggested earlier. Otherwise you lose more information than necessary.

[Gorf]

Originally Posted by orangespider

That is not an upscaler. It converts 55khz audio to 55khz audio. The difference that the source signal is like this:
bbbbbbbbbbbbbbbbcccccccccccccccc

and the destination signal is like this:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
aaayyyyyyyyyyyyyyyyyyyyyyyyyyyyy

actually your source would be:

b.....c.....d.....e.....f.....
|     |
T0    T1

(dots represent unknown/unsampled values)

and your destination

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
aaaaaayyyyyyyyyyyyyyyyyyyyyyyy
|     |
T0    T1

T0: the combination of x+a must match b
T1: the combination of x+y must match c

(d, e and f are never matched and ignored - Nyquist is still fulfilled because we used 5x oversampling in our case)

edit:
some picture...

Max-|         ,-'''-.                                        
    |      ,-'       `-.                                     
V1<-------'             `.                                   
    |  ,'|                `.                                 
    | /  |                  \                                
    |/   |                   \                               
----+----|--------------------\--------------------------    
    |    |     __           __ \          __           /  __ 
    |    |     ||/2         ||  \        3||/2        /  2|| 
    |    |                       `.                 ,'       
    |    |                         `.             ,'         
    |    |                           `-.       ,-'           
Min-|    |                              `-,,,-'              
    v    v                                                   
    T0   T1

Just because we did not "look" at the value a time T1 in our scan, does not mean it is the same value as at T0 - actually it is most certainly not.

Nyquist theorem does NOT tell you that the values between your samples are constant, but that all kinds of sines my occur between those points ...

[malko]

Really interesting and positive thread

[nikosidis]

Originally Posted by malko

Really interesting and positive thread

Sure is! I'm looking so much forward to test this more

A player plugin for Eagle Player with this method is what I'm hoping for

[orangespider]

Originally Posted by Gorf

actually your source would be:

b.....c.....d.....e.....f.....
|     |
T0    T1

(dots represent unknown/unsampled values)

and your destination

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
aaaaaayyyyyyyyyyyyyyyyyyyyyyyy
|     |
T0    T1

T0: the combination of x+a must match b
T1: the combination of x+y must match c

(d, e and f are never matched and ignored - Nyquist is still fulfilled because we used 5x oversampling in our case)

Why would you want that? That would just produce nearest neighbor at a non-constant frequency. What I want is this:

bbbbccccdddd
|   |   |
T0  T1  T2

(dots represent unknown/unsampled values)

and my destination

xxxxxxxx
ayyyyyyy
|   |   |
T0  T1  T2

And the goal is to have the average of T0-T1 and T1-T2 at the destination to be the same as the average of T0-T1 and T1-T2 at the source. I am not looking at the signal as points, but as ranges.

Originally Posted by Gorf

Just because we did not "look" at the value a time T1 in our scan, does not mean it is the same value as at T0 - actually it is most certainly not.

Nyquist theorem does NOT tell you that the values between your samples are constant, but that all kinds of sines my occur between those points ...

The issue is that you're ignoring values and aren't trying to match a constant frequency. The second issue is that your values will be less different than mine and therefore you will conserve less detail from the source.

[Gorf]

Originally Posted by orangespider

Why would you want that?

I don't "want" anything, I am just describing the way it is.

That would just produce nearest neighbor at a non-constant frequency.

well - we DO have a kind of non-constant frequency, since the phase mismatch...

What I want is this:

bbbbccccdddd
|   |   |
T0  T1  T2

(dots represent unknown/unsampled values)

but we DO have:

b...c...d...e...f...g...h...
|   |               |   |
T0  T1              T2  T3

(dots represent unknown/unsampled values)

and my destination

xxxxxxxx
ayyyyyyy
|   |   |
T0  T1  T2

And the goal is to have the average of T0-T1 and T1-T2 at the destination to be the same as the average of T0-T1 and T1-T2 at the source. I am not looking at the signal as points, but as ranges.

And that is wrong and violating Nyquist.

The issue is that you're ignoring values and aren't trying to match a constant frequency.

Because we don't have one constant frequency, but two frequencies with a phase-shift ...
Sampling by definition means ignoring all values between your sample points ...

The second issue is that your values will be less different than mine and therefore you will conserve less detail from the source.

It is the other way around - by calculating averages you introduce just little errors and distortions - as well as doing some kind of simple low pass filtering.

[orangespider]

Originally Posted by Gorf

It is the other way around - by calculating averages you introduce just little errors and distortions - as well as doing some kind of simple low pass filtering.

Ok. Here is an idea. You write the code for your transformation, I write it for mine. We compare results and see which works better. Either way one of us will have better quality and then we can both use it.

[orangespider]

Originally Posted by orangespider

Ok. Here is an idea. You write the code for your transformation, I write it for mine. We compare results and see which works better. Either way one of us will have better quality and then we can both use it.

Never mind that. I have tested both your way and mine and neither is entirely correct.

Your way really loses high frequencies much more heavily than mine and mine is much more noisy than yours.

While you do have some valid points, the issue with your approach is that you are looking at points, while in actuality the signal is sustained over a period of time. Just sampling a point at the edges of the signal will lose too much data. Consider this 55Khz input:
-1, 1, -1, 1, -1, 1
If you upscale that 16x you will get some curve that is like:

-1, -0.99, -0.95, -0.85... etc

So your method will then sample this as: -1, -0.85 and your output will be -1, -0.85, -1, -0.85, -1, -0.85, etc (note: duration of first one is 3, the second one is 29 at 885khz)

My method on the other hand will overcompensate the first value because it is shorter and we will get something like this:
-9.67, 1, -9.67, 1, -9.67, 1... etc

Now if you average my method out over 55Khz frequency, it will average to
(-9.67*3 + 1*12)/16, 1*16/16 which is:
-1, 1, -1, 1, -1, 1, -1, 1

However even the short burst of -9.67 will generate too much noise.

A third approach would be to average the values from the upscaled version and then we end up with this:
-0.98, 0.1

Interestingly enough this when averaged to 55Khz will produce:
-0.1, 0.1, -0.1, 0.1, -0.1, 0.1... etc

So at this time we have retained the correct frequency but our amplitude is 9.667 times lower for c0/c3 (and 31 times lower for c1/c2). From all the tested methods, this gives the best result. It is both cleaner than your approach and retains more high frequency. We could increase the distance between the 2 values by doing a haar transform and then multiplying the high frequency value 9.6667 times for c0/c3 and 31 times for c1/c2, however this would probably just put the result back to my original method.


edit: I am an idiot.

We know what the exact frequency loss is, so we can pre process the signal before we do anything and compensate. Just increase the 27710 frequency range by a factor of 29/3 for c0/c3 and 31 of c1/c2 and then do the processing using the average values as before. Except this time we didn't only get a very clean audio, we also kept all the frequency ranges intact.

edit 2:
http://s000.tinyupload.com/index.php...53815532511093

I've uploaded the following:
audio1.exe -- test with the song from nikosidis at 55420Hz on PAL
audio2.exe -- piano solo at 55420Hz on PAL
audio.asm -- assembler player
converter.pas -- delphi function from PC that converts 32bit float stereo raw audio to the amiga 4 channel 8bit format
hardware.i -- just in case someone doesn't have it

As far as I am concerned the quality is as good as it can get, I will convert it to realtime player code for amiga assembler and post that source too, but until then if someone wants to experiment with this or try to improve it, feel free. The output currently 9bit - 15bit quality in the range of -12223 to 12223 (depending on the source) and then that drops to 9bit quality at the maximum range of -16129 to 16129. The bit loss is dithered between the channels on the same side.

[nikosidis]

Recorded from A1200, PAL, audio1.exe
https://files.fm/u/3x7fbfnt8
Recorded from A1200, PAL, audio2.exe
https://files.fm/u/36x3x5veh

Download the files and playback from your computer. The streaming is not good I think.

The quality is fantastic I think
Looking so much forward to also hear this in full sample rate.
This is still so good that I would call this revolutionary regarding Paula stereo output.

The player must be named after orangespider. Maybe OrangeS-Player?

Some demo scene group must do a demo with this audio quality. Even if it is just still pictures.

Edit:
Do you like me to record this also from A600 output?

[orangespider]

Originally Posted by nikosidis

Recorded from A1200, PAL, audio1.exe
https://files.fm/u/3x7fbfnt8
Recorded from A1200, PAL, audio2.exe
https://files.fm/u/36x3x5veh

Download the files and playback from your computer. The streaming is not good I think.

Your recording setup is awesome, I don't see any recording noises in any of your recordings.

Originally Posted by nikosidis

The quality is fantastic I think
Looking so much forward to also hear this in full sample rate.
This is still so good that I would call this revolutionary regarding Paula stereo output.

Thanks. I am still hoping someone will explain to me how to setup the Productivity resolution correctly. I could go with interrupts, but I still don't know what the actual frequency is at 64 on that resolution.

Originally Posted by nikosidis

The player must be named after orangespider. Maybe OrangeS-Player?

I just hope someone will integrate it as a playback option into any player once we have the realtime amiga code.

Originally Posted by nikosidis

Some demo scene group must do a demo with this audio quality. Even if it is just still pictures.

Well I am currently working on a demo with my wife atm (she's doing the 3d objects and textures, I am writing the code), but it might never happen because I have set the bar way higher than it's healthy. Also, we didn't find someone to do the music for it yet.

Originally Posted by nikosidis

Do you like me to record this also from A600 output?

Does the A600 output sound different than the A1200 one with this player?

[roondar]

Originally Posted by orangespider

Thanks. I am still hoping someone will explain to me how to setup the Productivity resolution correctly. I could go with interrupts, but I still don't know what the actual frequency is at 64 on that resolution.

IIRC it should be (horizontal_scan_rate_prod/horizontal_scan_rate_pal) * pal_sample_rate_64.

Does the A600 output sound different than the A1200 one with this player?

Depends... Some of them have filters like the A1200, some of them don't.

[meynaf]

Originally Posted by orangespider

I just hope someone will integrate it as a playback option into any player once we have the realtime amiga code.

You can at least count on me. I already have all the relevant framework in my flac player.

[ross]

Originally Posted by nikosidis

Recorded from A1200, PAL
...
The quality is fantastic I think

Better and better

Originally Posted by orangespider

I am still hoping someone will explain to me how to setup the Productivity resolution correctly. I could go with interrupts, but I still don't know what the actual frequency is at 64 on that resolution.

I miss your point here.
If you use IRQs it is not important that it is Productivity resolution but any resolution that allows you to set Period = 64 (DMA must be fast enough to provide Paula with the data in time). Then you follow the IRQ frequency, not the VBI one.

[orangespider]

Originally Posted by ross

I miss your point here.
If you use IRQs it is not important that it is Productivity resolution but any resolution that allows you to set Period = 64 (DMA must be fast enough to provide Paula with the data in time). Then you follow the IRQ frequency, not the VBI one.

I still need to know the output frequency because if I think it's 55Khz, but it's 56Khz, then the music we're playing will be out of tune. I need to know the exact frequency I am converting to.

[robinsonb5]

Originally Posted by orangespider

but I still don't know what the actual frequency is at 64 on that resolution.

Just to be clear, the sample rate you get for a given period value doesn't depend on the screenmode, it depends on whether the particular Amiga you're using was manufactured as a PAL or NTSC system.

PAL Amigas and NTSC Amigas have slightly different base clocks. CCLK on an NTSC Amiga will be 3.579545MHz while on a PAL system it will be 3.546895. The frequency you get for a period value will be CCLK divided by that period value.

What does depend on the screenmode is whether the DMA system can fetch data fast enough to keep the audio system fed at your chosen frequency.

[orangespider]

Originally Posted by roondar

IIRC it should be (horizontal_scan_rate_prod/horizontal_scan_rate_pal) * pal_sample_rate_64.

I think I got this correctly, but I am not sure. PAL is 15.6Khz with 49.8 fps (due to the 313 scanlines instead of 312.5). Productivity is 29.29Khz with 58Hz. Based on that, I calculated that the number of scanlines per frame is 505. Which then should mean our playback frequency should be 55331.25 and the data rate should be 953.987 samples per frame.

I might be completely wrong about this though, but will try it with these values anyway.

eidt: And wrong I was.

Originally Posted by robinsonb5

Just to be clear, the sample rate you get for a given period value doesn't depend on the screenmode, it depends on whether the particular Amiga you're using was manufactured as a PAL or NTSC system.

PAL Amigas and NTSC Amigas have slightly different base clocks. CCLK on an NTSC Amiga will be 3.579545MHz while on a PAL system it will be 3.546895. The frequency you get for a period value will be CCLK divided by that period value.

What does depend on the screenmode is whether the DMA system can fetch data fast enough to keep the audio system fed at your chosen frequency.

So that would mean 64 will give me 55420 Hz and it would eat ~955.52 samples per frame.