[Rwp] rendering again

Tue Oct 20 10:54:21 EDT 2015

Right, in project settings alt enter.

On 10/20/2015 9:05 AM, Clarence Griffin via RWP wrote:
> 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
>