It seems that the lowest value the STS-samplers can sample is at -173dB, in 32-bit mode. This is about 6dB less than what VDAT records (about -180dB).
Editing a 32-bit file in STS recorded with VDAT still preserves the 180dB range though.
So I guess you could just as well sample in VDAT.
STS sampling observation/bug
-
lagoausente
- Posts: 552
- Joined: Wed Feb 09, 2005 4:00 pm
- Location: Spain
-
lagoausente
- Posts: 552
- Joined: Wed Feb 09, 2005 4:00 pm
- Location: Spain
You can't use 32-bit floating point files in STS nor VDAT.
Anyway, 32-bit floating point can represent a 32-bit Iinear/integer value perfectly as 32-bit float has virtually unlimited headroom. For this reason it can make sense to record 32-bit float in i.e. Cubase via the ASIO FLT drivers (*).
The "problem" with 32-bit floating point is when summing/representing two or more signals. Values below -155dB of the strongest value at the current sample will distort - distortion which can become audiable via further processing.
In contrast 32-bit linear sports a 192dB headroom.
Thus mixing natively in SFP is prefered if choice is between these two.
* I have discovered differences in the performance of ASIO1- and ASIO2-drivers.
The ASIO1-drivers seem to perform better in the sense that all the headroom is preserved. A signal at -180dB will pass from SFP via ASIO and back with the use of ASIO1-32- or FLT-drivers (choose which is best for the given software; i.e. Tracktion2 and Cubase wants to see float, REAPER wants to see int).
ASIO2-drivers will strangely not.
So it seems to be possible with a 1:1 signal pipe-line with the use of these less advanced ASIO-drivers, just like one would achieve via VDAT.
This is fairly low in the noise-floor, but I feel this is all about being confident in that our precious audio is preserved. There is a reason afteralll for why many of us prefere/have prefered VDAT over many current ASIO-capable hosts for handling audio.
Anyway, 32-bit floating point can represent a 32-bit Iinear/integer value perfectly as 32-bit float has virtually unlimited headroom. For this reason it can make sense to record 32-bit float in i.e. Cubase via the ASIO FLT drivers (*).
The "problem" with 32-bit floating point is when summing/representing two or more signals. Values below -155dB of the strongest value at the current sample will distort - distortion which can become audiable via further processing.
In contrast 32-bit linear sports a 192dB headroom.
Thus mixing natively in SFP is prefered if choice is between these two.
* I have discovered differences in the performance of ASIO1- and ASIO2-drivers.
The ASIO1-drivers seem to perform better in the sense that all the headroom is preserved. A signal at -180dB will pass from SFP via ASIO and back with the use of ASIO1-32- or FLT-drivers (choose which is best for the given software; i.e. Tracktion2 and Cubase wants to see float, REAPER wants to see int).
ASIO2-drivers will strangely not.
So it seems to be possible with a 1:1 signal pipe-line with the use of these less advanced ASIO-drivers, just like one would achieve via VDAT.
This is fairly low in the noise-floor, but I feel this is all about being confident in that our precious audio is preserved. There is a reason afteralll for why many of us prefere/have prefered VDAT over many current ASIO-capable hosts for handling audio.
i know there is a difference, but it has more sense when we are working on a finished song where the dynamic range must be at the maximum level.lagoausente wrote:Man, take an editor, and create a waveform at -170 db. Adjust the gain of you monitors to normal level, and tell me if you can hear something.
What is the dynamic range used in a single mixer channel during the mixdown ?
I have managed that 24 bits is enough for solo recordings and there is no difference when you use a 32 bits or 24 bits file inside the mix.
um, standard IEEE floating point numbers have a 24 bit mantissa and 8 bit exponent, which means they can represent a 24-bit integer perfectly, not a 32-bit one. you need a 40-bit floating point number to preseve all the resolution of a 32-bit integer.voidar wrote: Anyway, 32-bit floating point can represent a 32-bit Iinear/integer value perfectly as 32-bit float has virtually unlimited headroom. For this reason it can make sense to record 32-bit float in i.e. Cubase via the ASIO FLT drivers (*).
You are right in that float is structure differently. In fact, according to wikipedia (http://en.wikipedia.org/wiki/IEEE_Float ... t_Standard) the IEEE single precision floating point standard orders the 32-bits as:
1-bit sign
8-bit exponent
23-bit mantissa
According to your logic 32-bit float could not even represent 24-bit integer perfectly.
To understand 32-bit floating point you will need to think sample by sample, and floating point represents values by scaling its mantissa. The total amout of discreet values that a 32-bit floating point number can represent is:
(2^23) * (2^1) * (2^8 ) = 4294967296 discreet values.
The total amount of discreet values a 32-bit integer value can represent is:
2^32 = 4294967296 discreet values.
That's the same number right?
Then why are some of us shouting out why 32-bit int is so much better than 32-bit float? For storing data it is of equal value, but when processing, like when summing two signals together, 32-bit integer outperforms float in headroom because we are trying to represent two discreet 32-bit values in one 23+1-bit mantissa!
For 32-bit float this translates to about 155dB headroom between strongest and weakest value, and all signals are ranked in relevance to the strongest value.
With 32-bit integer we have a constant headroom of 192dB and all values must fit within this frame. Signals will clip or disappear unless you stay within the limits. Unlike float where it is very easy not to clip signals, just the weak signals start to distort, and what is weak is not constant.
Anyway, as I said, recording signals produced within the SFP-environment as 32-bit float in your ASIO-host should yield identical resolution as recording the same signals via VDAT at 32-bit integer.
In fact, it should be fine to record your mixdown from the a STM-mixer as 32-bit float too. They won't put out anything else but values between 0 and 4294967296.
You can test this your self.
Say you pass the lowest signal you can produce in SFP (I get to -180.6dB) through an ASIO1-FLT driver into Cubase. Whether you monitor or record@32-bit float you should see that exact same signal comming from your ASIO1 driver.
Interestingly I don't get these results with ASIO2-drivers, so unless you need sync and/or Direct Monitoring you should go with the ASIO1-drivers.
Also, ASIO-hosts want different formats.
Cubase/Nuendo and Tracktion 2 likes to see ASIO1-FLT as the integer/float-conversion is handled by the drivers themselves.
REAPER i.e. likes to see ASIO1-32 and won't even recognize FLT-drivers. REAPER will handle the integer/float-conversion.
1-bit sign
8-bit exponent
23-bit mantissa
According to your logic 32-bit float could not even represent 24-bit integer perfectly.
To understand 32-bit floating point you will need to think sample by sample, and floating point represents values by scaling its mantissa. The total amout of discreet values that a 32-bit floating point number can represent is:
(2^23) * (2^1) * (2^8 ) = 4294967296 discreet values.
The total amount of discreet values a 32-bit integer value can represent is:
2^32 = 4294967296 discreet values.
That's the same number right?
Then why are some of us shouting out why 32-bit int is so much better than 32-bit float? For storing data it is of equal value, but when processing, like when summing two signals together, 32-bit integer outperforms float in headroom because we are trying to represent two discreet 32-bit values in one 23+1-bit mantissa!
For 32-bit float this translates to about 155dB headroom between strongest and weakest value, and all signals are ranked in relevance to the strongest value.
With 32-bit integer we have a constant headroom of 192dB and all values must fit within this frame. Signals will clip or disappear unless you stay within the limits. Unlike float where it is very easy not to clip signals, just the weak signals start to distort, and what is weak is not constant.
Anyway, as I said, recording signals produced within the SFP-environment as 32-bit float in your ASIO-host should yield identical resolution as recording the same signals via VDAT at 32-bit integer.
In fact, it should be fine to record your mixdown from the a STM-mixer as 32-bit float too. They won't put out anything else but values between 0 and 4294967296.
You can test this your self.
Say you pass the lowest signal you can produce in SFP (I get to -180.6dB) through an ASIO1-FLT driver into Cubase. Whether you monitor or record@32-bit float you should see that exact same signal comming from your ASIO1 driver.
Interestingly I don't get these results with ASIO2-drivers, so unless you need sync and/or Direct Monitoring you should go with the ASIO1-drivers.
Also, ASIO-hosts want different formats.
Cubase/Nuendo and Tracktion 2 likes to see ASIO1-FLT as the integer/float-conversion is handled by the drivers themselves.
REAPER i.e. likes to see ASIO1-32 and won't even recognize FLT-drivers. REAPER will handle the integer/float-conversion.
yes, you have to think sample by sample...voidar wrote:...To understand 32-bit floating point you will need to think sample by sample, and floating point represents values by scaling its mantissa. ...
then at some point you will notice that signal reconstruction is done by a transfer function and not by shooting up individual voltages along a timeline
with all respect to your thorough examination - you're bashing the wrong guy - precision is not where you look for it.
The loss (if any) is in the math itself, in the various possibilities to implement one or the other mode of processing - there are countless inner loops in such programs...
The only way to tell the effectivedifference is to actually hear it (imho)
cheers, Tom
Of course, we should use our ears, but I want to be confident in the technology I use. I don't want to lose information unless I want to.
And when float works it's a hell of a lot easier to use tools outside of SFP
.
I am not sure I understand what you mean by this though:
And when float works it's a hell of a lot easier to use tools outside of SFP
.I am not sure I understand what you mean by this though:
[...] signal reconstruction is done by a transfer function and not by shooting up individual voltages along a timeline.
well, your focus on the absolute numeric value of the sample suggests that you assume this value is what's fed to the final converter stage on playback...
My math in this domain is more than humble but afaik the 'value' of the sample serves as a parameter for the reconstruction function.
My (intuitive - I may be wrong here) guess is the 'spatial' tolerance is much larger than the deviations you observed.
Why bother about fixed or float when you don't even have the slightest idea about the math model the next function (say a VST effect) used ?
I don't mean the numeric system but the library/individual implementation and such stuff. There are dozens of ways to program functionally identical routines.
cheers, Tom
My math in this domain is more than humble but afaik the 'value' of the sample serves as a parameter for the reconstruction function.
My (intuitive - I may be wrong here) guess is the 'spatial' tolerance is much larger than the deviations you observed.
Why bother about fixed or float when you don't even have the slightest idea about the math model the next function (say a VST effect) used ?
I don't mean the numeric system but the library/individual implementation and such stuff. There are dozens of ways to program functionally identical routines.
cheers, Tom
At best we will be looking at converters that can output 120dB maximum, and 96dB if you're mixing for CD, so in this regard 192dB is overkill. Internally however I believe every bit of fidelity counts in regards to the final output, especially after processing and summings some 20+ tracks. The small affect the the big.
I am not claiming I hear a difference, but I believe in signal-integrity. Call it religious if you will.
And I don't use VST's for signal processing usually, not for stuff that's going to end up being summed. I try to restrict myself to the Sharc-domain.
I am not claiming I hear a difference, but I believe in signal-integrity. Call it religious if you will.
And I don't use VST's for signal processing usually, not for stuff that's going to end up being summed. I try to restrict myself to the Sharc-domain.
which means in 32-bit int we are dealing with a 31-bit mantissa and 1-bit sign ??
sorry i dont get it!
for me:
with 32 bit int you have
1 to 2147483647 in dezimal which is +
and 2147483648 to 4294967296 in dezimal represent to 0 to -2147483648
there is no - or + in wave format you only have + 1 to 4294967296 dezimal
(256*256*256*256)
record 32bit int and convert the hex to dez you will see . .
but maybe i have a translation or knowledge probl. !!!!!!!!
and you are talking of completely diffrent things
so sorry again and good vibes from vienna
sorry i dont get it!
for me:
with 32 bit int you have
1 to 2147483647 in dezimal which is +
and 2147483648 to 4294967296 in dezimal represent to 0 to -2147483648
there is no - or + in wave format you only have + 1 to 4294967296 dezimal
(256*256*256*256)
record 32bit int and convert the hex to dez you will see . .
but maybe i have a translation or knowledge probl. !!!!!!!!
and you are talking of completely diffrent things
so sorry again and good vibes from vienna
-
Mr Arkadin
- Posts: 3283
- Joined: Thu May 24, 2001 4:00 pm
. My brain hurts.A 32-bit integer word can be both signed or unsigned. You still have 2^32 different bit states.
I might be mistaken some with my views on 32-bit floating point. It's a conversion thing. Use Creamware conversion.
Read http://www.cockos.com/forum/showthread.php?t=3153
I might be mistaken some with my views on 32-bit floating point. It's a conversion thing. Use Creamware conversion.
Read http://www.cockos.com/forum/showthread.php?t=3153