14.57731 bit audio

[nikosidis]

Originally Posted by pandy71

Try attached one - 5 seconds, single channel, 16 bit wav, 997Hz sine with sample rate 27710.1171875Hz with almost 0dBFS level quantized at 15 bit with HPTPDF dither. Should be ok with 14 bit playout routines.

This is only a wav file?
How can I compare with that one?

[nikosidis]

Originally Posted by orangespider

Nevermind then. Apparently it is the same noise Thorham is getting as well. I will have to do more test on the real amiga. If/when I get the noise under control I'll post a new exe. Thanks.

Even with the noise it should be possible to compare with the first test.

Here it is.

http://s000.tinyupload.com/index.php?file_id=61926493318735453855

[pandy71]

Originally Posted by nikosidis

This is only a wav file?
How can I compare with that one?

Tried to propose alternative that can be measured - will be good if you can join this to overall audio file list.

[nikosidis]

Originally Posted by pandy71

Tried to propose alternative that can be measured - will be good if you can join this to overall audio file list.

This is not a 16bit/44,1kHz file?

[nikosidis]

I suggest for that we use CD quality to test this and not PAL?

Hopefully Eagle Player can get a player to load with the new finding.

[ross]

Originally Posted by orangespider

update: It seems that most of the noise is coming from the channel 0 and channel 3 mix. Channel 1 and channel 2 mix seems much much better. Is there any chance that channel 3 playback is delayed for some reason?

This is somewhat expected. C1&C2 are not in phase by 45°, C0&C3 by 135°.
This is what will make the calibration procedure very complicated (if ever possible ..), too much distance between the positive H and negative L values for the final level.
The distortion compared to the classical method is much higher in this case.

[pandy71]

Originally Posted by nikosidis

This is not a 16bit/44,1kHz file?

This is 16 bit wav, mono, with sample rate 27710Hz so it can be played directly on Amiga with regular OCS screen and regular DMA (after conversion to 14 bit either 8 bit) - sine wave was coded as 15 bit with HPTPDF dither so effective resolution is 15 bits - it will be good to verify how 14 bit player routines perform conversion also it can be easily measured by everyone with PC audio card - i can generate any signal - music or synthetic.

[nikosidis]

This we song Assembly is nice to test I think. More dynamic, voice etc.
http://archive.scene.org/pub/parties...lorida_man.wav

As a start I will record my A1200 output with Eagle Player full quality. Productivity screenmode.

Here is the archive with output Left and Right + a joint stereo phile with this song.

At the end it is 16 bit wav, 997Hz sine that was requested to test.

https://files.fm/u/vp26kqwpr

[pandy71]

Originally Posted by nikosidis

More dynamic

Sadly to say it is heavily crushed with dynamics in total less than 30dB...
I don't think that music particularly with such poor dynamics is good test material.

[nikosidis]

Originally Posted by pandy71

Sadly to say it is heavily crushed with dynamics in total less than 30dB...
I don't think that music particularly with such poor dynamics is good test material.

I agree I tough it was better.
I will use a song I played myself with my band. It is very dynamic!

[roondar]

It's usually best to use some classical music for this kind of thing because that tends to have high dynamic range by default. A nice range can be found in for instance "In the Hall of the Mountain King" by Grieg. Another example that is slightly more modern would be Gershwin's "I Got Rhythm", which also starts really quiet and builds up to quite loud.

[Thorham]

Originally Posted by roondar

It's usually best to use some classical music for this kind of thing because that tends to have high dynamic range by default. A nice range can be found in for instance "In the Hall of the Mountain King" by Grieg. Another example that is slightly more modern would be Gershwin's "I Got Rhythm", which also starts really quiet and builds up to quite loud.

Very nice I usually just use the Final Fantasy X-2 intro music (piano). Isn't too loud and you can easily hear the noise with 14 bit playback.

Here's some decent hires test audio (a bunch of 24 bit 352.8 kHz FLAC files and more): http://www.2l.no/hires/index.html

[Gorf]

Originally Posted by ross

This is somewhat expected. C1&C2 are not in phase by 45°, C0&C3 by 135°.
This is what will make the calibration procedure very complicated (if ever possible ..), too much distance between the positive H and negative L values for the final level.
The distortion compared to the classical method is much higher in this case.

right, I remember parts of this... some channels start later than others

But degrees might be misleading? This depends on the sample frequency, doesn't it?
It is a certain number of "ticks" delayed...

Are above degrees relative to 27kHz?
Would it be 90° and 270° for 56kHz?

[nikosidis]

It is easy to hear the noise on the Amiga output from my recording. It is many quiet passages and mostly a live recording. Very good dynamics.

This is the original file from the recording.

https://files.fm/u/fycqv5dga

Here is the output from A1200. Eagle Player, Productivity screenmode.

https://files.fm/u/bg6nmhvvc

[Thomas Richter]

Quite frankly, I have my doubts that this works as intended because the problem is likely in the imprecisions of the 8-bit DAC which was calibrated to some limited precision at the factory. Rather, at a precision that is sufficient for 8-bit, but not for more bits. Why should anyone waste money with a costly calibration process if that's not necessary?



Anyhow, if you want me to try, I need an executable that either plays an input .wav file that is 16-bit, 44100 kHz sampling frequency, mono. Or an executable that plays a 441Hz sine wave (as close as you possibly can make it). Small frequency deviations are acceptable. Note that the more precise the sine wave is, the better the result will be.



With a 44.1kHz playback, this makes 100 samples per period. With less samples per period, and hence a lower playback frequency, quantization noise will be of course larger as the steps will be larger, so you better make the frequency as high as you can get.

[nikosidis]

Another test.
Mozart Violin concerto in D major.

http://www.lindberg.no/hires/test/2L...4k-16b_01.flac

Output from A1200, Eagle Player.

https://files.fm/u/w8xszhfmw

I hope we can find a way to test this with the new method.

[ross]

Originally Posted by Gorf

right, I remember parts of this... some channels start later than others

But degreed might be misleading? This depends on the sample frequency, doesn't it?
It is a certain number of "ticks" delayed...

Are above degrees relative to 27kHz?
Would it be 90° and 270° for 56kHz?

Yes, probably better relate it to CCK. There is 2CCK delay between consecutive data fetches, channel 0->1->2->3, C0 is coupled with C3 and C1 with C2.
This of course when channels are synchronized. So it seems (no one know it without internals..) that delay is related to AUDxDAT write (and relative channel counters).
It is probably a project choice, to unrelate the channels since they were designed exclusively for 4x8bit.
I do not think however that this change the delay effect when the frequency varies since Amiga use sample & hold and therefore the change of state is relatively immediate (ok,ok signal is filtered, so some changes might be here )

This is a grab by Toni from many years ago, two consecutive channels (0/1 or 2/3?), same data/volume/period:

[orangespider]

The noise is definitely coming from the delay between the channels. I don't know how much the delay is, but it is definitely less than 0.5 samples between channels 0 and 3 and even less between channels 1 and 2. If you turn on the lowpass filter, it completely removes the noise, however then we are losing high frequencies.

Possible solutions:
1) have the filter on and compensate the high frequency loss
2) have the encoding be aware of the delay and compensate for the delay
3) limit the noise by not allowing all value combinations


Issues with the possible solutions:
1) is this even possible?
2) seems very complicated and we would need to know the exact delay between the channels
3) we would be losing values by disabling combinations so 64/63 would probably not be the best solution anymore and we would have less volume and number of bits

[Gorf]

I guess that noise should disappear for a period of 64 instead of 128 (55 kHz sampling frequency) - but the delay would still lead to some distortion...

[Gorf]

Originally Posted by ross

Yes, probably better relate it to CCK. There is 2CCK delay between consecutive data fetches, channel 0->1->2->3, C0 is coupled with C3 and C1 with C2.

This is a grab by Toni from many years ago, two consecutive channels (0/1 or 2/3?), same data/volume/period:

What exactly do we see here?
The frequency of channel 2 is 86 kHz? ... that is a lot

The phase shift seems to be in deed 1/8 or 45° in that case ... or better 1.6 us.

That is still much longer than 2 CCK - more like 5.6 CCK (which makes no sense) ... so perhaps 6 CCK ?

However - the delay is constant and must therefore lead to a much smaller phase shift in lower sampling rates ...

Even at 55 kHz this should shrink down to ~28° - so our combined signal would be at the right value for over 90% of the time

If the shift is really three times bigger for the other combined channel we might run into some troubles and we might need to adjust the lookup-table accordingly or do some calculations in which we take the previous values and the partial overlap into account.

An other strategy could be to leave one value of our two-value-representation constant as long as possible instead of changing both values each sample ... in that case the mismatching overlap would get smaller percentage wise..
(Kind of a HAM-Mode for Paula *g*)