I'm completing work on an ACM driver (thanks Chris) and am testing it with
various clients (SoundRecorder, WinMediaPlayer, WinAmp, Audition. My codec
compresses 16 and 24 bit PCM wavs. I have the 16 bit and 24 bit compression
algorithms working etc.
In terms of the template code for my ACM driver, all references to audio
passed in and out is though pointers to the "source" and "destination" via
headers in the WAVEFORMATEX stucture. This is all fine for my 16-bit
PCM-16-bit Compressed scenario - I read the wBitsPerSample from the source
header, copy all values to the destination and bang in my compressed data.
When I use e.g. SoundRecorder to save a 16-bit PCM to my compressed format
and look at the resulting file properties, I see the channels, Fs,
BitsPerSample etc. all as I would expect and all my ACM clients can play it
no problem...
Now to the 24-bit scenario: my driver needs to compress from 24 bit PCM to
24-bit compressed and to do that I'm doing the exact same as for the 16-bit
case above - this time I set wBitsPerSample = 24 in the wav header. If I
use an ACM client to open a 24 bit PCM and convert to my 24 bit compressed
format, I can see that the resulting file properties (i.e. using Alt+Enter)
are reported as my compressed file format tag 24 bits etc. Yet when I try
to import into an editor (e.g. Audition) the file bit depth is reported as
16 bit....
Any help please! I'd like not to have to move everything to
WAVEFORMATEXTENSIBLE as I undertand it's advisable for > 16 bit audio
files... but if I have to some tips on the correct parameters would be
majorly appreciated...
Thanks,
Culann
Support for > 16 bit with the WAVEFORMATEX structure is vendor dependent.
You may find that some software supports it and others do not. From my
previous testing I've found that apps such as Windows Media Player will not
play 24 or 32 bit data files unless they have the WAVEFORMATEXTENSIBLE
header format.
Other than that just check that you have all the other header values
correct, i.e. make sure your block-align value is divisible by 3 and the
nAvgBytesPerSec value is calculated correctly.
Otherwise you may have no choice but to bight the WAVEFORMATEXTENSIBLE
bullet, we did a while back as it was the only way to get true
multi-channel support.
I can see that different clients set wav header data differently before
passing it to me; for example even though Adobe audition allows me to create
a 24-bit noise file in PCM wav format (this shows up as "24bit Packed Int
type 1"), when it passes this format to my driver, it sets the relevant
source stream headers BitsPerSample as 16 bit, even though it correctly sets
my compressed 3-byte format destination header as 24bit, i.e. . Why might
this be?
Assuming I can figure out a workaround for identifying when a PCM stream is
16 or 24 bit, can I then assume that 24 bit packed int means each 24 bit
sample is packed into 3 continous bytes?
Thanks,
Culann.
"Chris P. [MVP]" <ms...@chrisnet.net> wrote in message
news:1feldckijqio5.m...@40tude.net...
> Thanks Chris,
>
> I can see that different clients set wav header data differently before
> passing it to me; for example even though Adobe audition allows me to create
> a 24-bit noise file in PCM wav format (this shows up as "24bit Packed Int
> type 1"), when it passes this format to my driver, it sets the relevant
> source stream headers BitsPerSample as 16 bit, even though it correctly sets
> my compressed 3-byte format destination header as 24bit, i.e. . Why might
> this be?
That's rather odd, sounds like a bug in Audition.
> Assuming I can figure out a workaround for identifying when a PCM stream is
> 16 or 24 bit, can I then assume that 24 bit packed int means each 24 bit
> sample is packed into 3 continous bytes?
If the type is 1, 24 bit will be packed in 3 continuous bytes. If the type
is WAVE_FORMAT_EXTENSIBLE, the packing is determined by the wBitsPerSample
and wValidBitsPerSample value.