Community Forums Archive

Go Back

Subject:About 64 bit sound processing ...
Posted by: ClipMan
Date:5/26/2012 9:00:40 PM

I copied this post from Chris, the developer/engineer of the Goldwave audio editor after getting bugged by users to upgrade his program/plugins to 64 bits. I wanted to share this:

"64-bit audio processing gives no noticeable improvement in quality, wastes twice as much storage space, and is slower to process. Even if you are using third party applications that support 64-bit processing, it's irrelevant because when the audio is recorded or played through hardware, the quality is reduced to 24 bit anyway. The most important concept that technical people overlook is the physical limits (of hardware and the human ear). Those limits make 64-bit processing pointless. So, yes, technically 64 bit processing is more precise than 32 bit processing, but practically it's a waste for audio. Even if the hardware existed, you wouldn't be able to upgrade your ears to hear that much dynamic range."

Brian

Subject:RE: About 64 bit sound processing ...
Reply by: b.complex
Date:5/26/2012 9:34:00 PM

What does this have to do with a 64 bit OS? NOTHING. When we are talking about upgrading to a 64bit OS, we are not talking about improved audio quality, we are talking about access to all of the RAM we have and talking about full access to the capabilities of our hardware and OS specs, not "audio quality" per se. I'm still recording at 16/48.


In fact, part of that statement makes no sense. How does a 16 bit 48KHz WAV file processed by 64 bit processing take up "twice as much space" as a 16bit 48 KHz WAV file that was processed by 32 bit processing? It doesn't. So, I don't see the point of this post. Methinks it is a bit of "apples and oranges". we are talking about processing speeds and OS efficiency, not "audio quality" when we speak of 64 bit processing.

Message last edited on5/26/2012 9:38:25 PM byb.complex.
Subject:RE: About 64 bit sound processing ...
Reply by: ClipMan
Date:5/26/2012 9:41:15 PM

@ .... What does this have to do with a 64 bit OS? NOTHING.

Nobody said it had to do with the OS. He's talking about audio processing. So am I. Get off your soapbox and read it again. If this information has no value to you, just scroll.

Brian

Subject:RE: About 64 bit sound processing ...
Reply by: ClipMan
Date:5/26/2012 10:03:37 PM

Looks like a lot of music/sound producers are looking for 64 bit programs to run their 64 bit plugins which, according to Chris, are totally impractical. Say it ain't so, bro. The software developers must be going nuts.

Brian

Subject:RE: About 64 bit sound processing ...
Reply by: b.complex
Date:5/26/2012 10:20:43 PM

By your second post it is CLEAR what your intention is with this post, and my intention is that you are missing the point. The ADVANTAGES that people are looking for with 64 bit processing are SPEED, EFFICENCY and the full use of RAM to run their systems more effectively.

It has nothing to do with sound quality issues. I don't expect things to sound "better" with 64 bit processing, only to get them done faster and be able to ge more use out of things like KONTAKT because of the ability to utilize all of my RAM.

If "Chris" doesn't get that, then "Chris" needs to join the real world.

Subject:RE: About 64 bit sound processing ...
Reply by: ClipMan
Date:5/26/2012 10:28:43 PM

@ ... my intention is that you are missing the point

Excuse me. I opened a thread to give readers some info about 64 bit signal processing. How could I be missing the point? Take your rants to another thread. This isn't about you or your problems. Go away, please.

Brian

Subject:RE: About 64 bit sound processing ...
Reply by: b.complex
Date:5/26/2012 11:21:46 PM

Hmmmm... Perhaps I'm mis-reading you, but by "sharing" information that states...and I quote, "Those limits make 64-bit processing pointless. So, yes, technically 64 bit processing is more precise than 32 bit processing, but practically it's a waste for audio. "

Let's not forget your follow-up: "Looks like a lot of music/sound producers are looking for 64 bit programs to run their 64 bit plugins which, according to Chris, are totally impractical."

Impractical??? Having 8 GB of RAM and only being able to use 3.5 Gigs of it is impractical.

It appears that you are making an argument against the popular request for ACID to become 64bit in the next release...mostly because you are "sharing" it on this particular forum.

If that is not the case, then would you care to explain why you are choosing to "share" (ahem) this wonderful insight?

Message last edited on5/26/2012 11:26:47 PM byb.complex.
Subject:RE: About 64 bit sound processing ...
Reply by: sodbuster-ca
Date:5/27/2012 10:14:07 PM

"In fact, part of that statement makes no sense. How does a 16 bit 48KHz WAV file processed by 64 bit processing take up "twice as much space" as a 16bit 48 KHz WAV file that was processed by 32 bit processing? It doesn't.

b.complex"


Yeah, I agree. But I think he (Chris from Goldwave) was talking about "temporary storage" (machine level code RAM) for data processing; not file size. (He is a software programmer, after all). That's the only thing that makes sense to me.

It is true that the larger the bit depth, the more temporary storage you need for processing the data. As I recall from one of my freshman engineering courses (over 40 years ago), the steps in writing machine code involve:
1 Fetching data
2 Storing data
3 Processing data
4 Storing the processing results

So, if your data words are 64 bits, then they will require more temporary storage space than 32 bit data words.

Internal OS processing bit depth has no affect on audio file size. As you know, audio file size for uncompressed .WAV's is a function of the audio sampling bit depth (8, 12, 16, 24-bit etc) and the audio sampling rate (44.1, 48, 96khz, etc.).

Message last edited on5/27/2012 10:38:35 PM bysodbuster-ca.
Subject:RE: About 64 bit sound processing ...
Reply by: sodbuster-ca
Date:5/27/2012 10:28:12 PM

"It appears that you are making an argument against the popular request for ACID to become 64bit in the next release...mostly because you are "sharing" it on this particular forum.

b.complex"


Yep...that's the way I see it too.

If that was indeed his motivation for posting that paragraph/statement here, then it appears to be taken out of context.

To view the statement posted by the OP in full context, you must see the forum discussion which precipitated his (Chris from Goldwave) response:
Goldwave Forum discussion

The question posted on the Goldwave forum was: "The best settings for saving an MP3 file?". As in the case with most forum discussions, someone ventured off-topic and started talking about 64-bit OS's. That's when Chris stepped in and made his statement re: 64-bit (in the context of Goldwave Editor & MP3's).

Looking at this strickly from a "Goldwave Editor" point of view there is no current advantage to developing a 64-bit version of Goldwave. In that, I agree with Chris (from Goldwave). (Goldwave costs $49 for lifetime upgrades. Chris's return-on-investment (ROI) for a 64-bit re-write would be minimal -- pretty much a waste of time; a lot of work for nothing).

From a Digital Audio Workstation (DAW) and a video Non-Linear Editor (NLE) point of view, there are numerous reasons for going 64-bit.

Most of the major Pro DAW developers have already gone 64-bit. Before long, they all will be 64-bit. I haven't done any research on this but I suspect that all of the major Pro NLE developers have already released 64-bit versions of their programs.

So ClipMan, what is the purpose is this so-called "info" you posted?

Message last edited on5/27/2012 11:51:33 PM bysodbuster-ca.
Subject:RE: About 64 bit sound processing ...
Reply by: Geoff_Wood
Date:5/28/2012 2:29:21 AM

Note that "64-bit processing" has zero to do with 64-bittiness of an OS or application. You can do "64-bit processing on an 8-bit computer.

Unfortunately everybody here is just going to get confused about what "64-bit processing" means. Including Mr Goldwave it seems, as he seems to have started the blurred line ....

geoff

Message last edited on5/28/2012 2:33:03 AM byGeoff_Wood.
Subject:RE: About 64 bit sound processing ...
Reply by: ClipMan
Date:5/28/2012 8:46:20 AM

@ ... So ClipMan, what is the purpose is this so-called "info" you posted?

Looks like you clever guys discovered my secret motives. I am an agent hired by software developers to thwart the desires of users. Congratulations. Nobody can call you guys idiots.

Brian

Subject:RE: About 64 bit sound processing ...
Reply by: sodbuster-ca
Date:5/28/2012 4:06:55 PM

..."You can do "64-bit processing on an 8-bit computer.

Geof_Wood"


Well, it depends on what you mean by "64-bit processing", doesn't it?

My old 8088 based PC had a slot for an 8087 Math CoProcessor. The 8087, which I bought for $20 bucks, was basically a 32/64-bit floating point processor (FPU). That 8088 PC still had an 8-bit architecture limiting it to a maximum of 256 addresses. (2^8 = 256).

..."Unfortunately everybody here is just going to get confused about what "64-bit processing" means. Including Mr Goldwave it seems, as he seems to have started the blurred line ....

Geof_Wood"


Why don't you explain to us what "64-bit processing" means so that "we" won't be so confused? Also, why don't you include the following in your discussion to give us a well rounded overview of computer Processing & Architecture:

a) Floating point vs Integer processing
b) The value of having a larger number of available registers
c) On-chip vs external data storage
d) Instruction set types/differences (throw in some Mac vs PC)
e) Parallel vs Serial processing
f) Parallel vs Serial data transmission
g) Physical address Extensions
h) Architecture advances over the years
i) Anything else that you think would enhance our collective knowledge base (you know, give us "The Works")

As far as your "Mr Goldwave" comment is concerned (I assume you're referring to Chris), he actually got it right. He could have used better terminology but once I read his statements in context, I understood what he was trying to say. He was simply discussing the discernible audio difference resulting from 64-bit floating point math vs 32-bit floating point math. He believes there is no discernible difference between the two. In doing a little research around the web, I found others who think they can hear a difference. I personally don't care.

What I do care about, along with others, is having the "Tools" available to utilize more than 4GB of RAM which would enhance the capacity of my software samplers and other RAM intensive applications. And THAT is an entirely different story! Which is what b.complex and myself were trying to explain the "ClipMan".

Geoff, maybe you can explain it to him. Yes, maybe?

Message last edited on5/28/2012 4:52:05 PM bysodbuster-ca.
Subject:RE: About 64 bit sound processing ...
Reply by: sodbuster-ca
Date:5/28/2012 4:48:59 PM

"Looks like you clever guys discovered my secret motives... Nobody can call you guys idiots.

Clipman"


In comparison to you? Definitely not!

So ClipMan, you gonna' answer the question?

Subject:RE: About 64 bit sound processing ...
Reply by: Geoff_Wood
Date:5/28/2012 10:59:35 PM

64-bit processing is the mathematical model used for internally processing the data during calculations and rpesumably temp files.

It has nothing to do with the OS or application or plugin 'bitness'. Yes, your GPU in your 8-bit PC was potentially doing "64-bit processing".

And equally a 64 bit app in a 64-bit operating system can use "8,9, 15 (etc)-bit processing", if that's the app's design.

Clear enough ?

As to whether or not there is a preceivable sound improvement, I doubt it too. But if it's there and easily achievable, so why not use it ? Especially if everybody is going to be fretting and demanding it because some other app uses it - yet another big distraction....

geoff

Message last edited on5/29/2012 7:23:28 PM byGeoff_Wood.
Subject:RE: About 64 bit sound processing ...
Reply by: b.complex
Date:5/29/2012 7:33:42 AM

sodbuster -

Thanks for clearing that up. In the context of what you posted, it looks like "Chris" was taken out of context and re-purposed for Clipman's crusade against 64-bit processing. Also:

"What I do care about, along with others, is having the "Tools" available to utilize more than 4GB of RAM which would enhance the capacity of my software samplers and other RAM intensive applications. And THAT is an entirely different story! Which is what b.complex and myself were trying to explain the "ClipMan".

You have that right. I'm not expecting some kind of leap in "audio quality" - which is what it seems that clipman mistakenly is assuming people are looking for in 64 bit processing - I, personally (and it seems most people interested in this conversation) am just looking to get the most out of my applications and fulfill the promise of a 64-bit OS.


Subject:RE: About 64 bit sound processing ...
Reply by: Chienworks
Date:5/29/2012 11:17:15 AM

"That 8088 PC still had an 8-bit architecture limiting it to a maximum of 256 addresses. (2^8 = 256)."

The classical 8 bit chips used a "word" of 2 bytes for addressing resulting in a memory space of 65536 addresses, not 256. The 8000 series architecture in fact allowed another byte for paging, resulting in 256 sets of 65536 (64K) addresses for up to 16MB, though most of the motherboards utilizing it had a practical limit on the buss of 4MB. DOS around version 3 would only access 1MB, with the top 384KB reserved for system functions, leaving 640KB for the software to use.

However, all that aside, math functions have always been able to use as many bits as the programmers cared to allot. On my old Apple // 6502 8 bit computer i wrote many assembly language routines that used a very large number of bytes for the operands and results. I was routinely doing 256 or even 512 bit floating precision on my scientific calculations. The CPU could only work on 8 bits at a time, but it was easy to store the first part of the result and move on to the next 8 bits. We humans do the same thing with base 10 mathematics on paper: adding/multiplying/etc one digit with one other digit at a time, writing down the temporary result, carrying/borrowing as necessary, then moving to the next digit.

I recall that Microsoft's BASIC used 40 bits for the double precision variables. Some of the other languages i've used considered 40 bits to be single precision and used 80 bits for double. And all these ran on 8 bit 8088 chips under DOS 2 & 3.

The problem in this thread is the confusion between calculation precision size and memory addressing size. They're not related. Consider that Sound Forge was doing 32 bit floating calculations back under 8/16 bit chips, and is still doing 32 bit floating calculations under 64 bit chips.

Go Back