Hi all,

I have been recording WAV files with the Fireface 800. I am using this
sytems for a non-standard audio application and need to sample one mono
channel at 192kS using 24bit (this is a real requirement).

I have looked at the resulting wav files, and although Windows says
they are 24bit, I have my doubts. I expect that the file header says
they are 24bit (and that is what Windows reads)...but when I look at
the contents on the file I don't see 24bit.

My questions a
-Does anyone else have this problem? I suspect it is a laptop driver
issue.
-Is these a 'standard' way to look at the bit depth of a WAV file?
(I wrote my own program to do it, but I want a verification).

Thanks

Barchman:

Is these a 'standard' way to look at the bit depth of a WAV file?

What do you want to know?
The bitdata? Or the content of the bitdata?

(I wrote my own program to do it, but I want a verification).

I assume when you wrote a programm, you would not need mine...
I wrote a wave-converter for someone.

Hi Thomas,

Correction: "Is these a standard way..." - A slip of the finger

Well I wrote a matlab script and one of the guys her wrote a c program
to open wav files. The thing is we can't convince ourselves that the
wav files are in fact 24bit. When looking at the data it seems that the
smallest step we get between data points (the LSB) is larger than what
one woulf expect from a 24bit sampled signal. I guess this assumes that
there is a tiny bit of noise so you can see some small steps, but this
shouldn't be a problem.

If I can put in in terms of numbers, it would mean that if the maximum
output level one gets from a wav file is 1. Then the smallest step I
can see in my supposed 24bit file is 3.051E-5.
This is not 24bit, as the smallest step in a 24bit signal should be
down at 1/(2^24) = 29.6E-9 on a scale of 0 to 1.

Would your wav converter help me with a verification here?

Thanks for the help.
Simon

Barchman wrote:

I have looked at the resulting wav files, and although Windows says
they are 24bit, I have my doubts. I expect that the file header says
they are 24bit (and that is what Windows reads)...but when I look at
the contents on the file I don't see 24bit.

How are you looking, and what do you expect to see? And what are you
using as a recording application?

The accepted (highly accepted by marketing departments world wide,
skeptically accepted by engineers) definition of a 24-bit audio
recording is one that comes from an A/D converter that has a 24-bit
word length output. You have to look elsewhere to find out how many of
those bits are actually intelligence and how many remaining are just
noise. I can assure you that the converter in your unit is not capable
of resolving much better than about 21 bits.

And then there's noisy analog hardware ahead of the A/D converter that
contributes to the noise in the digital stream. If you look at the
signal-to-noise specification of the device, you'll find a number
(given the approximation of 6 dB per bit) that's on the order of 17 or
18 bits.

-Does anyone else have this problem? I suspect it is a laptop driver
issue.
-Is these a 'standard' way to look at the bit depth of a WAV file?

There's a device generically known as a "bitscope" that actually looks
at the data words. The best ones are hardware and are relatively
expensive. I haven't seen a dedicated software program (I don't know
why some clever soul doesn't write one) but I believe that SpectraFoo
(a Mac-only application) displays word length, and some hardware audio
devices (Lynx and RME are a couple that I know of) have utilities that
display word length.

Back around 5 years ago when 24-bit devices started to show up in the
product chain, there were some gadgets that displayed word length in
addition to what they were supposed to do. I think maybe the t.c.
Finalizer is one. Many of those only looked at the file header without
looking at the data and incorrectly identified word length if the
driver for the device that produced that file didn't put the right
length in the header. But I think all of those problems have been
resolved, at least in products that have been around for a while.

"Barchman" wrote in message
oups.com
Hi Thomas,

Correction: "Is these a standard way..." - A slip of the
finger

Well I wrote a matlab script and one of the guys her
wrote a c program to open wav files. The thing is we
can't convince ourselves that the wav files are in fact
24bit. When looking at the data it seems that the
smallest step we get between data points (the LSB) is
larger than what one woulf expect from a 24bit sampled
signal. I guess this assumes that there is a tiny bit of
noise so you can see some small steps, but this shouldn't
be a problem.

If I can put in in terms of numbers, it would mean that
if the maximum output level one gets from a wav file is
1. Then the smallest step I can see in my supposed 24bit
file is 3.051E-5.
This is not 24bit, as the smallest step in a 24bit signal
should be down at 1/(2^24) = 29.6E-9 on a scale of 0 to 1.

We all know that there is no such thing as 24 bit data in
the real world. Real-world converters run out of gas
someplace around 20 bits.

A step size of 3E-05 represents 33,333 steps for full scale.
That's really 15 bits worth of resolution.

It seems like you have a real-world device with 15 bits of
resolution that is generating 24 bit numbers. This is not
totally impossible.

May I ask what sort of device is generating this data
stream?

Hi Mike,

I am looking at the bits using a program I wrote myself with MATLAB
(and engineering and maths programming language). I get what you are
saying about 21 useful bits due to dynamic range, Signal to Noise ratio
etc. But unfortunately I do not 'see' anything close to 21 bits. In
fact it looks like I get 16 bits.
And that makes me suspect that the driver is 'throwing away' some of
the bit depth. Which is really annoying when you've just got a brand
spanking new RME Fireface 800
that samples at 192kS / 24bit.

The problem is I require the 24bits (21 bits OK too)...but 16bits isn't
good enough. The SNR of the RME Fireface 800 is 110dB RMS unweighted.
Thanks for the suggestions. I'll take a look at that Spectra Foo
program and see if it can debug my wav file for me. You are right when
you talk about the effective bits of the converter, but I still expect
to see some noisy bits and not just a lot of bits with not just 8 bits
that are static as I see now.

Thanks again,
Simon

I've got an RME Fireface 800 hooked up to an IBM laptop (with a PCMCIA
Firewire card).
I am only recording one mono analogue channel at 44.1kS / 24bit using
Samplitude DEMO version.
I have tried Audacity and some other programs too.

"Barchman" wrote in message
oups.com

I've got an RME Fireface 800 hooked up to an IBM laptop
(with a PCMCIA Firewire card).
I am only recording one mono analogue channel at 44.1kS /

24bit using Samplitude DEMO version.

I have tried Audacity and some other programs too.

Generally audio software that claims to do 24 bits, really
does. At least for recording and playback.

I'd look critically at the Fireface and its drivers.

For the price, I'd expect more.

You might want to use the freebie Audio Rightmark program to
get a broader look at the interface's performance. All
you've got to do with RMA55 is set switches and set levels
and push the button.

Hi again Arny,

Your suggestion looks promising, I'll download Audio Rightmark 5.5 and
give it a try.

Simon

"Barchman" wrote in message
ups.com
Hi again Arny,

Your suggestion looks promising, I'll download Audio
Rightmark 5.5 and give it a try.

It will at least confirm what you've seen from a different
viewpoint.

Audio interfaces with design, firmware or driver problems
that trash resolution down at inaudible or hard-to-hear
levels is an old story.

Barchman wrote:
I am looking at the bits using a program I wrote myself with MATLAB
(and engineering and maths programming language). I get what you are
saying about 21 useful bits due to dynamic range, Signal to Noise ratio
etc. But unfortunately I do not 'see' anything close to 21 bits. In
fact it looks like I get 16 bits.
And that makes me suspect that the driver is 'throwing away' some of
the bit depth. Which is really annoying when you've just got a brand
spanking new RME Fireface 800
that samples at 192kS / 24bit.

Record with signal on one channel and nothing on the other channel, and
do an od on the resulting file.

You should see four bytes of signal (the 24 bit data is actually stored
as a 32-bit word with the last byte zeroed out), then four bytes of
zero (or close to zero), then four more bytes of signal, as the right and
left channels are interleaved. (Ignore the first 56 bytes which are the
header).

A tool like od or git will tell you what is inside the file itself, so
you know where the issue is.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Can this be of any help?
http://www.digido.com/portal/pmodule...er_page_id=34/
F.

Scott Dorsey:

(the 24 bit data is actually stored as a 32-bit word with the last byte zeroed out)

No necessarily.

24bit can be stored in 4byte and in 3bytes. And in opposite to your
statement 3 bytes are prefered. Actually all 24bit waves produced by
Cubase and Wavelab are 3 bytes/sample.
There are some other strange formats. E.g. a studer recorder produces
20bit-Stereofiles and strores the 40 bits into 5bytes and complete
interlaced! It took me one day to reengineer the files.

I just looked at my code, so I paste some parts he

WaveFormat WaveFormatChunk::getWaveFormat() const {
// ------------ normal -------------
if (format == 1){
if (bitsPerSample == 16) return NORMAL16;
else if (bitsPerSample == 20) return NORMAL24;
else if (bitsPerSample == 24) return NORMAL24;

// ------------ studer -------------
else if (bitsPerSample == 32) return STUDER24L;
else return UNKNOWN;
}
else if (format == 153){
if (bitsPerSample == 20 && channels == 2) return STUDER20;
else if (bitsPerSample == 24 && channels == 2) return STUDER24;
else return UNKNOWN;
}
// ------------- other ------------
else return INVALID;
}

....

// special format from studer 2x24bit into 5 bytes
if (informat.getWaveFormat() == STUDER20){
samples[0]=(buffer[0] 12) + (buffer[1] 4) + ((buffer[2] |
0xF0) 4);
samples[1] = ((buffer[2] | 0x0F) 16) + (buffer[3] 8) +
(buffer[4]);
}

// special 24bit format from studer
// byte order is different instead of (0(MSB),1,2|3(MSB),4,5) -
1,0,3,2,5,4
else if (informat.getWaveFormat() == STUDER24){
samples[0] = (buffer[1] 16) + (buffer[0] 8) + (buffer[3]);
samples[1] = (buffer[2] 16) + (buffer[5] 8) + (buffer[4]);
}

Barchman wrote:
I've got an RME Fireface 800 hooked up to an IBM laptop (with a PCMCIA
Firewire card).

Use the bitscope in Digicheck (Bit Statistics and Noise under the
Function menu.)

"Barchman" wrote in message
oups.com...
Hi all,

I have been recording WAV files with the Fireface 800. I am using this
sytems for a non-standard audio application and need to sample one mono
channel at 192kS using 24bit (this is a real requirement).

I have looked at the resulting wav files, and although Windows says
they are 24bit, I have my doubts. I expect that the file header says
they are 24bit (and that is what Windows reads)...but when I look at
the contents on the file I don't see 24bit.

My questions a
-Does anyone else have this problem? I suspect it is a laptop driver
issue.
-Is these a 'standard' way to look at the bit depth of a WAV file?
(I wrote my own program to do it, but I want a verification).


What is it that you are expecting to see ?


geoff

"Barchman" wrote in message
oups.com...
Hi all,

I have been recording WAV files with the Fireface 800. I am using this
sytems for a non-standard audio application and need to sample one mono
channel at 192kS using 24bit (this is a real requirement).

I have looked at the resulting wav files, and although Windows says
they are 24bit, I have my doubts. I expect that the file header says
they are 24bit (and that is what Windows reads)...but when I look at
the contents on the file I don't see 24bit.

Could you place a sample .wav file somewhere, or email it to me, and I'll
see what it looks like to me.

Tim

Kurt Albershardt skrev:

Barchman wrote:
I've got an RME Fireface 800 hooked up to an IBM laptop (with a PCMCIA
Firewire card).

Use the bitscope in Digicheck (Bit Statistics and Noise under the
Function menu.)

Hi Kurt,

The bitscope doesn't tell you much about the analogue signal, as it
seems to be coded in two's compliment. Meaning that a small difference
from positive to negative will cause all bits to switch (they all go
green in the RME bitscope). Hence you don't get a one-to-one mapping
from the analogue to digital signal. A gray code would have worked I
guess...

Simon

Barchman wrote:

The [RME] bitscope doesn't tell you much about the analogue signal, as it
seems to be coded in two's compliment. Meaning that a small difference
from positive to negative will cause all bits to switch (they all go
green in the RME bitscope). Hence you don't get a one-to-one mapping
from the analogue to digital signal.

That's not what it's supposed to tell you. What you're asking about is
the resolution of the converter, and that's something you'll have to
test in the analog domain. What the (any) Bitscope tells you is how
many bits are toggling in the presence of a signal. That's what
determines whether it's a 24-bit, 20-bit, or 16-bit converter.

By shorting the input, you can determine how many bits are toggling
(representing noise, or dithering if it's engaged) with no input. There
will always be a few. But what's important is whether the 24th bit is
toggling. If it is, then it's a 24-bit converter. If the last 8 bits
are static, then it's a 16-bit converter.

That's all you can tell by looking at it digitally. To tell what the
converter is actually doing, you have to look at the analog output
compared to the analog input. You can't do that with software, at least
not without additional hardware. The RightMark program that Arny uses
for a lot of his testing can do a loopback test around the converter
and give you a measurement of quiescent noise and distortion. That may
be of some value or interest to you. It's a tryware program.

Hi Mike,

Using the RME bitscope program all bits toggle all the time, regardless
of input (shorted/not shorted/signal)...this leads me to believe that
the encoding of the bits is 2's compliment. Meaning that when the input
is around zero, which happend often enough with a ac signal, then all
the bits flip.
Hence the bit scope is no good...it should have been gray code where
one bit changes at a time always.
Am I missing something here.

Simon

"Barchman" wrote in message
ups.com...
Hi Mike,

Using the RME bitscope program all bits toggle all the time, regardless
of input (shorted/not shorted/signal)...this leads me to believe that
the encoding of the bits is 2's compliment. Meaning that when the input
is around zero, which happend often enough with a ac signal, then all
the bits flip.
Hence the bit scope is no good...it should have been gray code where
one bit changes at a time always.
Am I missing something here.

Simon

Yes it is two's-compliment, but no, all of the bits should not flip if the
values are from a 16-bit converter. The voltage of the signal is sampled,
and the bit-depth determines how many bits of *significance* the
two's-complement number will have. It matters not that the signal is close
to zero. Any change in voltage with register a change in two's-complement
value as long as the change is large enough to trigger that change in value.
Smaller changes will trigger two's-complement number changes for 24-bit
resolution than for 16-bit resolution (real-life converters aside).

If , in fact, all of the bits are flipping, then I suspect the data is from
a 24-bit converter.

Mike P.

"Thomas Thiele" wrote in message
ups.com...
Scott Dorsey:

(the 24 bit data is actually stored as a 32-bit word with the last byte
zeroed out)

No necessarily.

24bit can be stored in 4byte and in 3bytes. And in opposite to your
statement 3 bytes are prefered. Actually all 24bit waves produced by
Cubase and Wavelab are 3 bytes/sample.
There are some other strange formats. E.g. a studer recorder produces
20bit-Stereofiles and strores the 40 bits into 5bytes and complete
interlaced! It took me one day to reengineer the files.

I just looked at my code, so I paste some parts he

WaveFormat WaveFormatChunk::getWaveFormat() const {
// ------------ normal -------------
if (format == 1){
if (bitsPerSample == 16) return NORMAL16;
else if (bitsPerSample == 20) return NORMAL24;
else if (bitsPerSample == 24) return NORMAL24;

// ------------ studer -------------
else if (bitsPerSample == 32) return STUDER24L;
else return UNKNOWN;
}
else if (format == 153){
if (bitsPerSample == 20 && channels == 2) return STUDER20;
else if (bitsPerSample == 24 && channels == 2) return STUDER24;
else return UNKNOWN;
}
// ------------- other ------------
else return INVALID;
}

...

// special format from studer 2x24bit into 5 bytes
if (informat.getWaveFormat() == STUDER20){
samples[0]=(buffer[0] 12) + (buffer[1] 4) + ((buffer[2] |
0xF0) 4);
samples[1] = ((buffer[2] | 0x0F) 16) + (buffer[3] 8) +
(buffer[4]);
}

// special 24bit format from studer
// byte order is different instead of (0(MSB),1,2|3(MSB),4,5) -
1,0,3,2,5,4
else if (informat.getWaveFormat() == STUDER24){
samples[0] = (buffer[1] 16) + (buffer[0] 8) + (buffer[3]);
samples[1] = (buffer[2] 16) + (buffer[5] 8) + (buffer[4]);
}


Sometimes 24-bits are stored as 32-bit floating-point numbers. In this case,
nothing is zeroed. The exponent field, however, may have a biased zero
value.

Mike P.

Hi Geoff,

I expect to see 24bit of data. I don't care about the real dynamic
range, ie. the effiective bits right now. I just want to see more than
16bit wav files.
I'll soon to explain how far I've gotten and what I've found out.
Regards,

Simon

"Barchman" wrote in message
ups.com
Hi Geoff,

I expect to see 24bit of data. I don't care about the
real dynamic range, ie. the effiective bits right now. I
just want to see more than 16bit wav files.
I'll soon to explain how far I've gotten and what I've
found out. Regards,

There's a goodly selection of 24 bit files at:

http://64.41.69.21/technical/sample_rates/index.htm

Barchman wrote:
Kurt Albershardt skrev:

Barchman wrote:

I've got an RME Fireface 800 hooked up to an IBM laptop (with a PCMCIA
Firewire card).

Use the bitscope in Digicheck (Bit Statistics and Noise under the
Function menu.)


The bitscope doesn't tell you much about the analogue signal


Sure it does -- look to the right of the bit columns at the noise levels
for the channels you have selected. Do this with no input signal to
your converters and you will see their residual noise level.

"Barchman" wrote in message
ups.com...
Hi Geoff,

I expect to see 24bit of data. I don't care about the real dynamic
range, ie. the effiective bits right now. I just want to see more than
16bit wav files.

You will see 24 bits of data. However 3 or 4 of those bits will contain no
intelligent or input-related content.

geoff