Logic Pro 9 Yeah It's Impossible But...
- Thread starter LSchefman
- Start date
I think you are confusing Logic's new 64 bit memory processing with the audio engine which, to the best of my knowledge has always (for several versions anyway) and still does run at 32 bits internally.
The new 64 bit mode refers strictly to addressing memory and allows Logic to load more than the old 3.5 GB (approx)of samples into memory at once. Running in 64 bit mode is strictly for loading in huge sample libraries. It has nothing to do with the audio engine itself.
Having said that though, it doesn't fully discount the fact that you are hearing a difference. This whole 32 bit audio unit bridge is a new "1.0" feature in Logic. It's possible it is having some effect on the plug ins that are loaded into it. It's unlikely, but I guess not impossible.
I haven't hard or read any one else mention it. But the fact is that it _is_ being fed through this intermediary "bridge" and so - that could be affecting the sound somehow. But if this is the cause of what you are hearing, it has nothing to do with 64 bits sounding better than 32 bits; it would likely have to do with the audio unit bridge code and how it is written/working.
Hope this makes sense!
The new 64 bit mode refers strictly to addressing memory and allows Logic to load more than the old 3.5 GB (approx)of samples into memory at once. Running in 64 bit mode is strictly for loading in huge sample libraries. It has nothing to do with the audio engine itself.
Having said that though, it doesn't fully discount the fact that you are hearing a difference. This whole 32 bit audio unit bridge is a new "1.0" feature in Logic. It's possible it is having some effect on the plug ins that are loaded into it. It's unlikely, but I guess not impossible.
I haven't hard or read any one else mention it. But the fact is that it _is_ being fed through this intermediary "bridge" and so - that could be affecting the sound somehow. But if this is the cause of what you are hearing, it has nothing to do with 64 bits sounding better than 32 bits; it would likely have to do with the audio unit bridge code and how it is written/working.
Hope this makes sense!
Did you mean to write "and still does run at 64-bits internally" here?
Because it is not possible for a 64-bit application to run any 32-bit code. It's an all-or-nothing deal. That's why the 32-bit Audio Units have to be run in an external application. The 64-bit wide data paths that the application uses cannot run 32-bit wide plug-ins.
What I think that Les was saying is that he knew that the Logic Audio engine had used 64-bit precision math where advantageous, which is true. And I'm guessing that what you meant to say is that you too knew that the audio engine processing used 64-bit precision math where appropriate.
In other words, it is possible to use 64-bit precision math algorithms in either 32- or 64-bit wide data paths but it is not possible to use 32-bit code in a application that is coded for 64-bit wide data paths.
But yeah, this wouldn't change the fact that both versions should sound the same.
Orren
Because it is not possible for a 64-bit application to run any 32-bit code. It's an all-or-nothing deal. That's why the 32-bit Audio Units have to be run in an external application. The 64-bit wide data paths that the application uses cannot run 32-bit wide plug-ins.
What I think that Les was saying is that he knew that the Logic Audio engine had used 64-bit precision math where advantageous, which is true. And I'm guessing that what you meant to say is that you too knew that the audio engine processing used 64-bit precision math where appropriate.
In other words, it is possible to use 64-bit precision math algorithms in either 32- or 64-bit wide data paths but it is not possible to use 32-bit code in a application that is coded for 64-bit wide data paths.
But yeah, this wouldn't change the fact that both versions should sound the same.
Orren
I thought that in terms of actual audio processing, Logic ran (and still runs) at 32 bits internally. Remember when we used to freeze tracks in Logic 7 and the resultant files were 32 bit files? I thought this was the internal resolution that Logic's audio engine worked at. But I'll be the first to admit, I'm no math expert 
Again, you must separate the bit-size of the memory pathways, and the bit-precision of the math algorithms. Logic since the Logic 7 days (or earlier?) has used 64-bit precision mathematics in it's algorithms to get the best sound quality, even as it was running as a 32-bit addressing application.
Haven't you ever wondered about all these plug-ins like PSP Audioware plug-ins that say "includes FAT [for PSP] 64-bit precision algorithms" and things like that? I think all Ozone plug-ins are 64-bit precision. Haven't you wondered how a plug-in could say it used 64-bit processing, yet was only a 32-bit program (and in fact, couldn't run in 64-bit mode)? That's how.
And this is something totally and completely different The bit rate at which a file is bounced is not necessarily an indicator of the precision of the math algorithms. If it was, that would mean that if you bounced a 16-bit audio file, the audio engine would be operating at 16-bits (it is not), and that the 64-bit version of Logic could bounce 64-bit files (it can not). The bounce/export functions of Logic are capable of printing audio files at a number of bit sizes.
To get technical, printed audio files (not freeze files though) are actually integer (fixed point) files, meaning that they are converted from the floating point math used internally to fixed point files. That's why the Normalize option in the Bounce window is different from the Sample Editor normalize; the Bounce option is a "floating point" normalize that operates on the floating point data in memory to accurately print the data to a fixed point file.
All confusing stuff, but how many bits wide the data path of the application, the bit precision of the math algorithms, and the bit depths at which a file can be bounced are three separate things.
Orren
Haven't you ever wondered about all these plug-ins like PSP Audioware plug-ins that say "includes FAT [for PSP] 64-bit precision algorithms" and things like that? I think all Ozone plug-ins are 64-bit precision. Haven't you wondered how a plug-in could say it used 64-bit processing, yet was only a 32-bit program (and in fact, couldn't run in 64-bit mode)? That's how.
Remember when we used to freeze tracks in Logic 7 and the resultant files were 32 bit files? I thought this was the internal resolution that Logic's audio engine worked at. But I'll be the first to admit, I'm no math expert
The bit rate at which a file is bounced is not necessarily an indicator of the precision of the math algorithms. If it was, that would mean that if you bounced a 16-bit audio file, the audio engine would be operating at 16-bits (it is not), and that the 64-bit version of Logic could bounce 64-bit files (it can not). The bounce/export functions of Logic are capable of printing audio files at a number of bit sizes. To get technical, printed audio files (not freeze files though) are actually integer (fixed point) files, meaning that they are converted from the floating point math used internally to fixed point files. That's why the Normalize option in the Bounce window is different from the Sample Editor normalize; the Bounce option is a "floating point" normalize that operates on the floating point data in memory to accurately print the data to a fixed point file.
All confusing stuff, but how many bits wide the data path of the application, the bit precision of the math algorithms, and the bit depths at which a file can be bounced are three separate things.
Orren
You are confusing memory addressing with audio engine. Both are measured in bits, but have absolutely nothing to do with each other.
A bit is simply a "binary digit", 0 or 1
1 bit gives you two states: 0 or 1
2 bits gives you 4 states: 00, 01, 10 or 11
3 bits gives you 8 states: 000, 001, 010, 011, 100, 101, 110, 111
etc etc etc.... each extra bit gives twice as many states as the previous amount of bits
8 bits gives you 256 states: I ain't typing these out!
16 bits gives you 65,536 states
32 bits gives you 4.29 BILLION states
64 bits gives you 18,446,744 TRILLION states (gulp)
For memory addressing, 32bits can handle up to 4.29 BILLION Bytes (approximately 4GB). With today's computers being able to fit more RAM than this, it's a shame that any given 32bit application can't "see" more than 4GB RAM. It used to not be a limitation, because who the hell had more than 4GB RAM several years ago? An imaginary 33bit application could see twice this RAM: 8GB. An imaginary 34bit application could therefore see 16GB RAM. A 64bit application (actually, it's really a 63bit application) can "see" 9 ExaBytes (9EB) which is 9,000,000,000 GB. I don't think all the RAM in the world adds up to this.
So far, this has absolutely nothing to do with audio engine or sound quality.
Logic's audio engine (as is the case for most other DAWs) is 32bit float (don't ask about the "float" part - that's another discussion hardly relevant to this one). So there's 32bits worth of data that makes up the audio stream inside Logic. Even without the "float" part, that'd give you 192dB dynamic range (each bit gives you 6dB of dynamic range). No physical device could ever achieve this, nor does this range (quietest to loudest ratio) probably exist on earth. And the "float" part makes it even bigger than this.
Are there any DAWs with a 64bit audio engine? Would it make an audible difference? ProTools HD (not LE or MPowered) uses a 48bit fixed (not float) system.
So you can see that measuring two different things in "bits" has a very different result:
--For memory addressing, each additional bit DOUBLES the total amount of addressable memory.
--For audio engine, each additional bit adds 6dB of dynamic range
Comparing the two would be like comparing cheese with granite because both could be measured in grams.
A bit is simply a "binary digit", 0 or 1
1 bit gives you two states: 0 or 1
2 bits gives you 4 states: 00, 01, 10 or 11
3 bits gives you 8 states: 000, 001, 010, 011, 100, 101, 110, 111
etc etc etc.... each extra bit gives twice as many states as the previous amount of bits
8 bits gives you 256 states: I ain't typing these out!
16 bits gives you 65,536 states
32 bits gives you 4.29 BILLION states
64 bits gives you 18,446,744 TRILLION states (gulp)
For memory addressing, 32bits can handle up to 4.29 BILLION Bytes (approximately 4GB). With today's computers being able to fit more RAM than this, it's a shame that any given 32bit application can't "see" more than 4GB RAM. It used to not be a limitation, because who the hell had more than 4GB RAM several years ago? An imaginary 33bit application could see twice this RAM: 8GB. An imaginary 34bit application could therefore see 16GB RAM. A 64bit application (actually, it's really a 63bit application) can "see" 9 ExaBytes (9EB) which is 9,000,000,000 GB. I don't think all the RAM in the world adds up to this.
So far, this has absolutely nothing to do with audio engine or sound quality.
Logic's audio engine (as is the case for most other DAWs) is 32bit float (don't ask about the "float" part - that's another discussion hardly relevant to this one). So there's 32bits worth of data that makes up the audio stream inside Logic. Even without the "float" part, that'd give you 192dB dynamic range (each bit gives you 6dB of dynamic range). No physical device could ever achieve this, nor does this range (quietest to loudest ratio) probably exist on earth. And the "float" part makes it even bigger than this.
Are there any DAWs with a 64bit audio engine? Would it make an audible difference? ProTools HD (not LE or MPowered) uses a 48bit fixed (not float) system.
So you can see that measuring two different things in "bits" has a very different result:
--For memory addressing, each additional bit DOUBLES the total amount of addressable memory.
--For audio engine, each additional bit adds 6dB of dynamic range
Comparing the two would be like comparing cheese with granite because both could be measured in grams.
It is.
I'm not going to try and explain 64-bit precision math, mostly because I can't.
But here is an article on it: http://en.wikipedia.org/wiki/Double_precision_floating-point_format
And here's one more related to audio:
http://www.sweetwater.com/expert-center/glossary/t--DoublePrecision
Orren
I'm not going to try and explain 64-bit precision math, mostly because I can't.
But here is an article on it: http://en.wikipedia.org/wiki/Double_precision_floating-point_format
And here's one more related to audio:
http://www.sweetwater.com/expert-center/glossary/t--DoublePrecision
Orren
I'm right there with you. That's why I'm a writer.
So I tried to think of a more "literary" analogy. I'm sure that to a real mathematician this is full of holes, but I think it's close enough, and brings it back to Les's original point.
Let's imagine that we have two cars: the 32bitmobile, and the 64bitmobile. Both cars can carry the same stuff, but the 64bit mobile has more room.
Now let's say that the method we use to pack our stuff into each car is called "math." What we'll call "Single precision mode" (or 32-bit precision math) means that we just shove our stuff into the car "as is." What we'll call "double precision mode" (or 64-bit precision math) means we'll fold stuff in half. With me so far?
Okay, now let's assume we're trying to get our stuff to the gig. One of the things that we want to do is bring our mic stand with a boom attachment.
First, we'll pack the 32bitmobile. If we used "single precision math" to try to pack our mic stand into our 32bitmobile, it won't fit. The mic stand is too big. However if we use "double precision math" we fold our mic stand in half, and now it fits in the 32bitmobile. The mic stand fits in the 64bitmobile as is.
So in this rather wacky example, you can see that with double precision 64-bit math in a 32-bit "automobile," the "carrying quality" is identical to that of a 64-bit "automobile." (one problem with my analogy is that I'm using "carrying capacity" as a substitute for "audio quality," which is an odd correlation, but it's all I could come up with off the top of my head).
Anyway, I hope this makes it a tiny bit understandable about why a 32-bit audio engine utilizing double precision (64-bit) math algorithms would have the same audio quality as a 64-bit audio engine (utilizing single precision math algorithms). And as Ferenc pointed out, this has nothing to do with memory addressing, or file bouncing-we're just talking about audio engine quality in this analogy.
This definitely is confusing stuff!
Orren
That's why I'm a writer.So I tried to think of a more "literary" analogy. I'm sure that to a real mathematician this is full of holes, but I think it's close enough, and brings it back to Les's original point.
Let's imagine that we have two cars: the 32bitmobile, and the 64bitmobile. Both cars can carry the same stuff, but the 64bit mobile has more room.
Now let's say that the method we use to pack our stuff into each car is called "math." What we'll call "Single precision mode" (or 32-bit precision math) means that we just shove our stuff into the car "as is." What we'll call "double precision mode" (or 64-bit precision math) means we'll fold stuff in half. With me so far?
Okay, now let's assume we're trying to get our stuff to the gig. One of the things that we want to do is bring our mic stand with a boom attachment.
First, we'll pack the 32bitmobile. If we used "single precision math" to try to pack our mic stand into our 32bitmobile, it won't fit. The mic stand is too big. However if we use "double precision math" we fold our mic stand in half, and now it fits in the 32bitmobile. The mic stand fits in the 64bitmobile as is.
So in this rather wacky example, you can see that with double precision 64-bit math in a 32-bit "automobile," the "carrying quality" is identical to that of a 64-bit "automobile." (one problem with my analogy is that I'm using "carrying capacity" as a substitute for "audio quality," which is an odd correlation, but it's all I could come up with off the top of my head).
Anyway, I hope this makes it a tiny bit understandable about why a 32-bit audio engine utilizing double precision (64-bit) math algorithms would have the same audio quality as a 64-bit audio engine (utilizing single precision math algorithms). And as Ferenc pointed out, this has nothing to do with memory addressing, or file bouncing-we're just talking about audio engine quality in this analogy.
This definitely is confusing stuff!
Orren
Yes, I totally get what you're all saying.
As I said in the first place, I'm imagining it no doubt.
And maybe it's because I'm using memory-intensive samplers? Anyway, I know it's impossible.
But I think I hear something. Not to argue, you're all right, and yes I am crazy to think this.
Incidentally, I think I hear a difference between the "live" playback and a bounce also.
Imagination and expectations can trick one, as I am fully aware.
As I said in the first place, I'm imagining it no doubt.
And maybe it's because I'm using memory-intensive samplers? Anyway, I know it's impossible.
But I think I hear something. Not to argue, you're all right, and yes I am crazy to think this.
Incidentally, I think I hear a difference between the "live" playback and a bounce also.
Imagination and expectations can trick one, as I am fully aware.
Did Another Listening Test
...And this time I heard no difference at all between 64 and 32 bit sessions.
So yes, it must have just been one of those coincidences where I simply was having a great physical/audio-brain/mood day, happened to switch to 64 bits, and then thought I heard something.
Mood and simply feeling great affected things. As one might expect!
...And this time I heard no difference at all between 64 and 32 bit sessions.
So yes, it must have just been one of those coincidences where I simply was having a great physical/audio-brain/mood day, happened to switch to 64 bits, and then thought I heard something.
Mood and simply feeling great affected things. As one might expect!