Simple Amiga audio question.

[Thorham]

Hi,

If I take a 16 bit audio file, and chop of the bottom two bits from each sample, it seems that the sound quality (when playing back in 14 bit on the miggy) isn't reduced. What I want to know is simple: Is there really no audible difference, or is there still some?

Any thoughts are appreciated

[johnklos]

I used to use my Amiga 1200 for ALL audio, and I've had it connected to very nice, very accurate speakers and a very clean amplifier at a time when one of my roommates was an audiophile. After explaining to him that bits are bits (why, for instance, the $5000 CD players which do 50x oversampling and "bathe the underside of the disc in blue laser light" and so on give you the exact same bits as a $39 CD player, and that it's just the digital to analog convertors which matter), he began to focus more on the quality and merits of various DACs. He then proceeded to help me test various types of DACs, including the ones in my Amiga.

14 bit on the Amiga really doesn't make a very audible difference. If anything, it slightly softens the sound, but this could also be due to the Amiga audio hardware (note I always had the filters off). But that doesn't mean you don't get accurate treble; rather, you get good treble that doesn't sound artificial as it sometimes does when all of your gear is clean and you put in a test CD.

Note that Amiga hardware with the filters off and good quality sound will always exceed the quality you can get from most audio formats. mp3s, for instance, make me cringe - the quality difference is tremendous. Most people can't tell because they're used to mp3s, but I can easily hear the difference. Also, most compressed (filesize compression) formats also compress (audio compression) the audio levels, so a track from a CD compressed (file and audio) would often have all of the levels evened out, and this completely ruins certain kinds of music. Classical, for instance, will die from audio compression.

So if you have good quality, clean 16 bit audio files without audio or filesize compression and you convert them to 14 bit and play them on the Amiga with the filters off, you'll have audio quality which exceeds most consumer device outputs, in my opinion.

There are other factors - make sure your power supply is clean, and make sure you have good grounds so you don't need a ground loop isolator (which affects the quality of the sound), et cetera. An Amiga can sound quite good!

[Karlos]

So if you have good quality, clean 16 bit audio files without audio or filesize compression and you convert them to 14 bit and play them on the Amiga with the filters off, you'll have audio quality which exceeds most consumer device outputs, in my opinion.

No conversion to 14-bit is necessary. The 14-bit replay routines do all that anyway.

[Thorham]

I used to use my Amiga 1200 for ALL audio, and I've had it connected to very nice, very accurate speakers and a very clean amplifier at a time when one of my roommates was an audiophile.

That's cool, that will certainly sound great

14 bit on the Amiga really doesn't make a very audible difference.

Sorry, but I've asked the question in an unclear way What I'm really asking is if a 14 bit player actually chops off bits 0 and 1 of each sample. I should've been more clear here

Classical, for instance, will die from audio compression.

Yeah, I know, just try Classical internet radio stations. The music itself is still very enjoyable, but the quality certainly isn't optimal.

So if you have good quality, clean 16 bit audio files without audio or filesize compression and you convert them to 14 bit and play them on the Amiga with the filters off, you'll have audio quality which exceeds most consumer device outputs, in my opinion.

Cool This is about a little project of mine. I'm using 16 bit, 48Khz stereo WAVs which I've down sampled to 28KHz using Sox, so the quality is quite good.

There are other factors - make sure your power supply is clean, and make sure you have good grounds so you don't need a ground loop isolator (which affects the quality of the sound), et cetera. An Amiga can sound quite good!

Oh man, everything here is ungrounded

No conversion to 14-bit is necessary. The 14-bit replay routines do all that anyway.

Ah, yes, that's what I wanted to hear, thanks The bit chopping I'm doing is for a lossless compression algorithm I'm writing. Of course bit chopping isn't lossless, but the resulting data is meant to be replayed on an Amiga in 14 bit, so effectively it should be lossless.

Nice to have this and some other things cleared up, thanks guys

[platon42]

What I'm really asking is if a 14 bit player actually chops off bits 0 and 1 of each sample.

No, not if the output uses the calibration table. In this case, the conversion is not linear and all the 16 bits are used for mapping the input to the 2 x 8 bit output channels (one at full volume, the other at volume 1).

[koshman]

Yeah, I know, just try Classical internet radio stations. The music  itself is still very enjoyable, but the quality certainly isn't optimal.

I think jonklos was reffering more to so called "loudness war" in this case - i.e. severely reducing (compressing) dynamics by evening out the volume levels of different sections of a track (http://www.youtube.com/watch?v=xkkqsN69Jac&feature=fvst). Not that classical music would be the usual victim...

[bubblebobble]

Reducing bit resolution doesn't do anything to the frequency range, means bass and trebble are not affacted.
2 bits less raise the quantisation noise about 4 times. Nothing more, but nothing less. Depending on the audio material, this can get audible of course, especially in very silent passages. For "loud" regular pop music, this won't be much audible though. If the dynamic range is well used, quantisation noise starts to be audible roughly at 12 bits.
On the other hand, if you want to compress the audio data, removing 2 bits of 16 is ridiculous. Better use 8 or 4 bit ADPCM, the 8bit variant will sound almost as 16bits, and halves the data size. 4 bit is good for voices, but can get problematic for complex music with a lot of high frequencies, then it starts to crackle a bit.

[Thorham]

No, not if the output uses the calibration table. In this case, the conversion is not linear and all the 16 bits are used for mapping the input to the 2 x 8 bit output channels (one at full volume, the other at volume 1).

Perhaps the table includes the bit reduction?

I think jonklos was reffering more to so called "loudness war" in this case - i.e. severely reducing (compressing) dynamics by evening out the volume levels of different sections of a track (http://www.youtube.com/watch?v=xkkqsN69Jac&feature=fvst). Not that classical music would be the usual victim...

Ugh, that's a pretty bad practice (and I'm not even an audiophile)

Reducing bit resolution doesn't do anything to the frequency range, means bass and trebble are not affacted.
2 bits less raise the quantisation noise about 4 times. Nothing more, but nothing less. Depending on the audio material, this can get audible of course, especially in very silent passages. For "loud" regular pop music, this won't be much audible though. If the dynamic range is well used, quantisation noise starts to be audible roughly at 12 bits.

Very interesting

On the other hand, if you want to compress the audio data, removing 2 bits of 16 is ridiculous.

It's for an audio compressor I'm writing for a little project of mine, the bit chopping isn't used by itself.

Better use 8 or 4 bit ADPCM, the 8bit variant will sound almost as 16bits, and halves the data size. 4 bit is good for voices, but can get problematic for complex music with a lot of high frequencies, then it starts to crackle a bit.

ADPCM is a last resort in case I can't fit all the music on a single CD. I really want lossless 14 bit compression.

[bubblebobble]

Just to clarify: by "compressing" you mean data compression, not dynamic range compression as a DSP effect?

Looseless:
If you compress looseless, you can not guarantee any compression rate. If the data to compress doesn't show any redundancy, no compression is possible. (like zipping a zip file)
In reality, true looseless compression achives about 2 times compression rate on average complex audio data.

Loosless compression almost always works with a predictor (a function that predicts the next sample from the previous samples), calculates the error of the prediction (the delta between the predicted and real value) and zipps the result. E.g. like Flac for audio or PNG for images.

DPCM or ADPCM is not looseless. ADPCM8 uses 8 bits to store the error of the prediction and unpacks into 16bit samples. This is  loossy, but almost not audible. ADPCM4 uses 4 bit per 16bit sample, and is audible, depending on the material of course. Music will sound a bit harsh in high frequencies. MP3 uses 1-2bit per 16bit sample and designed for music. So if you want to pack music, this should be your first choise. If you use 192 or 256 kbps and a decend encoder like LAME, the compression is almost not audible. Better than 12bit or ADPCM4. ADPCM8 is much faster to encode/decode than MP3, but packs only 1:2.

[Thorham]

Just to clarify: by "compressing" you mean data compression, not dynamic range compression as a DSP effect?

Yes, I mean data compression. Adding audio effects is absolutely out of the question, even if it improves compressibility.

Loosless compression almost always works with a predictor

Yes, but I've been unable to come up with a reasonable predictor (it's really easy to make a bad one :lol:), so I'm experimenting whith the deltas of the samples, or, to be more accurate, the deltas between the deltas. I'll try those predictors again, but I just wanted to try something else after failing initially.

DPCM or ADPCM is not looseless.

Yep, I know, hence the 'last resort' remark This might be a last resort because I'm trying to fit 1.67 gigs of audio on a CD with a few megs to spare (for code and graphics) :lol:

Anyway, I want to store the audio without any loss, and while mp3 could be useful, it's to heavy for the target hardware (as low as possible).

[Piru]

Yes, I mean data compression.

http://flac.sourceforge.net/

You're unlikely to beat flac with your custom "predictors".

[Thorham]

http://flac.sourceforge.net/

You're unlikely to beat flac with your custom "predictors".

Sorry, but FLAC isn't an option, because it's to heavy. Someone is doing a FLAC decoder for Amiga, and while it's quite optimized, it still uses about 90% CPU time on a 50Mhz '030. This is sadly much too heavy. Not a problem for me personally, but I want this to work on lesser CPUs than said CPU.

Also, I'm not using predictors at all right now (tried something quick, and failed :lol:), just deltas

[Karlos]

I wrote a low CPU use audio compression format. Encoding was relatively expensive though. Essentially, it split 16-bit audio into frames, found the best N delta values (depending on the # of bits  to encode) for that frame (the expensive bit).

It supported, if I recall correctly, between 2-5 bit encoding. It was lossy but didn't sound too awful.

The idea was that each frame could be independently replayed.

Each compressed frame contained a 16-bit word that had some encoding flags, followed by a 16-bit signed sample (2 for stereo and so on) that comes unmodified from the input frame and serves as the starting point. After that, the next 4/8/16/32 16-bit words contain the best 4/8/16/32 delta values as determined by the encoder.

The remainder of the compressed frame was simply bitfield lookups into that table. Stereo data was interleaved IIRC. For 2-bit encoding, each 16-bit word contained 8 entries, 3-bit encoding stored 5 entries (LSB aligned), 4-bit encoding stored 4 entries, 5-bit stored 3 entries (LSB aligned).

The replay algorithm simply takes the start value and then extracts each field value, looks up the delta value from the table and adds it to the current value to recreate the next sample.

I am sure I still have the sources somewhere.

[Karlos]

^ I never implemented it, but the replay routines were aimed at keeping the sample data compressed in memory and simply generating output directly to a mixing stage. In order to support volume, each frame would have it's start sample and delta table attenuated to the current volume, resulting in an output stream at the correct level of attenuation.

This meant that the mixing routine only ever had to add the output sample values. Overall the aim was to avoid excessive multiplication or table lookup.

[bubblebobble]

Loosless compression will be always too expensive for your purpose, since it always involves some kind of zip compression.

MP3 is too expensive as well, otherwise this would be the best choise.

What's left is only DPCM or ADPCM. Those are relatively cheap to decode in linear complexity.
If you are calculating deltas, you are already using a predictor. The predictor says "the next sample will have the same value as the current one". Which isn't a bad predictor at all. This gives you already 80% of the quality.
ADPCM is significantly better than DPCM, since the value range is adaptive to the current audio data. But I would say roughly 4 times more expensive to calculate.

If this is a game project, I would also consider using a lower samplingrate and maybe mono, because nobody would recognize your nearly-looseless afforts anyway. 44100Hz/16bit/stereo is already quite expensive to sqeeze through the Zorro Slot without any decoding involved.
In 16kHz/8bit/mono you could also consider to use mp3, and decode it "offline" into a ram buffer. If the songs are not soo long, this should be affordable. 8bit isn't too bad either if you do proper dithering. (same effect as with pictures, when doing dithering even 12bit color looks acceptable)