More questions about 24 vs 32 bits

pwppch wrote on 1/19/2000, 2:28 PM

I can't see the benifit.

When Vegas records audio, it is recording and saving what the
hardware gives it. We do no processing on the audio as it is
recorded. So we save at what ever the bit depth and sample rate - in
fixed point - that the hardware gives us.

When we read the audio back into Vegas, we convert to floating point.
All processing is done in floating point until the audio is rendered
to either audio hardware or to a file. We do a simple dither based on
the type of conversion being done before converting to the final
output.

Additionally, you can place our dither plugin - or some other
dithering plugin - on the main buses. (Doesn't make much sense to do
this at the track or send level.) This will dither the floating point
stream such that when converted to fixed point at a specific bit
depth, the best possible conversion will occur. (There are other
techniques to improve the floating point stream before the conversion
as well. )

Samplitude has to do the same thing somewhere at somepoint. I know
that Samplitude permits the recording into floating point. This is
all fine and dandy. The original material is still fixed point and
converted to floating point before it is saved. There can be no gain
or loss by converting before saving or after reading if the original
material is fixed point. There is no loss of data in either case.
When you do the conversion makes no difference. We do it when we
read. Samplitude permits you to do it when recording.

Perhaps Samplitude permits processing of recorded material during
recording(?) If so, then yes, they are changing the content and
possibly adding content that was not there in the original fixed
point original. Saving to floating point would assure that nothing is
lost. Vegas does not do any processing while recording, so saving to
floating point doesn't gain anything.

Rendering to files:
As of today, there is little point in delivering media in floating
point format. I don't know of a CODEC for Win9x or NT that will
convert FP streams to the fixed point formats of audio hardware. In
Win98 and Win2000, the WDM driver model and what is known as the
KMixer supposedly support (or will support) streaming in floating
point. This would permit the application to stream raw floating point
data to the output devices. The conversion is done by the kmixer, vs
the application. I can't comment on the quality of the conversion
that takes place in the kmixer. Personally I would rather have
control over the conversion vs letting some black box in the OS
handle it.

I know of no hardware that actually produces or accepts floating
point. Even if it did, floating point A/D and D/A converters are
_very_ expensive, impractical, and, as far as I have read, unreliable
and experimental. The realworld is still fixed point - today. I would
be intersted if anybody knows of a FP D/A or A/D converts that are on
the market.

Vegas does not do any behind the scenes mixing or 'pre-rendering', so
there would be no benifit to storing files back out to floating
point. (The conversion from fixed point to floating point is nominal
as far as CPU usage goes.) Does Samplitude do anything like this? If
if does, then pre-rendering to floating point would assure no data
loss.

The only place I could think that rendering to floating point could
be used in Vegas would be in mix to new track. This would produce and
maintain all processing done during the mix to new stages. With lots
of processing and such this could possible be a benifit. Still, you
would have to do a lot of mix to new track processing to reap the
benifit.

So, except for the case of mix to new, there is no benifit.

Peter

Vern Cooper wrote:
>>I read the following in the Samplitude newsgroup regarding
>>the reason they use 32bit files instead of 24 bit. Does the
>>same hold true for Vegas? Would we be signifigantly better
>>off using 32 bit float files instead of 24 bit?
>>
>>"Any conversation between 24 int and float produces small
>>data loss, even when dithering is used. Thats why we use
>>float also in the files. This way absolutely NO data loss
>>occurs and we have headroom above 0 dB!
>>
>>Cubase, Sadie etc.: 24 bit file -> 32 bit float processing
>>(small loss) -> volume setting -12 dB -> back to 24 bits -
>>result is 22 bits audio and 2 times of conversation loss.
>>
>>Samplitude: float file -> 32 bit processing (no loss) - >
>>volume setting -12 dB-> back to 32 bit file (no loss) - >
>>result is 32 bit float resolution, no bit loss, no
>>additional dither noise etc..."
>>

blisster wrote on 1/19/2000, 4:19 PM

I see your point. Still, if you plan to master a mixed down
file,there would be a definite benefit to having a 32-bit file to
process, right? Is this something that could possibly be built into a
future version of Vegas? Or can I do this now by changing the bit
depth of my project to 32 bits and saving the wave as a 32bit file?

Peter Haller wrote:
>>I can't see the benifit.
>>
>>When Vegas records audio, it is recording and saving what the
>>hardware gives it. We do no processing on the audio as it is
>>recorded. So we save at what ever the bit depth and sample rate -
in
>>fixed point - that the hardware gives us.
>>
>>When we read the audio back into Vegas, we convert to floating
point.
>>All processing is done in floating point until the audio is
rendered
>>to either audio hardware or to a file. We do a simple dither based
on
>>the type of conversion being done before converting to the final
>>output.
>>
>>Additionally, you can place our dither plugin - or some other
>>dithering plugin - on the main buses. (Doesn't make much sense to
do
>>this at the track or send level.) This will dither the floating
point
>>stream such that when converted to fixed point at a specific bit
>>depth, the best possible conversion will occur. (There are other
>>techniques to improve the floating point stream before the
conversion
>>as well. )
>>
>>Samplitude has to do the same thing somewhere at somepoint. I know
>>that Samplitude permits the recording into floating point. This is
>>all fine and dandy. The original material is still fixed point and
>>converted to floating point before it is saved. There can be no
gain
>>or loss by converting before saving or after reading if the
original
>>material is fixed point. There is no loss of data in either case.
>>When you do the conversion makes no difference. We do it when we
>>read. Samplitude permits you to do it when recording.
>>
>>Perhaps Samplitude permits processing of recorded material during
>>recording(?) If so, then yes, they are changing the content and
>>possibly adding content that was not there in the original fixed
>>point original. Saving to floating point would assure that nothing
is
>>lost. Vegas does not do any processing while recording, so saving
to
>>floating point doesn't gain anything.
>>
>>Rendering to files:
>>As of today, there is little point in delivering media in floating
>>point format. I don't know of a CODEC for Win9x or NT that will
>>convert FP streams to the fixed point formats of audio hardware. In
>>Win98 and Win2000, the WDM driver model and what is known as the
>>KMixer supposedly support (or will support) streaming in floating
>>point. This would permit the application to stream raw floating
point
>>data to the output devices. The conversion is done by the kmixer,
vs
>>the application. I can't comment on the quality of the conversion
>>that takes place in the kmixer. Personally I would rather have
>>control over the conversion vs letting some black box in the OS
>>handle it.
>>
>>I know of no hardware that actually produces or accepts floating
>>point. Even if it did, floating point A/D and D/A converters are
>>_very_ expensive, impractical, and, as far as I have read,
unreliable
>>and experimental. The realworld is still fixed point - today. I
would
>>be intersted if anybody knows of a FP D/A or A/D converts that are
on
>>the market.
>>
>>Vegas does not do any behind the scenes mixing or 'pre-rendering',
so
>>there would be no benifit to storing files back out to floating
>>point. (The conversion from fixed point to floating point is
nominal
>>as far as CPU usage goes.) Does Samplitude do anything like this?
If
>>if does, then pre-rendering to floating point would assure no data
>>loss.
>>
>>The only place I could think that rendering to floating point could
>>be used in Vegas would be in mix to new track. This would produce
and
>>maintain all processing done during the mix to new stages. With
lots
>>of processing and such this could possible be a benifit. Still, you
>>would have to do a lot of mix to new track processing to reap the
>>benifit.
>>
>>So, except for the case of mix to new, there is no benifit.
>>
>>Peter
>>
>>
>>Vern Cooper wrote:
>>>>I read the following in the Samplitude newsgroup regarding
>>>>the reason they use 32bit files instead of 24 bit. Does the
>>>>same hold true for Vegas? Would we be signifigantly better
>>>>off using 32 bit float files instead of 24 bit?
>>>>
>>>>"Any conversation between 24 int and float produces small
>>>>data loss, even when dithering is used. Thats why we use
>>>>float also in the files. This way absolutely NO data loss
>>>>occurs and we have headroom above 0 dB!
>>>>
>>>>Cubase, Sadie etc.: 24 bit file -> 32 bit float processing
>>>>(small loss) -> volume setting -12 dB -> back to 24 bits -
>>>>result is 22 bits audio and 2 times of conversation loss.
>>>>
>>>>Samplitude: float file -> 32 bit processing (no loss) - >
>>>>volume setting -12 dB-> back to 32 bit file (no loss) - >
>>>>result is 32 bit float resolution, no bit loss, no
>>>>additional dither noise etc..."
>>>>

pwppch wrote on 1/19/2000, 4:46 PM

So what you want to do is render your final mix to a floating point
file so that you can load this into a 2 track editor and then do you
final mastering.

Ok, I can see doing this. There wasn't any plan to support this, but
it would be easy enough.

I question the benifits.

Some benifit? Maybe.

Buy hey, I like simple features.

I am going to run some tests internally and see what the actual
difference is. I mean, I want to 1) hear the difference and 2) See
the difference on my scope. Also want to talk to our DSP gurus here
at the Foundry. I am getting the feeling this is like the reported
dynamic range of sound cards vs what they really can do.

Will let you know what I find out.

Peter

Vern Cooper wrote:
>>I see your point. Still, if you plan to master a mixed down
>>file,there would be a definite benefit to having a 32-bit file to
>>process, right? Is this something that could possibly be built into
a
>>future version of Vegas? Or can I do this now by changing the bit
>>depth of my project to 32 bits and saving the wave as a 32bit file?
>>
>>Peter Haller wrote:
>>>>I can't see the benifit.
>>>>
>>>>When Vegas records audio, it is recording and saving what the
>>>>hardware gives it. We do no processing on the audio as it is
>>>>recorded. So we save at what ever the bit depth and sample rate -
>>in
>>>>fixed point - that the hardware gives us.
>>>>
>>>>When we read the audio back into Vegas, we convert to floating
>>point.
>>>>All processing is done in floating point until the audio is
>>rendered
>>>>to either audio hardware or to a file. We do a simple dither
based
>>on
>>>>the type of conversion being done before converting to the final
>>>>output.
>>>>
>>>>Additionally, you can place our dither plugin - or some other
>>>>dithering plugin - on the main buses. (Doesn't make much sense to
>>do
>>>>this at the track or send level.) This will dither the floating
>>point
>>>>stream such that when converted to fixed point at a specific bit
>>>>depth, the best possible conversion will occur. (There are other
>>>>techniques to improve the floating point stream before the
>>conversion
>>>>as well. )
>>>>
>>>>Samplitude has to do the same thing somewhere at somepoint. I
know
>>>>that Samplitude permits the recording into floating point. This
is
>>>>all fine and dandy. The original material is still fixed point
and
>>>>converted to floating point before it is saved. There can be no
>>gain
>>>>or loss by converting before saving or after reading if the
>>original
>>>>material is fixed point. There is no loss of data in either case.
>>>>When you do the conversion makes no difference. We do it when we
>>>>read. Samplitude permits you to do it when recording.
>>>>
>>>>Perhaps Samplitude permits processing of recorded material during
>>>>recording(?) If so, then yes, they are changing the content and
>>>>possibly adding content that was not there in the original fixed
>>>>point original. Saving to floating point would assure that
nothing
>>is
>>>>lost. Vegas does not do any processing while recording, so saving
>>to
>>>>floating point doesn't gain anything.
>>>>
>>>>Rendering to files:
>>>>As of today, there is little point in delivering media in
floating
>>>>point format. I don't know of a CODEC for Win9x or NT that will
>>>>convert FP streams to the fixed point formats of audio hardware.
In
>>>>Win98 and Win2000, the WDM driver model and what is known as the
>>>>KMixer supposedly support (or will support) streaming in floating
>>>>point. This would permit the application to stream raw floating
>>point
>>>>data to the output devices. The conversion is done by the kmixer,
>>vs
>>>>the application. I can't comment on the quality of the conversion
>>>>that takes place in the kmixer. Personally I would rather have
>>>>control over the conversion vs letting some black box in the OS
>>>>handle it.
>>>>
>>>>I know of no hardware that actually produces or accepts floating
>>>>point. Even if it did, floating point A/D and D/A converters are
>>>>_very_ expensive, impractical, and, as far as I have read,
>>unreliable
>>>>and experimental. The realworld is still fixed point - today. I
>>would
>>>>be intersted if anybody knows of a FP D/A or A/D converts that
are
>>on
>>>>the market.
>>>>
>>>>Vegas does not do any behind the scenes mixing or 'pre-
rendering',
>>so
>>>>there would be no benifit to storing files back out to floating
>>>>point. (The conversion from fixed point to floating point is
>>nominal
>>>>as far as CPU usage goes.) Does Samplitude do anything like this?
>>If
>>>>if does, then pre-rendering to floating point would assure no
data
>>>>loss.
>>>>
>>>>The only place I could think that rendering to floating point
could
>>>>be used in Vegas would be in mix to new track. This would produce
>>and
>>>>maintain all processing done during the mix to new stages. With
>>lots
>>>>of processing and such this could possible be a benifit. Still,
you
>>>>would have to do a lot of mix to new track processing to reap the
>>>>benifit.
>>>>
>>>>So, except for the case of mix to new, there is no benifit.
>>>>
>>>>Peter
>>>>
>>>>
>>>>Vern Cooper wrote:
>>>>>>I read the following in the Samplitude newsgroup regarding
>>>>>>the reason they use 32bit files instead of 24 bit. Does the
>>>>>>same hold true for Vegas? Would we be signifigantly better
>>>>>>off using 32 bit float files instead of 24 bit?
>>>>>>
>>>>>>"Any conversation between 24 int and float produces small
>>>>>>data loss, even when dithering is used. Thats why we use
>>>>>>float also in the files. This way absolutely NO data loss
>>>>>>occurs and we have headroom above 0 dB!
>>>>>>
>>>>>>Cubase, Sadie etc.: 24 bit file -> 32 bit float processing
>>>>>>(small loss) -> volume setting -12 dB -> back to 24 bits -
>>>>>>result is 22 bits audio and 2 times of conversation loss.
>>>>>>
>>>>>>Samplitude: float file -> 32 bit processing (no loss) - >
>>>>>>volume setting -12 dB-> back to 32 bit file (no loss) - >
>>>>>>result is 32 bit float resolution, no bit loss, no
>>>>>>additional dither noise etc..."
>>>>>>

GooberNumber9 wrote on 1/30/2000, 3:08 AM

Ok... I know I'm not a devloper for SF at all, but MY Vegas Pro
actually saves all my 24-bit waves as 32-bit files. I also noted that
the Windows 98 properties page for the files doesn't report a bit-
depth at all, but I was able to confirm the 32-bit format by doing
some division based on the file size and the sample rate.
So, in answer to Vern's question "There would be a benefit to having
a 32-bit file to process, right?" it seems in my case at least that's
exactly what I'm getting, even though my project property is at 24-
bit.
Frankly, if there's no benefit to Vegas saving everything in 32-bit
format, I'd really wish it DIDN'T. Personally, I have some pretty
severe hard drive space issues, and I'm only working on six songs
with maybe 16 mono tracks each.

TOdd

Peter Haller wrote:
>>So what you want to do is render your final mix to a floating point
>>file so that you can load this into a 2 track editor and then do
you
>>final mastering.
>>
>>Ok, I can see doing this. There wasn't any plan to support this,
but
>>it would be easy enough.
>>
>>I question the benifits.
>>
>>Some benifit? Maybe.
>>
>>Buy hey, I like simple features.
>>
>>I am going to run some tests internally and see what the actual
>>difference is. I mean, I want to 1) hear the difference and 2) See
>>the difference on my scope. Also want to talk to our DSP gurus here
>>at the Foundry. I am getting the feeling this is like the reported
>>dynamic range of sound cards vs what they really can do.
>>
>>Will let you know what I find out.
>>
>>Peter
>>
>>
>>Vern Cooper wrote:
>>>>I see your point. Still, if you plan to master a mixed down
>>>>file,there would be a definite benefit to having a 32-bit file to
>>>>process, right? Is this something that could possibly be built
into
>>a
>>>>future version of Vegas? Or can I do this now by changing the bit
>>>>depth of my project to 32 bits and saving the wave as a 32bit
file?
>>>>
>>>>Peter Haller wrote:
>>>>>>I can't see the benifit.
>>>>>>
>>>>>>When Vegas records audio, it is recording and saving what the
>>>>>>hardware gives it. We do no processing on the audio as it is
>>>>>>recorded. So we save at what ever the bit depth and sample
rate -
>>>>in
>>>>>>fixed point - that the hardware gives us.
>>>>>>
>>>>>>When we read the audio back into Vegas, we convert to floating
>>>>point.
>>>>>>All processing is done in floating point until the audio is
>>>>rendered
>>>>>>to either audio hardware or to a file. We do a simple dither
>>based
>>>>on
>>>>>>the type of conversion being done before converting to the
final
>>>>>>output.
>>>>>>
>>>>>>Additionally, you can place our dither plugin - or some other
>>>>>>dithering plugin - on the main buses. (Doesn't make much sense
to
>>>>do
>>>>>>this at the track or send level.) This will dither the floating
>>>>point
>>>>>>stream such that when converted to fixed point at a specific
bit
>>>>>>depth, the best possible conversion will occur. (There are
other
>>>>>>techniques to improve the floating point stream before the
>>>>conversion
>>>>>>as well. )
>>>>>>
>>>>>>Samplitude has to do the same thing somewhere at somepoint. I
>>know
>>>>>>that Samplitude permits the recording into floating point. This
>>is
>>>>>>all fine and dandy. The original material is still fixed point
>>and
>>>>>>converted to floating point before it is saved. There can be no
>>>>gain
>>>>>>or loss by converting before saving or after reading if the
>>>>original
>>>>>>material is fixed point. There is no loss of data in either
case.
>>>>>>When you do the conversion makes no difference. We do it when
we
>>>>>>read. Samplitude permits you to do it when recording.
>>>>>>
>>>>>>Perhaps Samplitude permits processing of recorded material
during
>>>>>>recording(?) If so, then yes, they are changing the content and
>>>>>>possibly adding content that was not there in the original
fixed
>>>>>>point original. Saving to floating point would assure that
>>nothing
>>>>is
>>>>>>lost. Vegas does not do any processing while recording, so
saving
>>>>to
>>>>>>floating point doesn't gain anything.
>>>>>>
>>>>>>Rendering to files:
>>>>>>As of today, there is little point in delivering media in
>>floating
>>>>>>point format. I don't know of a CODEC for Win9x or NT that will
>>>>>>convert FP streams to the fixed point formats of audio
hardware.
>>In
>>>>>>Win98 and Win2000, the WDM driver model and what is known as
the
>>>>>>KMixer supposedly support (or will support) streaming in
floating
>>>>>>point. This would permit the application to stream raw floating
>>>>point
>>>>>>data to the output devices. The conversion is done by the
kmixer,
>>>>vs
>>>>>>the application. I can't comment on the quality of the
conversion
>>>>>>that takes place in the kmixer. Personally I would rather have
>>>>>>control over the conversion vs letting some black box in the OS
>>>>>>handle it.
>>>>>>
>>>>>>I know of no hardware that actually produces or accepts
floating
>>>>>>point. Even if it did, floating point A/D and D/A converters
are
>>>>>>_very_ expensive, impractical, and, as far as I have read,
>>>>unreliable
>>>>>>and experimental. The realworld is still fixed point - today. I
>>>>would
>>>>>>be intersted if anybody knows of a FP D/A or A/D converts that
>>are
>>>>on
>>>>>>the market.
>>>>>>
>>>>>>Vegas does not do any behind the scenes mixing or 'pre-
>>rendering',
>>>>so
>>>>>>there would be no benifit to storing files back out to floating
>>>>>>point. (The conversion from fixed point to floating point is
>>>>nominal
>>>>>>as far as CPU usage goes.) Does Samplitude do anything like
this?
>>>>If
>>>>>>if does, then pre-rendering to floating point would assure no
>>data
>>>>>>loss.
>>>>>>
>>>>>>The only place I could think that rendering to floating point
>>could
>>>>>>be used in Vegas would be in mix to new track. This would
produce
>>>>and
>>>>>>maintain all processing done during the mix to new stages. With
>>>>lots
>>>>>>of processing and such this could possible be a benifit. Still,
>>you
>>>>>>would have to do a lot of mix to new track processing to reap
the
>>>>>>benifit.
>>>>>>
>>>>>>So, except for the case of mix to new, there is no benifit.
>>>>>>
>>>>>>Peter
>>>>>>
>>>>>>
>>>>>>Vern Cooper wrote:
>>>>>>>>I read the following in the Samplitude newsgroup regarding
>>>>>>>>the reason they use 32bit files instead of 24 bit. Does the
>>>>>>>>same hold true for Vegas? Would we be signifigantly better
>>>>>>>>off using 32 bit float files instead of 24 bit?
>>>>>>>>
>>>>>>>>"Any conversation between 24 int and float produces small
>>>>>>>>data loss, even when dithering is used. Thats why we use
>>>>>>>>float also in the files. This way absolutely NO data loss
>>>>>>>>occurs and we have headroom above 0 dB!
>>>>>>>>
>>>>>>>>Cubase, Sadie etc.: 24 bit file -> 32 bit float processing
>>>>>>>>(small loss) -> volume setting -12 dB -> back to 24 bits -
>>>>>>>>result is 22 bits audio and 2 times of conversation loss.
>>>>>>>>
>>>>>>>>Samplitude: float file -> 32 bit processing (no loss) - >
>>>>>>>>volume setting -12 dB-> back to 32 bit file (no loss) - >
>>>>>>>>result is 32 bit float resolution, no bit loss, no
>>>>>>>>additional dither noise etc..."
>>>>>>>>

pwppch wrote on 1/30/2000, 1:33 PM

This is dependent on the hardware. Some hardware only support 24 bit
npacked or 32 bit. We record what the hardware provides us. We
default to opening recording ports as follows:

24 bit unpacked (24 bits in a 32 bit carrier with the lower 8 bits
zero)
32 bit PCM - Many 24 bit drivers/hardware support 24 bit this way
24 bit packed - Some hardware does not support this format. Some
hardware is very inefficient when streaming in this format.

A future rev will always save to 24 bit packed when this is the
current bit depth.

Peter

Todd Wilcox wrote:
>>Ok... I know I'm not a devloper for SF at all, but MY Vegas Pro
>>actually saves all my 24-bit waves as 32-bit files. I also noted
that
>>the Windows 98 properties page for the files doesn't report a bit-
>>depth at all, but I was able to confirm the 32-bit format by doing
>>some division based on the file size and the sample rate.
>>So, in answer to Vern's question "There would be a benefit to
having
>>a 32-bit file to process, right?" it seems in my case at least
that's
>>exactly what I'm getting, even though my project property is at 24-
>>bit.
>>Frankly, if there's no benefit to Vegas saving everything in 32-bit
>>format, I'd really wish it DIDN'T. Personally, I have some pretty
>>severe hard drive space issues, and I'm only working on six songs
>>with maybe 16 mono tracks each.
>>
>>TOdd
>>
>>Peter Haller wrote:
>>>>So what you want to do is render your final mix to a floating
point
>>>>file so that you can load this into a 2 track editor and then do
>>you
>>>>final mastering.
>>>>
>>>>Ok, I can see doing this. There wasn't any plan to support this,
>>but
>>>>it would be easy enough.
>>>>
>>>>I question the benifits.
>>>>
>>>>Some benifit? Maybe.
>>>>
>>>>Buy hey, I like simple features.
>>>>
>>>>I am going to run some tests internally and see what the actual
>>>>difference is. I mean, I want to 1) hear the difference and 2)
See
>>>>the difference on my scope. Also want to talk to our DSP gurus
here
>>>>at the Foundry. I am getting the feeling this is like the
reported
>>>>dynamic range of sound cards vs what they really can do.
>>>>
>>>>Will let you know what I find out.
>>>>
>>>>Peter
>>>>
>>>>
>>>>Vern Cooper wrote:
>>>>>>I see your point. Still, if you plan to master a mixed down
>>>>>>file,there would be a definite benefit to having a 32-bit file
to
>>>>>>process, right? Is this something that could possibly be built
>>into
>>>>a
>>>>>>future version of Vegas? Or can I do this now by changing the
bit
>>>>>>depth of my project to 32 bits and saving the wave as a 32bit
>>file?
>>>>>>
>>>>>>Peter Haller wrote:
>>>>>>>>I can't see the benifit.
>>>>>>>>
>>>>>>>>When Vegas records audio, it is recording and saving what the
>>>>>>>>hardware gives it. We do no processing on the audio as it is
>>>>>>>>recorded. So we save at what ever the bit depth and sample
>>rate -
>>>>>>in
>>>>>>>>fixed point - that the hardware gives us.
>>>>>>>>
>>>>>>>>When we read the audio back into Vegas, we convert to
floating
>>>>>>point.
>>>>>>>>All processing is done in floating point until the audio is
>>>>>>rendered
>>>>>>>>to either audio hardware or to a file. We do a simple dither
>>>>based
>>>>>>on
>>>>>>>>the type of conversion being done before converting to the
>>final
>>>>>>>>output.
>>>>>>>>
>>>>>>>>Additionally, you can place our dither plugin - or some other
>>>>>>>>dithering plugin - on the main buses. (Doesn't make much
sense
>>to
>>>>>>do
>>>>>>>>this at the track or send level.) This will dither the
floating
>>>>>>point
>>>>>>>>stream such that when converted to fixed point at a specific
>>bit
>>>>>>>>depth, the best possible conversion will occur. (There are
>>other
>>>>>>>>techniques to improve the floating point stream before the
>>>>>>conversion
>>>>>>>>as well. )
>>>>>>>>
>>>>>>>>Samplitude has to do the same thing somewhere at somepoint. I
>>>>know
>>>>>>>>that Samplitude permits the recording into floating point.
This
>>>>is
>>>>>>>>all fine and dandy. The original material is still fixed
point
>>>>and
>>>>>>>>converted to floating point before it is saved. There can be
no
>>>>>>gain
>>>>>>>>or loss by converting before saving or after reading if the
>>>>>>original
>>>>>>>>material is fixed point. There is no loss of data in either
>>case.
>>>>>>>>When you do the conversion makes no difference. We do it when
>>we
>>>>>>>>read. Samplitude permits you to do it when recording.
>>>>>>>>
>>>>>>>>Perhaps Samplitude permits processing of recorded material
>>during
>>>>>>>>recording(?) If so, then yes, they are changing the content
and
>>>>>>>>possibly adding content that was not there in the original
>>fixed
>>>>>>>>point original. Saving to floating point would assure that
>>>>nothing
>>>>>>is
>>>>>>>>lost. Vegas does not do any processing while recording, so
>>saving
>>>>>>to
>>>>>>>>floating point doesn't gain anything.
>>>>>>>>
>>>>>>>>Rendering to files:
>>>>>>>>As of today, there is little point in delivering media in
>>>>floating
>>>>>>>>point format. I don't know of a CODEC for Win9x or NT that
will
>>>>>>>>convert FP streams to the fixed point formats of audio
>>hardware.
>>>>In
>>>>>>>>Win98 and Win2000, the WDM driver model and what is known as
>>the
>>>>>>>>KMixer supposedly support (or will support) streaming in
>>floating
>>>>>>>>point. This would permit the application to stream raw
floating
>>>>>>point
>>>>>>>>data to the output devices. The conversion is done by the
>>kmixer,
>>>>>>vs
>>>>>>>>the application. I can't comment on the quality of the
>>conversion
>>>>>>>>that takes place in the kmixer. Personally I would rather
have
>>>>>>>>control over the conversion vs letting some black box in the
OS
>>>>>>>>handle it.
>>>>>>>>
>>>>>>>>I know of no hardware that actually produces or accepts
>>floating
>>>>>>>>point. Even if it did, floating point A/D and D/A converters
>>are
>>>>>>>>_very_ expensive, impractical, and, as far as I have read,
>>>>>>unreliable
>>>>>>>>and experimental. The realworld is still fixed point - today.
I
>>>>>>would
>>>>>>>>be intersted if anybody knows of a FP D/A or A/D converts
that
>>>>are
>>>>>>on
>>>>>>>>the market.
>>>>>>>>
>>>>>>>>Vegas does not do any behind the scenes mixing or 'pre-
>>>>rendering',
>>>>>>so
>>>>>>>>there would be no benifit to storing files back out to
floating
>>>>>>>>point. (The conversion from fixed point to floating point is
>>>>>>nominal
>>>>>>>>as far as CPU usage goes.) Does Samplitude do anything like
>>this?
>>>>>>If
>>>>>>>>if does, then pre-rendering to floating point would assure no
>>>>data
>>>>>>>>loss.
>>>>>>>>
>>>>>>>>The only place I could think that rendering to floating point
>>>>could
>>>>>>>>be used in Vegas would be in mix to new track. This would
>>produce
>>>>>>and
>>>>>>>>maintain all processing done during the mix to new stages.
With
>>>>>>lots
>>>>>>>>of processing and such this could possible be a benifit.
Still,
>>>>you
>>>>>>>>would have to do a lot of mix to new track processing to reap
>>the
>>>>>>>>benifit.
>>>>>>>>
>>>>>>>>So, except for the case of mix to new, there is no benifit.
>>>>>>>>
>>>>>>>>Peter
>>>>>>>>
>>>>>>>>
>>>>>>>>Vern Cooper wrote:
>>>>>>>>>>I read the following in the Samplitude newsgroup regarding
>>>>>>>>>>the reason they use 32bit files instead of 24 bit. Does the
>>>>>>>>>>same hold true for Vegas? Would we be signifigantly better
>>>>>>>>>>off using 32 bit float files instead of 24 bit?
>>>>>>>>>>
>>>>>>>>>>"Any conversation between 24 int and float produces small
>>>>>>>>>>data loss, even when dithering is used. Thats why we use
>>>>>>>>>>float also in the files. This way absolutel