 |
|  Integer bit depth rendering [HELP] | |
|
 |
Atlantis
  Member
Topics: 84
Replies: 3227
Registered: 14.Jan.03 |
 |
Has anyone else notice that when exporting audio from Reason (I'm using 24 bit, but I assume it happens with 16 bit as well), there's a -121.6 dB noisefloor, regardless of the volume of the sound. So even if I export the signal at a quiet volume, there's still this DC offset-like noise that gets rendered as well when there's no sound playing. I thought turning the volume of the sound up as high as it could go without causing clipping might mean a better signal to noise ratio, but still the noise remains at -121.6 dB.
Actually I've noticed the same in Renoise's output when rendering with an integer bit depth, and the same goes for Sk@le Tracker. But it's only when I use floating point precision in Renoise (the only software I've come across with floating point rendering so far) that it completely disappears. So I guess it must be something to do with the limitations of rendering with integer bit precision? Does anyone know why this happens? Or better yet, how to avoid it? 
Atlantis Atlantean Records .: extant music beyond existence
Multi-band professor .: PM me for all your mastering needs or tips. 
Bloody kids these days.  |
|
FeralCode
Member
Topics: 125
Replies: 1202
Registered: 19.Mar.03 |
I guess these should be asked in Reason / Renoise support forums. When I export anything from Reason, there might be such case, but I simply do not measure -121.6 db noise... I simply cannot or dont worry.
.jpg) |
|
PPH
Member
Topics: 48
Replies: 843
Registered: 13.Jul.03 |
|
Atlantis wrote on 30 Sep. (12:51) :
Has anyone else notice that when exporting audio from Reason (I'm using 24 bit, but I assume it happens with 16 bit as well), there's a -121.6 dB noisefloor, regardless of the volume of the sound. So even if I export the signal at a quiet volume, there's still this DC offset-like noise that gets rendered as well when there's no sound playing. I thought turning the volume of the sound up as high as it could go without causing clipping might mean a better signal to noise ratio, but still the noise remains at -121.6 dB.
Actually I've noticed the same in Renoise's output when rendering with an integer bit depth, and the same goes for Sk@le Tracker. But it's only when I use floating point precision in Renoise (the only software I've come across with floating point rendering so far) that it completely disappears. So I guess it must be something to do with the limitations of rendering with integer bit precision? Does anyone know why this happens? Or better yet, how to avoid it?
Atlantis Atlantean Records .: extant music beyond existence
Multi-band professor .: PM me for all your mastering needs or tips.
Bloody kids these days. |
What do you mean by "integer but depth"? Isn't bit depth naturally integer? Here's what I think you're talking about: The amplitudes are stored as integers. So, if you have 16 bits, then the values of each sample are between 0 and 65535. With floating point rendering, the values would be between 0 and 1, for example, and would be decimals. Is that what you mean?
Anyway, why does it surprise you that the volume of the sound in decibels is always the same. That just means that the volume of this noise is proportional to the volume of the exported signal, right? I know I may be wrong, so correct me if I'm mistaken, but as dB are a relative scale, then, the fact that the value in decibels of the noise is always the same, that means the signal to noise ration is always the same. I think this noise might have something to do with errors in the calculations. Maybe using floating point arithmetic makes it possible to reduce round off errors.
Er...I know I haven't been helpful, but I'm trying to understand this. It makes me curious 
From Darkness To Light, my newest track.
"I swear by my life and my love of it that I will never live for the sake of another man, nor ask another man to live for mine"
-John Galt, "Atlas Shrugged", by Ayn Rand |
|
PPH
Member
Topics: 48
Replies: 843
Registered: 13.Jul.03 |
Atlantis, I just copied your post and posted it to the music-dsp mailing list, to which I am subscribed. I think some of those dsp gurus may know the answer.
From Darkness To Light, my newest track.
"I swear by my life and my love of it that I will never live for the sake of another man, nor ask another man to live for mine"
-John Galt, "Atlas Shrugged", by Ayn Rand |
|
Atlantis
Member
Topics: 84
Replies: 3227
Registered: 14.Jan.03 |
|
PPH, your post has actually been helpful.  Well, the fact that you posted it to that music-dsp mailling list anyway.  jk
But what you say is correct. That's what floating point bit depth is and from what I've read, it means that samples can be stored more accurately at quiet and loud volumes. With integers, the possible values of each sample ranges from 0 to 65535, but using floating point somehow means that you can store low values more accurately. I'm not exactly sure how that works, and to be honest I don't really care, as I'm only really interested in how the final result sounds.
But when you say the noise might have something to do with errors in the calculations, I think that probably explains it. It's probably just because when there's no sound playing there should be a near-zero sample value, in which case it is rounded to the closest possible value of -121.6 dB. Don't know why they can't just make it 0 or -inf dB, though.
Well, in this case the volume of the noise isn't proportional to the signal, because raising the volume of the signal still keeps the noise level the same, unlike when working in an analogue environment where the noise would increase too. Maybe you see this the other way though, which is why you say it is in fact proportional. But anyway, I'm curious to see what results you get from posting this on that mailing list, so let me know.
Atlantis Atlantean Records .: extant music beyond existence
Multi-band professor .: PM me for all your mastering needs or tips.
Bloody kids these days. |
|
PPH
Member
Topics: 48
Replies: 843
Registered: 13.Jul.03 |
|
Atlantis wrote on 30 Sep. (14:41) :
PPH, your post has actually been helpful. Well, the fact that you posted it to that music-dsp mailling list anyway. jk
But what you say is correct. That's what floating point bit depth is and from what I've read, it means that samples can be stored more accurately at quiet and loud volumes. With integers, the possible values of each sample ranges from 0 to 65535, but using floating point somehow means that you can store low values more accurately. I'm not exactly sure how that works, and to be honest I don't really care, as I'm only really interested in how the final result sounds.
But when you say the noise might have something to do with errors in the calculations, I think that probably explains it. It's probably just because when there's no sound playing there should be a near-zero sample value, in which case it is rounded to the closest possible value of -121.6 dB. Don't know why they can't just make it 0 or -inf dB, though.
Well, in this case the volume of the noise isn't proportional to the signal, because raising the volume of the signal still keeps the noise level the same, unlike when working in an analogue environment where the noise would increase too. Maybe you see this the other way though, which is why you say it is in fact proportional. But anyway, I'm curious to see what results you get from posting this on that mailing list, so let me know.
Atlantis Atlantean Records .: extant music beyond existence
Multi-band professor .: PM me for all your mastering needs or tips.
Bloody kids these days. |
Well, I already got an answer. They told me NEVER to render a track with "integer precision", unless I was force to do it, for example, to burn a CD. So, now I'm beginning to understand it. The following are conjectures, but I think they are reasonable, and, in any case, you will be capable of spotting errors in my reasoning.
Here's how I think it works:
A digital signal of 16 bits is an array of integer numbers. If you convert those integer to floating point numbers, you won't get more precision. Moreover, if you convert them and then normalize them (i.e., you divide all numbers by the peak amplitude so that you obtain values between 0 and 1) you'll introduce errors.
However, let's suppose that you start working with this signal, and apply several effects to it. In this case, the best thing to do is to work with floating point numbers. Let's suppose you apply five consecutive effects. If you work with integers, you'll round off all numbers that fall between two integers. If you work with floating point numbers, the rounding off will be much less severe. If you work with integers, in the end, you'll still have a 16-bit wave. If you work with floating point, in the end you'll have an array of floating point numbers, which won't be a 16-bit wave, because you'll have much more than 65536 values (2^16 = 65536, just in case someone wonders how I came up with that number).
In the end, if you have to burn the thing to a CD, you'll lose precision, because you'll be restricting the values to those 65536 16-bit accepts. However, if you work with floating point and do the conversion in the end, the accumulated error will be much less than if you render all tracks separately with integer precision, mix them and then render the mix again. The better thing to do is to render them with floating point precision (I didnt' know that was possible with wave files, by the way; I thought wave files recorded integers, period), mix them that way, and only convert to integer precision in the end. That's, of course, quite obvious, but now were coming near the point, which is the following. As you probably know, round off errors can be viewed as noise. It's quite reasonable to think that the noise you hear when rendering with integer precision is noise that corresponds to round-off errors. It's not that they can't represent the zero and so they round small values to the lowest possible floating point number. It's that there is a certain amount of round-off errors that can be heard as random noise. In this case, I think it's quite natural for the noise to be proportional to the volume, although that's just a guess.
From Darkness To Light, my newest track.
"I swear by my life and my love of it that I will never live for the sake of another man, nor ask another man to live for mine"
-John Galt, "Atlas Shrugged", by Ayn Rand |
|
PPH
Member
Topics: 48
Replies: 843
Registered: 13.Jul.03 |
The bottom line is: if you use Reason or other program that doesn't support floating point rendering, you'd better do the whole post production within Reason.
From Darkness To Light, my newest track.
"I swear by my life and my love of it that I will never live for the sake of another man, nor ask another man to live for mine"
-John Galt, "Atlas Shrugged", by Ayn Rand |
|
Atlantis
Member
Topics: 84
Replies: 3227
Registered: 14.Jan.03 |
Great post, although just one thing I didn't quite get (PPH, maybe you can ask this person again?):
|
Moreover, if you convert them and then normalize them (i.e., you divide all numbers by the peak amplitude so that you obtain values between 0 and 1) you'll introduce errors. |
Does that mean that if I render my tracks in 24 bit in Reason (it doesn't have floating point precision, so I take it that'd be a case of being forced to), then convert the bitrate to 32 bit floating point in Sound Forge, do all my processing, and dither down to 16 bit at the end again and normalise the wave, does that mean I've introduced errors I could have avoided if I hadn't changed the bitrate to 32 bit floating point first?
Atlantis Atlantean Records .: extant music beyond existence
Multi-band professor .: PM me for all your mastering needs or tips.
Bloody kids these days. |
|
Atlantis
Member
Topics: 84
Replies: 3227
Registered: 14.Jan.03 |
PPH wrote on 30 Sep. (16:32) :
The bottom line is: if you use Reason or other program that doesn't support floating point rendering, you'd better do the whole post production within Reason.
|
That's true, but I don't believe computers are capable yet of doing both the tracking and sequencing calculations as well as effect and mastering calculations. There's just no way on Earth that you could do that all in the one application.
Atlantis Atlantean Records .: extant music beyond existence
Multi-band professor .: PM me for all your mastering needs or tips.
Bloody kids these days. |
|
DDspeed
 Artist
Topics: 24
Replies: 4892
Registered: 07.Jun.03 |
|
if by floating point rendering you mean 32-bit float, than it doesn't work the way described... It does not save the information between 0 and 1.
32-bit is 24-bit + 8-bit for floating point data. In other words it's same as 24-bit, but also saves an 8-bit floating point value. Thanks to this you gain virtually infinite dynamic precision.
BTW, an exact description on how 32-bit float works is in Renoise forum, posted by Martinal . I'll try finding that for you.
EDIT:
Found! And guess what, Atlantis... It was a reply to your topic on Renoise forums .
A quote of Martinal.
Not exactly. Short version: 24bit integer waves have the same accuracy as
32bit floating point waves, but floating point values have other nice
properties when processing audio (easier to work with, no clipping, ...).
Long version:
8/16/24 bit waves use integers, ie whole numbers. For example the values
0,1,2,3...255 for 8bit numbers. The 0's and 1's of an integer each add a power of 2 to the number, 4 bit examples:
0001 = 2^0 = 1
0010 = 2^1 = 2
1011 = 2^3 + 2^1 + 2^0 = 8+2+1 = 11
Floating point values are represented in a completely different way.
Roughly, a bit inaccurately, speaking they're represented like this:
a * 2^b
32 bit IEEE (the name of the most widely used standard) floats use 8 bits for
b and 24 bits for a. The accuracy is given by the size of a, and the max/min is
most affected by the size of b.
So 32bit waves which use only the range +/- 1.0 have the same accuracy as
24bit waves, _but_ they can hold larger values than 1.0 and thus reduce or
remove the clipping problem integers give us.
The floating point representation is similar to a common scientific notation:
a * 10^b, often written as "a e b". Examples:
1.23e+6 = 1230000
1.23e+1 = 12.3
1.23e-3 = 0.00123
So you see the number a "floats" up and down the number scale
depending on the order of magnitude given by b. This way it is possible
to represent both very large and very small numbers with a very limited
number of digits. But large numbers loose accuracy in the smallest digits.
Whereas integers are always 100% accurate, but have a more limited range.
|
|
|
|
|
|
|
Latest Topics
![[203.118.142.61]](pics/ip.gif){kind=small}
