From: Noel Borthwick on
Also if you read further, they don't consider 24 bit to be of type
WAVE_FORMAT_PCM. I don't know what the justification for that is.

If wFormatTag is WAVE_FORMAT_PCM, then wBitsPerSample should be equal to 8
or 16. For non-PCM formats, this member must be set according to the
manufacturer's specification of the format tag.


"Noel Borthwick" <nospam(a)cakewalk.com> wrote in message
news:9KKdnbTT9vBYEWnYnZ2dnUVZ_u-unZ2d(a)rcn.net...
> Actually in their defence, they claim that 24 bits is not an appropriate
> format to describe using WAVEFORMATEX. That doesn't justify not supporting
> millions of files already in the field, but..
>
> http://msdn2.microsoft.com/en-us/library/ms713497.aspx
>
> "Formats that support more than two channels or sample sizes of more than
> 16 bits can be described in a WAVEFORMATEXTENSIBLE structure, which
> includes the WAVEFORMAT structure."
>
>
>
> "Michael" <muirhead(a)haidagwaii.net> wrote in message
> news:fvedndK_mp9N62nYnZ2dnUVZ_smonZ2d(a)qcislands.net...
>> Thanks tons for this info, Noel. Very odd that M$ apparently doesn't
>> want its own driver models (hence its own apps) to properly recognize a
>> file format they created and used to fully support. :-\
>>
>> http://msdn2.microsoft.com/en-us/library/ms789667.aspx
>> The subset of WAVEFORMATEX PCM formats that KMixer supports differs
>> between Windows releases, as shown in the following table.
>> Windows Release Packed Sample Sizes Number of Channels
>> Windows 98 "Gold" 8, 16, 24, and 32 bits Multichannel
>> Windows 98 SE 8 and 16 bits only Mono and stereo only
>> Windows 98 SE + hotfix 8, 16, 24, and 32 bits Mono and stereo only
>> Windows 2000 8 and 16 bits only Mono and stereo only
>> Windows Me 8, 16, 24, and 32 bits Mono and stereo only
>> Windows XP and later 8 and 16 bits only Mono and stereo only
>>
>> I liked especially the bit about the M$ rep who admitted not
>> understanding such a basic failure in the OS he's supposed to support.
>> :-)
>>
>> Noel Borthwick wrote:
>>
>>> Interesting. I've known about the WMP incompatibility with 24 bit audio
>>> files, but didn't know someone wrote a filter to circumvent this. A long
>>> time ago my machine somehow started playing 24 bit wave files from
>>> SONAR -
>>> most likely I acquired a filter like this through some application I
>>> installed. I spoke to someone from MS once and he was very puzzled by
>>> how
>>> my version of WMP played these 24 bit audio files and his didn't :-)
>>>
>>> Some background about 24 bit audio and this format to explains the
>>> history
>>> of this infamous problem. Years ago (90's) when audio editors like
>>> SoundForge first started supporting 24 bit audio these files were
>>> written
>>> with the classic WAVEFORMATEX header with the bit depth set to 24 bits.
>>> For some reason Microsoft has stubbornly failed to acknowledge this a
>>> valid wave format and prefers the file to be authored with a
>>> WAVEFORMATEXTENSIBLE header. A few years ago when we were adding
>>> surround
>>> support (which requires a WAVEFORMATEXTENSIBLE header), out of curiosity
>>> I changed the way SONAR wrote 24 bit audio to write it in the MS blessed
>>> way. Unfortunately all hell broke loose since only SONAR and a couple of
>>> applications were able to read these files. It turned out that
>>> WAVEFORMATEXTENSIBLE was very poorly supported by most DAW's and audio
>>> editors. They would either barf on the file or read it as an incorrect
>>> format. So I switched back to writing them in classic WAVEFORMATEX. I'd
>>> much rather other apps read these files than MediaPlayer thank you <g>
>>>
>>> Its pretty strange that Microsoft has stubbornly refused to support
>>> these
>>> files despite the fact that the entire audio industry writes them this
>>> way.
>>> Noel
>>>
>>> "Shawn O'Connor" <SO(a)comcast.net> wrote in message
>>> news:7c6dnUk11vQSqGzYnZ2dnUVZ_t2tnZ2d(a)comcast.com...
>>>> This might help.....
>>>>
>>>> Legacy HD Audio Filter - Many audio processing applications still
>>>> produce
>>>> high-definition audio such as 24bit/96kHz in a legacy WAV format. By
>>>> default
>>>> DirectShow players (such as Media Player) won't be able to play these
>>>> files
>>>> as the Audio Renderer refuses to accept this legacy type even though it
>>>> is perfectly capable of playing it. This filter registers itself as
>>>> being
>>>> able
>>>> to handle this legacy format, and at the same time converts to a format
>>>> the
>>>> DirectShow Audio Renderer will accept (WAVEFORMATEXTENSIBLE). This is
>>>> done without altering the audio data in any way.
>>>>
>>>> http://www.chrisnet.net/msdn/AudioTypeConvert.zip
>>>>
>>>> Download it, Unzip it, and place the AudioTypeConvert.ax file in your
>>>> System32 folder.
>>>> Then open a Command Prompt and register it with this:
>>>>
>>>> regsvr32 c:\windows\system32\AudioTypeConvert.ax
>>>>
>>>> If you want to remove it at anytime just unregister it with:
>>>>
>>>> regsvr32 /U c:\windows\system32\AudioTypeConvert.ax
>>
>>
>
>


From: Noel Borthwick on
Oh well, here is the justification...
Their rationale is that you need more descriptive information to describe
the 24 bit format in general, than what WAVEFORMATEX allows. This has more
relevence to describing an audio stream to a driver than the file format
itself, so its still not a justification to refuse to load legacy 24 bit
files.

http://msdn2.microsoft.com/en-us/library/ms789667.aspx
WAVEFORMATEX is sufficient for describing formats with sample sizes of 8 or
16 bits, but WAVEFORMATEXTENSIBLE is necessary to adequately describe
formats with a sample precision of greater than 16 bits. Here are two
examples:

a.. A stream with a sample precision of 24 bits can use a 32-bit container
size for efficient processing, but can be converted to use a 24-bit
container to improve storage efficiency without loss of data.
b.. When processing a stream with 24-bit sample data, a rendering device
that provides only 20 bits of precision can use dithering to improve the
fidelity of its output signal. Dithering, however, requires additional
processing time, and if the original stream is accurate to only 20 bits, the
additional processing is unnecessary.

In both of these examples, preserving signal quality while making the right
tradeoff between processing and storage efficiency is possible only if both
the sample precision and container size are known.



"Noel Borthwick" <nospam(a)cakewalk.com> wrote in message
news:0didnUqQNZhBEGnYnZ2dnUVZ_oupnZ2d(a)rcn.net...
> Also if you read further, they don't consider 24 bit to be of type
> WAVE_FORMAT_PCM. I don't know what the justification for that is.
>
> If wFormatTag is WAVE_FORMAT_PCM, then wBitsPerSample should be equal to 8
> or 16. For non-PCM formats, this member must be set according to the
> manufacturer's specification of the format tag.
>
>
> "Noel Borthwick" <nospam(a)cakewalk.com> wrote in message
> news:9KKdnbTT9vBYEWnYnZ2dnUVZ_u-unZ2d(a)rcn.net...
>> Actually in their defence, they claim that 24 bits is not an appropriate
>> format to describe using WAVEFORMATEX. That doesn't justify not
>> supporting millions of files already in the field, but..
>>
>> http://msdn2.microsoft.com/en-us/library/ms713497.aspx
>>
>> "Formats that support more than two channels or sample sizes of more than
>> 16 bits can be described in a WAVEFORMATEXTENSIBLE structure, which
>> includes the WAVEFORMAT structure."
>>
>>
>>
>> "Michael" <muirhead(a)haidagwaii.net> wrote in message
>> news:fvedndK_mp9N62nYnZ2dnUVZ_smonZ2d(a)qcislands.net...
>>> Thanks tons for this info, Noel. Very odd that M$ apparently doesn't
>>> want its own driver models (hence its own apps) to properly recognize a
>>> file format they created and used to fully support. :-\
>>>
>>> http://msdn2.microsoft.com/en-us/library/ms789667.aspx
>>> The subset of WAVEFORMATEX PCM formats that KMixer supports differs
>>> between Windows releases, as shown in the following table.
>>> Windows Release Packed Sample Sizes Number of Channels
>>> Windows 98 "Gold" 8, 16, 24, and 32 bits Multichannel
>>> Windows 98 SE 8 and 16 bits only Mono and stereo only
>>> Windows 98 SE + hotfix 8, 16, 24, and 32 bits Mono and stereo only
>>> Windows 2000 8 and 16 bits only Mono and stereo only
>>> Windows Me 8, 16, 24, and 32 bits Mono and stereo only
>>> Windows XP and later 8 and 16 bits only Mono and stereo only
>>>
>>> I liked especially the bit about the M$ rep who admitted not
>>> understanding such a basic failure in the OS he's supposed to support.
>>> :-)
>>>
>>> Noel Borthwick wrote:
>>>
>>>> Interesting. I've known about the WMP incompatibility with 24 bit audio
>>>> files, but didn't know someone wrote a filter to circumvent this. A
>>>> long
>>>> time ago my machine somehow started playing 24 bit wave files from
>>>> SONAR -
>>>> most likely I acquired a filter like this through some application I
>>>> installed. I spoke to someone from MS once and he was very puzzled by
>>>> how
>>>> my version of WMP played these 24 bit audio files and his didn't :-)
>>>>
>>>> Some background about 24 bit audio and this format to explains the
>>>> history
>>>> of this infamous problem. Years ago (90's) when audio editors like
>>>> SoundForge first started supporting 24 bit audio these files were
>>>> written
>>>> with the classic WAVEFORMATEX header with the bit depth set to 24 bits.
>>>> For some reason Microsoft has stubbornly failed to acknowledge this a
>>>> valid wave format and prefers the file to be authored with a
>>>> WAVEFORMATEXTENSIBLE header. A few years ago when we were adding
>>>> surround
>>>> support (which requires a WAVEFORMATEXTENSIBLE header), out of
>>>> curiosity
>>>> I changed the way SONAR wrote 24 bit audio to write it in the MS
>>>> blessed
>>>> way. Unfortunately all hell broke loose since only SONAR and a couple
>>>> of
>>>> applications were able to read these files. It turned out that
>>>> WAVEFORMATEXTENSIBLE was very poorly supported by most DAW's and audio
>>>> editors. They would either barf on the file or read it as an incorrect
>>>> format. So I switched back to writing them in classic WAVEFORMATEX. I'd
>>>> much rather other apps read these files than MediaPlayer thank you <g>
>>>>
>>>> Its pretty strange that Microsoft has stubbornly refused to support
>>>> these
>>>> files despite the fact that the entire audio industry writes them this
>>>> way.
>>>> Noel
>>>>
>>>> "Shawn O'Connor" <SO(a)comcast.net> wrote in message
>>>> news:7c6dnUk11vQSqGzYnZ2dnUVZ_t2tnZ2d(a)comcast.com...
>>>>> This might help.....
>>>>>
>>>>> Legacy HD Audio Filter - Many audio processing applications still
>>>>> produce
>>>>> high-definition audio such as 24bit/96kHz in a legacy WAV format. By
>>>>> default
>>>>> DirectShow players (such as Media Player) won't be able to play these
>>>>> files
>>>>> as the Audio Renderer refuses to accept this legacy type even though
>>>>> it
>>>>> is perfectly capable of playing it. This filter registers itself as
>>>>> being
>>>>> able
>>>>> to handle this legacy format, and at the same time converts to a
>>>>> format
>>>>> the
>>>>> DirectShow Audio Renderer will accept (WAVEFORMATEXTENSIBLE). This is
>>>>> done without altering the audio data in any way.
>>>>>
>>>>> http://www.chrisnet.net/msdn/AudioTypeConvert.zip
>>>>>
>>>>> Download it, Unzip it, and place the AudioTypeConvert.ax file in your
>>>>> System32 folder.
>>>>> Then open a Command Prompt and register it with this:
>>>>>
>>>>> regsvr32 c:\windows\system32\AudioTypeConvert.ax
>>>>>
>>>>> If you want to remove it at anytime just unregister it with:
>>>>>
>>>>> regsvr32 /U c:\windows\system32\AudioTypeConvert.ax
>>>
>>>
>>
>>
>
>


From: Michael on
My thoughts exactly. Enhancing storage efficiency while also streaming
efficiently is all well and good where possible, but it doesn't explain or
justify discontinuing (what I suppose they'd call "legacy") support for a
widely used 24-bit WAVEFORMATEX format. Coulda just left it up to KMIXER
to do what it *used* to do whenever it encounters such an animal. That's
what object headers are *for*. :-\

Noel Borthwick wrote:

> Oh well, here is the justification...
> Their rationale is that you need more descriptive information to describe
> the 24 bit format in general, than what WAVEFORMATEX allows. This has more
> relevence to describing an audio stream to a driver than the file format
> itself, so its still not a justification to refuse to load legacy 24 bit
> files.
>
> http://msdn2.microsoft.com/en-us/library/ms789667.aspx
> WAVEFORMATEX is sufficient for describing formats with sample sizes of 8
> or 16 bits, but WAVEFORMATEXTENSIBLE is necessary to adequately describe
> formats with a sample precision of greater than 16 bits. Here are two
> examples:
>
> a.. A stream with a sample precision of 24 bits can use a 32-bit
> container size for efficient processing, but can be converted to use a
> 24-bit container to improve storage efficiency without loss of data.
> b.. When processing a stream with 24-bit sample data, a rendering device
> that provides only 20 bits of precision can use dithering to improve the
> fidelity of its output signal. Dithering, however, requires additional
> processing time, and if the original stream is accurate to only 20 bits,
> the additional processing is unnecessary.
>
> In both of these examples, preserving signal quality while making the
> right tradeoff between processing and storage efficiency is possible only
> if both the sample precision and container size are known.
>
>
>
> "Noel Borthwick" <nospam(a)cakewalk.com> wrote in message
> news:0didnUqQNZhBEGnYnZ2dnUVZ_oupnZ2d(a)rcn.net...
>> Also if you read further, they don't consider 24 bit to be of type
>> WAVE_FORMAT_PCM. I don't know what the justification for that is.
>>
>> If wFormatTag is WAVE_FORMAT_PCM, then wBitsPerSample should be equal to
>> 8 or 16. For non-PCM formats, this member must be set according to the
>> manufacturer's specification of the format tag.
>>
>>
>> "Noel Borthwick" <nospam(a)cakewalk.com> wrote in message
>> news:9KKdnbTT9vBYEWnYnZ2dnUVZ_u-unZ2d(a)rcn.net...
>>> Actually in their defence, they claim that 24 bits is not an appropriate
>>> format to describe using WAVEFORMATEX. That doesn't justify not
>>> supporting millions of files already in the field, but..
>>>
>>> http://msdn2.microsoft.com/en-us/library/ms713497.aspx
>>>
>>> "Formats that support more than two channels or sample sizes of more
>>> than 16 bits can be described in a WAVEFORMATEXTENSIBLE structure, which
>>> includes the WAVEFORMAT structure."
>>>
>>>
>>>
>>> "Michael" <muirhead(a)haidagwaii.net> wrote in message
>>> news:fvedndK_mp9N62nYnZ2dnUVZ_smonZ2d(a)qcislands.net...
>>>> Thanks tons for this info, Noel. Very odd that M$ apparently doesn't
>>>> want its own driver models (hence its own apps) to properly recognize a
>>>> file format they created and used to fully support. :-\
>>>>
>>>> http://msdn2.microsoft.com/en-us/library/ms789667.aspx
>>>> The subset of WAVEFORMATEX PCM formats that KMixer supports differs
>>>> between Windows releases, as shown in the following table.
>>>> Windows Release Packed Sample Sizes Number of Channels
>>>> Windows 98 "Gold" 8, 16, 24, and 32 bits Multichannel
>>>> Windows 98 SE 8 and 16 bits only Mono and stereo only
>>>> Windows 98 SE + hotfix 8, 16, 24, and 32 bits Mono and stereo only
>>>> Windows 2000 8 and 16 bits only Mono and stereo only
>>>> Windows Me 8, 16, 24, and 32 bits Mono and stereo only
>>>> Windows XP and later 8 and 16 bits only Mono and stereo only
>>>>
>>>> I liked especially the bit about the M$ rep who admitted not
>>>> understanding such a basic failure in the OS he's supposed to support.
>>>> :-)
>>>>
>>>> Noel Borthwick wrote:
>>>>
>>>>> Interesting. I've known about the WMP incompatibility with 24 bit
>>>>> audio files, but didn't know someone wrote a filter to circumvent
>>>>> this. A long
>>>>> time ago my machine somehow started playing 24 bit wave files from
>>>>> SONAR -
>>>>> most likely I acquired a filter like this through some application I
>>>>> installed. I spoke to someone from MS once and he was very puzzled by
>>>>> how
>>>>> my version of WMP played these 24 bit audio files and his didn't :-)
>>>>>
>>>>> Some background about 24 bit audio and this format to explains the
>>>>> history
>>>>> of this infamous problem. Years ago (90's) when audio editors like
>>>>> SoundForge first started supporting 24 bit audio these files were
>>>>> written
>>>>> with the classic WAVEFORMATEX header with the bit depth set to 24
>>>>> bits. For some reason Microsoft has stubbornly failed to acknowledge
>>>>> this a valid wave format and prefers the file to be authored with a
>>>>> WAVEFORMATEXTENSIBLE header. A few years ago when we were adding
>>>>> surround
>>>>> support (which requires a WAVEFORMATEXTENSIBLE header), out of
>>>>> curiosity
>>>>> I changed the way SONAR wrote 24 bit audio to write it in the MS
>>>>> blessed
>>>>> way. Unfortunately all hell broke loose since only SONAR and a couple
>>>>> of
>>>>> applications were able to read these files. It turned out that
>>>>> WAVEFORMATEXTENSIBLE was very poorly supported by most DAW's and audio
>>>>> editors. They would either barf on the file or read it as an incorrect
>>>>> format. So I switched back to writing them in classic WAVEFORMATEX.
>>>>> I'd much rather other apps read these files than MediaPlayer thank
>>>>> you <g> Its pretty strange that Microsoft has stubbornly refused to
>>>>> support
>>>>> these
>>>>> files despite the fact that the entire audio industry writes them this
>>>>> way.
>>>>> Noel
>>>>>
>>>>> "Shawn O'Connor" <SO(a)comcast.net> wrote in message
>>>>> news:7c6dnUk11vQSqGzYnZ2dnUVZ_t2tnZ2d(a)comcast.com...
>>>>>> This might help.....
>>>>>>
>>>>>> Legacy HD Audio Filter - Many audio processing applications still
>>>>>> produce
>>>>>> high-definition audio such as 24bit/96kHz in a legacy WAV format. By
>>>>>> default
>>>>>> DirectShow players (such as Media Player) won't be able to play these
>>>>>> files
>>>>>> as the Audio Renderer refuses to accept this legacy type even though
>>>>>> it
>>>>>> is perfectly capable of playing it. This filter registers itself as
>>>>>> being
>>>>>> able
>>>>>> to handle this legacy format, and at the same time converts to a
>>>>>> format
>>>>>> the
>>>>>> DirectShow Audio Renderer will accept (WAVEFORMATEXTENSIBLE). This is
>>>>>> done without altering the audio data in any way.
>>>>>>
>>>>>> http://www.chrisnet.net/msdn/AudioTypeConvert.zip
>>>>>>
>>>>>> Download it, Unzip it, and place the AudioTypeConvert.ax file in your
>>>>>> System32 folder.
>>>>>> Then open a Command Prompt and register it with this:
>>>>>>
>>>>>> regsvr32 c:\windows\system32\AudioTypeConvert.ax
>>>>>>
>>>>>> If you want to remove it at anytime just unregister it with:
>>>>>>
>>>>>> regsvr32 /U c:\windows\system32\AudioTypeConvert.ax


From: Gerry Peters on
Sp Michael have you fuond that you do have that .AX file registered
already? So it has nothing to do with codecs?

I tried it and now I can play 24 bit with Media player - too cool.

Gerry Peters

On Sun, 11 Mar 2007 17:00:34 -0700, "Michael"
<muirhead(a)haidagwaii.net> wrote:

>My thoughts exactly. Enhancing storage efficiency while also streaming
>efficiently is all well and good where possible, but it doesn't explain or
>justify discontinuing (what I suppose they'd call "legacy") support for a
>widely used 24-bit WAVEFORMATEX format. Coulda just left it up to KMIXER
>to do what it *used* to do whenever it encounters such an animal. That's
>what object headers are *for*. :-\
>
>Noel Borthwick wrote:
>
>> Oh well, here is the justification...
>> Their rationale is that you need more descriptive information to describe
>> the 24 bit format in general, than what WAVEFORMATEX allows. This has more
>> relevence to describing an audio stream to a driver than the file format
>> itself, so its still not a justification to refuse to load legacy 24 bit
>> files.
>>
>> http://msdn2.microsoft.com/en-us/library/ms789667.aspx
>> WAVEFORMATEX is sufficient for describing formats with sample sizes of 8
>> or 16 bits, but WAVEFORMATEXTENSIBLE is necessary to adequately describe
>> formats with a sample precision of greater than 16 bits. Here are two
>> examples:
>>
>> a.. A stream with a sample precision of 24 bits can use a 32-bit
>> container size for efficient processing, but can be converted to use a
>> 24-bit container to improve storage efficiency without loss of data.
>> b.. When processing a stream with 24-bit sample data, a rendering device
>> that provides only 20 bits of precision can use dithering to improve the
>> fidelity of its output signal. Dithering, however, requires additional
>> processing time, and if the original stream is accurate to only 20 bits,
>> the additional processing is unnecessary.
>>
>> In both of these examples, preserving signal quality while making the
>> right tradeoff between processing and storage efficiency is possible only
>> if both the sample precision and container size are known.
>>
>>
>>
>> "Noel Borthwick" <nospam(a)cakewalk.com> wrote in message
>> news:0didnUqQNZhBEGnYnZ2dnUVZ_oupnZ2d(a)rcn.net...
>>> Also if you read further, they don't consider 24 bit to be of type
>>> WAVE_FORMAT_PCM. I don't know what the justification for that is.
>>>
>>> If wFormatTag is WAVE_FORMAT_PCM, then wBitsPerSample should be equal to
>>> 8 or 16. For non-PCM formats, this member must be set according to the
>>> manufacturer's specification of the format tag.
>>>
>>>
>>> "Noel Borthwick" <nospam(a)cakewalk.com> wrote in message
>>> news:9KKdnbTT9vBYEWnYnZ2dnUVZ_u-unZ2d(a)rcn.net...
>>>> Actually in their defence, they claim that 24 bits is not an appropriate
>>>> format to describe using WAVEFORMATEX. That doesn't justify not
>>>> supporting millions of files already in the field, but..
>>>>
>>>> http://msdn2.microsoft.com/en-us/library/ms713497.aspx
>>>>
>>>> "Formats that support more than two channels or sample sizes of more
>>>> than 16 bits can be described in a WAVEFORMATEXTENSIBLE structure, which
>>>> includes the WAVEFORMAT structure."
>>>>
>>>>
>>>>
>>>> "Michael" <muirhead(a)haidagwaii.net> wrote in message
>>>> news:fvedndK_mp9N62nYnZ2dnUVZ_smonZ2d(a)qcislands.net...
>>>>> Thanks tons for this info, Noel. Very odd that M$ apparently doesn't
>>>>> want its own driver models (hence its own apps) to properly recognize a
>>>>> file format they created and used to fully support. :-\
>>>>>
>>>>> http://msdn2.microsoft.com/en-us/library/ms789667.aspx
>>>>> The subset of WAVEFORMATEX PCM formats that KMixer supports differs
>>>>> between Windows releases, as shown in the following table.
>>>>> Windows Release Packed Sample Sizes Number of Channels
>>>>> Windows 98 "Gold" 8, 16, 24, and 32 bits Multichannel
>>>>> Windows 98 SE 8 and 16 bits only Mono and stereo only
>>>>> Windows 98 SE + hotfix 8, 16, 24, and 32 bits Mono and stereo only
>>>>> Windows 2000 8 and 16 bits only Mono and stereo only
>>>>> Windows Me 8, 16, 24, and 32 bits Mono and stereo only
>>>>> Windows XP and later 8 and 16 bits only Mono and stereo only
>>>>>
>>>>> I liked especially the bit about the M$ rep who admitted not
>>>>> understanding such a basic failure in the OS he's supposed to support.
>>>>> :-)
>>>>>
>>>>> Noel Borthwick wrote:
>>>>>
>>>>>> Interesting. I've known about the WMP incompatibility with 24 bit
>>>>>> audio files, but didn't know someone wrote a filter to circumvent
>>>>>> this. A long
>>>>>> time ago my machine somehow started playing 24 bit wave files from
>>>>>> SONAR -
>>>>>> most likely I acquired a filter like this through some application I
>>>>>> installed. I spoke to someone from MS once and he was very puzzled by
>>>>>> how
>>>>>> my version of WMP played these 24 bit audio files and his didn't :-)
>>>>>>
>>>>>> Some background about 24 bit audio and this format to explains the
>>>>>> history
>>>>>> of this infamous problem. Years ago (90's) when audio editors like
>>>>>> SoundForge first started supporting 24 bit audio these files were
>>>>>> written
>>>>>> with the classic WAVEFORMATEX header with the bit depth set to 24
>>>>>> bits. For some reason Microsoft has stubbornly failed to acknowledge
>>>>>> this a valid wave format and prefers the file to be authored with a
>>>>>> WAVEFORMATEXTENSIBLE header. A few years ago when we were adding
>>>>>> surround
>>>>>> support (which requires a WAVEFORMATEXTENSIBLE header), out of
>>>>>> curiosity
>>>>>> I changed the way SONAR wrote 24 bit audio to write it in the MS
>>>>>> blessed
>>>>>> way. Unfortunately all hell broke loose since only SONAR and a couple
>>>>>> of
>>>>>> applications were able to read these files. It turned out that
>>>>>> WAVEFORMATEXTENSIBLE was very poorly supported by most DAW's and audio
>>>>>> editors. They would either barf on the file or read it as an incorrect
>>>>>> format. So I switched back to writing them in classic WAVEFORMATEX.
>>>>>> I'd much rather other apps read these files than MediaPlayer thank
>>>>>> you <g> Its pretty strange that Microsoft has stubbornly refused to
>>>>>> support
>>>>>> these
>>>>>> files despite the fact that the entire audio industry writes them this
>>>>>> way.
>>>>>> Noel
>>>>>>
>>>>>> "Shawn O'Connor" <SO(a)comcast.net> wrote in message
>>>>>> news:7c6dnUk11vQSqGzYnZ2dnUVZ_t2tnZ2d(a)comcast.com...
>>>>>>> This might help.....
>>>>>>>
>>>>>>> Legacy HD Audio Filter - Many audio processing applications still
>>>>>>> produce
>>>>>>> high-definition audio such as 24bit/96kHz in a legacy WAV format. By
>>>>>>> default
>>>>>>> DirectShow players (such as Media Player) won't be able to play these
>>>>>>> files
>>>>>>> as the Audio Renderer refuses to accept this legacy type even though
>>>>>>> it
>>>>>>> is perfectly capable of playing it. This filter registers itself as
>>>>>>> being
>>>>>>> able
>>>>>>> to handle this legacy format, and at the same time converts to a
>>>>>>> format
>>>>>>> the
>>>>>>> DirectShow Audio Renderer will accept (WAVEFORMATEXTENSIBLE). This is
>>>>>>> done without altering the audio data in any way.
>>>>>>>
>>>>>>> http://www.chrisnet.net/msdn/AudioTypeConvert.zip
>>>>>>>
>>>>>>> Download it, Unzip it, and place the AudioTypeConvert.ax file in your
>>>>>>> System32 folder.
>>>>>>> Then open a Command Prompt and register it with this:
>>>>>>>
>>>>>>> regsvr32 c:\windows\system32\AudioTypeConvert.ax
>>>>>>>
>>>>>>> If you want to remove it at anytime just unregister it with:
>>>>>>>
>>>>>>> regsvr32 /U c:\windows\system32\AudioTypeConvert.ax
>
From: Michael on
Gerry Peters wrote:

> Sp Michael have you fuond that you do have that .AX file registered
> already? So it has nothing to do with codecs?

Hmmm... not sure what you're saying here, Gerry. I do know now that it
isn't the codecs per-se, but that something or other has installed a filter
that seems to wrap WAVEFORMATEX files so its headers make sense to
DirectSound... but the filter's name and origin are a mystery to me: -)

> I tried it and now I can play 24 bit with Media player - too cool.
>
> Gerry Peters

Yay!! :-) I don't know why still, but I've been able to do that for a
long time.




> On Sun, 11 Mar 2007 17:00:34 -0700, "Michael"
> <muirhead(a)haidagwaii.net> wrote:
>
>> My thoughts exactly. Enhancing storage efficiency while also streaming
>> efficiently is all well and good where possible, but it doesn't explain
>> or justify discontinuing (what I suppose they'd call "legacy") support
>> for a widely used 24-bit WAVEFORMATEX format. Coulda just left it up
>> to KMIXER to do what it *used* to do whenever it encounters such an
>> animal. That's what object headers are *for*. :-\
>>
>> Noel Borthwick wrote:
>>
>>> Oh well, here is the justification...
>>> Their rationale is that you need more descriptive information to
>>> describe the 24 bit format in general, than what WAVEFORMATEX allows.
>>> This has more relevence to describing an audio stream to a driver than
>>> the file format itself, so its still not a justification to refuse to
>>> load legacy 24 bit files.
>>>
>>> http://msdn2.microsoft.com/en-us/library/ms789667.aspx
>>> WAVEFORMATEX is sufficient for describing formats with sample sizes of 8
>>> or 16 bits, but WAVEFORMATEXTENSIBLE is necessary to adequately describe
>>> formats with a sample precision of greater than 16 bits. Here are two
>>> examples:
>>>
>>> a.. A stream with a sample precision of 24 bits can use a 32-bit
>>> container size for efficient processing, but can be converted to use a
>>> 24-bit container to improve storage efficiency without loss of data.
>>> b.. When processing a stream with 24-bit sample data, a rendering
>>> device that provides only 20 bits of precision can use dithering to
>>> improve the fidelity of its output signal. Dithering, however, requires
>>> additional processing time, and if the original stream is accurate to
>>> only 20 bits, the additional processing is unnecessary.
>>>
>>> In both of these examples, preserving signal quality while making the
>>> right tradeoff between processing and storage efficiency is possible
>>> only if both the sample precision and container size are known.
>>>
>>>
>>>
>>> "Noel Borthwick" <nospam(a)cakewalk.com> wrote in message
>>> news:0didnUqQNZhBEGnYnZ2dnUVZ_oupnZ2d(a)rcn.net...
>>>> Also if you read further, they don't consider 24 bit to be of type
>>>> WAVE_FORMAT_PCM. I don't know what the justification for that is.
>>>>
>>>> If wFormatTag is WAVE_FORMAT_PCM, then wBitsPerSample should be equal
>>>> to 8 or 16. For non-PCM formats, this member must be set according to
>>>> the manufacturer's specification of the format tag.
>>>>
>>>>
>>>> "Noel Borthwick" <nospam(a)cakewalk.com> wrote in message
>>>> news:9KKdnbTT9vBYEWnYnZ2dnUVZ_u-unZ2d(a)rcn.net...
>>>>> Actually in their defence, they claim that 24 bits is not an
>>>>> appropriate format to describe using WAVEFORMATEX. That doesn't
>>>>> justify not supporting millions of files already in the field, but..
>>>>>
>>>>> http://msdn2.microsoft.com/en-us/library/ms713497.aspx
>>>>>
>>>>> "Formats that support more than two channels or sample sizes of more
>>>>> than 16 bits can be described in a WAVEFORMATEXTENSIBLE structure,
>>>>> which includes the WAVEFORMAT structure."
>>>>>
>>>>>
>>>>>
>>>>> "Michael" <muirhead(a)haidagwaii.net> wrote in message
>>>>> news:fvedndK_mp9N62nYnZ2dnUVZ_smonZ2d(a)qcislands.net...
>>>>>> Thanks tons for this info, Noel. Very odd that M$ apparently
>>>>>> doesn't want its own driver models (hence its own apps) to properly
>>>>>> recognize a file format they created and used to fully support. :-\
>>>>>>
>>>>>> http://msdn2.microsoft.com/en-us/library/ms789667.aspx
>>>>>> The subset of WAVEFORMATEX PCM formats that KMixer supports differs
>>>>>> between Windows releases, as shown in the following table.
>>>>>> Windows Release Packed Sample Sizes Number of Channels
>>>>>> Windows 98 "Gold" 8, 16, 24, and 32 bits Multichannel
>>>>>> Windows 98 SE 8 and 16 bits only Mono and stereo only
>>>>>> Windows 98 SE + hotfix 8, 16, 24, and 32 bits Mono and stereo
>>>>>> only Windows 2000 8 and 16 bits only Mono and stereo only
>>>>>> Windows Me 8, 16, 24, and 32 bits Mono and stereo only
>>>>>> Windows XP and later 8 and 16 bits only Mono and stereo only
>>>>>>
>>>>>> I liked especially the bit about the M$ rep who admitted not
>>>>>> understanding such a basic failure in the OS he's supposed to
>>>>>> support. :-)
>>>>>>
>>>>>> Noel Borthwick wrote:
>>>>>>
>>>>>>> Interesting. I've known about the WMP incompatibility with 24 bit
>>>>>>> audio files, but didn't know someone wrote a filter to circumvent
>>>>>>> this. A long
>>>>>>> time ago my machine somehow started playing 24 bit wave files from
>>>>>>> SONAR -
>>>>>>> most likely I acquired a filter like this through some application I
>>>>>>> installed. I spoke to someone from MS once and he was very puzzled
>>>>>>> by how
>>>>>>> my version of WMP played these 24 bit audio files and his didn't :-)
>>>>>>>
>>>>>>> Some background about 24 bit audio and this format to explains the
>>>>>>> history
>>>>>>> of this infamous problem. Years ago (90's) when audio editors like
>>>>>>> SoundForge first started supporting 24 bit audio these files were
>>>>>>> written
>>>>>>> with the classic WAVEFORMATEX header with the bit depth set to 24
>>>>>>> bits. For some reason Microsoft has stubbornly failed to acknowledge
>>>>>>> this a valid wave format and prefers the file to be authored with a
>>>>>>> WAVEFORMATEXTENSIBLE header. A few years ago when we were adding
>>>>>>> surround
>>>>>>> support (which requires a WAVEFORMATEXTENSIBLE header), out of
>>>>>>> curiosity
>>>>>>> I changed the way SONAR wrote 24 bit audio to write it in the MS
>>>>>>> blessed
>>>>>>> way. Unfortunately all hell broke loose since only SONAR and a
>>>>>>> couple of
>>>>>>> applications were able to read these files. It turned out that
>>>>>>> WAVEFORMATEXTENSIBLE was very poorly supported by most DAW's and
>>>>>>> audio editors. They would either barf on the file or read it as an
>>>>>>> incorrect format. So I switched back to writing them in classic
>>>>>>> WAVEFORMATEX. I'd much rather other apps read these files than
>>>>>>> MediaPlayer thank you <g> Its pretty strange that Microsoft has
>>>>>>> stubbornly refused to support
>>>>>>> these
>>>>>>> files despite the fact that the entire audio industry writes them
>>>>>>> this way.
>>>>>>> Noel
>>>>>>>
>>>>>>> "Shawn O'Connor" <SO(a)comcast.net> wrote in message
>>>>>>> news:7c6dnUk11vQSqGzYnZ2dnUVZ_t2tnZ2d(a)comcast.com...
>>>>>>>> This might help.....
>>>>>>>>
>>>>>>>> Legacy HD Audio Filter - Many audio processing applications still
>>>>>>>> produce
>>>>>>>> high-definition audio such as 24bit/96kHz in a legacy WAV format.
>>>>>>>> By default
>>>>>>>> DirectShow players (such as Media Player) won't be able to play
>>>>>>>> these files
>>>>>>>> as the Audio Renderer refuses to accept this legacy type even
>>>>>>>> though it
>>>>>>>> is perfectly capable of playing it. This filter registers itself as
>>>>>>>> being
>>>>>>>> able
>>>>>>>> to handle this legacy format, and at the same time converts to a
>>>>>>>> format
>>>>>>>> the
>>>>>>>> DirectShow Audio Renderer will accept (WAVEFORMATEXTENSIBLE). This
>>>>>>>> is done without altering the audio data in any way.
>>>>>>>>
>>>>>>>> http://www.chrisnet.net/msdn/AudioTypeConvert.zip
>>>>>>>>
>>>>>>>> Download it, Unzip it, and place the AudioTypeConvert.ax file in
>>>>>>>> your System32 folder.
>>>>>>>> Then open a Command Prompt and register it with this:
>>>>>>>>
>>>>>>>> regsvr32 c:\windows\system32\AudioTypeConvert.ax
>>>>>>>>
>>>>>>>> If you want to remove it at anytime just unregister it with:
>>>>>>>>
>>>>>>>> regsvr32 /U c:\windows\system32\AudioTypeConvert.ax


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13
Prev: Please help
Next: Midi Latency -Recording only