Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER Compatibility

Closed Thread
 
Thread Tools Display Modes
Old 06-24-2014, 11:41 PM   #1
alanofoz
Human being with feelings
 
alanofoz's Avatar
 
Join Date: Sep 2009
Location: Oz - Blue Mountains NSW, formerly Geelong
Posts: 943
Default Problem: When recording to 32 bit, bottom 8 bits are incorrect

Edit: This first post was written in haste and was therefore rather poorly expressed, leading to some confusion further on in the thread. For future reference I'll now try to make it clearer. I'll delete nothing, and make some additions in red, so that the original post may still be seen, warts & all. Hopefully those parts of the thread resulting from my carelessness will continue to make sense.

Having accidentally started a project with "WAV bit depth" of "32 bit FP", I decided to look closely at the files and discovered both ones AND zeroes in the bottom 8 bits of a very low level sample. This sample had a bit depth of 32 bits!!. This shouldn't be happening - the sound interface can only deliver 24 bits. The 8 least significant bits should all be zero for such low level signals. Further investigation revealed that ALL samples in the file had incorrect values in the bottom 8 bits.

I expect this to be my error, but cannot see what I'm doing wrong. It's almost like some dither being added, but how? Could this be some error affecting the data or is it something else entirely? And BTW it's not me misinterpreting little endian data or FP format.

I'm using Win 8 and a Zoom R16 with the ASIO driver indicating 24 bits.
__________________
It's "its" except when it's "it is".

alanofoz, aka Alan of Australia

Last edited by alanofoz; 06-28-2014 at 05:40 AM. Reason: Clarification
alanofoz is offline  
Old 06-25-2014, 12:00 AM   #2
G-Sun
Human being with feelings
 
G-Sun's Avatar
 
Join Date: May 2010
Location: Norway
Posts: 7,318
Default

Quote:
Originally Posted by alanofoz View Post
Having accidentally started a project with "WAV bit depth" of "32 bit FP", I decided to look closely at the files and discovered both ones AND zeroes in the bottom 8 bits. This shouldn't be happening - the sound interface can only deliver 24 bits. The 8 least significant bits should all be zero.

I expect this to be my error, but cannot see what I'm doing wrong. It's almost like some dither being added, but how? Could this be some error affecting the data or is it something else entirely? And BTW it's not me misinterpreting little endian data or FP format.

I'm using Win 8 and a Zoom R16 with the ASIO driver indicating 24 bits.
Well, it could be right or could be wrong,
but does it matter anyway?
__________________
Reaper x64, win 11
Composer, text-writer, producer
Bandcamp
G-Sun is offline  
Old 06-25-2014, 03:31 AM   #3
alanofoz
Human being with feelings
 
alanofoz's Avatar
 
Join Date: Sep 2009
Location: Oz - Blue Mountains NSW, formerly Geelong
Posts: 943
Default

Quote:
Originally Posted by G-Sun View Post
Well, it could be right or could be wrong,
but does it matter anyway?
Yes, it certainly does.

If I'm doing something wrong I need to know.

More to the point, if the bottom 8 bits are wrong, how far up the ladder does the error extend? Can we guarantee that the next bit up is right? Or the next 8 bits? This should just not be happening.

Whether user error or something else, until I resolve the problem I just can't trust the data I'm recording.
__________________
It's "its" except when it's "it is".

alanofoz, aka Alan of Australia
alanofoz is offline  
Old 06-25-2014, 04:08 AM   #4
Arran
Human being with feelings
 
Join Date: Aug 2012
Location: Bolton, UK
Posts: 234
Default

At what point are you looking at the files? If you start a project at 32 bits then it will pass 32 bits to your ASIO driver which will truncate them.
Arran is offline  
Old 06-25-2014, 04:25 AM   #5
schwa
Administrator
 
schwa's Avatar
 
Join Date: Mar 2007
Location: NY
Posts: 15,749
Default

Internal processing in REAPER is always 64 bit float. The output will be rounded by REAPER to 24 bit fixed or whatever the sound interface expects before being delivered to the interface. The bit depth setting in Project Settings/Media only affects how files are written to disk, which is separate from how audio is delivered to the interface.

In other words, you're not doing anything wrong, and there should be no problem with using your current settings.
schwa is offline  
Old 06-25-2014, 04:45 AM   #6
AmmoniumNitrate
Banned
 
Join Date: Jul 2013
Posts: 493
Default

Quote:
Originally Posted by alanofoz View Post
... The 8 least significant bits should all be zero....
Why do you assume that? Are you talking about bits in the significand, or are you talking about bits in the exponent?

I don't see why these should all be 0. If you can show me why, I'll be interested in understanding what's happening.
AmmoniumNitrate is offline  
Old 06-25-2014, 05:13 AM   #7
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 11,183
Default

Quote:
Originally Posted by alanofoz
Having accidentally started a project with "WAV bit depth" of "32 bit FP", I decided to look closely at the files and discovered both ones AND zeroes in the bottom 8 bits
As Schwa and others have said, rest assured that 24 bits will be sent to your I/O and all is well, even though the disk files use 32 bits in FP format.
__________________
To install you need the CSI Software and Support Files
For installation instructions and documentation see the Wiki
Donate -- via PayPal to waddingtongeoff@gmail.com
Geoff Waddington is offline  
Old 06-25-2014, 09:42 AM   #8
DVDdoug
Human being with feelings
 
Join Date: Jul 2010
Location: Silicon Valley, CA
Posts: 2,779
Default

Quote:
, I decided to look closely at the files and discovered both ones AND zeroes in the bottom 8 bits. This shouldn't be happening - the sound interface can only deliver 24 bits.
It's floating point so the "bottom 8 bits" are not what you think. Wikipedia explains how the bits are allocated in 32-bit floating point.

Secondly, the sample values are scaled differently. A 0dB peak in 24 bits has a value around 8 million (I think) whereas a 0dB peak in 32-bit floating point has a value of 1.0.
DVDdoug is online now  
Old 06-25-2014, 01:30 PM   #9
alanofoz
Human being with feelings
 
alanofoz's Avatar
 
Join Date: Sep 2009
Location: Oz - Blue Mountains NSW, formerly Geelong
Posts: 943
Default

Thanks to all who replied.

As stated in the thread title, this is a problem when recording, not processing or playing back. I obviously didn't make this clear enough. Sorry about that.

I also expressed this rather badly, incorrectly in fact (my excuse is that I'm still jetlagged after the long flight back from the UK). I should have said that immediately after recording to a 32 bit file the file's bit depth should be 24. In fact it's 30, 31 or 32 bits in the recordings I've made today.

So, to clarify, all I'm doing is recording a stereo signal. I click Record, then Stop, then Save All (the "Select files to save..." dialogue box), exit Reaper & examine the files using a hex editor.

I am VERY familiar with the IEEE 754 FP standard, and with the little endian byte order in wave files. So mea culpa in talking about the bottom 8 bits as I did.

Fact remains though, the file's bit depth is wrong.
__________________
It's "its" except when it's "it is".

alanofoz, aka Alan of Australia

Last edited by alanofoz; 06-25-2014 at 01:54 PM.
alanofoz is offline  
Old 06-25-2014, 01:44 PM   #10
AmmoniumNitrate
Banned
 
Join Date: Jul 2013
Posts: 493
Default

Quote:
Originally Posted by alanofoz View Post
... this is a problem....
I don't think it is a problem. You're assuming:

Quote:
Originally Posted by alanofoz View Post
... The 8 least significant bits should all be zero.... This should just not be happening....
I still see no basis for your assumption. If you can show it's a good assumption, I'd think Cockos would implement it; if you don't show it, it seems neither here nor there.
AmmoniumNitrate is offline  
Old 06-25-2014, 01:52 PM   #11
AmmoniumNitrate
Banned
 
Join Date: Jul 2013
Posts: 493
Default

Quote:
Originally Posted by alanofoz View Post
I am VERY familiar with the IEEE 754 FP standard
So you're aware that the significand of a 32 bit FP value contains only 23 bits, and yet you want 8 of these to be set to 0, leaving you with only 15 non-zero bits in the significand, and this is a patently bad idea.
AmmoniumNitrate is offline  
Old 06-25-2014, 02:04 PM   #12
schwa
Administrator
 
schwa's Avatar
 
Join Date: Mar 2007
Location: NY
Posts: 15,749
Default

I have just tested this and everything works as expected. ASIO interface set to 24 bit, recorded to 32 bit FP, faders set to unity and no processing: the file contains no information below 24 bits. You can see this by looking at the raw file, or more conveniently by using a bitmeter FX.

Because REAPER processes everything internally at 64 bit FP, any processing at all will introduce the full 64 bits of resolution. That means any fader or send set to anything but unity, any panning, stereo mixdown, any FX, anything at all.

Touching the fader on the track causes the bitmeter to report a full 64 bits in use, as expected.


schwa is offline  
Old 06-25-2014, 02:35 PM   #13
alanofoz
Human being with feelings
 
alanofoz's Avatar
 
Join Date: Sep 2009
Location: Oz - Blue Mountains NSW, formerly Geelong
Posts: 943
Default

I'm seriously running out of time so I'll have to put off my replies for a few hours, sorry.

I've just made a number of recordings in 32 bit and 24 bit and I still see a problem which I'll describe when I get back.

If I could change the thread title it would say:

When recording to 32 bit, the file's bit depth is incorrect.


And I still believe it's me doing something wrong.
__________________
It's "its" except when it's "it is".

alanofoz, aka Alan of Australia
alanofoz is offline  
Old 06-25-2014, 03:50 PM   #14
DVDdoug
Human being with feelings
 
Join Date: Jul 2010
Location: Silicon Valley, CA
Posts: 2,779
Default

Quote:
When recording to 32 bit, the file's bit depth is incorrect.
I don't even know if "bit depth" has a meaning floating point...

With very-very small numbers (large negative exponents) you have very high precision, and less precision with very large numbers (with large positive exponents). i.e. If I have a very small floating point number I can change it by 1/2 a 'bit', or by 1/1000th of a 'bit'.

But, it's my understanding that you can take a 24-bit integer value and convert it 32-bit floating point, then convert it back to 24-bit integer with no errors. If you were to convert from 32-bit floating point to 32-bit integer, there might be rounding errors in the normalization/de-normalization calculations that end-up in the bottom 8 bits... I don't know... That's beyond my math & programming skills.

Last edited by DVDdoug; 06-25-2014 at 04:09 PM.
DVDdoug is online now  
Old 06-26-2014, 05:47 AM   #15
alanofoz
Human being with feelings
 
alanofoz's Avatar
 
Join Date: Sep 2009
Location: Oz - Blue Mountains NSW, formerly Geelong
Posts: 943
Default

As I said in my previous post, I still see a problem.

Boring mathematical background:

24 bit data will contain any of 8388608 positive integer values and the same number of negative values.
FP data can vary between -1 and +1.
(But you know all this of course).

A 24 bit interface can only supply these integer values, no matter where the data ends up - either a 24 bit or FP file.


The file that started me off here (accidentally recorded as FP instead of 24 bit) started with some low values, the first being 0.0051855091 (rounded) as indicated by Adobe Audition, and confirmed by my own calculations from the data shown in my hex editor.
i.e. 3BA9EB34 = 00111011 10101001 11101011 00110100 which converted to decimal is 0.00518550910055637359619140625.

Problem is, a 24 bit interface cannot possibly supply this value - it's not one of the integer values available. In the 24 bit range of 8388608 positive integer values, this is between the two possible values of 43499 and 43500, and closest to 43499.

Compare these values converted to FP with the value actually in the file:-

00111011 10101001 11101011 00110100 - value in file (43499.203125 in the 24 bit range!!!)
00111011 10101001 11101011 00000000 - 43499
00111011 10101001 11101100 00000000 - 43500

So where does this value come from?


Note:
1. the valid values at this level have zeroes in the lowest 8 bits, leading to my carelessness in stating the problem originally. Hopefully I can live that down!!
2. all samples I looked at, whatever the amplitude, have similar errors.
3. examining the samples using only Adobe Audition reveals the same story albeit with values rounded to fewer places.
4. if I convert the FP file to 24 bit it does not null with the original - there is low level noise which reminds me of dither (probably jumping to conclusions).
__________________
It's "its" except when it's "it is".

alanofoz, aka Alan of Australia
alanofoz is offline  
Old 06-26-2014, 05:51 AM   #16
alanofoz
Human being with feelings
 
alanofoz's Avatar
 
Join Date: Sep 2009
Location: Oz - Blue Mountains NSW, formerly Geelong
Posts: 943
Default

Quote:
Originally Posted by Arran View Post
At what point are you looking at the files? If you start a project at 32 bits then it will pass 32 bits to your ASIO driver which will truncate them.
I'm looking at the files immediately after recording, so the data has come FROM the ASIO driver. A 24 bit sound interface can only supply 24 bits, hence my puzzlement in seeing a 32 bit file with a bit depth more than 24.

I certainly agree that 32 bit data fed TO the ASIO driver will be truncated, but I'm not doing that.

Quote:
Originally Posted by schwa View Post
Internal processing in REAPER is always 64 bit float. The output will be rounded by REAPER to 24 bit fixed or whatever the sound interface expects before being delivered to the interface. The bit depth setting in Project Settings/Media only affects how files are written to disk, which is separate from how audio is delivered to the interface.

In other words, you're not doing anything wrong, and there should be no problem with using your current settings.
Yes, but I'm not doing any processing, and I'm not delivering anything TO the interface.

Quote:
Originally Posted by AmmoniumNitrate View Post
Why do you assume that? Are you talking about bits in the significand, or are you talking about bits in the exponent?

I don't see why these should all be 0. If you can show me why, I'll be interested in understanding what's happening.
Quote:
Originally Posted by AmmoniumNitrate View Post
I don't think it is a problem. You're assuming:


I still see no basis for your assumption. If you can show it's a good assumption, I'd think Cockos would implement it; if you don't show it, it seems neither here nor there.
Oops! But I think I've explained that now...

Quote:
Originally Posted by AmmoniumNitrate View Post
So you're aware that the significand of a 32 bit FP value contains only 23 bits, and yet you want 8 of these to be set to 0, leaving you with only 15 non-zero bits in the significand, and this is a patently bad idea.
Yes, although it's what should happen with the low level signals I started looking at.

Quote:
Originally Posted by Geoff Waddington View Post
As Schwa and others have said, rest assured that 24 bits will be sent to your I/O and all is well, even though the disk files use 32 bits in FP format.
I hope so, but I seem to be getting impossible vales that lie between the possible integer values available with 24 bit data.

Quote:
Originally Posted by DVDdoug View Post
It's floating point so the "bottom 8 bits" are not what you think. Wikipedia explains how the bits are allocated in 32-bit floating point.

Secondly, the sample values are scaled differently. A 0dB peak in 24 bits has a value around 8 million (I think) whereas a 0dB peak in 32-bit floating point has a value of 1.0.
Thanks, I do understand that in spite of my earlier carelessness. I first encountered this format in 1967, before it was even known as IEEE 754, so my carelessness is even more embarrassing.

Quote:
Originally Posted by schwa View Post
I have just tested this and everything works as expected. ASIO interface set to 24 bit, recorded to 32 bit FP, faders set to unity and no processing: the file contains no information below 24 bits. You can see this by looking at the raw file, or more conveniently by using a bitmeter FX.

Because REAPER processes everything internally at 64 bit FP, any processing at all will introduce the full 64 bits of resolution. That means any fader or send set to anything but unity, any panning, stereo mixdown, any FX, anything at all.

Touching the fader on the track causes the bitmeter to report a full 64 bits in use, as expected.]
Thanks, understood, and I am looking at the raw file. No processing, FX or anything.

I must look at your Bitter though and hopefully report back. But it's way past my bedtime & many family commitments for the next couple of days...

Quote:
Originally Posted by DVDdoug View Post
I don't even know if "bit depth" has a meaning floating point...
You're probably right, but for the purposes of this discussion...

Quote:
With very-very small numbers (large negative exponents) you have very high precision, and less precision with very large numbers (with large positive exponents). i.e. If I have a very small floating point number I can change it by 1/2 a 'bit', or by 1/1000th of a 'bit'.

But, it's my understanding that you can take a 24-bit integer value and convert it 32-bit floating point, then convert it back to 24-bit integer with no errors. If you were to convert from 32-bit floating point to 32-bit integer, there might be rounding errors in the normalization/de-normalization calculations that end-up in the bottom 8 bits... I don't know... That's beyond my math & programming skills.
I'll claim to have the mathematical and (C) programming skills in this area... and I agree totally with your comments about converting between 24 bit & FP. In both directions.

Further to that, if a FP file only contains integer values from a sound interface, you should be able to convert it back to 24-bit integer with no errors. And this file should completely null with the original.

But this isn't happening because the file doesn't have integer values even though the interface's ASIO driver should only supply integers. And this is my problem in a nutshell.
__________________
It's "its" except when it's "it is".

alanofoz, aka Alan of Australia
alanofoz is offline  
Old 06-26-2014, 06:01 AM   #17
Jae.Thomas
Human being with feelings
 
Join Date: Jun 2006
Posts: 22,567
Default

how are you checking the files? you aren't rendering first, right? You are checking the source files you recorded?

maybe you could upload an example with a project file?
Jae.Thomas is offline  
Old 06-26-2014, 07:14 AM   #18
AmmoniumNitrate
Banned
 
Join Date: Jul 2013
Posts: 493
Default

Quote:
Originally Posted by alanofoz View Post
... 24 bit data will contain any of 8388608 positive integer values and the same number of negative values.
You're saying that in 24-bit PCM, half the possible values represent positive amplitudes, and the other half represent negative amplitudes; and that would leave you no value for representing 0. That's not the way PCM really works, as real PCM allows you to represent 0.

Quote:
Originally Posted by alanofoz View Post
The file... started with some low values, the first being 0.0051855091 (rounded) as indicated by Adobe Audition, and confirmed by my own calculations from the data shown in my hex editor.
i.e. 3BA9EB34 = 00111011 10101001 11101011 00110100 which converted to decimal is 0.00518550910055637359619140625.

Problem is, a 24 bit interface cannot possibly supply this value - it's not one of the integer values available. In the 24 bit range of 8388608 positive integer values, this is between the two possible values of 43499 and 43500, and closest to 43499.
How exactly are you translating between 24 bit PCM "integers" and 32 bit FP? What formula are you using for this translation?

Quote:
Originally Posted by alanofoz View Post
Boring mathematical background: ... (But you know all this of course).
No, I don't know all that, and I'm wondering where you got that idea.

Last edited by AmmoniumNitrate; 06-26-2014 at 01:11 PM.
AmmoniumNitrate is offline  
Old 06-26-2014, 07:29 AM   #19
schwa
Administrator
 
schwa's Avatar
 
Join Date: Mar 2007
Location: NY
Posts: 15,749
Default

Quote:
Originally Posted by alanofoz View Post
3BA9EB34
I believe that floating point value should not exist in a file written from 24-bit unprocessed data.

In all honesty the likelihood of error in the REAPER code that converts incoming fixed point samples from the interface, to floating point samples for internal processing, is essentially nil. And it's trivial to test that the behavior when writing floating point samples to file is correct.

The only explanations I can see are either that there is some unintentional processing enabled in your project, or (no offense intended) that you are misinterpreting the sample data in the file. You are welcome to post your RPP project file here, and a short audio file that demonstrates the issue.
schwa is offline  
Old 06-26-2014, 10:32 AM   #20
AmmoniumNitrate
Banned
 
Join Date: Jul 2013
Posts: 493
Default

Quote:
Originally Posted by alanofoz View Post
this is a problem when recording.... all I'm doing is recording a stereo signal.... if I convert the FP file to 24 bit it does not null with the original
How do you have an "original" 24-bit PCM file, seeing as your recording was saved to 32-bit FP? Did you actually take the difference between two 24-bit PCM signals and find non-null results, or are you merely speculating?
AmmoniumNitrate is offline  
Old 06-26-2014, 10:51 AM   #21
AmmoniumNitrate
Banned
 
Join Date: Jul 2013
Posts: 493
Default

Quote:
Originally Posted by alanofoz View Post
Quote:
Originally Posted by DVDdoug View Post
I don't even know if "bit depth" has a meaning floating point...
You're probably right, but for the purposes of this discussion...
But for purposes of this discussion what? He is right, and your reasoning seems to be based on a fallacious concept of bit depth.

Last edited by AmmoniumNitrate; 06-26-2014 at 01:12 PM.
AmmoniumNitrate is offline  
Old 06-26-2014, 11:41 AM   #22
AmmoniumNitrate
Banned
 
Join Date: Jul 2013
Posts: 493
Default

Quote:
Originally Posted by alanofoz View Post
00111011 10101001 11101011 00000000 - 43499
00111011 10101001 11101100 00000000 - 43500
Where did you see this data?

Last edited by AmmoniumNitrate; 06-26-2014 at 01:13 PM.
AmmoniumNitrate is offline  
Old 06-26-2014, 02:12 PM   #23
alanofoz
Human being with feelings
 
alanofoz's Avatar
 
Join Date: Sep 2009
Location: Oz - Blue Mountains NSW, formerly Geelong
Posts: 943
Default

Quote:
Originally Posted by Jason Brian Merrill View Post
how are you checking the files? you aren't rendering first, right? You are checking the source files you recorded?
Quote:
Originally Posted by alanofoz View Post
So, to clarify, all I'm doing is recording a stereo signal. I click Record, then Stop, then Save All (the "Select files to save..." dialogue box), exit Reaper & examine the files using a hex editor.
No rendering, yes I am checking the source files I recorded.

Quote:
maybe you could upload an example with a project file?
Good idea, that and a few other things I'll do as soon as I get the time.
__________________
It's "its" except when it's "it is".

alanofoz, aka Alan of Australia
alanofoz is offline  
Old 06-26-2014, 02:17 PM   #24
alanofoz
Human being with feelings
 
alanofoz's Avatar
 
Join Date: Sep 2009
Location: Oz - Blue Mountains NSW, formerly Geelong
Posts: 943
Default

Quote:
Originally Posted by schwa View Post
I believe that floating point value should not exist in a file written from 24-bit unprocessed data.

In all honesty the likelihood of error in the REAPER code that converts incoming fixed point samples from the interface, to floating point samples for internal processing, is essentially nil. And it's trivial to test that the behavior when writing floating point samples to file is correct.

The only explanations I can see are either that there is some unintentional processing enabled in your project, or (no offense intended) that you are misinterpreting the sample data in the file. You are welcome to post your RPP project file here, and a short audio file that demonstrates the issue.
I agree with all of that and as I said in my reply to Brian, I'll post the files when I can.

Your reply deserves more attention & I'll follow up when I'm less rushed.
__________________
It's "its" except when it's "it is".

alanofoz, aka Alan of Australia
alanofoz is offline  
Old 06-26-2014, 02:26 PM   #25
alanofoz
Human being with feelings
 
alanofoz's Avatar
 
Join Date: Sep 2009
Location: Oz - Blue Mountains NSW, formerly Geelong
Posts: 943
Default

AmmoniumNitrate,

I need a bit more time to do justice to your posts. It's early morning here, I might manage something at lunchtime.
__________________
It's "its" except when it's "it is".

alanofoz, aka Alan of Australia
alanofoz is offline  
Old 06-26-2014, 02:53 PM   #26
AmmoniumNitrate
Banned
 
Join Date: Jul 2013
Posts: 493
Default

Quote:
Originally Posted by alanofoz View Post
AmmoniumNitrate,

I need a bit more time to do justice to your posts. It's early morning here, I might manage something at lunchtime.
Thanks, but I think I've become a 3rd wheel in this discussion. I see no problem with 3BA9EB34, but since schwa sees a problem with it,

Quote:
Originally Posted by schwa View Post
Quote:
Originally Posted by alanofoz View Post
3BA9EB34
I believe that floating point value should not exist in a file written from 24-bit unprocessed data.
my opinion doesn't matter.
AmmoniumNitrate is offline  
Old 06-26-2014, 03:36 PM   #27
kenz
Human being with feelings
 
Join Date: Aug 2013
Posts: 339
Default

32-bit Floating Point has a 24-bit mantissa IIRC.

There is absolutely no reason for your least significant 8 bits to be 0, because that would make it 16-bit. You just don't understand, 32-bit floating point wastes 8 bits on exponent, the other 24 are used to represent the mantissa/precision.

For fixed point, the exponent is fixed at 1, which is why you can't go over the 1.0 value (so to speak) and you get clipping. With floating point, because 8 bits represent the exponent, you won't get clipping and much higher dynamic range, very useful when processing only, storing 32-bit FP on disk or a file is a waste IMO unless you need data that is so loud for some reason.


Actually it's 7 bits for exponent, and 1 bit for the value being negative or not, but whatever...

But yeah, the point is, there should NOT be any 8-bits zero for 32-bit FP if you record from 24-bit. That would apply if you recorded from 16-bit interface.
kenz is offline  
Old 06-26-2014, 03:39 PM   #28
AmmoniumNitrate
Banned
 
Join Date: Jul 2013
Posts: 493
Default

Quote:
Originally Posted by kenz View Post
32-bit Floating Point has a 24-bit mantissa IIRC.
........ 23
AmmoniumNitrate is offline  
Old 06-26-2014, 03:42 PM   #29
kenz
Human being with feelings
 
Join Date: Aug 2013
Posts: 339
Default

Technically, it is 24, but the left-most is implicit '1', unless the number is denormalized which happens for very small numbers (smaller than e-127 that is, when exponent is at its limit).

Exponent is 7 bits and sign bit is 1, so that makes mantissa/significand 24-bits, with the implicit left bit.
kenz is offline  
Old 06-26-2014, 03:48 PM   #30
AmmoniumNitrate
Banned
 
Join Date: Jul 2013
Posts: 493
Default

Quote:
Originally Posted by kenz View Post
Exponent is 7 bits
........... 8
AmmoniumNitrate is offline  
Old 06-26-2014, 06:04 PM   #31
kenz
Human being with feelings
 
Join Date: Aug 2013
Posts: 339
Default

Yeah, my bad on that one, I stand corrected. I guess I messed it up somewhere. (since it would be 31 bits with 7, 1+7+23)
kenz is offline  
Old 06-26-2014, 09:43 PM   #32
alanofoz
Human being with feelings
 
alanofoz's Avatar
 
Join Date: Sep 2009
Location: Oz - Blue Mountains NSW, formerly Geelong
Posts: 943
Default

Quote:
Originally Posted by kenz View Post
There is absolutely no reason for your least significant 8 bits to be 0, because that would make it 16-bit. You just don't understand, 32-bit floating point wastes 8 bits on exponent, the other 24 are used to represent the mantissa/precision.
Oh, I understand perfectly well thanks. Please get past the carelessness in my first post where I was referring to a sample value but wrote as if I was referring to a file. Repeat this is a single SAMPLE I'm referring to.
The value was 00111011 10101001 11101011 00110100 (3BA9EB34) which is 43499.203125 in the 24 bit range of 8388608 positive integer values.
But this is not an integer value, so how can it come from the integer data stream supplied by the ASIO driver?

The nearest integer value is 43499 in the 24 bit range, and if this is recorded into a 32 bit FP file it will be 00111011 10101001 11101011 00000000, such a low value only requiring 16 bits.

Boiled down, this is really what I've been talking about all along. Why am I concerned about such a low level signal? Because the same errors are occurring on all the samples, it was just more obvious on the low level ones. And because something is wrong if non-integer values are recorded (as opposed to processed) into the file.

So what's causing the problem? schwa is right in post #19
Quote:
Originally Posted by schwa View Post
The only explanations I can see are either that there is some unintentional processing enabled in your project, or (no offense intended) that you are misinterpreting the sample data in the file. You are welcome to post your RPP project file here, and a short audio file that demonstrates the issue.
To which I'll add the unlikely possibilities: Reaper, the ASIO driver, Windows 8, and the likely possibility that I'm doing something wrong.

The fact still remains that when I record to a 32 bit float file, all the values should correspond to integers in the 24 bit range. At present they do not.



Oh, glad to see we got the FP format sorted, and yes, it's 1 sign bit, 8 exponent bits and the 24 bit significand stored as 23 bits plus 1 implied bit.
__________________
It's "its" except when it's "it is".

alanofoz, aka Alan of Australia
alanofoz is offline  
Old 06-26-2014, 09:51 PM   #33
alanofoz
Human being with feelings
 
alanofoz's Avatar
 
Join Date: Sep 2009
Location: Oz - Blue Mountains NSW, formerly Geelong
Posts: 943
Default

Quote:
Originally Posted by AmmoniumNitrate View Post
You're saying that in 24-bit PCM, half the possible values represent positive amplitudes, and the other half represent negative amplitudes; and that would leave you no value for representing 0. That's not the way PCM really works, as real PCM allows you to represent 0.
In two's complement arithmetic zero is considered to be a positive number, so the 8388608 +ve numbers are 0 to 8388607. The 8388608 -ve numbers are -1 to -8388608. Also, 16 bit and 24 bit integer wave files contain values in two's complement form, so that is the way PCM works

Quote:
How exactly are you translating between 24 bit PCM "integers" and 32 bit FP? What formula are you using for this translation?
I'm using a program I wrote a few years ago. With the healthy suspicion about my expertise in this thread, should you suspect my program? Too right you should. So I also used Adobe Audition to convert, then for good measure I used sox. All returned identical values.

It's not a formula, its an algorithm. I expect the wikipedia article DVDdoug linked to will explain it as well as any other.

Quote:
No, I don't know all that, and I'm wondering where you got that idea.
40 years of two's complement experience. And in the case of FP I'm referring to the full scale values corresponding to the 24 bit int values. The fact that FP can exceed full scale is irrelevant to my problem.

Quote:
Originally Posted by AmmoniumNitrate View Post
How do you have an "original" 24-bit PCM file, seeing as your recording was saved to 32-bit FP? Did you actually take the difference between two 24-bit PCM signals and find non-null results, or are you merely speculating?
I didn't refer to any original 24 bit file. The original is the file I started with, i.e. the FP file originally recorded.

I converted the original FP file to a 24 bit file as described above, opened both files in Audition, copied one and pasted the inverted data over the other. If the values were the same the result would have yielded a file full of zeroes. It did not.

Quote:
Originally Posted by AmmoniumNitrate View Post
But for purposes of this discussion what? He is right, and your reasoning seems to be based on a fallacious concept of bit depth.
For convenience I'm just using bit depth in the same way as Adobe Audition when it displays the bit depth of a FP file. If a 24 bit file is converted to FP, by this definition, the FP file will have a bit depth of 24. If I (and Adobe) are technically wrong I don't think it matters in the context of this thread. And I don't feel the need to investigate further.

Quote:
Originally Posted by AmmoniumNitrate View Post
Where did you see this data?
I never said I saw these values. These are the calculated values of the nearest integers to the non-integer value stored in my original file.


Sorry, I really didn't want to clutter this thread with this level of detail, but I was asked...
__________________
It's "its" except when it's "it is".

alanofoz, aka Alan of Australia

Last edited by alanofoz; 06-30-2014 at 05:01 AM.
alanofoz is offline  
Old 06-26-2014, 09:58 PM   #34
alanofoz
Human being with feelings
 
alanofoz's Avatar
 
Join Date: Sep 2009
Location: Oz - Blue Mountains NSW, formerly Geelong
Posts: 943
Default

Quote:
Originally Posted by AmmoniumNitrate View Post
Thanks, but I think I've become a 3rd wheel in this discussion.
No, you're the one that led me to my Oops! moment and caused me to think straight. (See post #16)
__________________
It's "its" except when it's "it is".

alanofoz, aka Alan of Australia
alanofoz is offline  
Old 06-26-2014, 10:08 PM   #35
alanofoz
Human being with feelings
 
alanofoz's Avatar
 
Join Date: Sep 2009
Location: Oz - Blue Mountains NSW, formerly Geelong
Posts: 943
Default

FWIW the zip file contains a project file, the 32 bit recorded file and the 24 bit file converted from this in Audition.


This is just a mono recording for simplicity.
Attached Files
File Type: zip BitDepthTest.zip (528.2 KB, 124 views)
__________________
It's "its" except when it's "it is".

alanofoz, aka Alan of Australia
alanofoz is offline  
Old 06-26-2014, 11:03 PM   #36
alanofoz
Human being with feelings
 
alanofoz's Avatar
 
Join Date: Sep 2009
Location: Oz - Blue Mountains NSW, formerly Geelong
Posts: 943
Default

Quote:
Originally Posted by schwa View Post
I have just tested this and everything works as expected. ASIO interface set to 24 bit, recorded to 32 bit FP, faders set to unity and no processing: the file contains no information below 24 bits. You can see this by looking at the raw file, or more conveniently by using a bitmeter FX.

Because REAPER processes everything internally at 64 bit FP, any processing at all will introduce the full 64 bits of resolution. That means any fader or send set to anything but unity, any panning, stereo mixdown, any FX, anything at all.

Touching the fader on the track causes the bitmeter to report a full 64 bits in use, as expected.



And here's mine:





There's clearly something happening here that shouldn't be. The only effect is bitter, the fader is set to unity, pan to centre. I don't know what else can affect the data.

Interestingly, if I move the fader it doesn't indicate 64 bits. How do I check that I have the 64 bit engine selected? (Not that it can affect the unprocessed file.)
__________________
It's "its" except when it's "it is".

alanofoz, aka Alan of Australia
alanofoz is offline  
Old 06-26-2014, 11:55 PM   #37
AmmoniumNitrate
Banned
 
Join Date: Jul 2013
Posts: 493
Default

Quote:
Originally Posted by alanofoz View Post
Quote:
Originally Posted by AmmoniumNitrate View Post
How exactly are you translating between 24 bit PCM "integers" and 32 bit FP? What formula are you using for this translation?
It's not a formula, its an algorithm. I expect the wikipedia article DVDdoug linked to will explain it as well as any other.
But that Wikipedia article specifies no formula or algorithm for such translation. Will you please answer my question here with a specific formula or algorithm?

Quote:
Originally Posted by alanofoz View Post
Quote:
Originally Posted by AmmoniumNitrate View Post
Quote:
Originally Posted by alanofoz View Post
Boring mathematical background:

24 bit data will contain any of 8388608 positive integer values and the same number of negative values.
FP data can vary between -1 and +1.
(But you know all this of course).
No, I don't know all that, and I'm wondering where you got that idea.
40 years of two's complement experience. And in the case of FP I'm referring to the full scale values corresponding to the 24 bit int values.
And somewhere along the way you decided that an x800000 in 24-bit PCM should convert to -1.0 in FP, and you decided that if anyone does it differently, you'd call it "noise" and "error", even if the results weren't noisy or erroneous in any conventional sense?

Quote:
Originally Posted by alanofoz View Post
Quote:
Originally Posted by AmmoniumNitrate View Post
How exactly are you translating between 24 bit PCM "integers" and 32 bit FP? What formula are you using for this translation?
I also used Adobe Audition to convert, then for good measure I used sox. All returned identical values.
And you assumed that if Reaper converted differently from Audition and sox, that Reaper was somehow wrong and others were somehow right, as if there's some standard? And this standard is specified by Adobe and sox?

Quote:
Originally Posted by alanofoz View Post
if I convert the FP file to 24 bit it does not null with the original - there is low level noise
By that, you simply mean that Reaper and Audition translate 24-bit PCM to 32-bit FP differently, and you choose to call any divergence from Audition's translation "noise"? And even if Reaper converts the 32-bit FP file back to the original 24-bit PCM signal without a hitch, you'll still say there was "noise" and "error", because that's your concept of "noise" and "error"?

Last edited by AmmoniumNitrate; 06-27-2014 at 12:24 AM.
AmmoniumNitrate is offline  
Old 06-27-2014, 12:13 AM   #38
vordex
Human being with feelings
 
vordex's Avatar
 
Join Date: Sep 2013
Location: Oxfordshire, UK
Posts: 60
Default

Quote:
Originally Posted by AmmoniumNitrate View Post
And somewhere along the way you decided that an x80000000 00000000 00000000 in 24-bit PCM should convert to -1.0 in FP, and you decided that if anyone does it differently, you'd call it "noise" and "error", even if the results weren't noisy or erroneous in any conventional sense?
With respect, the OP is quite clear at the outset:

Quote:
Originally Posted by alanofoz View Post
I expect this to be my error
He's simply trying to determine what's causing unexpected bits in the FP data.
vordex is offline  
Old 06-27-2014, 12:20 AM   #39
AmmoniumNitrate
Banned
 
Join Date: Jul 2013
Posts: 493
Default

Quote:
Originally Posted by vordex View Post
He's simply trying to determine what's causing unexpected bits in the FP data.
When he calls those bits "noise" and "error" he's doing something different from calling them "unexpected".
AmmoniumNitrate is offline  
Old 06-27-2014, 01:10 AM   #40
alanofoz
Human being with feelings
 
alanofoz's Avatar
 
Join Date: Sep 2009
Location: Oz - Blue Mountains NSW, formerly Geelong
Posts: 943
Default

Quote:
Originally Posted by AmmoniumNitrate View Post
But that Wikipedia article specifies no formula or algorithm for such translation. Will you please answer my question here with a specific formula or algorithm?
To convert from FP to 24 bit take the bottom 23 bits, add the implied bit to give you the significand. Bit shift according to the exponent. Apply the sign bit.
I'll leave it to you to reverse the process.

Quote:
And somewhere along the way you decided that an x800000 in 24-bit PCM should convert to -1.0 in FP, and you decided that if anyone does it differently, you'd call it "noise" and "error", even if the results weren't noisy or erroneous in any conventional sense?
I made no such decision. Others before me have decided that years ago. I'm not aware of anyone doing it differently, including Reaper, so what am I calling anything?

But that's not even what I'm talking about. Some combination of Reaper, the Zoom16 and its ASIO driver, Win 8, some so far unknown procedure of mine is placing non-integer values into the original file. This is incorrect. Anything that deviates from a correct signal may certainly be referred to as errors or noise.

Quote:
And you assumed that if Reaper converted differently from Audition and sox, that Reaper was somehow wrong and others were somehow right, as if there's some standard? And this standard is specified by Adobe and sox?
I never said Reaper "converted" differently from Audition or sox.

Quote:
By that, you simply mean that Reaper and Audition translate 24-bit PCM to 32-bit FP differently, and you choose to call any divergence from Audition's translation "noise"? And even if Reaper converts the 32-bit FP file back to the original 24-bit PCM signal without a hitch, you'll still say there was "noise" and "error", because that's your concept of "noise" and "error"?
I assume no such thing, I expect they do their conversions the same way.


With respect, I'll not buy into your posts any further. I've spent more time addressing your questions than the rest of my time in this thread combined, and I don't think it's helping to solve the problem at hand. I feel that you are just trying to prove me wrong in many ways, and if so the burden of proof falls to you I'm afraid.
__________________
It's "its" except when it's "it is".

alanofoz, aka Alan of Australia
alanofoz is offline  
Closed Thread

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 08:49 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.