Looking for:
logic pro x 32 bit floating - Apple Community.
Logic pro x 32 bit floating point free -
To start the conversation again, simply ask a new question. This is not so much a question as a comment on a prior thread RE: the need for Logic to support bit float files.
There are beginning to be bit float recorders out there Zoom F6 and SoundDevices MixPre II series among them , and I have found the feature to be more useful than might be initially obvious to us as audio engineers doing primarily music. It's quite remarkable, actually, and I believe this will eventually change our industry.
That is, an input could actually be recorded so hot as to render the resulting audio file to be flat as a pancake, and it can easily be recovered at the mix or mastering stage by simply reducing the gain digitally. No distortion. And it really does sound absolutely fine. Likewise when recording too low: you can bring up the resulting file with digital gain, and there is essentially no change in the noise floor whatsoever.
As a recordist with 24 years of experience, I have never seen anything like this. It's truly remarkable. But it won't work in Logic, because Logic can't handle the bit float files. It still converts them to bit, which does not allow the behavior I've described above. Posted on Aug 3, PM. Page content loaded. I see this as more a comment on the features and quality of modern ADDAC recorders than about bit depth. The 32 bits "debate" is only about the interface between the physical and the digital worlds.
To understand how futile it is, just try to translate a 32 bits depth in electromagnetic physics. Have fun Aug 4, AM. And just to consider, more and more hardware is able to handle bit audio files.
Many mastering studios ask for bit audio these days. It's an obvious question: why can't Logic play bit files? Even QuickTime Player is able to play them. My feeling is that 32 bits thing is more marketing for now. Why not 64 or bits? Most of current 32 bits files are just 16 bits or 24 bits padded files. Aug 4, PM. Yes, and even FCPX can play bit files and recover too-low or too-hot information. Logic really needs to be able to do this, too. Adobe Audition can do it, Reaper can do it Well, except it's not just marketing in the example I provided above.
I recently bought an F6 for location work, and the feature works as advertised when in an application that can handle the bit floating files in my case, iZotope RX. So there will theoretically never be a need for greater bit depth than bit when it comes to recorded files.
Internal DAW math is obviously an entirely different issue. I tend to agree about the dynamic range. It's just there are so many other factors involved. Characteristics of the sound wave, electromagnetic constraints Don't get me wrong, I see a use for higher bit depth. It's always worth baring in mind that 32 bit float is not, and was never meant to be, a destination or output format.
As you say, it's really good for accidents and unexpectedness in location situations and transfering audio unscathed from one platform to another but any peaks exceeding 0dbfs need to be brought back under control before outputing to a general playable format i. I also agree it's a useful format and it would be massively useful if Logic could import 32 bit float files natively.
Accidents and unexpectedness aside, it shouldn't be an excuse to forget about proper gain staging which is still a big part of getting a fantastic recording and mix. All the great recording and mix engineers talk a lot about good gain staging. Aug 5, AM. Aug 5, PM in response to octopi In response to octopi.
Indeed, bit float is almost more of a container that allows audio to travel to its destination without worry of getting "broken" while in the container. Aug 5, PM. It is all about quantizing the real world and keep fidelity in digital transformations. This reminds me of the field of Information Theory I studied decades ago. I begged them for years. I think it is really irresponsible from their marketing department to claim "The Zoom F6 is the first professional field recorder to feature both bit float recording".
The tricky part is the word "recording". What I guess they mean is, they save the recorded signal as a 32bit floating file which is great. What they falsely imply intentionally or unintentionally is that their converters are bit float. However, if you look at their spec sheet, it says 16bit or 24bit. So if you clip the converter above 0dBFS at 24bit fixed , then you have a clipped signal and saving it as a 32bit float file will not magically remove the clipping distortion unless I'm missing something here.
Aug 6, AM. Cubase has had bit FP support since at least but Logic's devs never seemed intrested in bitFP support. Aug 6, PM. I'm really glad you pointed all that out, Edgar. You're absolutely right about the amount of confusion re: these things. The part you're missing here is that both the F6 and the Sound Devices MixPre II series really are recording not just saving bit float files. They're doing it by essentially having 2 or more separate converters for each input.
These two converters are able to dynamically work together in a multistage setup to cover a greater dynamic range than bit fixed integer. The converter is not going to clip. It's a clever approach. I think Sound Devices got a patent for their particular way of doing it. I'm not sure how the F6 differs in its method for achieving the goal, but I can testify that it does work. Aug 7, PM. The Zoom has 2 converters on each input, one to handle low level signal, the other to handle high level signal.
Both of these converters are 24 bit but are dealing with their own range. The resulting combination is then stored as a 32 bit float file on the Zoom. It's a clever and highly useful design but their marketing speak doesn't give the whole picture of what's going on. However you look at it, any overs that are not clipped by storing as a 32 bit float file will need to be brought back to fixed point legal values before final output to your detination format - no one is going to be playing your audio back through an F6 or DAW.
I'm not knocking the Zoom F6, it's a clever and useful device again for unexpectedness. The zoom doesn't store everything as 32 bit float though and there is good reason for this.
If you have a perfectly legal 24bit audio file which never goes into overload and clipping, saving it as a 32 bit float file will give you absolutely no advantage, in fact, it willproduce a vey slight loss. However, if you have an audio file that is within the floating point DAW i. The Zoom F6 accomodates this nicely by not forcing everything to 32 bit loat, i. Going back to Logic's inability to import 32 bit float files natively, I share a lot of people's frustrations at this.
After all, it's processing them internally all in float anyway. It is bewildering. Aug 8, AM. Question: Q: Logic support for bit float files More Less.
Community Get Support. Sign in Sign in Sign in corporate. Browse Search. Ask a question. User profile for user: Mark the Williams Mark the Williams. Question: Q: Question: Q: Logic support for bit float files This is not so much a question as a comment on a prior thread RE: the need for Logic to support bit float files. So I hope Apple adds this needed feature and function soon. More Less. Reply I have this question too 45 I have this question too Me too 45 Me too.
All replies Drop Down menu. Loading page content. User profile for user: Wilddrums Wilddrums. Reply Helpful Thread reply - more options Link to this Post. User profile for user: yoyoBen yoyoBen. Logic's Freeze-Files are bit.
bit Float Audio - When Is The Best Time To Use It? | Production Expert - Discussion
Remember Me? The No. Today's Posts competitions support us FAQ advertise our advertisers newsletter. When you buy products through links across our site, we may earn an affiliate commission. Learn more. Logic Pro - bit FP bit depth? I know Cubase offers bit floating-point storage for audio files, which means you don't have to worry about a post-recorded signal clipping until it finally hits the output bus.
This, of course, assumes no outboard gear or fixed-point plugins in the signal chain. Does Logic Pro offer the same thing? I searched through the user manual, couldn't find any doc on it. Freeze files are 32 bit and all recorded audio is the bit depth you record at.
Not sure about VI realtime playback. Logic processes everything using floating point arithmetic so it isn't an issue. Recording bit depth has nothing to do with processing. Logic actually uses a combination of 32 bit float and 64 bit "where applicable".
And you're absolutely right, there's no point in exporting a 32 bit mixdown. But there's no point in exporting a 32 bit float mixdown for anything else, e. My Studio. My understanding is that 32bit floating point signed is typically 23bits for the mantissa, the extra 8 bits are used for the exponent and the first left, most significant bit is assumed to be 1, freeing it up for other tasks.
There are variations within even floating point and how they're used but the main things to remember is that you trade a bit of precision versus using fixed point for significantly more dynamic range and significantly simpler math.
The loss of precision shows up as quantize noise but is basically a non-issue with any properly designed floating point signal chain as it's so rediculously low.
If your mix bus is 32bit flt then 32bit flt should be a bit match, but imo if you're doing so much processing that you can tell the difference between that and 24bit for a single instrument or stem you may have other issues a need for overprocessing can indicate issues at the source. At the current time it seems there is no 32bit float export or import of sound files in Logic Pro Also, 32bit float on Mac is a mess. On windows there is Wav and about nothing else and broadcast wav or so, but that is compatible.
Apple had aif, caf and of course there is wav Oh well. Maybe it's worth asking Apple why it's not supported and if there are plans to include it at some point.
Once in a blue moon when someone sends me a 32 bit float file by error, I use Barbabatch V4 to convert it into a 24 bit file. Apart from being able to read the format from someone else who doesn't know what they're doing, it would seem. WaveBurner Pro part of Logic Studio actually reads 32 bit floating point files and converts them, but it's not usable for true conversion purposes unlike Barbabatch. The thing is that when you bounce a selection or a track, it would be highly beneficial to store tracks in bit float.
Anytime you add destructive effects or do destructive editing, storing files in bit can be very necessary. I HATE that fact that if I bounce all of my tracks as audio files in Logic, not a one can clip , otherwise there is terrible distortion, even though it can clip hard during a mix with no adverse effects or distortion at all. That being said, storing ALL recorded audio in bit is simply inefficient and needless.
This is because the audio is still being recorded in 24 or even 16 bit resolution. Therefore, when storing all recorded audio in bit float, you are adding a byte of extraneous information every sample. Larry Mal. Hold on: the only time anyone needs dither is from going from 24 bits of depth to 16 bits of depth. Going from 32 bits to 24 bits does not need dither, and no one who runs any kind of mastering studio wouldn't be ignorant of that. These are admittedly very low level artifatcs but that doesn't matter if you're interested in the best possible preservation of audio quality, as we should be as mastering engineers.
Sorry if I come across as aggressive but with your obviously great reputation I feel I shouldn't have to tell you this! Actually that is not true, the mantissa is normalised, meaning it always starts with 1 not 0. Since it always starts with 1 there is no need for that bit, instead a 1 is implied as the first bit in the mantissa, meaning it is actually 24bits.
Secondly since the signed bit have a special resereved bit not part of the mantissa you can store values from to , so the range is , which is twice as large and would require 25bits if the signed bit was part of the mantissa, or if it was represented as fixed. Again, the actual sound contents of a 24 bit WAV file and a 32 bit floating point are virtually identical.
The 8 extra bits are reserved for headroom, not extra resolution as such. Therefore there's virtually no difference in the actual sound contents, and going from 32 bit floating point to 24 bit is a fairly simple process, as Larry pointed out. Thank you, my wording was unclear I think in trying to be overly brief. You have 24bits represented with the first bit assumed to be 1 hence 23, but I see the second half of my first sentence still did clearly states that the first bit of the mantissa is assumed to be one.
As for the loss of precision, this is because the floating point values are not evenly distributed in their scale or separate from each other. Values represented at the extremes of the floating point scale have a lot of deviation which can certainly lead to quantize noise.
The tradeoff of course is that the quantize noise is so rediculously low in practice as I mention below that you get significantly better data out of the other end of many calculations than you would have by sticking with integers, and the math is tremendously simpler to code for complex operations like calculating DFT so there is less chance for an error in thinking through your algorithm.
If my understanding is wrong, feel free to point it out as you have been pointing out my lack of clarity. And in relation to another thread on HT here you can often get higher utilization of a processor due to the amount of resources available for INT based operations, again increasing execution speed.
Point being that x86 based programmers typically prefer INT for the speed of execution and the multitude of ways that certain operations can be accomplished or simulated. You also need to be aware of quantization errors or implement some form of accumulator to track these across multiple operations. Since these need to be accounted for on each step in an algorithm that performs calculation that's an additional burden for the programmer and gives room for error and bugs I can think of a few hardware units that suffer from poor programming in this regard even with DSPs.
So it would seem to follow that in floating point operations the vastly simplified number of ways to go about things and the fact that the representation of values has such incredible headroom with low quantization noise makes this much less of an issue. It's also entirely possible that the typical audio programmer is simply calling math routines that account for all of this most FFT based code seems to rely on this , in which case it may a nonissue for coding a plugin or typical DAW app.
The only real error I can see in the discussion above is in stating things like "The 8 extra bits are reserved for headroom, not extra resolution as such" when converting from 24INT to 32FLT. As we stated though the quantization noise is so negligable that no audio converter should be able to reproduce it their own self noise being significantly higher. Would a mastering chain magnify those errors to the point where you care? It's not extraneous, since the number is stored in the same manner as scientific notation but with base two.
The extra byte is used for the exponent. You are still writing 8 extra bits of information to the disk per sample that has absolutely nothing to do with the actual LPCM stream arriving from the converter. Any stream from a bit converter can be accurately represented in 24 bits.
Now, later, it can be useful for sure, but capturing every bit stream in bit seems like a lot of overhead in terms of disk space. Especially with most people today leaving 10dB of headroom while tracking Here's my question: In a bit mix environment, is it less strenuous on the system if all of your streams already in bit as opposed to storing in bit and having the mix engine preform the calculation on the fly?
If it is, I'll start recording in bit today in Nuendo. Again that's not totally accurate in my experience with floating point numbers, floating point can be significantly MORE accurate on signals with very low dynamics where a integer signal would have problems say with only 1 or 2 bits of precision available but on signals with extreme dynamics the deviation between values at the top of the scale is so large that you will certainly get quantization.
In practice though the quantize error noise is insignificant when converting back to an integer format as will be necessary for playback if nothing else. I'm not sure about the difference in execution speed on the latest generations of Intel CPU's, my understanding is that floating point operations have been heavily optimised and gained alot of hardware suport over the years.
Floats might even be faster, I'm not sure. Yes, you would have to look out for integer overflow with ints, but on the other hand, ints have better accuracy. The way I see it there would be things you would have to look out for either way. I think it's related to the details of the discussion at large, but I agree that the benefit of storing data on disc as float is not beneficial most of the times, the way I see it. I'm not arguing that 32 bit floating point isn't more accurate than 24 bit fixed when you're processing audio, of course.
But delivering a mix as a 32 bit floating point file and a 24 bit WAV file peaking at to -3 dBFS to the ME for mastering will yield virtually identical end results. Furthermore, many professional mastering software applications do not accept 32 bit floating point files or simply convert them on import. As you point out, this is a highly theoretical discussion in practice. Which makes me curious if perhaps the discussion is more related to intersample overs and actual clipping from people who don't want to worry whether they've kept levels down on individual channels, rather than whether the noisefloor accumulates enough to worry about it ie, loss of precision.
This is an equally distributed probability function that shouldn't 'color' the output at all since there is no frequency content for the brain to 'hear' or become amplified. It's easy to find out what points are adding TPDF dither which is what you're thinking of , just do an inverse null or send null data through and look for the added dither.
Even certain EQ plugins that are known for a lack of low-bandwidth ripple are actually achieving this not just via their windowing on the filter algorithm or FIR functionality but also via adding TPDF to the output. So under the theory that adding the dither 'randomizes' this zipper noise and other truncation artifacts and pushes them low enough to 'unmask' what was masked, adding TPDF when changing bit-depths avoids those distortions from accumulating at the expense of a bit of noise accumulating.
So even with later amplification, if your gain-staging has been well handled throughout the previous signal chain you shouldn't be contributing enough of anything to worry about. The real concern again in my understanding is with dither that is COLORED or has uneven distribution, as this is no longer random and can affect perception of the final output.
So you add your shaped dither in the last step to insure that additional processing isn't altered by the colored noise. I guess I wasn't suggesting Lagerfeldt applies dither himself so much as alluding to the fact that some software can impart dither to an audio file internally when making edits or processing - this is why I'm cautious of software like Logic that uses 24 bit files and has a 32 bit or higher internal engine.
It may apply its own internal dither of suspect quality , or truncate, each time an audio file is changed; it's hard to be sure.
Working at 32 bit for me takes some of this mystery away and gives me more control over what's being done to the audio. Top Mentioned Manufacturers. Facebook Twitter Reddit LinkedIn. Subscribe to our mailing lists. By using this site, you agree to our use of cookies. Code by Port Forward.
Hosted by Nimbus Hosting.
No comments:
Post a Comment