http://www.theregister.co.uk/content/4/35348.html

Rabid 64-bit computing fans can now pick up a trial version of Windows XP 64-bit Edition via CD or download off this Microsoft site. The pre-release software is good for 360 days and gives customers with an AMD64-based PC or laptop a chance to test the OS. The bra has come off, but you'll have to wait to see the pasties hit the floor ....

So its gonna be soon that those new AMDs are gonna fly ...

So who is going to be the first VST/VSTi developer or sequencer developer to state how great 64 bit is and how much speed boost we are all going to obtain ?

Tachikoma.

Well, it'll be useful if you want to memory map a 10G sample library, but otherwise it's a bit irrelevant.

Now 64-bit VST. That's gonna be huge.

Ah, pretty soon we'll finally have 64bit mixbus. If you're serious into mixing, 32bit's isn't enough, which is also why luxury studios still rely on analog summing. 64bits will eventually help cure that.

Also, finally we'll have real 64bit accuracy for all plugin calculations. I mean, it's a fact some TDM plugs can sounds subtly better to 32bit nativebecause of the 48bit interger math involved. Naturally 64bit means even less truncation.

Differences will be too subtle for prosumers though..

Phaedo wrote:

Well, it'll be useful if you want to memory map a 10G sample library, but otherwise it's a bit irrelevant. Now 64-bit VST. That's gonna be huge.

Oh, especially VST would profit from using 64 bit floating point instead of the current 32 bit float used.

32 bit float has it's weaknesses. It's nothing but a compromise. In fact, even 32 bit integer is more accurate than using 32 bit floats, because they need to squeeze exponent and mantissa into 4 bytes.

Developers "favor" floats over doubles (64 bit floating point numbers) just for efficiency reasons: 32 bit data can be transferred over the 32 bit bus in one bus-cycle, but it's inaccurate as hell.

If developers had a 64 bit bus, they would just use double precision floats (the FPU computes everything in 80 bits anyway), which then would be as fast as processing single precision floats now.

Of course this inaccuracy cannot be percieved when listening to a single effect or sample.

But when mixing many busses / channels / effects, or processing audio many times, the inaccuracies eventually will sum up.

So yes, 64 bit would be HUGE for VST.

Kingston wrote:

Differences will be too subtle for prosumers though..

D'you know jonas?

Not all developers favour 32-bit floats over 64-bit double-precision floats....

Regards
Dave
Muon Software Ltd
www.muon-software.com

Personally, I hope floats stay 32 bits and doubles 64, and we get a new type "quad".

Otherwise some serialization/encryption/compression stuff I wrote last year is prolly gonna break in 64-bit compilers... and I don't want to have to look at that code ever again.

Muon Software Ltd wrote:

Not all developers favour 32-bit floats over 64-bit double-precision floats.... Regards Dave Muon Software Ltd www.muon-software.com

Sure Dave,

of course not all...

This subject is probably beyond my ken but here goes:

Doesn't 32bit offer enough bits to end the problem of clipping in audio? If that's the case then I can only imagine that 64bit refines this process rather than offers new advantages.

I can't imagine that the onward progress of computing will ever end but how many more bytes do we need? Disk space is ever increasing along with bandwidth but still music (and most media) is transfered over the net in compressed formats and is distributed in 16bit format. Consumers appear happy with this and I wonder how long it will take for this to change?

My issue with higher bit levels is the need for computation power and disk space to handle these increases. Not to mention the redundancy of 32bit software and the hardware that handles it. 32bit already offers excellent quality IMO so where does it all end?

/checks credit balance and weeps /

Whatever floats your boat

It's not really clipping that is the concern, it is the accuracy of intermediate calculations.

This is because binary floating point representations are only approximations - if you look at what gets stored in memory when you put 1.0/3.0 into a 64 bit float compared to what gets stored from the same calculation when the result is a 32 bit float you will clearly see that you have gained some accuracy by using the extra bits for storage.

When you have lots and lots of calculations in a row it is better to make sure all intermediate results are stored with as much accuracy as possible IMHO. The performance implications aren't as onerous as you might think either.

Regards
Dave

From what I am hearing, going to 64 can actually slow things down a bit. The computer will not only be processing words of twice the size, but storing them in memory and moving them across busses. Bottlenecks may appear in some systems.

Robert

Quote:

If you're serious into mixing, 32bit's isn't enough,

wake up, 64bit is not enough. 512bit or nothing! 64bit is so amateurish..

I'm sure you're of those newbies who still mix at 96khz? lol, pro's only do 384khz.

safeaim wrote:

Whatever floats your boat

boo!


uhmm.. my only REAL concern with 64-bit systems/software are.. will most developers CHARGE for an update to make existing software take advantage of the extra bits.. and if so does anyone have an idea or thought on if it will be a small fee or a significant amount?

Quote:

my only REAL concern with 64-bit systems/software are.. will most developers CHARGE for an update to make existing software take advantage of the extra bits

the rule is $4 per bit, so you should expect $128 upgrades.
Bits have a high production cost you know. Each bit is carefully handcrafted by little Swiss kids. Say no to bits made in china - those don't sound good. I mean, did you ever see a pro using bits made in china?

the poor little kids working in sweatshops, handcrafting the extra bits.. wow I never thought of it that way..

okay i'll fork over my lifesavings now for the software upgrade.

but seriously.. are fees for 64bit versions of software a probable situation?


will you (gol) charge fees to upgrade to 64bit versions of your software when/if they are created?

what about the port from 32 to 64 bits.. is there much involved?

Well, as you know, ImageLine have a lifetime free updates policy so I think your safe with Fruity but you'll probably find that most dev's will just include the 64-bit stuff within a normal upgrade so it will come down to their general upgrade policy, I imagine.

I don't get all this hype on a 64bit processor. We had SSE2 instructions for a long time now, and guess what they do? Process double numbers. (64 bits = double, 32 bits = float) Or am I getting something wrong here?

Also, there are several VSTs and Hosts that already do things on 64 bits, but they use double the cycles for that. Those are going to run much faster on a 64 bits processor, but only after they recompile it without spliting all double values into 2 floats...

Wk

I think I read the Sonalksis EQ uses 64 bit floating point. Could anybody explain if and what difference would a 64 bit environment make to plugins that already use 64bit floating point?

I just explained that above, it would run faster. Double the speed on some cases.

Example:

You have a 64 bits number, on a 32 bits processor. The ASM code will split the number into 2 numbers and use 2 CPU cycles to compute whatever you need. In some cases, even more than 2 CPU cycles.

On a 64 bit processor you don't need that anymore. BUT I'm pretty sure that you need to recompile the aplication, since I don't know if the processor sees the procedure for doing a 64 bits number and just don't "split" the number anymore... this I don't know.

Also, keep in mind that SSE2, that Pentium-4 machines have, already does 64 bits MATH and you can even do 4 numbers at a time, blazingly fast...

So the 64 bit thing is more a hype to my eyes. But there is a good thing, now AMD processors also have SSE2, before the didn't...

Wk

There will not changing sooo much for coding DSP.


AMD Athlon™ 64
Processor
Compatible with Existing 32-Bit Code Base
– Including support for SSE, SSE2, MMX™,
3DNow!™ technology and legacy x86 instructions
– Runs existing operating systems and drivers
– Local APIC on-chip

• AMD64 Technology
– AMD64 technology instruction set extensions
– 64-bit integer registers, 48-bit virtual addresses,
40-bit physical addresses
– Eight new 64-bit integer registers (16 total)
– Eight new 128-bit SSE/SSE2 registers (16 total)


As You can see, there is alot new "integer" stuff on 64 bit processors. Not so much new for "normal" floating point performing.

The only interesting of all this is the double amount of SSE/2 registers. Theoretically this would mean double performance, but...

SSE/2 must be explicitely programmed with the special instruction sets. Only very less audio plugins use this actually. It's not usfull for all kind of audio algorithms, because many audio processes cannot perform in parallel (i.e serial filter poles). SSE processes conceptually parallel.

But if they can use it (i.e. mixers or other parallel vector calculations), the speed increase may be significant.

WilliamK wrote:

I just explained that above, it would run faster. Double the speed on some cases. Example: You have a 64 bits number, on a 32 bits processor. The ASM code will split the number into 2 numbers and use 2 CPU cycles to compute whatever you need. In some cases, even more than 2 CPU cycles. On a 64 bit processor you don't need that anymore. BUT I'm pretty sure that you need to recompile the aplication, since I don't know if the processor sees the procedure for doing a 64 bits number and just don't "split" the number anymore... this I don't know. Also, keep in mind that SSE2, that Pentium-4 machines have, already does 64 bits MATH and you can even do 4 numbers at a time, blazingly fast... So the 64 bit thing is more a hype to my eyes. But there is a good thing, now AMD processors also have SSE2, before the didn't... Wk

Not exactly,

- FPU registers have (traditionally) 80bit precision,
- SSE/2 has internally 128bit on 32bit processors already.
- Calculation of 64bit numbers (integers) is also already possible with (old) MMX instruction sets on Intel 32bit procesors.

The point is, that the so called 64bit processors are designed for 64bit bus architecture. So the data transfer from and to the processor will be much faster due the higher bandwidth.

The internal precision is already very high on 32bit processors. The precision of calculations inside a 64bit processor will not change, as far as I can see.

Quote:

will you (gol) charge fees to upgrade to 64bit versions of your software when/if they are created?

I don't think I will soon use 64bit floats in my inner loops. I'll probably do in 5 years or so, when everyone will have a 64bit CPU.

That's unless too many people start believing in that 64bit hype bullshit [really, it is. Of course people who advertise '64bit processing' as a feature of their plugin will tell you otherwise].
If something like 'FL sucks, it only processes in 32bit' or 'IL is stubborn not willing to switch to 64bit', we'd better take their money & let them use slower code, if it's what they want.

You'll be explained that 'doing stuff in 32bit float shows a loss'. Big deal, as if 64bit was lossless.. There will always be a loss, 64bit, 128bit, or 1billion bits, as long as it's digital. The question is when is it enough? If you have some basic programming skills, try performing a lot [as they say] of operations on 32bit floats, check the average loss & judge if you can hear the loss.

Quote:

what about the port from 32 to 64 bits.. is there much involved?

If it's plain high-level code, it's usually nothing more than a change in the variable declaration, & some minor things. If it's assembler, it can get more complex, but not much.
For 64bit CPU's will also depend on how they work. I remember when the switch from 16bit to 32bit was done, 16bit accesses then became slower because there was a 'code switch' to be added before them, when your code was set as being 32bit (both can still exist). If it happens to be the same for 64bit, I can imagine that 32bit accesses would then be slower in favor of 64bit. That or (more likely) 8bit accesses, which are still as fast as 32bit today (with some exceptions).

As someone wrote above, the FPU is *already* working on 80bit (with some switchable exceptions) internally, which is more than 64bit.
When you work in tight asm code, you can do stuff with a 80bit precision, without losing speed. You only lose some speed when you read/write from/to 64bit memory parts. You only do a lot of read/write to memory in complex loops, because there are only 8 FPU registers & they're quickly all used.

& btw the good thing with 64bit CPU's (at least AMD's) is that they will extend the number of registers, both integer & float, & that will help a lot speeding up more complex inner loops.

Kingston wrote:

Also, finally we'll have real 64bit accuracy for all plugin calculations. I mean, it's a fact some TDM plugs can sounds subtly better to 32bit nativebecause of the 48bit interger math involved. Naturally 64bit means even less truncation. Differences will be too subtle for prosumers though..

So with all that's being said, some native plugins are already using 64bit precision so does that mean that the TDM being better than Native debate is all hot air? Is it just a case of the plugin developer choosing to use a few more of our native cpu cycles?

Quote:

wake up, 64bit is not enough. 512bit or nothing! 64bit is so amateurish.. I'm sure you're of those newbies who still mix at 96khz? lol, pro's only do 384khz.

gol, I suppose you're finding yourself funny, but I think you oughta do some serious A/Bing between 32mixbus (pretty much any DAW) and properly set up analog summing. The difference is fairly obvious, provided you are in a good monitoring environment... Also note the (usually) 48bit summing in luxury digital desks...

Even if this whole 64bits thing is too much hyping, it'll still be easier to implement a 64bit bus now.

Quote:

So with all that's being said, some native plugins are already using 64bit precision so does that mean that the TDM being better than Native debate is all hot air? Is it just a case of the plugin developer choosing to use a few more of our native cpu cycles?

Its a dead debate in a way. I was just referring to waves plugins and the way they're coded. There is a subtle difference (TDM is better). I mailed waves and asked why and got two replies (marketing replied that there is no difference, LOL). R'n'D said it comes down to the 48bit integer based DSP in the motorola chips and the 32bit floats used in native environments.

Makes you wonder why they didn't opt for 64bit float precision in native environments like so many other developers... (suppose they concidered it a reasonable trade off between quality and efficiency)

Quote:

gol, I suppose you're finding yourself funny,

sometimes yes, but this was more 'sad-sarcasm' than 'funny-sarcasm'

Quote:

but I think you oughta do some serious A/Bing between 32mixbus (pretty much any DAW) and properly set up analog summing. The difference is fairly obvious, provided you are in a good monitoring environment...

I'm sure someone did those obvious tests already, do you have any link or ref?

wait.. I thought you were talking about differences between 32bit float mixing & 64bit float mixing, but you say analog? Wether it'd be true or not, all it'd prove is that the (or one) analog mixing is different, & that wouldn't even explain the reason. But what does this prove as for 64bit processing?

Quote:

Makes you wonder why they didn't opt for 64bit float precision in native environments like so many other developers

the first question is to know wether it's the developers or the marketing that opts for 64bit float precision

Quote:

I'm sure someone did those obvious tests already, do you have any link or ref?

www.gearslutz.com

there's miles of forum discussions on this topic, along with audio examples. (from seasoned analog purists viewpoint though...)

Quote:

wait.. I thought you were talking about differences between 32bit float mixing & 64bit float mixing, but you say analog? Wether it'd be true or not, all it'd prove is that the (or one) analog mixing is different, & that wouldn't even explain the reason. But what does this prove as for 64bit processing?

gol, the difference between 32bit summing and 48bit summing can be easily heard. Try the Sony DMX mixers for example. Of course, with 64bit summing, it would be even more obvious.

That's also why I keep referring to analog summing, it simply has "infinite" accuracy. (usually with higher noise floor, or colored gain stages)

The same rules apply to calculations in plugin kernels. (obviously)

gol wrote:

Quote: my only REAL concern with 64-bit systems/software are.. will most developers CHARGE for an update to make existing software take advantage of the extra bits the rule is $4 per bit, so you should expect $128 upgrades. Bits have a high production cost you know. Each bit is carefully handcrafted by little Swiss kids. Say no to bits made in china - those don't sound good. I mean, did you ever see a pro using bits made in china?

-now I have wet pants

agent 007 wrote:

WilliamK wrote: I just explained that above, it would run faster. Double the speed on some cases. Example: ..... Wk Not exactly, - FPU registers have (traditionally) 80bit precision,

Yes, fpu arithmetic will be no diferant. What should benefit is speed of storing/loading fpu registers. However this is likely to be small cause a good optimizer (human or compiler) will minimize loading and storing and try and keep as much as posible in the fpu registers.

Quote:

- SSE/2 has internally 128bit on 32bit processors already.

I dont think there is any change to SSE. However they dont actualy use 128 bit floating point. They can work on 4 32 bit floats or 2 64 bit doubles. Ie. 128 bit data packets, not 128 bit floats.

Quote:

- Calculation of 64bit numbers (integers) is also already possible with (old) MMX instruction sets on Intel 32bit procesors.

Nope, they act on multiple 32,16 or 8 bit numbers. The only 64 bit ops are the mmx boolean operators. In fact the mmmx multiply only works on 16 bit numbers, it just does 4 at once. And it takes 3 cycles, so the benefits are not always, 4 times the data 4 times the perfomance.

Quote:

The point is, that the so called 64bit processors are designed for 64bit bus architecture. So the data transfer from and to the processor will be much faster due the higher bandwidth.

Yes, i think people missunderstand that 64 bit architechre is primarily needed for a larger address space and not the abilty to do 64 bit integer math.

Quote:

The internal precision is already very high on 32bit processors. The precision of calculations inside a 64bit processor will not change, as far as I can see.

All that changes is we now hav 64 bit integer arithmetic, 64 bit pointers. 64 bit integer math is hardly ever ever needed anyway. And some extra registers IIRC.

What has improved (At least for AMD) imensely is the system bus. Its faster, larger bandwidth, can transmit & recieve at the same time and some chips have two channels. The memory controler is now on the cpu die which means it can work better with the cpu.

chris

cbenci wrote:

I think I read the Sonalksis EQ uses 64 bit floating point. Could anybody explain if and what difference would a 64 bit environment make to plugins that already use 64bit floating point?

The performance hit for 64 bit floats is purely to do with memory overhead. Twice as much memory used, cache misses can cost more, twice the amount of data going across the system bus.

64 bit cpus should improve this only because they have wider and faster system bus. They will reduce the memory overhead no speed up any of the arithmetic.

chris

nollock wrote:

Quote: - SSE/2 has internally 128bit on 32bit processors already. I dont think there is any change to SSE. However they dont actualy use 128 bit floating point. They can work on 4 32 bit floats or 2 64 bit doubles. Ie. 128 bit data packets, not 128 bit floats. Quote: - Calculation of 64bit numbers (integers) is also already possible with (old) MMX instruction sets on Intel 32bit procesors. Nope, they act on multiple 32,16 or 8 bit numbers. The only 64 bit ops are the mmx boolean operators. In fact the mmmx multiply only works on 16 bit numbers, it just does 4 at once. And it takes 3 cycles, so the benefits are not always, 4 times the data 4 times the perfomance. chris

You are right, if You use only the inbuilt instruction sets.
But You can actually use the registers in your way if you program in assembler.

Remember: The very first floating point assembler libraries were also designed on 16 bit processors, in fact they have used 16bit registers to simulate a 128bit FPU completely in software. Of course the performance was bad with this, but the precision was excellent.

OK, this is pure "scientific arithmetics". But actually possible with the current registers.

It's inevitable - 64bit processing and software will take over and we'll all have to upgrade eventually. OMG! More expense down the road.

agent 007 wrote:

nollock wrote: Nope, they act on multiple 32,16 or 8 bit numbers. The only 64 bit ops are the mmx boolean operators. In fact the mmmx multiply only works on 16 bit numbers, it just does 4 at once. And it takes 3 cycles, so the benefits are not always, 4 times the data 4 times the perfomance. chris You are right, if You use only the inbuilt instruction sets. But You can actually use the registers in your way if you program in assembler.

I have been using mmx assembler for years. Here is the problem...

There is no way handle arithmetic overflow. If you add two 32 bit numbers together with mmx there is no way to handle the situation where the result needs 33 bits to represent it. With the normal ALU there is the carry flag which would be set to represent the 33rd bit. Hence the ADC instruction for add with carry.

Quote:

Remember: The very first floating point assembler libraries were also designed on 16 bit processors, in fact they have used 16bit registers to simulate a 128bit FPU completely in software. Of course the performance was bad with this, but the precision was excellent.

Yes because the normal ALU has the carry flag, normal ALU instructions affect the CPU flags so you can branch and compare registers. There are no mmx instructions for that, it just isnt posible.

Quote:

OK, this is pure "scientific arithmetics". But actually possible with the current registers.

With the normal ALU instructions, not MMX.

MMX is tiny specialised instruction set. What your sugesting is like saying you could build a house with just a screwdriver.

chris

64bits ... which makes me wonder when will summing busses get 64 precision and when will rme's totalmix offer 80bit mixing precision.

erm - will I have to upgrade pickups as well ..
and cables and stuff?

Quote:

gol, the difference between 32bit summing and 48bit summing can be easily heard.

Just for the fun of it, I mixed 10.000 sines (took some time) as temporary 32bit & 64bit floats, to test. I add both values, then divide by 2. That's 10.000 additions (sum) & divisions (amp) (2 things you do when you mix things together), done while storing results in temporary single & double floats. I then output the result to 16bit files (if you have bandwidth to waste, you can still redo this test & save as 64bit waves, if they exist).

The files are here:
http://www.flstudio.com/gol/Sine_32bit.wavhttp://www.flstudio.com/gol/ Sine_64bit.wav

I didn't even bother to check if they were 100% the same (they probably weren't before the conversion to 16bit I guess).

Now all this proves is that it should be pretty safe & accurate to mix 10.000 signals in a mixer, & you were talking about mixing.

I'm sure some here think they have a valid point to do some things in 64bit. In filters or FFT's for ex. I'd be glad to hear something from them. I mean hear, not math examples. I think it's pretty clear & obvious for everyone that extra bits aren't vapor, they do give more accuracy. But people are probably more interested in whether they can notice a difference between specific DSP done with 32 or 64bit. There must be some obvious examples, so please educate (so far we only got marketing).

Quote:

Try the Sony DMX mixers for example. Of course, with 64bit summing, it would be even more obvious.

how do you know the difference is due to the difference in bit depth?

Quote:

how do you know the difference is due to the difference in bit depth?

I don't of course, but I can ask the people who actually designed this desk. Give me a week or so. They won't (of course) give any specific details, but probably some insight on why they chose 48bits just for the final summing stage (before final dither). that is what the manual states anyway, the rest is of it is 24bits, if memory serves me correctly. (It's all based on a certain Sharc DSP chip, I'll check)

Ah, 32 / 40 bit precision actually (from the manual).

Also, in your test, the 16bit output files pretty much null the differences. We are talking about hi-grade audio afterall. And next time, do the test with real (recorded) material recorded in a good environment (good preamps/AD/DA). And I couldn't stress good monitors and experienced ears enough.

Or are you one of those people who can't hear the difference between even 16bit vs 24bits? You even yourself wanted to "hear, not math examples". Why this rather theoretical sine example then?

Sounds to me like you're a coder, which in this case would amount to a blind person guiding the deaf... (no offence, I know my limits)

In case you want clear evidence on the *audible* differences between different summing stages, bitdepths etc. there's a recent CD (called DAWsum I think) by the people who also do those mic/preamp/AD/DA shootout CDs.

Do a search on www.gearslutz.com, plenty of discussion there.

The general concensus on the subject seems to be that while you can get great results in any recent DAWs, the highest quality still requires analog summing, or higher bitrates, which is why there're things like the Dangerous 2 Bus, or the Sony DMX's (I'm sure oxford range as well) summing stage.

Quote:

Also, in your test, the 16bit output files pretty much null the differences.

I told you, if you have some basic programming skills & some bandwidth to waste, you can post the same results as 32 or 64bit wave files.

Quote:

Or are you one of those people who can't hear the difference between even 16bit vs 24bits?

Exactly. In fact, I don't think anyone does/can. I think there are some who can make the tests themselves, & realize they can't hear the diff, & others who rely on falsified results from someone else, & think that the different coloration they hear is the result of a different bit depth.
I don't want you to trust me but rather make the tests yourself. & not just by using different pieces of hardware, & conclude that the different coloration is obviously due to one specific feature.

Note: I don't totally diss the 24bit hype. For recording, it IS useful. But I find it a pity that in such a said 'pro' domain, you find the same 'more bits=better' hype as with game consoles.

Quote:

Why this rather theoretical sine example then?

well it's obvious:
-it needs to be something
-what else is more likely to show you inaccuracies than a pure sine? not a noisy drumloop I guess..

Thanks for doing that test, Gol.

Personally, I'm guessing that 32-bit, floating-point summing most likely is not a big bottleneck for most people in terms of getting desired results in music creation!

Quote:

Exactly. In fact, I don't think anyone does/can. I think there are some who can make the tests themselves, & realize they can't hear the diff, & others who rely on falsified results from someone else, & think that the different coloration they hear is the result of a different bit depth. I don't want you to trust me but rather make the tests yourself. & not just by using different pieces of hardware, & conclude that the different coloration is obviously due to one specific feature.

should've known better not to enter this type of argument with a person who can't tell the difference between 16bit/24bit audio... *sigh*

I'd like to stress that I come from an audiophile background, and I really *do* hear these things. I've done countless of blind tests on similar subtle things.

Quote:

well it's obvious: -it needs to be something -what else is more likely to show you inaccuracies than a pure sine? not a noisy drumloop I guess..

noisy drumloop certainly wouldn't help, but I was talking about extremely hi quality audio here. Some of us are already taking the steps forward from 16bit/44.1khz, you know..

Also, these subtle differences manifest themselves much easier on realworld material, on sounds that our ears are more used to hearing. More natural ambiences and more solid imaging are the things that you hear first when going to higher bitrates.

Things like average ADC and preamps null the benefits of higher bitrates though... Which is the case probably more than 90% of the time.

I think lots of the kvr user base shouldn't even bother with this stuff. Most would just end up wasting bandwidth, with no audible benefits.

Quote:

Personally, I'm guessing that 32-bit, floating-point summing most likely is not a big bottleneck for most people in terms of getting desired results in music creation!

Certainly true.

VitaminD, in answer to your earlier question, during the transition period from 32 to 64, developers generally have 2 choices: (A) Put both editions in one box, for one price, or (B) sell separate boxes, one for 32-bit and one for 64-bit.

The vast majority of developers will choose option (A), because it is more expensive for them to create separate SKU's for each flavor. So, you'll get your upgrade to 64 bits for "free", but the package might be more expensive for everyone, if they have to include 2 CD's, or DVD's, or whatever. A few developers (usually with high-end or very large products) will take option B (the separate-box route). At that point, it is possible to charge differently for each flavor, but I don't think you'll see wild differences. Then it's up to you to choose which product you buy.

At some point (prolly years from now), developers will stop supporting 32-bit systems altogether. You may still be able to get along if the 64-bit OS will run on 32-bit systems (with a "translation layer"), but I have heard no news of this regarding the new Microsoft OS.

BTW, Intel is finally going to acknowledge that AMD has the right idea, and are going to talk about their 32/64 bit plans at their developer conference later in February. This won't be about Itanium, but instead they'll explain how they'll add 64-bit extensions into their current line of 32-bit chips (just like AMD). There are a lot of rumors that they'll use *exactly* the same instruction set that AMD uses. If they don't, you'll need yet another 64-bit OS (and it will split the software development world too.... you'd have *2* flavors of 64-bit software). Since Microsoft already has 2 64-bit OS'es in the works (Itanium and AMD), the rumors say that they are not willing to make yet another. Intel will have to pick one of the existing ones, which really means they'll be stuck with AMD. The rumors further state that the current Intel chips may well contain this new 64-bit support, but disabled. That would explain why the Prescott chips were late, slow, and hot. There are precedents for introducing features in this way.... 64-bit would be enabled in the next releases, in another 6 months or so. In any case, we should know by the end of February. If Intel jumps into the 64-bit game, then the transition will obviously happen a *whole* lot quicker than if it was just AMD, and we'll see lots of 64-bit software, say, within the next year or so. If not, and it is only AMD, then it'll take years for all the software devs to jumpon board.

Quote:

Some of us are already taking the steps forward from 16bit/44.1khz, you know..

I should have realized that everything goes faster these days, even natural selection..

Quote:

I'd like to stress that I come from an audiophile background, and I really *do* hear these things. I've done countless of blind tests on similar subtle things.

I'm sure you do hear differences. But as long as you're only on the listener side, you can't be sure of the real cause of those differences.

I think one thing that gets overlooked is that you require the extra acuuracy for when you do things like compressing a sound - the inaccuracies that you would not normally have heard become more obvious. Also, things like state variable filters seriously benefit from increased accuracy because truncation builds up as more iterations of the algorithm are processed.
I wrote a simple IIR filter using integer math for filtering a supply voltage reasding of an embedded IC the other day - it is remarkable how much difference a couple bits of acuracy affects an IIR - the rounding errors really creep in.

gol you do come off as a smug twat - but then im assuming english isnt your native language soooo

dvd-a and sacd allow you to play the old cd layer too
if when you switch from one to another you cannot hear the difference you have a hearing problem - consult a doctor

and while it might be something other than the difference in bit depth and sample rate (i suspect the latter) you would think if there was some miracle way of making things sound better they would use it on ole vanilla CD.

mind you both of these only use 24 bit - and the limit to the quality of that is the playback equipment - ie stereo speakers etc

So ultimately 64 bit mixing seems excessive - but 64 bit inside plug-ins ???

ericj23 wrote:

So ultimately 64 bit mixing seems excessive - but 64 bit inside plug-ins ???

I reckon it is necessary for iterative processes.

Quote:

if when you switch from one to another you cannot hear the difference you have a hearing problem - consult a doctor

can you please post 2 example waves (16 & 24bit of the same audio source, as you wrote). I'd really like to believe in it you know.

Quote:

and while it might be something other than the difference in bit depth and sample rate (i suspect the latter) you would think if there was some miracle way of making things sound better they would use it on ole vanilla CD.

they would, if they didn't intend to sell you audio DVD's

Quote:

That's also why I keep referring to analog summing, it simply has "infinite" accuracy. (usually with higher noise floor, or colored gain stages)

Infinite is a mathematical term. A concept that it's impossible to conceive as real in our universe. There's no infinite things, otherwise, from my point of view, something "infinite" in our universe would lead it to dissapear, erroneous, or make it -static-.

If distance between 2 universe points is infinitelly divisible, we couldnt move!.

I would prefer to think we live in a discrete universe..., but well, i dont know a a shit about physics.


Btw: I agree with gol.


After all, i doubt anyone of us have even a "96dB-ideal" (16bits!) dynamic range monitoring.

Mine is like 38dB with the bedroom windows closed and a average, non-disturb-my-neighbourgh volume. =).

...arguru needs bed now...

ericj23 wrote:

dvd-a and sacd allow you to play the old cd layer too if when you switch from one to another you cannot hear the difference you have a hearing problem - consult a doctor

Who says that they didn't make the old CD layer look really worse on purpose? I mean, if there wouldn't be a real difference, who would buy SACD of DVD audio? So I don't think it's a fair test.

Green Red Brownell wrote:

The rumors further state that the current Intel chips may well contain this new 64-bit support, but disabled.

Correct. There are rumors that this 64 bit instruction set isn't compatible with AMD's, so if they even wanted to enable it, it wouldn't make much sense.

Green Red Brownell wrote:

That would explain why the Prescott chips were late, slow, and hot.

Late? No, that's due to problems with the new 0.09 micron process. Slow? No, that's mostly due to the much longer pipeline. Hot? No, the 64-bit part isn't even actively working and therefore it's an excellent thermal conductor. The reason of its huge power consuming behaviour is the big raise in current leaks, which are caused by the new 0.09 micron process.

Just to make some things more clear. The rest of your story was very true.

arguru wrote:

After all, i doubt anyone of us have even a "96dB-ideal" (16bits!) dynamic range monitoring. Mine is like 38dB with the bedroom windows closed and a average, non-disturb-my-neighbourgh volume. =).

I don't really think thats the point. Calculation error gets inflated as you use more complex processing.

If you use a limiter and increase the signal level by 6dB's, then stuff that you wouldn't have originally heard becomes audiable.

It is also easy to hear the improvement in filtering of a 96KHz source than of a 44.1KHz source.

Whilst at the end of the day 16bit 44.1KHz is good enough for the final product, during development you should work at a higher resolution.
If you don't, then your music will not sound as good as it could do.

The same goes for graphics (unless you are designing pixel accurate stuff, which doesn't really apply to audio).

Exactly, arguru, you kind of missed the point and I agree in the point you made but in a host that does complex mixing of over 30 tracks you definately will hear a difference especially if you use lots of plugins. Btw. Bob Katz has some very enlightening text about this subject in his book 'Mastering Audio'. However, he does come out as slightly biased towards digital systems (seriously! ).

Anyways, in a realworld mixing system with more than 30 tracks and atleast 20 plugins rounding errors get passed on to another stage where the original data is again rounded wrong etc. So, of course a higher internal precision will help AND is definately audible to you guys too. I'll try to make you folks some audio examples in school at some point where we have PT HD and Logic on a G5. I can run a PT HD mixdown and a Logic running a different hardware so that it's 32bit float (PT is 48 bit fixed).

Cheers!
bManic

Quote:

The same goes for graphics (unless you are designing pixel accurate stuff, which doesn't really apply to audio).

except that the standard (for 2D) is still photoshop today.. which works exclusively with 3x8bit RGB. And it's definitely NOT enough, you can easily see inaccuracies stack with layers. But if even people in publication don't care, it probably means it's not important. Personally when photoshop with start supporting everything in its 3x16bit mode, I'll be happy & never think that 16bit isn't enough. 3x8bit for the final product, 3x16bit to build it..

Quote:

Anyways, in a realworld mixing system with more than 30 tracks and atleast 20 plugins rounding errors get passed on to another stage where the original data is again rounded wrong etc.

you could just grab some compiler & do the basic 10.000 sine mixing test I did..

Quote:

I don't really think thats the point. Calculation error gets inflated as you use more complex processing. If you use a limiter and increase the signal level by 6dB's, then stuff that you wouldn't have originally heard becomes audiable. It is also easy to hear the improvement in filtering of a 96KHz source than of a 44.1KHz source. Whilst at the end of the day 16bit 44.1KHz is good enough for the final product, during development you should work at a higher resolution. If you don't, then your music will not sound as good as it could do. The same goes for graphics (unless you are designing pixel accurate stuff, which doesn't really apply to audio).

Maybe i didnt explain myself right. I was not referring to MIXING where accuracy is needed, i were [edited:was]referring to MONITORING. ie: Mix in 32Float/64Double -> 16 bit output monitor.

Hummm, about the example you guys are doing with SINE waveforms mixed. This is not a good example at all. You should mix 10.000 complex waveforms, like voices, car-noises, strings, things like that. THEM you WILL hear the difference from a 32 bits to a 64 bits mixing.

Remember, that with 64 bits mixing all over the synth, the voices mixer will also get a sound improvement. Right now only final VSTs mixing at some hosts (EG: CubaseSX) is done at 64 bits. And you can hear the difference. I know cause when I was coding EVE I did the final mixing at 32 bits, and people was noticing a sound difference when using the multi-output version with CubaseSX 64 bits mixer. So I used 64 bits for the final mix, and the sound got good as CubaseSX mixer.

There is no limit for things, one day they will make a 128 bits processor, and developers will program for those. There is always room for improvements on the audio of plugins.

Just keep in mind that there are some people that want "perfect" sound.

Wk

Quote:

You should mix 10.000 complex waveforms,

I did my best, why don't YOU & post the results?

Quote:

like voices, car-noises, strings, things like that. THEM you WILL hear the difference from a 32 bits to a 64 bits mixing.

a sine is the purest signal - IF you don't hear any truncation noise on a low sine, you won't for any signal. I could have posted sines of different freqs, but I don't see how posting a car noise would let you hear low-bit depth noise. A car noise is a good example of something that could even be 8bit.

Is anyone gonna post some example waves or what? I've been asking this for years, & all I got was 'try this or that piece of hardware', or 'consult a doctor', while it would be dead simple to post a 24bit wave file, & the same converted to 16bit, so that we can hear the obvious noise difference.

im sure their must be some calculations where those last few bits matter - not summing but multiplying for example (especially when one of the numbers is small)> now i have no idea when such calculatiosn would arise - but im sure they will. But ultimately I dont think the increase in bit depth is what will help make recorded music sound clearer - i suspect its the increased sample frequency

nothing to do with noises for bats either - just more samples of any given waveform makes it easier to reproduce - and all the lyndquist shit vanishes out of human hearing range

as for posting an sacd vs a cd - emmm their is no file format for sacd files and their 2.4 Ghz sample rate and no digital out so im afriad i cant - go to a sony store and try one ask them to play kind of blue (if you know it) and DEMAND they dont play the 5.1 remix - thats just a technological advance too far

Ok, today I will post examples from 32 to 64 bits, mixed down to 16 bits, is very easy to do. Just give me a few minutes, just got back home...

Wk

Quote:

Ok, today I will post examples from 32 to 64 bits, mixed down to 16 bits, is very easy to do.

ok, & plz tell where it was used (filter, etc).

I'm also interested in:
-32bit vs 64bit mixing (which is truely bullshit so I'm not expecting any wave so soon)
-24bit integer vs 16bit integer wave files (which I've been asking for years & never got anything, except one web site that roughly said 'raise your soundcard's level 10x your listening level, & listen to those almost inaudible wave files'.

[edit] I removed the files since they didn't shown much diferences from 32 to 64 bits. I still got to make new ones.

Wk

Quote:

BTW: Before anyone says that there is NO difference, look again. Save the two files and open on a picture editor, switch from one to another, there are several diferences.

But no one ever said there was no difference. The extra bits obviously aren't wasted. It's easy to show inaccuracies mathematically. 64bit is also less accurate than 128bit, 128bit is also inaccurate.. Does the fact 128bit will show even less inaccuracies than 64bit proves 64bit is not enough?

As you wrote, we can look, but we can't hear, so until everyone starts looking at spectrums of their CD's instead of listening..

Check this out:

http://www.bores.com/courses/intro/chips/6_precis.htm

here's an extract for those of you who are lazy:

Quote:

There is a potential disadvantage to the way floating point works. Because the hardware automatically scales and normalises every number, the errors due to truncation and rounding depend on the size of the number. If we regard these errors as a source of quantisation noise, then the noise floor is modulated by the size of the signal. Although the modulation can be shown to be always downwards (that is, a 32 bit floating point format always has noise which is less than that of a 24 bit fixed point format), the signal dependent modulation of the noise may be undesirable: notably, the audio industry prefers to use 24 bit fixed point DSP processors over floating point because it is thought by some that the floating point noise floor modulation is audible.

dear God, please, make them RME guys cook a 80bit fixpoint DSP mixer for nextgen hammerfalls and also make them steiny's make a good use of it in master chain.

ach, while at it - force them intel wiseasses to come up with a pentium audio edition.

they deserve to be punished, don't they

eh, forgot - and low noise picato's for my git.