with the newer flash recorders I now have higher resolution and sample
rate options then my older 44.1/16 PCM
I realize I can record at lower safer levels with the 24bit resolution
but I was wondering if sampling at 96 or 88 and resampling to my final
level of 44.1 after post processing has any advantage.
Interesting question. We are investigating the similar topic, for
industrial data acquisition purpose. In our case, the advantage of
retaining higher sampling rate and dynamic range is obvious. It leaves
more room for post-processing. Is your application pure audio?
Phil wrote:
> I realize I can record at lower safer levels with the 24bit resolution
> but I was wondering if sampling at 96 or 88 and resampling to my final
> level of 44.1 after post processing has any advantage.
I would wonder if there are consumer devices out where 48/16 is the
limiting factor. Usually the SNR is limited more or less below 90dB by
anything else in the signal path. And most devices use oversampling
anyway. Normally the dynamics and bandwidth of 48/16 is sufficient for
any home audio application.
Of course, if we are talking about professional recording devices at
least the 24 bit are useful because it makes the recording level much
more safe. And for measurement purposes 96kHz is useful too.
Whether 88 or 96kHz is useful for your post processing is another
question. In theory it is not, unless you do a frequency transformation.
Marcel Müller wrote:
> Phil wrote:
>> I realize I can record at lower safer levels with the 24bit resolution
>> but I was wondering if sampling at 96 or 88 and resampling to my final
>> level of 44.1 after post processing has any advantage.
>
> I would wonder if there are consumer devices out where 48/16 is the
> limiting factor. Usually the SNR is limited more or less below 90dB by
> anything else in the signal path. And most devices use oversampling
> anyway. Normally the dynamics and bandwidth of 48/16 is sufficient for
> any home audio application.
> Of course, if we are talking about professional recording devices at
> least the 24 bit are useful because it makes the recording level much
> more safe. And for measurement purposes 96kHz is useful too.
> Whether 88 or 96kHz is useful for your post processing is another
> question. In theory it is not, unless you do a frequency transformation.
>
>
> Marcel
Marcel basically covered it. In general, it will depend on what
processing you do.
Because sampling with more quantization levels and at a higher rate will
give you a better SNR. And any processing, processes the signal and the
noise. So if your processing has some feedback that creates unhappy
situations with processing noise. But I am guessing in you situation
any such processing is probably not going to be encountered or significant.
Most ADCs internally oversample and then downsample to get better SNR.
Interestingly many also use less quantization levels and much higher
sampling rate, which sort of cancel each other out.
DigitalSignal wrote:
>>I agree. I now have a 24 bit WAV file and a C program I wrote to reduce
>>it to 16 bit with the appropriate shift.
> On average how much compression ratio have you achieved?
The advantage is that you don't have to guess as accurately
what the record level will be.
I don't know about the OP, I was recently using a Roland R1
recorder. It has the choice of 16 or 24 bit WAV, and some
choices of MP3. With 24 bits, I then wrote a C program to
find the minimum and maximum sample values, along with a some
other statistical values. I then did the conversion to 16 bits
by rounding and shifting the appropriate number of bits.
>DigitalSignal wrote:
>>>I agree. I now have a 24 bit WAV file and a C program I wrote to reduce
>>>it to 16 bit with the appropriate shift.
>
>> On average how much compression ratio have you achieved?
>
>The advantage is that you don't have to guess as accurately
>what the record level will be.
>
>I don't know about the OP, I was recently using a Roland R1
>recorder. It has the choice of 16 or 24 bit WAV, and some
>choices of MP3. With 24 bits, I then wrote a C program to
>find the minimum and maximum sample values, along with a some
>other statistical values. I then did the conversion to 16 bits
>by rounding and shifting the appropriate number of bits.
This doesn't sound right. If you want the best quality possible in
the final 16-bit signal, look into dithering and noise-shaping rather
than doing rounding, and it's best to do all your processing in
floating point (that way you can change the level to any arbitrary
value, rather than only in the 3dB steps that bit shifting gives).
OTOH, the difference can be subtle, and many people can't tell even
under the best listening conditions.
>>I don't know about the OP, I was recently using a Roland R1
>>recorder. It has the choice of 16 or 24 bit WAV, and some
>>choices of MP3. With 24 bits, I then wrote a C program to
>>find the minimum and maximum sample values, along with a some
>>other statistical values. I then did the conversion to 16 bits
>>by rounding and shifting the appropriate number of bits.
> This doesn't sound right. If you want the best quality possible in
> the final 16-bit signal, look into dithering and noise-shaping rather
> than doing rounding, and it's best to do all your processing in
> floating point (that way you can change the level to any arbitrary
> value, rather than only in the 3dB steps that bit shifting gives).
> OTOH, the difference can be subtle, and many people can't tell even
> under the best listening conditions.
I thought about it, but so far I haven't tried. By finding the
peak and appropriate shifting, the quietest parts aren't so far down.
It is a recording with a live audience, and the background isn't all
that quiet, anyway. It would be nice, though. Do others do it?
On Tue, 06 May 2008 20:51:45 -0800, glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:
>Ben Bradley wrote:
>(snip, I wrote)
>
>>>I don't know about the OP, I was recently using a Roland R1
>>>recorder. It has the choice of 16 or 24 bit WAV, and some
>>>choices of MP3. With 24 bits, I then wrote a C program to
>>>find the minimum and maximum sample values, along with a some
>>>other statistical values. I then did the conversion to 16 bits
>>>by rounding and shifting the appropriate number of bits.
>
>> This doesn't sound right. If you want the best quality possible in
>> the final 16-bit signal, look into dithering and noise-shaping rather
>> than doing rounding, and it's best to do all your processing in
>> floating point (that way you can change the level to any arbitrary
>> value, rather than only in the 3dB steps that bit shifting gives).
>> OTOH, the difference can be subtle, and many people can't tell even
>> under the best listening conditions.
>
>I thought about it, but so far I haven't tried. By finding the
>peak and appropriate shifting, the quietest parts aren't so far down.
>
>It is a recording with a live audience, and the background isn't all
>that quiet, anyway. It would be nice, though. Do others do it?
Yes, I'm pretty sure most all audio editing software (everything
from Audacity to Pro Tools) have been doing it as I described for many
years now.
It might be easier to write some script file for an audio editing
program to do what you want. I don't know what programs have what
features nowadays, but the old Cool Edit 2000 has/had scripting so you
could do several automated things with audio files.
>>> This doesn't sound right. If you want the best quality possible in
>>>the final 16-bit signal, look into dithering and noise-shaping rather
>>>than doing rounding, and it's best to do all your processing in
>>>floating point (that way you can change the level to any arbitrary
>>>value, rather than only in the 3dB steps that bit shifting gives).
>>> OTOH, the difference can be subtle, and many people can't tell even
>>>under the best listening conditions.
It isn't hard to do other step sized, but I didn't so far.
Just multiply by some number before shifting. Even a 32 bit
int should be enough, but definitely 64 bits.
>>I thought about it, but so far I haven't tried. By finding the
>>peak and appropriate shifting, the quietest parts aren't so far down.
>>It is a recording with a live audience, and the background isn't all
>>that quiet, anyway. It would be nice, though. Do others do it?
> Yes, I'm pretty sure most all audio editing software (everything
> from Audacity to Pro Tools) have been doing it as I described for many
> years now.
This was pretty simple and free. This is personal, and the
budget is low.
> It might be easier to write some script file for an audio editing
> program to do what you want. I don't know what programs have what
> features nowadays, but the old Cool Edit 2000 has/had scripting so you
> could do several automated things with audio files.
If I want to add dither can I use an array of some reasonable
length as a periodic data stream? Generating enough random
numbers for a whole CD might take a while.
On Sat, 17 May 2008 22:39:00 -0800, glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:
>Ben Bradley wrote:
>(someone wrote)
....
>>>It is a recording with a live audience, and the background isn't all
>>>that quiet, anyway. It would be nice, though. Do others do it?
>
>> Yes, I'm pretty sure most all audio editing software (everything
>> from Audacity to Pro Tools) have been doing it as I described for many
>> years now.
>
>This was pretty simple and free. This is personal, and the
>budget is low.
>
>> It might be easier to write some script file for an audio editing
>> program to do what you want. I don't know what programs have what
>> features nowadays, but the old Cool Edit 2000 has/had scripting so you
>> could do several automated things with audio files.
>
>If I want to add dither can I use an array of some reasonable
>length as a periodic data stream?
since it's likely "below the threshold of hearing", a second's
worth of random numbers (44,000) ought to do (if it's loud enough to
hear, the ear will be able to hear the repeated nature of the noise),
but a simple what's-it-called, 'congruence' random number generator
can generate adequate numbers with minimal code execution per sample.
If you filter the noise for noise-shaping, the filter code will take
more CPU cycles.
>Generating enough random
>numbers for a whole CD might take a while.
>
>-- glen