[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 24-bit wav files and other observations
From: |
Daniel J Sebald |
Subject: |
Re: 24-bit wav files and other observations |
Date: |
Mon, 25 Feb 2008 13:34:56 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 |
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