14.57731 bit audio

[nikosidis]

Originally Posted by orangespider

update: All experiments to further improve on this have failed, seems like the versions I've posted are the best possible both for PAL and productivity. Will try to adapt it for 124 for PAL and for 70 for productivity later just to squeeze out a bit more samples per second.

From what I understand it will be best to convert none compressed files to a standard for playback on the Amiga?
I normally use standard wav or AIFF files. Or at least convert to them.

[ross]

Phew! you are writing so much!
I find the time to look at the thread every now and then, so I lose train of thought sometimes .

What's this "audio channel collapses"?!
Do not make much sense to me..

If this also happens with IRQ4 then you may be right, but I don't think it's possible (unless you can't fill the buffers in time).

[orangespider]

Originally Posted by ross

What's this "audio channel collapses"?!
Do not make much sense to me..

If this also happens with IRQ4 then you may be right, but I don't think it's possible (unless you can't fill the buffers in time).

Has nothing to do with filling, it collapses on a looped fixed buffer too. It's hardware related.


Anyway, turns out my new method wasn't as hopeless as it seemed, the issue was that I was testing at AUDxPER 70. Now as I've finally found out, anything below 72 is unstable. This playback method requires high precision from hardware timing otherwise we get random noise. On PAL I could go down to 124 without issues, but for productivity 72 is the lower limit.

The new conversion is superior to the previous version, the frequency retention is so good that I can't even hear any difference between the PAL and the Productivity versions, whatever errors are there they are in frequencies that my ears can't pick up anymore.

I have uploaded the latest version:
http://s000.tinyupload.com/index.php...91824436594910

It has the following files:
audio-pal.asm -- pal audio player for 57.206Hz
audio-pal-1.exe -- pal, 57.206Hz sample (song)
audio-pal-2.exe -- pal, 57.206Hz sample (piano)
audio-prod.asm -- productivity player for 98524Hz
audio-prod-1.exe -- productivity, 98524Hz sample (song)
audio-prod-2.exe -- productivity, 98524Hz sample (piano)
converter.pas -- delphi code containing both the PAL and Productivity converters
hardware.i

btw: The PAL and Productivity functions are exactly the same now, they are just using a different constant for AUDxPER. If anyone wants to play at a different frequency, all you need to do is to change that constant from 72 (prod function) or 124 (pal function) to whatever you wish.

[ross]

Originally Posted by orangespider

Has nothing to do with filling, it collapses on a looped fixed buffer too. It's hardware related.

If this were true then it requires more precise evidence and would grab Toni's attention.

Anyway, turns out my new method wasn't as hopeless as it seemed, the issue was that I was testing at AUDxPER 70. Now as I've finally found out, anything below 72 is unstable.

This can be explained by $79 CCK per line (I very often seen video productivity modes that use this value).
Are you really sure it's not your case?

Even PAL 124 is right, notice the (*) in my post, 124 is the 'generic' minimum usable value.

[orangespider]

Originally Posted by ross

If this were true then it requires more precise evidence and would grab Toni's attention.


This can be explained by $79 CCK per line (I very often seen video productivity modes that use this value).
Are you really sure it's not your case?

Even PAL 124 is right, notice the (*) in my post, 124 is the 'generic' minimum usable value.

I'm not sure what the case is, but I thought I could go down to 64, turns out 64-67 collapses one of the audio channels into silence periodically, and 68-71 just generates weird artifacts when using my system.72 and above works well, just as 124 and above works well in PAL.

Anyway... Back to topic.

I did some measurements to try to figure out the actual output bitrate.

Based on number of unique combinations that appear within the tested samples, we come to 14.789 bits. However when measuring PSNR and comparing to PSNR of different fixed bitrates, it would appear we are at an average 11.048 bits per sample. How many bits per sample do we actually have after the hardware does it's thing is hard to tell.

[nikosidis]

Recorded from output of my A1200 latest version from orangespider.

This is the productivity output. The 2 files will be played in order.

https://files.fm/u/7jkjvztkn

The same goes for PAL.

https://files.fm/u/d889s6jfj

Last and not least the original file of the first song. Not output from my Amiga

https://files.fm/u/bwevv52uq

[nikosidis]

Here is my conclusion.

PAL is for sure the king of the hill here! Who would expect PAL to be this good?

It is also where it really counts! This a lot of people will enjoy.

Thet said, productivity is a little more clear with my AKG headphones. It is less noise and specially for the piano recording I can hear more dynamics and silence.

For the original file it is hard to hear much difference from the productivity recording output from A1200!! Whow!!

With real good headphones you can hear some noise in some passages but play this in a normal enviroment from speakers or normal headphones and no one would notice a difference in the first song. For the piano recording it is little different but it is still good. Much better than what we ever had from before.

Thanks orangespider. Great job!!

[Gorf]

Originally Posted by nikosidis

Recorded from output of my A1200 latest version from orangespider.

This is the productivity output. The 2 files will be played in order.

https://files.fm/u/7jkjvztkn

The same goes for PAL.

https://files.fm/u/d889s6jfj

Last and not least the original file of the first song. Not output from my Amiga

https://files.fm/u/bwevv52uq

Somehow the piano in the previous version (file "Productivity_Piano.wav") sounded just a little bit better to me than the piano part in this version.
Maybe different recording level? Do I hear some clipping in the new version?

[orangespider]

Originally Posted by Gorf

Somehow the piano in the previous version (file "Productivity_Piano.wav") sounded just a little bit better to me than the piano part in this version.
Maybe different recording level? Do I hear some clipping in the new version?

It's also possible that it did actually have slightly less noise. This version mainly focuses on frequency retention while the previous version was more about smoothing than anything else. That one worked by increasing the frequencies we are about to lose because of the smoothing and then smoothing the signal. This one works by maintaining the exact frequency levels of the source. If you compare the productivity (or even the pal) to the original song, you'll notice how it is a near exact match. That wasn't the case in the previous version.

On another note, I've found a new can of worms that I am a bit scared to open:
AUD0PER = 124
AUD1PER = 124
AUD2PER = 125
AUD3PER = 125

Now that seems like something that could do things.

[nikosidis]

Originally Posted by Gorf

Somehow the piano in the previous version (file "Productivity_Piano.wav") sounded just a little bit better to me than the piano part in this version.
Maybe different recording level? Do I hear some clipping in the new version?

The recording level can be slightly different but I don not think there are any clipping. At least not as I can hear.
I can try to record again will less level on input.

[Gorf]

Originally Posted by nikosidis

Here is my conclusion.

PAL is for sure the king of the hill here! Who would expect PAL to be this good?

It is also where it really counts! This a lot of people will enjoy.

Thet said, productivity is a little more clear with my AKG headphones. It is less noise and specially for the piano recording I can hear more dynamics and silence.

For the original file it is hard to hear much difference from the productivity recording output from A1200!! Whow!!

With real good headphones you can hear some noise in some passages but play this in a normal enviroment from speakers or normal headphones and no one would notice a difference in the first song. For the piano recording it is little different but it is still good. Much better than what we ever had from before.

Thanks orangespider. Great job!!

In deed - I would say this is a huge step forward!
It is clearly much better than the previous "14-bit" playback and that is even true for listening to your re-recordings - as good as they are, some quality loss is unavoidable this way: so I am sure on your A1200 this sounds even better.

Now I probably have to modify the low pass filter in my A3000

[Gorf]

Originally Posted by nikosidis

The recording level can be slightly different but I don not think there are any clipping. At least not as I can hear.
I can try to record again will less level on input.

it is in the first half of the piano on the left channel... don't know what it is, but it probably not supposed to be there. But it is very faint.

Since I do not know, what else was changes in the parameters of the conversion, it makes probably no sense to rerecord it ...

I am sure there will be some additional tricks and finetuning of this method over time - but for now it is already a very good achievement.

[nikosidis]

Originally Posted by Gorf

it is in the first half of the piano on the left channel... don't know what it is, but it probably not supposed to be there. But it is very faint.

Since I do not know, what else was changes in the parameters of the conversion, it makes probably no sense to rerecord it ...

I am sure there will be some additional tricks and finetuning of this method over time - but for now it is already a very good achievement.

Done

https://files.fm/u/tc8qcgjhw

[orangespider]

Anyone has any clue what will exactly happen if we do 124 and 125 period on the channels?

If we are talking in period ticks then I know that the channels will start like this:
tick 0 - channel 0
tick 4 - channel 1
tick 8 - channel 2
tick 12 - channel 3

Then I know this too:
tick 124 - channel 0
tick 128 - channel 1

But here is where my confusion starts. We would need a new value at tick 133 for channel 2 and at 137 for channel 3. My guess is they would get delayed to the next tick dividable by 4 to:
tick 136 - channel 2
tick 140 - channel 3 .. but this is just a guess

next I know we are going to have this:
tick: 248 - channel 0
tick: 252 - channel 1

and then we get to the real enigma.. if channels 2 and 3 were delayed, what will happen to them? My guess is they would get updated at:
tick: 260 - channel 2
tick: 264 - channel 3
... but then later when channel 2/3 meets channel 0/1 again, who will delay who?

Now that I think about it, if they can indeed only get updated on the 4th tick, that would explain the weird noises I was getting at periods 69-71.

So... Anyone have any info on this?

[Gorf]

Originally Posted by nikosidis

Done

https://files.fm/u/tc8qcgjhw

thank you!

did not change it - so it is not because of your recording:
there is something wrong with the left channel

[nikosidis]

Originally Posted by Gorf

In deed - I would say this is a huge step forward!
It is clearly much better than the previous "14-bit" playback and that is even true for listening to your re-recordings - as good as they are, some quality loss is unavoidable this way: so I am sure on your A1200 this sounds even better.

Now I probably have to modify the low pass filter in my A3000

Hehe, Yes it is so cool that in 2021 we find even better audio output from Paula
I have one A3000 here too. Lovely computer
Later I can try to record from output of the A3000 and the A600.
The problem with A3000 is that is not set up to transfer files. On my A1200 it is connected to my Linux server to transfer files. A1200 and A600 also have PCMCIA with flash card to transfer files.

[orangespider]

Originally Posted by nikosidis

Hmmm. I also like the piano sound in the first recording better. I think it has more dynamics, or transients coming through. It seams a tad more clear? Better SNR?

I still have the first version code. The difference between them is that the first one was tuned to sound better while the second one is tuned to be more accurate to the source.

[nikosidis]

Originally Posted by orangespider

I still have the first version code. The difference between them is that the first one was tuned to sound better while the second one is tuned to be more accurate to the source.

Thanks It is a difference but we like to be as accurate as possible. I think track 1 sound better with the latest recording. The old recording sounded a little thin for some reason.

I'm looking forward to the player so we can compare more stuff

[Toni Wilen]

Not sure what "collapsing" is supposed to mean but perhaps you hit this special condition: http://eab.abime.net/showthread.php?t=100311

[orangespider]

Originally Posted by Toni Wilen

Not sure what "collapsing" is supposed to mean but perhaps you hit this special condition: http://eab.abime.net/showthread.php?t=100311

No it's not that. What is happening the AUDxDAT gets stuck at the current value for a while and then that makes the channel silent for the duration. It happens in WinUAE and on the real Amiga too. Then after a short while the channel continues the playback. This keeps happening periodically. At 64 this effect happens most often, then as you go up towards 68 it happens less and less often. Then at 68 it works normally although for whatever reason the audio quality is lower than it should be until 72.