Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER Compatibility

Closed Thread
 
Thread Tools Display Modes
Old 06-27-2014, 02:45 AM   #41
AmmoniumNitrate
Banned
 
Join Date: Jul 2013
Posts: 493
Default

Quote:
Originally Posted by alanofoz View Post
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.
Suit yourself, but the problem at hand is all in your head. We all start out not knowing how to convert PCM to FP. But your making up assumptions and then attacking my motives for questioning your assumptions, that's psychosis on your part.

Quote:
Originally Posted by alanofoz View Post
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.
That would map the FP range [-1.0, +1.0] onto three and only three 24-bit PCM values: -1, 0, and +1. Now that would be a real error.
Quote:
Originally Posted by alanofoz View Post
I'll leave it to you to reverse the process.
He doesn't know how it should be done; but that isn't stopping him from accusing others of doing it wrong.

Quote:
Originally Posted by alanofoz View Post
Quote:
Originally Posted by AmmoniumNitrate View Post
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?
Who are these "others" he's talking about? That's not how we always did things at CCRMA, Creative Labs, or Intel. This guy's lack of awareness (combined with his pretending he knows what he's talking about) is the problem, and it doesn't mean Reaper, Windows, or anyone else is causing "noise" as he's accusing.

Quote:
Originally Posted by alanofoz View Post
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.
He's making a choice to interpret the FP values in a certain way, and that's no one's error but his own.

Quote:
Originally Posted by alanofoz View Post
Anything that deviates from a correct signal may certainly be referred to as errors or noise.
He's aware of only one way to convert 24-bit PCM to 32-bit FP, and he's pretending it's the only "correct" way. This error is his, no one else's. He misunderstands what it means to "correctly" convert 24-bit PCM to 32-bit FP. His conception of "noise" is absurd, despite his certainty.

Quote:
Originally Posted by alanofoz View Post
Quote:
Originally Posted by AmmoniumNitrate View Post
... 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 expect they do their conversions the same way.
This expectation is an error on his part; no one else's. More like a delusion, to the extreme he's taking it.

Last edited by AmmoniumNitrate; 06-27-2014 at 03:46 AM.
AmmoniumNitrate is offline  
Old 06-27-2014, 03:42 AM   #42
Geoff Waddington
Human being with feelings
 
Geoff Waddington's Avatar
 
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 3,787
Default

What happens if you drop Bitter (the Schwa VST plugin used in post -- it's free) on the track while recording?
__________________
CSI - You can donate here: geoffwaddington.ca
Alpha software: https://stash.reaper.fm/v/36903/CSI%20alpha.zip
Reaper forum thread: https://forum.cockos.com/showthread.php?t=183143
Geoff Waddington is offline  
Old 06-27-2014, 04:48 AM   #43
alanofoz
Human being with feelings
 
alanofoz's Avatar
 
Join Date: Sep 2009
Location: Oz - Blue Mountains NSW, formerly Geelong
Posts: 744
Default

Good idea, could be very revealing.
__________________
It's "its" except when it's "it is".

bunyipmusic.com
alanofoz is offline  
Old 06-27-2014, 05:05 AM   #44
AmmoniumNitrate
Banned
 
Join Date: Jul 2013
Posts: 493
Default

Quote:
Originally Posted by Geoff Waddington View Post
What happens if you drop Bitter (the Schwa VST plugin used in post -- it's free) on the track while recording?
When looking at a 32-bit FP signal, how is Bitter supposed to know which formula is being used for conversion from 24-bit PCM to 32-bit FP? There is no single correct formula for this. As long as the original 24-bit PCM is recoverable, there is no noise being introduced. One man's adventure with a hex editor and not knowing what he was looking at is for all intents and purposes irrelevant.
AmmoniumNitrate is offline  
Old 06-27-2014, 05:34 AM   #45
schwa
Administrator
 
schwa's Avatar
 
Join Date: Mar 2007
Location: NY
Posts: 10,366
Default

Quote:
Originally Posted by alanofoz View Post
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.)
There is only a 64 bit engine. Sorry, I was unclear earlier; the track fader is post-FX so you will only see the increased resolution caused by a fader move if you create a send and measure bit depth on the receiving track. You will see increased resolution on the single track instance if you edit the media item in any way, for example by dragging the automatically created fadein or fadeout.

Thanks for attaching the project. I do not see anything in the project itself that would affect the recorded media. I have to think that the audio coming in has been unintentionally processed by software upstream of REAPER.

Could you show a screenshot of the device ASIO settings? Many interfaces include preprocessing software (such as RME's totalmix) that can affect the signal upstream of the DAW. Any chance of sample rate conversion, trim, anything being enabled on the device or the device software control panel? It's also possible there is a miscommunication between the device and REAPER about the sample rate or bit depth, which should be discoverable by looking at the device software control panel.
schwa is offline  
Old 06-27-2014, 06:23 AM   #46
alanofoz
Human being with feelings
 
alanofoz's Avatar
 
Join Date: Sep 2009
Location: Oz - Blue Mountains NSW, formerly Geelong
Posts: 744
Default

Quote:
Originally Posted by schwa View Post
There is only a 64 bit engine. Sorry, I was unclear earlier; the track fader is post-FX so you will only see the increased resolution caused by a fader move if you create a send and measure bit depth on the receiving track. You will see increased resolution on the single track instance if you edit the media item in any way, for example by dragging the automatically created fadein or fadeout.

Thanks for attaching the project. I do not see anything in the project itself that would affect the recorded media. I have to think that the audio coming in has been unintentionally processed by software upstream of REAPER.

Could you show a screenshot of the device ASIO settings? Many interfaces include preprocessing software (such as RME's totalmix) that can affect the signal upstream of the DAW. Any chance of sample rate conversion, trim, anything being enabled on the device or the device software control panel? It's also possible there is a miscommunication between the device and REAPER about the sample rate or bit depth, which should be discoverable by looking at the device software control panel.
Thanks for the 64 bit explanation.

I'm also coming to the conclusion that it's something upstream from Reaper, probably not processing though (see the screenshot below). I'm not sure how the data could be corrupted coming from the ASIO driver, but I'm tending towards that idea.

On this machine I have Audition 1.5 which uses WDM not ASIO, and have just tried it. In this case there is no problem - the file is 32 bit FP, containing 24 bit data as I expect.

I can try other computers including an XP machine. I'll just need to install Reaper on them. I'll also dig out the Cubase LE that came with the Zoom and see what happens there. All time consuming

__________________
It's "its" except when it's "it is".

bunyipmusic.com
alanofoz is offline  
Old 06-27-2014, 06:26 AM   #47
schwa
Administrator
 
schwa's Avatar
 
Join Date: Mar 2007
Location: NY
Posts: 10,366
Default

Quote:
Originally Posted by alanofoz View Post
On this machine I have Audition 1.5 which uses WDM not ASIO, and have just tried it. In this case there is no problem - the file is 32 bit FP, containing 24 bit data as I expect.
You can select the WDM driver in REAPER, as well.
schwa is offline  
Old 06-27-2014, 06:47 AM   #48
schwa
Administrator
 
schwa's Avatar
 
Join Date: Mar 2007
Location: NY
Posts: 10,366
Default

Quote:
Originally Posted by schwa View Post
I have to think that the audio coming in has been unintentionally processed by software upstream of REAPER.
Actually, I think upstream processing is not the issue. Even if there were processing prior to the ASIO driver delivering samples to REAPER, the samples should still be delivered in the expected 24-bit format.

This leaves the following possibilities as far as I can tell:

1. Miscommunication of sample rate format between the Zoom driver and REAPER. There is a defined ASIO format of 24-bit data aligned within a 32-bit stream. It's farfetched, but possible the Zoom is using this format and miscommunicating it as 32-bit data.

2. Some processing happening within REAPER that I haven't thought of yet.

3. A thorough misunderstanding of the problem.


It would definitely be illuminating to:

A. Insert the bitmeter on the recording track. If it reports 24 bits coming from the interface, the processing is happening within REAPER.

B. Use the same device in REAPER with a different driver, such as WDM.

C. Set the device bit depth to 16.

Last edited by schwa; 06-27-2014 at 07:16 AM.
schwa is offline  
Old 06-27-2014, 06:55 AM   #49
AmmoniumNitrate
Banned
 
Join Date: Jul 2013
Posts: 493
Default

schwa, does Reaper in fact divide by 0x800000 to convert from 24-bit PCM to FP?
AmmoniumNitrate is offline  
Old 06-27-2014, 10:49 AM   #50
schwa
Administrator
 
schwa's Avatar
 
Join Date: Mar 2007
Location: NY
Posts: 10,366
Default

Quote:
Originally Posted by schwa View Post
1. Miscommunication of sample rate format between the Zoom driver and REAPER. There is a defined ASIO format of 24-bit data aligned within a 32-bit stream. It's farfetched, but possible the Zoom is using this format and miscommunicating it as 32-bit data.
We are now almost certain this is the case, that the Zoom ASiO driver is delivering 32-bit data with garbage in the bottom 8 bits.

The latest prerelease should handle this properly in WASAPI mode. We should be able to correct the ASIO case in the next prerelease. Thanks for the report.
schwa is offline  
Old 06-27-2014, 11:07 AM   #51
AmmoniumNitrate
Banned
 
Join Date: Jul 2013
Posts: 493
Default

Quote:
Originally Posted by alanofoz View Post
Quote:
Originally Posted by AmmoniumNitrate View Post
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....
http://blog.bjornroche.com/2009/12/i...out-there.html

http://www.kvraudio.com/forum/viewto...?f=33&t=414666

Would be nice to know Reaper's practices in this respect.
AmmoniumNitrate is offline  
Old 06-27-2014, 02:56 PM   #52
alanofoz
Human being with feelings
 
alanofoz's Avatar
 
Join Date: Sep 2009
Location: Oz - Blue Mountains NSW, formerly Geelong
Posts: 744
Default

Quote:
Originally Posted by schwa View Post
We are now almost certain this is the case, that the Zoom ASiO driver is delivering 32-bit data with garbage in the bottom 8 bits.
That would certainly fit with my observations. I wonder if bits 24 to 31 are garbage whether bit 23 might be affected by rounding. (Rhetorical question.) In any case, if we can trust at least 23 bits in a 24 bit file, the problem is hardly worth worrying about.

OTOH this might support my submission to the financial controller* for approval of the purchase of a Focusrite Scarlett 18i20.

* i.e. Mrs Alanofoz.

Quote:
The latest prerelease should handle this properly in WASAPI mode. We should be able to correct the ASIO case in the next prerelease. Thanks for the report.
Good news, thanks.

We have family staying with us this weekend, so that takes precedence, but I now have a list of things to try, including WDM in Reaper.

schwa, many thanks for your perseverance with this. Extremely helpful.
__________________
It's "its" except when it's "it is".

bunyipmusic.com
alanofoz is offline  
Old 06-27-2014, 03:12 PM   #53
AmmoniumNitrate
Banned
 
Join Date: Jul 2013
Posts: 493
Default

Quote:
Originally Posted by alanofoz View Post
I wonder if bits 24 to 31 are garbage whether bit 23 might be affected by rounding.
And whether it's truly garbage, and whether the effect might be beneficial, because "noise" isn't what some seem to assume.
AmmoniumNitrate is offline  
Old 06-27-2014, 03:13 PM   #54
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 12,560
Default

To clarify:

This behavior is a bug in the Zoom ASIO driver -- it tells the host application that it is returning 32-bit integer samples, by setting the format to ASIOSTInt32LSB, and filling in the low 8 bits of each sample with various values. REAPER is merely interpreting the data as it should according to the spec.

The Zoom ASIO driver should probably either zero the low byte of each sample, or use the ASIOSTInt32LSB24 sample type.

We could work around this by treating ASIOSTInt32LSB as ASIOSTInt32LSB24, which is probably completely safe, however there is really no benefit (as these low bits are meaningless and should have no effect whatsoever when writing normal PCM data), and in theory if the state of the art of converters should improve, we could someday see meaningful bit depths of greater than 24 bits, which would then be lost.

TL;DR: Zoom driver is wrong, but without any consequence. We could fix on our end, but no real point.
Justin is online now  
Old 06-27-2014, 03:17 PM   #55
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 12,560
Default

Quote:
Originally Posted by alanofoz View Post
I wonder if bits 24 to 31 are garbage whether bit 23 might be affected by rounding. (Rhetorical question.)
Only if dithering -- if you truncated then the low bits would be simply removed. If dithering to 24 bits they may give you a bit's worth of noise (which is well below the actual noise floor of any real world converter), and if you dither to some lower bit depth (such as 16 bit) it would likely have a statistically insignificant effect.
Justin is online now  
Old 06-27-2014, 07:39 PM   #56
alanofoz
Human being with feelings
 
alanofoz's Avatar
 
Join Date: Sep 2009
Location: Oz - Blue Mountains NSW, formerly Geelong
Posts: 744
Default Resolved

Thanks for the confirmation Justin. Needless to say, this fits my observation exactly. As this thread evolved a bug in Zoom's driver was looking more and more likely.

I can now comfortably continue to use 24 bit projects.
__________________
It's "its" except when it's "it is".

bunyipmusic.com

Last edited by alanofoz; 06-28-2014 at 05:41 AM.
alanofoz is offline  
Old 06-28-2014, 10:18 PM   #57
alanofoz
Human being with feelings
 
alanofoz's Avatar
 
Join Date: Sep 2009
Location: Oz - Blue Mountains NSW, formerly Geelong
Posts: 744
Default

Not wanting to revive this thread, but just want to express my gratitude to those who were not dismissive of my observations/interpretations, especially schwa and Justin.

And very well done too schwa & Justin for following through to a resolution. I don't imagine the testing to have been a trivial effort.

A fantastic demonstration of the responsiveness of Reaper's devs. How many apps can you think of where there would be any response at all, or as fast? And just from a forum post, not even a bug report.

Great conclusion to this thread.
__________________
It's "its" except when it's "it is".

bunyipmusic.com
alanofoz is offline  
Old 06-28-2014, 10:27 PM   #58
AmmoniumNitrate
Banned
 
Join Date: Jul 2013
Posts: 493
Default

Quote:
Originally Posted by alanofoz View Post
Not wanting to revive this thread, but just want to express my gratitude to those who were not dismissive of my observations/interpretations....
I never doubted your observations, but your interpretations were bad and still are bad, if you're still assuming bit-shifting is the only way people are converting from ints to floats; if you're still doing "null tests" by subtracting whatever Audition happens to come up with; and if you still expect to find 0-bits in floats when you shouldn't expect it.

Last edited by AmmoniumNitrate; 06-28-2014 at 10:36 PM.
AmmoniumNitrate is offline  
Old 06-29-2014, 12:52 AM   #59
Nystagmus
Human being with feelings
 
Nystagmus's Avatar
 
Join Date: Oct 2013
Posts: 509
Default

Maybe the r16 is utilizing bits differently. For example, rather than implementiing zero to full scale in both polarities it's adding the additional 8 bits to the 16 bits of zero to full scale as headroom above full scale in both polarities. So the bits expected to be empty LSB's wouldn't but the MSB's would be. I'd take a look at that if i were you. Also consider thermal noise or leakage from the fx built in unit to be part of the waveform... And also maybe grounding issues or electrical interference. And remember that 24 bits might be sent with an 8 bit mantissa of a 32 bit word. So maybe something is happening that way or the 24 bit packing is messed up in the r16. Hardware makers make all kinds of shortcuts and trade offs. I would wonder about the interface. And i own an r8.
Nystagmus is offline  
Old 06-29-2014, 01:04 AM   #60
Nystagmus
Human being with feelings
 
Nystagmus's Avatar
 
Join Date: Oct 2013
Posts: 509
Default

oops i just now read the rest of the thread. Sorry about my hasty response. Cool to see you noticed the zoom driver operating at 32 bits. That makes sense.
Nystagmus is offline  
Old 06-29-2014, 02:33 PM   #61
alanofoz
Human being with feelings
 
alanofoz's Avatar
 
Join Date: Sep 2009
Location: Oz - Blue Mountains NSW, formerly Geelong
Posts: 744
Default

Quote:
Originally Posted by Nystagmus View Post
oops i just now read the rest of the thread. Sorry about my hasty response. Cool to see you noticed the zoom driver operating at 32 bits. That makes sense.
Join the club, my own post to start the thread was also written in haste. Fortunately, in spite of the bad start, the thread reached a satisfactory resolution.
__________________
It's "its" except when it's "it is".

bunyipmusic.com
alanofoz is offline  
Old 06-29-2014, 02:55 PM   #62
chip mcdonald
Human being with feelings
 
chip mcdonald's Avatar
 
Join Date: May 2006
Location: NA - North Augusta South Carolina
Posts: 3,764
Default

I know this is only obliquely related, but:

Is there some forum online where people hangout discussing low level aspects of ASIO drivers? In other words, it has always seemed like voodoo, the bridge from "how the ASIO driver communicates with the USB port > hand off to DAW"?

Centrance writes just about everyone's drivers, right? How does that work?

Is there some list of who uses Centrance and who doesn't? The idea that Zoom could have chosen to do something "different" with the math to get to 32 is curious, and begs the question "could it be more favorable if the ASIO driver is asked to pass a different int?" or some such (excuse my dilettante programming knowledge).

There have been the diffuse rumors in the nooks and crannies of the internet about "X interface really should be ran at x HZ sample rate because the chip is designed for that", and then one wonders if what is delivered off the USB port can stymy a particular interface's intended digital output, etc. etc...

?
__________________
]]]>-guitar lessons - www.chipmcdonald.com-<[[[
Experiencing Guitar: Essays from Teaching by Chip McDonald https://www.amazon.com/dp/1521877823..._QZJxAbA4GVDC1
chip mcdonald is offline  
Old 06-29-2014, 03:05 PM   #63
AmmoniumNitrate
Banned
 
Join Date: Jul 2013
Posts: 493
Default

I wrote ring-0 drivers for Creative Labs but I'm sworn to secrecy.
AmmoniumNitrate is offline  
Old 06-29-2014, 07:01 PM   #64
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 12,560
Default

Quote:
Originally Posted by chip mcdonald View Post
The idea that Zoom could have chosen to do something "different" with the math to get to 32 is curious, and begs the question "could it be more favorable if the ASIO driver is asked to pass a different int?" or some such (excuse my dilettante programming knowledge).
The driver can choose a sample format in order to achieve the desired bit depth and to operate as efficiently as it can. I think the developers of the Zoom driver intended to have 24 bit samples padded to 32 bits (which simplifies a lot of things and can be more efficient), but instead report it as "32 bits", which is a mistake.
Justin is online now  
Old 06-30-2014, 12:11 AM   #65
alanofoz
Human being with feelings
 
alanofoz's Avatar
 
Join Date: Sep 2009
Location: Oz - Blue Mountains NSW, formerly Geelong
Posts: 744
Default

Quote:
Originally Posted by AmmoniumNitrate View Post
I never doubted your observations, but your interpretations were bad and still are bad, if you're still assuming bit-shifting is the only way people are converting from ints to floats; if you're still doing "null tests" by subtracting whatever Audition happens to come up with; and if you still expect to find 0-bits in floats when you shouldn't expect it.
I see that you still have concerns about my posts, so now that the original problem has been resolved it's probably OK to address them.

Firstly though, I paid you the respect of spending a large amount of my time addressing your concerns in posts #6, #10 & #11 (see post #16), posts #18, #20, #21, #22 (see post #33), post #26 (see post # 34), and post #37 (see post #40). And I did this in spite of the often condescending style of your posts.

By the end of post #40, I felt that the thread was in danger of losing its focus, namely where were the discrepancies in the lowest 8 bits coming from. So I politely told you I wouldn't address any more your posts, and also politely told you how they were making me feel. And because you had consistently questioned my processes and interpretations without offering any alternatives I effectively asked you to prove me wrong. Your reply in post #41 struck me as beyond the pale, but other people less involved than you or I are probably better able to judge that.

I'll address your technical questions in a new post...
__________________
It's "its" except when it's "it is".

bunyipmusic.com
alanofoz is offline  
Old 06-30-2014, 12:24 AM   #66
alanofoz
Human being with feelings
 
alanofoz's Avatar
 
Join Date: Sep 2009
Location: Oz - Blue Mountains NSW, formerly Geelong
Posts: 744
Default

I observed a problem, namely that the values coming from the ASIO driver to the FP file created by Reaper were all non-integer.

AN, post #58: "I never doubted your observations"
AN, post #41: "but the problem at hand is all in your head."

So which is it?


AN, post #58: "but your interpretations were bad and still are bad, if you're still assuming bit-shifting is the only way people are converting from ints to floats"

Fortunately I don't assume that, nor did I ever say so. It's just one often convenient way of doing it. And it's only part of the process I described (did you miss that). In fact, let's demonstrate another...

AN, post #37: "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?"

You're right, but it's easy to modify the method given (which includes an example) for float to decimal. And I'll now answer your question (ad tedium). I'll use that method to convert the FP value to convert the value that I quoted in post #15, i.e. 0x3BA9EB34. See also post #19.

0x3BA9EB34 = 00111011 10101001 11101011 00110100

The sign bit is 0 - i.e. it's a +ve number.
Exponent is 01110111 = 119 decimal. Subtracting 127 as per Wikipedia gives -8 as the actual exponent.
Significand = 0101001 11101011 00110100 (the lowest 23 bits). And with the implied '1' it's 10101001 11101011 00110100.

Now apply the exponent by multiplying the significand by 2^-8: Result is 1010100111101011.00110100 (I could have done that by bit shifting of course.)
The integer part is 43499 (I cheated here - I used Windows calculator. Hope you can accept that.)
The fractional part is 2^-3 + 2^-4 + 2^-6 = 0.203125

Final result 43499.203125 (Which is what I said originally.) This is the method I outlined for you in post #40, except for the bit shifting part which I did another way this time.


AN, post #41: Of my method you said, "That would map the FP range [-1.0, +1.0] onto three and only three 24-bit PCM values: -1, 0, and +1."

Really???


Now, strictly speaking I've left out two steps.

1. In the FP format the 23 stored bits of the significand is a fractional value. To fix that I should move the binary point 23 places to the left. (Sorry, that's bit shifting in thin disguise.)
2. I'm converting to values in a 24 bit range. So I should multiply by 2^23.

As these 2 steps would cancel out I've left them out. With the level of expertise you're claiming, e.g. post #63, I'm sure you don't need me to explain that.



AL (that's me), post #40: I'll leave it to you to reverse the process. (i.e. convert back to float.)
AN, post #41: "He doesn't know how it should be done; but that isn't stopping him from accusing others of doing it wrong."

Taking the second part of that statement first, please tell me where I accused anyone of doing it wrong. I did say that the bottom 8 bits were wrong, I did not even hint at how I thought that was happening. Turns out (Post #50, #54 & #64) that Zoom's ASIO driver puts garbage in the bottom 8 bits.

And here is how it can be done.

This time I'll take the 24 bit value that should have been stored in the file. i.e. 43499 = 0x00A9EB = 00000000 10101001 11101011

This must be normalised. i.e. discard all leading zeroes. i.e. 10101001 11101011

The leading '1' is then discarded because it will always be a '1' so it may be implied. We now have 0101001 11101011

The significand is then padded to 23 bits. i.e. 0101001 11101011 00000000

The number of leading zeroes we removed now needs to be subtracted from 127 to provide the exponent value. In this case that's 127 - 8 = 119 = 0x77 = 0x01110111

So the sign bit, exponent and significand are 0, 01110111, and 0101001 11101011 00000000, i.e. 00111011 10101001 11101011 00000000 = 0x3BA9EB00



To test: Using the hex editor I placed many alternate values of 0x00A9EB and the -ve equivalent into a 24 bit file and many values of 0x3BA9EB00 and the -ve equivalent into a 32 bit FP file, forming a waveform in each. Remember I've just shown that these values are equivalent. When I opened these files in Reaper and rendered, the output file showed EXACTLY the same values in each case. Of course it was much easier to test in Audition, but you've shown an unwillingness to accept results in Audition.



AN, post #58: "if you're still doing "null tests" by subtracting whatever Audition happens to come up with"

Can you please explain what's wrong with null tests? Please quote verifiable results. IOW please put the same effort into your reply that I've put into mine. So far all you've done is dismiss results from Audition. e.g. "whatever Audition happens to come up with" is very dismissive and unsubstantiated.



AN, post #58: "and if you still expect to find 0-bits in floats when you shouldn't expect it."

Please revisit the specific sample I talked about and explain to me why it shouldn't have zeroes in the lowest 8 bits.



AN, post #41: "He's aware of only one way to convert 24-bit PCM to 32-bit FP, and he's pretending it's the only "correct" way."

How do you know that I know only one way? Where did I ever say it's the only "correct" way?



AN post #41: "This error is his, no one else's. He misunderstands what it means to "correctly" convert 24-bit PCM to 32-bit FP. His conception of "noise" is absurd, despite his certainty."

Please prove all of this with facts & figures. I've put a lot of effort into replying to you, please don't insult me by doing less in return.
__________________
It's "its" except when it's "it is".

bunyipmusic.com

Last edited by alanofoz; 06-30-2014 at 12:58 AM.
alanofoz is offline  
Old 06-30-2014, 04:54 AM   #67
richie43
Human being with feelings
 
Join Date: Dec 2009
Location: Minnesota
Posts: 8,555
Default

I can see that this formerly useful thread has degraded into a "pissing match", which is unfortunate and silly.....
But I just downloaded the sample Reaper project and opened it. After loading the "ConvertedTo24bitInAudition" wav file and flipping the phase on it, these files nulled about as much as I have ever seen. I am unclear what the issue is then.
__________________
http://soundyaudio.com/ The Sounds of the Hear and Now
richie43 is offline  
Old 06-30-2014, 07:09 AM   #68
AmmoniumNitrate
Banned
 
Join Date: Jul 2013
Posts: 493
Default

Quote:
Originally Posted by AmmoniumNitrate View Post
Quote:
Originally Posted by alanofoz View Post
Quote:
Originally Posted by AmmoniumNitrate View Post
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?
Others before me have decided that years ago.
Who are these "others" he's talking about? That's not how we always did things at CCRMA, Creative Labs, or Intel.
Quote:
Originally Posted by alanofoz View Post
I've put a lot of effort into
You've put a lot of effort into making up pretend people ("others"), and you've put a lot of effort into not answering the question "Who are these 'others' he's talking about?"
AmmoniumNitrate is offline  
Old 06-30-2014, 08:13 AM   #69
schwa
Administrator
 
schwa's Avatar
 
Join Date: Mar 2007
Location: NY
Posts: 10,366
Default

There is useful information in this thread that is at risk of being swamped by not-useful information.

The thread summation and conclusion is in post #54.
schwa is offline  
Old 06-30-2014, 08:23 AM   #70
planetnine
Human being with feelings
 
planetnine's Avatar
 
Join Date: Oct 2007
Location: Lincoln, UK
Posts: 7,585
Default

Quote:
Originally Posted by richie43 View Post
I can see that this formerly useful thread has degraded into a "pissing match", which is unfortunate and silly.....
But I just downloaded the sample Reaper project and opened it. After loading the "ConvertedTo24bitInAudition" wav file and flipping the phase on it, these files nulled about as much as I have ever seen. I am unclear what the issue is then.

I think the issue was with the drivers for his particular interface Richie, you'd not encounter it without the same hardware and drivers...



>
planetnine is offline  
Old 06-30-2014, 10:22 AM   #71
Nystagmus
Human being with feelings
 
Nystagmus's Avatar
 
Join Date: Oct 2013
Posts: 509
Default

Quote:
Originally Posted by Justin View Post
To clarify:

This behavior is a bug in the Zoom ASIO driver -- it tells the host application that it is returning 32-bit integer samples, by setting the format to ASIOSTInt32LSB, and filling in the low 8 bits of each sample with various values. REAPER is merely interpreting the data as it should according to the spec.

The Zoom ASIO driver should probably either zero the low byte of each sample, or use the ASIOSTInt32LSB24 sample type.

We could work around this by treating ASIOSTInt32LSB as ASIOSTInt32LSB24, which is probably completely safe, however there is really no benefit (as these low bits are meaningless and should have no effect whatsoever when writing normal PCM data), and in theory if the state of the art of converters should improve, we could someday see meaningful bit depths of greater than 24 bits, which would then be lost.

TL;DR: Zoom driver is wrong, but without any consequence. We could fix on our end, but no real point.
bump to clarify what schwa just said (whole thread ended back at post #54)
Nystagmus is offline  
Old 06-30-2014, 10:30 AM   #72
AmmoniumNitrate
Banned
 
Join Date: Jul 2013
Posts: 493
Default

Quote:
Originally Posted by Nystagmus View Post
bump to clarify what schwa just said (whole thread ended back at post #54)
If the thread truly ended at #54, there's no danger in anyone reading past #54, so I don't understand the point of posts #69 and #71? When I read, I don't rely on anyone else to tell me what I should and should not read, and I trust other readers are equally as capable.
AmmoniumNitrate is offline  
Old 06-30-2014, 10:49 AM   #73
AmmoniumNitrate
Banned
 
Join Date: Jul 2013
Posts: 493
Default

Quote:
Originally Posted by alanofoz View Post
AL (that's me), post #40: I'll leave it to you to reverse the process. (i.e. convert back to float.)
AN, post #41: "He doesn't know how it should be done; but that isn't stopping him from accusing others of doing it wrong."

Taking the second part of that statement first, please tell me where I accused anyone of doing it wrong.
When you converted from 24-bit Int to 32-bit FP, and you deemed your own personal conversion-formula to be "correct", and you declared all alternative formulas "erroneous" and "noisy"...

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'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.
Quote:
Originally Posted by alanofoz View Post
Anything that deviates from a correct signal may certainly be referred to as errors or noise.
... and you made up pretend people to agree with you...

Quote:
Originally Posted by alanofoz View Post
Others before me have decided that years ago.

Last edited by AmmoniumNitrate; 06-30-2014 at 11:15 AM.
AmmoniumNitrate is offline  
Old 06-30-2014, 12:22 PM   #74
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 12,560
Default

Quote:
Originally Posted by schwa View Post
There is useful information in this thread that is at risk of being swamped by not-useful information.

The thread summation and conclusion is in post #54.
indeed, closing
Justin is online now  
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 03:57 PM.


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