1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Logic 9 Yeah It's Impossible But...

Discussion in 'Logic 9' started by LSchefman, Apr 5, 2010.

  1. LSchefman

    LSchefman Senior member

    Yeah It Really Was Impossible

    Edited 'cause my original post has no useful info, but the responses do.
  3. Eli

    Eli Senior member

    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!
  4. Orren Merton

    Orren Merton Logic Samurai / Administrator Staff Member

    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. :)

  5. Eli

    Eli Senior member

    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 :confused:
  6. Orren Merton

    Orren Merton Logic Samurai / Administrator Staff Member

    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. :)

  7. zerobeat

    zerobeat Senior member

    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 dynami
    c range

    Comparing the two would be like comparing cheese with granite because both could be measured in grams.
  8. Eli

    Eli Senior member

    This all makes perfect sense. But I don't quite understand how the "64 bit precision math" Orren explains fits in to all of this. This seems to be a third type of measurement.
  9. Orren Merton

    Orren Merton Logic Samurai / Administrator Staff Member

    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:

  10. Doug Zangar

    Doug Zangar Senior member

    I've enjoyed this thread, but that math stuff....
    head in a vice.jpg
  11. Orren Merton

    Orren Merton Logic Samurai / Administrator Staff Member

    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! :)

  12. Eli

    Eli Senior member

    Orren: Actually - that does help unravel the complexity of it all a bit - at least for me :D

    Good analogy, even though it might not fit perfectly.
  13. LSchefman

    LSchefman Senior member

    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.
  14. Doug Zangar

    Doug Zangar Senior member

    Orren - thanks for analogy. I actually did go to the links and read them. Now I feel like an expert in discussing this stuff :rolleyes:

    But I can drop terms like double precision.....!

    Zerobeat - thanks for the math on the RAM access (seriously!). I never realized that's how exponential it all was.
  15. LSchefman

    LSchefman Senior member

    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! :D

Share This Page