[Rwp] rendering again
Chris Belle
cb1963 at sbcglobal.net
Tue Oct 20 20:33:10 EDT 2015
Ha, we both came to similar experimental ideas at the same time 'grin'.
Your listening
or capturing hardware shouldn't
matter so much for the internal data bus width testing,
as when I set the mixing depth in reaper to 64 bit, even 16 bit streams
allowed me to turn it all the way down to -140 -150 and still sound good.
But when I dropped it to 32 and 24 bits, that low level started to get
ragged.
That mackie is only low level like that on the master bus,
I do wish it was adjustable, but it's like that so you can feed multiple
tracks to the master bus
and not exceed nominal levels.
But recording to the individual in-puts or to the subs, the gain staging
is pretty spot on.
and I can easily get -12 or -6,
but when you hit 0 you are clipping.
Try using a sub pair instead of the master bus,
to sum your signals and you will get gain from all the faders involved,
On 10/20/2015 5:22 PM, Snowman via RWP wrote:
> Chris, Yep about all that.
> The problems start to appear when one goes looking for them.
> And, of course the A/D converter resolution is, how many bits? Maybe 24?
> Interesting experiment is to poke nice smooth white noise into an
> analog input, and drop the drive level way way down, and the listening
> volume way way up. If nothing bad happens to you, you'll start to
> hear that coarsness taking hold at lower levels.
> But, you really have to go low to hear that. Try it with 8 bitgs, if
> you wonder what we're talking about.
>
> But, if it's true that modern systems are hardly bothered by the extra
> data of 64-bit, why not use it for internal work.
>
> I use higher bit depts when sucking from the Mackie Onyx firewire,
> since it loves to make you operate down around -20 to -30DB. In that
> case, you really have to have it.
>
>
>
>
> ----- Original Message ----- From: "Chris Belle via RWP"
> <rwp at bluegrasspals.com>
> To: "Reapers Without Peepers" <rwp at bluegrasspals.com>
> Cc: "Chris Belle" <cb1963 at sbcglobal.net>
> Sent: Tuesday, October 20, 2015 4:56 PM
> Subject: Re: [Rwp] rendering again
>
>
> Hey Jim?
>
> I have done some casual testing with sonar and rendering out 16 bits and
> 24 bit files with a very long piano fade,
> like you'd get on the low a.
>
> It's quite significant with 16 bit
>
> even compared to 24 bit, it made a difference in half a minute worth of
> fade.
>
>
> You did have to turn the volume way up to hear it, or normalize the tail
> up so you wouldn't have to turn the amp way up, but
>
> 16 bit tails would fade out or get jittery around 84 db down while 24
> bit tails didn't get that way till about 137 db down.
>
> With dithering it made the tails smoother.
>
> the problem with this isn't so much what bit depth you use, 32 or 64
> bit, either would be pretty darn fine res, but when you go back and
> forth between say 24 bit and then back to 32 bit.
>
> If you render your stems out for gluing and such as 24 bit stems, and ok
> at that point they are good for use with any input to sound cards or
> what ever, where as 32 or 64 bit floating point wavs are only good for
> internal use for the most part.
>
> but all those extra bits from a 32 or 64 bit wav that you did use would
> get truncated,
> and then when you re-introduced the 24 bit wav back in to your
> processing in your project it get's translated back to 32 or 64 bit so
> where the extra wide data path might matter is if you weren't all the
> way to the top of scale say you had some stuff you were rendering and
> you were down
> -20 db, well at 24 bit you're still having a wide margin of error, but
> with 32 bit or 64 bit you are really safe.
>
> Most people would never turn their amps up that loud, but say if you
> were listening in a concert setting with classical music with a very
> wide dynamic range, and delicate instruments at low levels
> which might be afected by the noise floor then that extra margin might
> matter.
>
> 24 bit is still pretty good even not dithered, but if you use dither to
> mask your tails,
> or use a high enough bit depth so you never ever reach the edge of the
> data stream before the tail runs out,
> and give yourself more than enoughroom for processing, like we know our
> eq's and compressors and such like 32 or 64 bit data paths,
> then to me it makes sense to keep it big and wide until you reach the
> real world.
>
> Your also following the practices of the dsp chip makers at this point,
> even dsp chips of 15 years ago made our digital mixers and such with 36
> bit data paths, for instance the delta card is 36 bit
> 4 bits bigger than the 32 bit floating point sonar defaults to, the
> behringer x32 is 40 bit,
> I think the RME stuff is 64 bit,
> so could we hear it, probably at 24 bit you could hear some of it under
> certain circumstances,
> probably not so much at 32 or 64 bit.
>
> A lot would depend on the type of listening; you were doing, and the
> type of processing,
> but the way to test any of this stuff is to listen to the tails and the
> edges of things when they fade out.
>
> Like I said, my testing was casual, and only with sonar's dithering and
> rendering so far, I plan to do some with reaper,
> but it is telling to me that sonar uses dithering even at the higher bit
> depths,,
> and defaults to a higher bit depth internally
>
> You certainly wouldn't notice it on your typical podcast, or audio book,
> heck with those you probably wouldn't notice it doing 16 bit with no
> dither.
> even.
> Certainly not at low level casual listening living room volumes.
> but if you were going to pay attention to such details, sonar's default
> setting are much better for full proofing this sort of thing than
> reaper's is.
> YOu don't get the internal dithering with reaper, but you can certainly
> turn the data path up big and wide so you never deal with the tails of
> things so to speak.
> Or use the render options in reaper that allow you to dither and noise
> shape,
> it's kind of a pain to do so instead of the convenient glue and render
> options offered internally,
> but at least then you know you would have done everything possible to
> make your files as transparent as possible.
> I think I'd trust it all at 64 bit,
> rendering,
> one could also do some screwy things like turn one bus way down and
> another way up that were in series, totally do your gain staging wrong,
> to see how far you could push things to the edges of your data streams
> and see how they act with and without dithering,
> but with normal best practices, 32 or 64 bit rendering would give you
> very nice results with or without dithering.
> bu the dithering gives you just that little bit more safety in case
> something screwy happens, you'd get a smooth noise floor sound instead
> of a jittery ragged quantizing
> error when you ran out of bits.
>
> Very much hair splitting here I know for every day practices, but yes, I
> too am interested to see what others do besides me and Justin and
> Patrick at this point.
>
>
> But I am talking best practices senarios here for future proofing
> projects,
> On 10/20/2015 4:11 PM, Snowman via RWP wrote:
>> I'm curious. Have any of you guys with good hearing actually tried
>> to demonstrate the distortion that results from using lower bit
>> depths? Mathematically, I know it is better. But, can you hear it?
>>
>> The resolution of 32-bit is pretty significant.
>> and 64-bit is just obscene, which is why they don't mess with
>> dithering at such high depths.
>> When I could hear worth beans, it was clear that you started to hear
>> obvious quantization when you dropped below 16, especially the
>> texture of very soft sounds, which wasn't apparent unless you turned
>> the gain way up.
>> 32 bits is 65,000 times finer resolution. If you look at the
>> quantization error of even 32 bits, it is very tiny, something better
>> than oned part in 4 billion, which is 0.000000025 percent.
>> and 64 bits is incredibly fine resolution.
>> So, is it, really, necessary, or just better.
>>
>> ----- Original Message ----- From: "Clarence Griffin via RWP"
>> <rwp at bluegrasspals.com>
>> To: "'Reapers Without Peepers'" <rwp at bluegrasspals.com>
>> Cc: "Clarence Griffin" <goldfingas at gmail.com>
>> Sent: Tuesday, October 20, 2015 9:05 AM
>> Subject: Re: [Rwp] rendering again
>>
>>
>> You can change all that in settings though, yes?
>>
>>
>> -----Original Message-----
>> From: RWP [mailto:rwp-bounces at bluegrasspals.com] On Behalf Of Chris
>> Belle
>> via RWP
>> Sent: Tuesday, October 20, 2015 1:10 AM
>> To: Reapers Without Peepers
>> Cc: Chris Belle
>> Subject: Re: [Rwp] rendering again
>>
>> Just to put a little more butter on the bread, about this ever so
>> contravertial topic, so tp speak, sonar renders everything at 32 bit
>> floating point if you leave things at default.
>>
>> So when you freeze, or bounce anything, you get a 32 bit file
>> internally.
>> Many players, and some other DAW's can't handle this format so I
>> guess that
>> may be one reason reaper defaults to 24 bit bounces, they call it
>> glue, but
>> it amounts to just about the same thing.
>> making a new file processed from other files.
>>
>> Ideally, when you do this, you want to do it to the same size file,
>> or one
>> bigger which will ensure you retain the information you had, when
>> using a
>> bigger file, the extra bites usually get padded with zeros.
>> Sonar has dithering options in this rendering bouncing process, in
>> case you
>> do decide to use a smaller bounce size, so you can take care of those
>> tails,
>> but reaper does not.
>>
>> Not obviously on the surface anyway,
>> so that's why I was thinking of doing all my internal bounces at 64
>> bit and
>> only going down to 24 or 16 bitg when I was finished with the projec.
>> Most people I know using sonar in a high end situation turn
>> everything up to
>> 64 bit, as well as checking the box for the 64 bit double precission
>> engine.
>>
>> Whether this makes any detectable difference for most situations is
>> anybody's guess or conjecture, but I do know if you do this, rounding
>> errors
>> become so very negligible.
>> and so far out there that it's not really a consideration anymore.
>>
>> From what I gather, anything above 32 bit is good, and this is
>> because most
>> plugs we use process at either 32 bit or 64 bit floating point.
>>
>> So having this mixing bit depth internally guarantees that
>> everything get's
>> translated, more or less.
>>
>> And different pieces of hardware like the behringer board have their
>> own bit
>> depth when processing, for the behringer, it's 40 bit.
>>
>> Of course, it doesn't make sense to try and use big files outside our
>> DAW's,
>> many times I get only white noise when experimentally trying to play
>> say a
>> 32 bit floating point file in winamp, and a 64 won't even get
>> started, I get
>> a system error.
>>
>> But when having a conversation with my mentor Jim Roseberry over at
>> studiocat.com, who builds the finest DAW's in the land, and is an
>> endless
>> wealth of patient knowledge when I've been building my own machines, or
>> helping others, trying to figure out the best ways to do things, he says
>> that 64 bit processing on our modern systems doesn't hit them much
>> harder,
>> and it insures the best possible resolution for all the things we
>> might do,
>> cuts out those rounding errors, and I think there is probably
>> something to
>> that.
>>
>> The only time I might ignore this rule is if I were just recording
>> something
>> with no processing, no plugs, just wanted a straight bounce of what I
>> recorded in to straight out.
>>
>> At that point, then any 64 bit
>> wide bus or even 32 would probably be wasted, since you're not going
>> to do
>> any mixing.
>>
>> I would be curious to hear from others if anyone has ever used any of
>> the
>> more unusual bit depth options in the advanced reaper tab, like 12
>> bit or
>> even 8 bit.
>>
>> Probably be kind of cool for some low fi sort of electronic thing,
>> though
>> there are probably better ways to do that with things like bit reduction
>> plugs, like some of the j s stuf, but I wonder what the thinking was
>> to even
>> include them in reaper?
>>
>> Sonar doesn't have such a thing, only the check box for the 64 bit
>> double
>> precission engine thing, but nothing for mixing bit depth as such,
>> but it
>> does have the extra options dither and such for rendering both for
>> internal
>> use, and for export, anyway, these are two entirely different animals.
>>
>> On 10/19/2015 10:33 PM, Chris Belle wrote:
>>> I was speaking of rendered or printed fx to a file.
>>>
>>> yes, if you still have the project, it would make sense to go back to
>>> the project and get it straight from the source.
>>>
>>> We can't do anything about media we get from other sources, already
>>> processed at 16 bit, and 24 bit audio is indeed very wide and not
>>> likely to have audible artifacts from processing.
>>> at the normal levels we will use them.
>>>
>>> I'm talking about best practices for maintaining the best audio
>>> quality in house though.
>>>
>>> Internally with in your reaper projects.
>>>
>>> When you glue, or render, and create a 24 bit file, that is coming
>>> from a 64 bit wide file, then you are technically throwing away
>>> resolution.
>>> Could you hear it?
>>> Probably not.
>>> You might not even hear it most of the time if you rendered 16 bit
>>> unless you turned it way up and caught a grainy tail or something.
>>> But it's the principal of conservation, of data, you can't get the
>>> data back once it's gone, kind of like making an mp3 from a wav and
>>> then getting the wav back, not quite as bad, but once you go from a 64
>>> bit file to a 24 bit file, say you glued a bunch of stuff and then
>>> wanted to use it in the same project again, then it returns back to
>>> the 64 bit environment.
>>> from a lower bit depth.
>>>
>>>
>>> If you glue at 64 bits, you maintain the same wideness of data path.
>>>
>>> That's what I'm getting at.
>>>
>>> 24 bits is probably wide enough at any rate though, for most work,
>>> especially if you only go through the process one time, and don't keep
>>> going back and forth, but my concern was that there was no dither
>>> option in reaper when you down size like this, when you go from bigger
>>> to smaller, you should always dither which takes care of the potential
>>> for truncated data, so you don't get ragged edges.
>>>
>>> 24 bit is huge, and 64 bit is even
>>> more so,
>>> noise floors will be something like 135 140 db down, and I don't even
>>> know what they'd be for a 64 bit file, nothing our systems could
>>> produce for sure, but I was jus thinking since there is no dither
>>> internally that I know of keeping things the same till the last dither
>>> might be the safest, speaking strictly from a technical point of view.
>>> But 24 bit rendering is not at all a bad compromise, and I would have
>>> to do some testing with some long tails to see if I could hear
>>> anything.
>>>
>>>
>>> On 10/19/2015 3:00 AM, Justin Macleod via RWP wrote:
>>>>
>>>> Hi,
>>>>
>>>> I'm slightly confused.
>>>>
>>>> You said:
>>>>
>>>> so considering our plug-ins generally process at 32 or 64 bit if we
>>>> render out at 24 bit and then brin the file back in for further use,
>>>> then we theoretically might be throwing away some resolution.
>>>>
>>>> But why would we do that? If you needed the file again, why would you
>>>> not just open the project with it in and copy the audio across? Then
>>>> you would have the 64-bit version. I totally see the need when gluing
>>>> items and freezing tracks, but rendering out everything at 64 bit
>>>> float when you have the projects anyway strikes me as being
>>>> exceedingly hard-drive space intensive.
>>>>
>>>> Plus, how is using 24-bit files that you've have rendered out from
>>>> previous projects any different from a DJ mixing with 16-bit CD
>>>> tracks for mix tapes or film production houses using 24-bit sound
>>>> effects and royalty free music. If you use any third-party media at
>>>> all in your projects, from sample libraries etc, you're going to be
>>>> taking the same quality hit as compared to a 64 bit version of the
>>>> same file.
>>>>
>>>> Sorry if I'm being dense and have missed something,
>>>>
>>>> Justin
>>>>
>>>> *From:*RWP [mailto:rwp-bounces at bluegrasspals.com] *On Behalf Of
>>>> *Tayeb Meftah via RWP
>>>> *Sent:* 19 October 2015 08:14
>>>> *To:* Reapers Without Peepers <rwp at bluegrasspals.com>
>>>> *Cc:* Tayeb Meftah <tayeb.meftah at gmail.com>
>>>> *Subject:* Re: [Rwp] rendering again
>>>>
>>>> HELLO Chris
>>>>
>>>> out of subject question
>>>>
>>>> i wonder are you a blind person?
>>>>
>>>> or a sighted person helping here?
>>>>
>>>> thank
>>>>
>>>>
>>>> Envoyé de mon iPad
>>>>
>>>>
>>>> Le 19 oct. 2015 à 05:56, Chris Belle via RWP <rwp at bluegrasspals.com
>>>> <mailto:rwp at bluegrasspals.com>> a écrit :
>>>>
>>>> Been reading the manual and playing with reapers different options
>>>> for rendering and bit depth and dithering and such.
>>>>
>>>>
>>>> I noticed, when you consolidate or export tracks,
>>>> there is no option for dither there.
>>>>
>>>> When you render to a bigger bit depth than you are recording,
>>>> the extra bits are padded with zeros theoretically, but when you
>>>> go the other way, you want something to fix up those rounding
>>>> errors, or ragged tails you might have on the ends.
>>>> way down low.
>>>>
>>>> You'd never hear it probably with any modern mix hugging the top
>>>> end of the scale, but sonar has dithering options all through the
>>>> architecture,
>>>> you can set dither for triangular or rectangular, or pow r 3, or
>>>> turn it off is you want, but the only place I find it in reaper is
>>>> a single noise shaping option and dither option for rendering.
>>>>
>>>> so because of that reason, I wonder if maybe best practice in
>>>> reaper is to set everything the same across the board the same
>>>> until you are going to do your final render.
>>>>
>>>> In other words, since reaper defaults to 64 bit mixing resolution
>>>> then maybe we should render to 64 bit floating point.
>>>> Sonar's rendering is set to 32 floating point by default,
>>>> and there is a check box to check and uncheck the 64 bit double
>>>> precission processing engine, which probably equates to reapers 64
>>>> bit internal mixing depth,
>>>> so considering our plug-ins generally process at 32 or 64 bit
>>>> if we render out at 24 bit and then brin the file back in for
>>>> further use, then we theoretically might be throwing away some
>>>> resolution.
>>>>
>>>> But leaving everything at 32 or 64 bit, and leaving any shaving
>>>> down of the file till the very last would guarantee never to
>>>> introduce rounding errors to the process.
>>>> The way it is now, if we ever need to use the consolidate options
>>>> or the batch file processing, and we choose a lower bit rate, than
>>>> what the files are in at present, then
>>>> I seriously wonder if reaper does just truncate those extra bits.
>>>> Also I wonder even when dithering down when we use the render
>>>> option which does give us that single dither and noise shaping
>>>> options,
>>>> even when we are rendering to 24 bit, if we are coming from a 32
>>>> or 64 bit environment,
>>>> if we should go ahead and turn on dither.
>>>> Reaper also has some interesting features that you can't do in
>>>> sonar, like reducing the mixing latency down to even 8 bits if you
>>>> like.
>>>>
>>>> And some things I've never seen like 39 bit and 12 bit.
>>>>
>>>> Which makes me think that maybe if you want to do straight
>>>> recording, and never dither at all, for something casual, where
>>>> processing has already been applied,
>>>> oh, for instance a radio show marathon that went on for a weekend,
>>>> and you wanted to just go off and leave it and then come back and
>>>> if you didn't do any volume changes, or any processes inside
>>>> reaper involving plugs, or gain staging and such, since
>>>> technically with a DAW, or you don't change a fader anywhere then
>>>> what you put in should be the same as what you get out,
>>>> then I wonder if lowering the mixing resolution down to the file
>>>> format you want, say 16 bit or 24 bit, I wonder if that makes any
>>>> sense?
>>>>
>>>>
>>>> _______________________________________________
>>>> RWP mailing list
>>>> RWP at bluegrasspals.com <mailto:RWP at bluegrasspals.com>
>>>> http://bluegrasspals.com/mailman/listinfo/rwp
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> RWP mailing list
>>>> RWP at bluegrasspals.com
>>>> http://bluegrasspals.com/mailman/listinfo/rwp
>>>
>>
>> _______________________________________________
>> RWP mailing list
>> RWP at bluegrasspals.com
>> http://bluegrasspals.com/mailman/listinfo/rwp
>>
>>
>> _______________________________________________
>> RWP mailing list
>> RWP at bluegrasspals.com
>> http://bluegrasspals.com/mailman/listinfo/rwp
>>
>>
>> _______________________________________________
>> RWP mailing list
>> RWP at bluegrasspals.com
>> http://bluegrasspals.com/mailman/listinfo/rwp
>>
>
> _______________________________________________
> RWP mailing list
> RWP at bluegrasspals.com
> http://bluegrasspals.com/mailman/listinfo/rwp
>
>
> _______________________________________________
> RWP mailing list
> RWP at bluegrasspals.com
> http://bluegrasspals.com/mailman/listinfo/rwp
>
More information about the RWP
mailing list