[Arny Krueger]

"Eeyore" wrote in
message ...


Arny Krueger wrote:

"Eeyore" wrote
Arny Krueger wrote:
"Eeyore" wrote

A little update here.

Prism's DreamAD-2 quotes 130dB unweightewd dynamic range !
http://www.prismsound.com/music_reco...2_tecspec.html

Hey, and they will even give you $600 change from $10K.

More overkill.

A specialist market.

Maybe they can sell one to AP. ;-)

Their test set competes with AP !


I had no idea that
http://www.prismsound.com/test_measu...ope_specs.html
existed. Thanks for the tip!

[Ro]

50% greater?

16 bit: 65,536 possible values for each sample
24 bit 16,777,216 possible values for each sample

So, recording at 24 bit is at least 256 times more processor intensive than
at 16 bit. Then, if there are some funny implementations going on somewhere
that calls for moving samples around on the disk etc... much easier for
troubles to arise...


Ro_ro wrote:
You can't improve on the source at the end of the day. Thus using 24 bit
sample resolution is wasted. Cds are 16 bit. Not sure what online radio
is.
And btw sample resolution has nothing to do with bitrate.

False. For uncompressed PCM audio, the bit rate is the product
of the sample rate, the sample width in bits and the number
of channels per sample block. Thus, 24 bit audio has a raw
bitrate 50% greater than 16 bit audio at the same sample
rate, assuming packed 3-byte samples.

Then 24bit sampling is hugely more processor and memory
intensive than 16bit.

No, it is not. For recording, it is only 50% more "intensive."
That's not "hugely" And for recording, most of the work
the CPU is doing is simply moving samples around and
some bookkeeping, at most.

I'd say at a guess yhat maybe your muddy results were due to your PC
struggling, especially if you had other apps going on at the same
time...

Yeah, that'd be a guess, and a wrong one at that. If the
PC was "struggling," as you suggest, you'd have large
gaps in the audio as the process was unable to keep
up. You'd not have a severe bandwidth limiting as the
original poster described.

It might be helpful to actually read some of the thread,
where it was determined that the soundcard the poster
was using has a very poor implementation of 24 bit,
24 kHz sampling.

[[email protected]]

Ro wrote:
50% greater?

16 bit: 65,536 possible values for each sample
24 bit 16,777,216 possible values for each sample

So, recording at 24 bit is at least 256 times more
processor intensive than at 16 bit.

What a load of absolute crap! You ARE joking, aren't
you? Please say you are because, if not, this is about
the dumbest explanation I have ever seen.

Go look up the number of procerssor cycles needed
to do an move, copy, add, subtract, multiply or divide
on 16 bit vs 32 bit numbers. In a 32-bit wide architecture,
often there are NO extra cycles, and such processing
takees little, if any extra CPU effort.

As to the 50% figure for recording, it simply comes
from the fact that you're moving, in the case of 3-byte
packed 24 bit data, 50% more bytes around. If you're
storing them as 24 bits left0justified in a 32-bit long
integer, then the overhead may be 100% becuase you
have 4 bytes per sample instead of 2. But, in fact,
the processor architecture may be more efficient at
moving a single 32-bit long instead of 2 16-bit words
or 4 8-bit bytes.

But the notion that a 24-bit stream is 256 times more
intensive than 16 bits is pure nonsense.

Then, if there are some funny implementations going
on somewhere that calls for moving samples around
on the disk etc... much easier for troubles to arise...

Like I said before, it might have been helpfulk for you
to actually have read what the thread was about before
you came up with your, uh, "explanantion." It also might
have been helpful for you to actually have researched
your answer before posting it. Saves you a lot of
embarassment that way.

[Richard Crowley]

"Ro" wrote...
50% greater?

16 bit: 65,536 possible values for each sample
24 bit 16,777,216 possible values for each sample

So, recording at 24 bit is at least 256 times more
processor intensive than at 16 bit. Then, if there are
some funny implementations going on somewhere
that calls for moving samples around on the disk etc...
much easier for troubles to arise...

Please do not post such nonsense in public places.
Naieve readers may actually think you have a clue
what you are talking about.

[Randy Yates]

"Ro" writes:

50% greater?

Yes, as Dick said, assuming 3-byte packed form, 50% greater.

16 bit: 65,536 possible values for each sample
24 bit 16,777,216 possible values for each sample

So, recording at 24 bit is at least 256 times more processor intensive than
at 16 bit. Then, if there are some funny implementations going on somewhere
that calls for moving samples around on the disk etc... much easier for
troubles to arise...

You have no clue what you're talking about.

First, you must separate algorithm computation from data transfer
overhead. As Dick said, when recording, there is essentially no
algorithm computation - you're simply moving samples around. And the
difference in processor time to move 24-bit samples around is at worst
50 perecent (on an x86 architecture assuming 3-byte packed samples).

And even if there were algorithm computations going on, a 24-bit
computatiion does NOT require 256 times the cycles for a 16-bit
computation. For example, a 16-bit by 16-bit to 32-bit multiply might
take X cycles on the x86 architecture. To perform a 24-bit by 16-bit
to 40-bit multiply might have to use double-precision, so the
difference would be something on the order of a factor of 4 (4X
cycles).
--
% Randy Yates % "My Shangri-la has gone away, fading like
%% Fuquay-Varina, NC % the Beatles on 'Hey Jude'"
%%% 919-577-9882 %
%%%% % 'Shangri-La', *A New World Record*, ELO
http://home.earthlink.net/~yatescr

[AZ Nomad]

On Tue, 26 Sep 2006 13:55:53 GMT, Randy Yates wrote:


"Ro" writes:

50% greater?

Yes, as Dick said, assuming 3-byte packed form, 50% greater.

16 bit: 65,536 possible values for each sample
24 bit 16,777,216 possible values for each sample

So, recording at 24 bit is at least 256 times more processor intensive than
at 16 bit. Then, if there are some funny implementations going on somewhere
that calls for moving samples around on the disk etc... much easier for
troubles to arise...

You have no clue what you're talking about.

First, you must separate algorithm computation from data transfer
overhead. As Dick said, when recording, there is essentially no
algorithm computation - you're simply moving samples around. And the
difference in processor time to move 24-bit samples around is at worst
50 perecent (on an x86 architecture assuming 3-byte packed samples).

If the processor is faster than about a 16mhz 80386, then it will never have
any problem pushing around 24 bit data. Doing CPU intensive transforms will
take perhaps 50% more time, but maybe not given that it is running on a 32
bit processor. Doing math on 24 bits doesn't take much more time than
doing it on 16 bits.

[Laurence Payne]

On Tue, 26 Sep 2006 13:22:21 +0100, "Ro" wrote:

16 bit: 65,536 possible values for each sample
24 bit 16,777,216 possible values for each sample

So, recording at 24 bit is at least 256 times more processor intensive than
at 16 bit.

Why? It's not any harder to read "23, 45, 57" than it is to read "1,
3, 6".