English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 11 February 2021, 16:00   #181
nikosidis
Registered User

 
Join Date: Jan 2020
Location: oslo/norway
Posts: 766
Quote:
Originally Posted by orangespider View Post
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.
nikosidis is offline  
Old 11 February 2021, 16:38   #182
ross
Defendit numerus

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 3,213
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).
ross is offline  
Old 11 February 2021, 16:51   #183
orangespider
Registered User

 
Join Date: Feb 2021
Location: Becej / Serbia
Posts: 120
Quote:
Originally Posted by ross View Post
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.
orangespider is offline  
Old 11 February 2021, 17:07   #184
ross
Defendit numerus

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 3,213
Quote:
Originally Posted by orangespider View Post
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.

Quote:
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.

Last edited by ross; 11 February 2021 at 17:12.
ross is offline  
Old 11 February 2021, 17:28   #185
orangespider
Registered User

 
Join Date: Feb 2021
Location: Becej / Serbia
Posts: 120
Quote:
Originally Posted by ross View Post
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.
orangespider is offline  
Old 11 February 2021, 17:55   #186
nikosidis
Registered User

 
Join Date: Jan 2020
Location: oslo/norway
Posts: 766
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

Last edited by nikosidis; 11 February 2021 at 19:05.
nikosidis is offline  
Old 11 February 2021, 18:09   #187
nikosidis
Registered User

 
Join Date: Jan 2020
Location: oslo/norway
Posts: 766
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!!

Last edited by nikosidis; 11 February 2021 at 18:19.
nikosidis is offline  
Old 11 February 2021, 18:19   #188
Gorf
Registered User

Gorf's Avatar
 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 1,309
Quote:
Originally Posted by nikosidis View Post
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?
Gorf is offline  
Old 11 February 2021, 18:26   #189
orangespider
Registered User

 
Join Date: Feb 2021
Location: Becej / Serbia
Posts: 120
Quote:
Originally Posted by Gorf View Post
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.
orangespider is offline  
Old 11 February 2021, 18:26   #190
nikosidis
Registered User

 
Join Date: Jan 2020
Location: oslo/norway
Posts: 766
Quote:
Originally Posted by Gorf View Post
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.
nikosidis is offline  
Old 11 February 2021, 18:30   #191
Gorf
Registered User

Gorf's Avatar
 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 1,309
Quote:
Originally Posted by nikosidis View Post
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 is offline  
Old 11 February 2021, 18:36   #192
Gorf
Registered User

Gorf's Avatar
 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 1,309
Quote:
Originally Posted by nikosidis View Post
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.
Gorf is offline  
Old 11 February 2021, 18:40   #193
nikosidis
Registered User

 
Join Date: Jan 2020
Location: oslo/norway
Posts: 766
Quote:
Originally Posted by Gorf View Post
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
nikosidis is offline  
Old 11 February 2021, 18:46   #194
orangespider
Registered User

 
Join Date: Feb 2021
Location: Becej / Serbia
Posts: 120
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?
orangespider is offline  
Old 11 February 2021, 18:50   #195
Gorf
Registered User

Gorf's Avatar
 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 1,309
Quote:
Originally Posted by nikosidis View Post
thank you!

did not change it - so it is not because of your recording:
there is something wrong with the left channel
Gorf is offline  
Old 11 February 2021, 18:50   #196
nikosidis
Registered User

 
Join Date: Jan 2020
Location: oslo/norway
Posts: 766
Quote:
Originally Posted by Gorf View Post


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.
nikosidis is offline  
Old 11 February 2021, 19:13   #197
orangespider
Registered User

 
Join Date: Feb 2021
Location: Becej / Serbia
Posts: 120
Quote:
Originally Posted by nikosidis View Post
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.
orangespider is offline  
Old 11 February 2021, 19:15   #198
nikosidis
Registered User

 
Join Date: Jan 2020
Location: oslo/norway
Posts: 766
Quote:
Originally Posted by orangespider View Post
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
nikosidis is offline  
Old 11 February 2021, 19:19   #199
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,699
Not sure what "collapsing" is supposed to mean but perhaps you hit this special condition: http://eab.abime.net/showthread.php?t=100311
Toni Wilen is offline  
Old 11 February 2021, 19:52   #200
orangespider
Registered User

 
Join Date: Feb 2021
Location: Becej / Serbia
Posts: 120
Quote:
Originally Posted by Toni Wilen View Post
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.
orangespider is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
15 bit 44 khz audio idea. Thorham Coders. General 31 17 February 2021 08:51
24 or 32 bit audio capture within WinUAE EAUniW support.WinUAE 7 17 September 2018 22:22
Questions about 14 bit audio playback xxxxx Coders. Asm / Hardware 16 22 December 2014 19:30
High Quality reproduction of Audio on 8 bit. pandy71 Amiga scene 0 01 July 2013 15:08
Simple 14 bit audio question... Thorham Coders. General 7 06 June 2010 10:55

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


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


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.12381 seconds with 16 queries