Re: 24-bit wav files and other observations

[Daniel J Sebald]

Przemek Klosowski wrote:
>    Well, probably few general-purpose systems.  There are many 24-bit
>    embedded processors, of course, and then there are plenty of data
>    files that use 24-bit data.  So, from an analytical standpoint
>    there are reasons for having 24-bit "native" types.  It's similar
>    to the situation that we have very few 8 bit CPU's anymore, but the
>    8-bit width "native" format is still ubiquitous.
>
> Actually, most of the CPUs in existence are 8-bit; they are in your
> consumer appliances, calculators, cars, watches, etc etc. The
> prevalence of 8-bit data types has nothing to do with those,
> though---it just happens to be a convenient size with granularity almost
> right to encode most human-language communication, and a lot of data
> if the required accuracy is not better than 0.4%.

Good point.  I agree.  Just a (bad) analogy, I guess.  I'm not advocating 
tossing the 8-bit data width.


> If the 8-bit byte is ever dethroned, it will be by internationalization
> (Unicode characters) and by the fact that control loops for things
> like motors, actuators, etc. barely work when the signal to quantization
> noise ratio is 24dB (8-bit data) and really prefer 36 dB (12-bit data) or
> 48 dB (16-bit data).
>
> 24 bit data is in the area of diminishing return: for 33% more space
> (32 bits) you get a dynamic range hike from 72 to 96 dB, and you don't
> have to deal with unaligned loads. Even in graphic cards, where
> essentially one throws away the fourth byte (bits 25-32), the 32-bit
> pixel is often used rather than the 24-bit pixel, just to make data
> moves easier.

It sounds like you are making the point that having 'int24' as part of auload 
or maybe even 'fread' is fine, but internal to Octave an 'int24' type is not 
particularly useful?

I've tried making a patch with an 'int24' type in Octave and there is more to 
change/add than I suspected.  The main src/ directory isn't too bad, but then 
it ties into the library directory and I'm not familiar with that setup.  I 
could send that auload patch to OcatveForge list and be done with it.

If I'm recalling correctly, part of the reason for having the 24-bit samples 
(with associated good quality analog electronics and A/D up front) is to 
perform mathematical operations, like mixing, and not degrade to a resolution 
below what the application demands.

Dan