Is there a command-line flag to set 0dbfs?

[Jacob Joaquin]

Is there a command-line flag to set 0dbfs?

Thanks,
Jake
--
The Csound Blog - http://csound.noisepages.com/


Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[richarddobson]

It is almost certianly not safe to have one - prevailing practice
amongst Csounders is to write explicit values for amplitude; whether
they have set 0dbfs or not. For it to work as a command line flag, ~all~
amplitudes would have to be written explicitly as relative to 0dbFS
(including in the score). It might be a very good idea (at the price of
some verbosity in the code); but it is rather a large cultural shift!

Richard Dobson

Jacob Joaquin wrote:
> Is there a command-line flag to set 0dbfs?
>
> Thanks,
> Jake




Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Jacob Joaquin]

At the risk of sounding like I don't know what I'm talking about
(which happens to be the case, but at least I'll learn something)...

Let's say I set 0dbfs to 1.0.  All my amplitudes are explicit values
(1.0, 0.5, 0.333, etc.)  After I render the file, the overall amps is
0.677.  Can I set 0dbfs to 0.677 to do a normalized render? Or does
this alter the relative amplitudes between notes?

Best,
Jake
--
The Csound Blog - http://csound.noisepages.com/


On Mon, Nov 2, 2009 at 11:34 AM, Richard Dobson
<richarddobson@...> wrote:
> It is almost certianly not safe to have one - prevailing practice amongst
> Csounders is to write explicit values for amplitude; whether they have set
> 0dbfs or not. For it to work as a command line flag, ~all~ amplitudes would
> have to be written explicitly as relative to 0dbFS (including in the score).
> It might be a very good idea (at the price of some verbosity in the code);
> but it is rather a large cultural shift!
>
> Richard Dobson


Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[richarddobson]

Jacob Joaquin wrote:

> At the risk of sounding like I don't know what I'm talking about
> (which happens to be the case, but at least I'll learn something)...
>
> Let's say I set 0dbfs to 1.0.  All my amplitudes are explicit values
> (1.0, 0.5, 0.333, etc.)  After I render the file, the overall amps is
> 0.677.  Can I set 0dbfs to 0.677 to do a normalized render? Or does
> this alter the relative amplitudes between notes?
>
> Best,
> Jake

Well, I admit that idea  had not occurred to me! But those amplitudes
are still absolute until scaled relative to 0dBFS at the point of
writing the samples, so that if you set 0dBFS to 0.677, but have an
amplitude in your orch of 1.0, that becomes overrange by 1.0/0.677.

Just as, if 0dBFS is the default 32767 and you set an amplitude value of
1.0, you end up with a virtually silent file.

What would be required would be to write, say,

asig oscil  0.5*0dBFS, 440,1

and so on. Eveywhere.

Having said that, I would not recommend normalising to above -3dB (=
0.7071), unless the waveform is a sinusoid, and 0.677 is very close to
that already. The analogue waveform between adjacent samples can quite
easily be a larger level.  Think "Gibbs effect" on square waves, etc.
Normalized to digital peak, they will in principle overload (or clip) at
the converter. At a pinch you could normalise to -1.5dB and survive,
most of the time.

I would suggest that tasks such as normalising are best kept separate
from compositional processes, as part of final mastering (since you
might well want to add some dither too).

Richard Dobson






Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Jacob Joaquin]

Thanks for the insight, and answering at least one question before I
had a chance to ask. Specifically about why we should normalize to
-3dB. I've seen it done this way, as such with the OLPC Berklee sample
library, but didn't know the reason why.

My intention is to blog about this normalizing 0dbfs trick. Though it
appears I'm going to have to discard much of what I've written while
adding a few other things.

Best,
Jake
--
The Csound Blog - http://csound.noisepages.com/

> Well, I admit that idea  had not occurred to me! But those amplitudes are
> still absolute until scaled relative to 0dBFS at the point of writing the
> samples, so that if you set 0dBFS to 0.677, but have an amplitude in your
> orch of 1.0, that becomes overrange by 1.0/0.677.
>
> Just as, if 0dBFS is the default 32767 and you set an amplitude value of
> 1.0, you end up with a virtually silent file.
>
> What would be required would be to write, say,
>
> asig oscil  0.5*0dBFS, 440,1
>
> and so on. Eveywhere.
>
> Having said that, I would not recommend normalising to above -3dB (=
> 0.7071), unless the waveform is a sinusoid, and 0.677 is very close to that
> already. The analogue waveform between adjacent samples can quite easily be
> a larger level.  Think "Gibbs effect" on square waves, etc. Normalized to
> digital peak, they will in principle overload (or clip) at the converter. At
> a pinch you could normalise to -1.5dB and survive, most of the time.
>
> I would suggest that tasks such as normalising are best kept separate from
> compositional processes, as part of final mastering (since you might well
> want to add some dither too).
>
> Richard Dobson

Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Jacob Joaquin]

I ran some tests and discovered this equation for bringing the ceiling
3dB above the overall amps produced from a Csound render:

10 ** (3.0 / 20.0) * overall_amps

In the case of trapped.csd, the overall amps produced from a render is
31755.3.  Running it through the equation gives a value of
44855.553490758954.  In the orchestra of trapped, I set 0dbfs to this
value for a normalized render.

0dbfs = 44855.553490758954

Am I correct in saying that trapped renders -3dB from the ceiling in
this scenario?

Providing the above information is true. I discovered that this
technique only works with absolute numbers. If any relative amplitudes
exist, these will scale proportionately with any changes made to
0dbfs.  For example:

a1 oscils 0.5 * 0dbfs, 440, 0
a2 diskin2 "foo.aif", 1  ; This opcode scales with 0dbfs

Absolute numbers work because the ceiling can be moved closer or
farther away from the absolute values.

Best,
Jake
--
The Csound Blog - http://csound.noisepages.com/

> Well, I admit that idea  had not occurred to me! But those amplitudes are
> still absolute until scaled relative to 0dBFS at the point of writing the
> samples, so that if you set 0dBFS to 0.677, but have an amplitude in your
> orch of 1.0, that becomes overrange by 1.0/0.677.
>
> Just as, if 0dBFS is the default 32767 and you set an amplitude value of
> 1.0, you end up with a virtually silent file.
>
> What would be required would be to write, say,
>
> asig oscil  0.5*0dBFS, 440,1
>
> and so on. Eveywhere.
>
> Having said that, I would not recommend normalising to above -3dB (=
> 0.7071), unless the waveform is a sinusoid, and 0.677 is very close to that
> already. The analogue waveform between adjacent samples can quite easily be
> a larger level.  Think "Gibbs effect" on square waves, etc. Normalized to
> digital peak, they will in principle overload (or clip) at the converter. At
> a pinch you could normalise to -1.5dB and survive, most of the time.
>
> I would suggest that tasks such as normalising are best kept separate from
> compositional processes, as part of final mastering (since you might well
> want to add some dither too).
>
> Richard Dobson

Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[richarddobson]

At the risk of asking the obvious - there can't be many calls to "outs"
etc in "trapped". Would it not be both simpler and clearer simply to
scale the arguments to outs by an appropriate amount?

The reason for having 0dBFS is not as a hack to overcome arbitrary
overrange or normalisation tasks, but to formalize levels to a
reasonable convention; of which really the only reasonable one these
days is 1.0.

Sure you can set 0dBFS to any value, including 44855.whatever; but such
a value has no meaning or significance. I am unable to see it as
something one could possibly recommend as any form of good practice. If
you need to reduce amplitudes, reduce amplitudes!

0dBFS was/is supposed to contribute to the self-documenting of the code
(not least, to demonstrate the Csound language's independence from
sample type).  The best suggestion I have, following your line of
argument, is to use it to define a formal amount of ~headroom~ for
real-time streaming purposes. Given that nominal 0dBFS is 1.0, so that
all amplitudes are defined relative to that level, you can then redefine
0dBFS to say 2.0, which would establish 6dB of headroom. If you are
rendering to a hi-res size (24bit or floats), headroom of 18dB is common
in professional studios; I have seen 20dB mentioned. See the various
descriptions on the net about Bob Katz's "K-meter" system. But I would
regard even this as dangerous; not least for the reasons you describe
regarding local use of 0dBFS. At best and worst, I suggest 0dBFS should
be some comprehensible round number. If it is still in the
documentation, I remember suggesting that you might want to use 1000 as
the value, as an easy number to work with.


And my opinion still is that (at least where the task actually is to
create a soundfile) the task of post-normalising a file (to whatever
standard reference level) should be a separate and external procedure.

When I defined 0dBFS I gave a lot of thought to the idea of defining a
"headroom" global opcode along with it, given the increasing use of
Csound for real-time work. It would act as an additional scalar on all
amplitude values. Perhaps it is time to revisit that idea?

Richard Dobson



Jacob Joaquin wrote:

> I ran some tests and discovered this equation for bringing the ceiling
> 3dB above the overall amps produced from a Csound render:
>
> 10 ** (3.0 / 20.0) * overall_amps
>
> In the case of trapped.csd, the overall amps produced from a render is
> 31755.3.  Running it through the equation gives a value of
> 44855.553490758954.  In the orchestra of trapped, I set 0dbfs to this
> value for a normalized render.
>
> 0dbfs = 44855.553490758954
>
> Am I correct in saying that trapped renders -3dB from the ceiling in
> this scenario?
>
> Providing the above information is true. I discovered that this
> technique only works with absolute numbers. If any relative amplitudes
> exist, these will scale proportionately with any changes made to
> 0dbfs.  For example:
>
> a1 oscils 0.5 * 0dbfs, 440, 0
> a2 diskin2 "foo.aif", 1  ; This opcode scales with 0dbfs
>
> Absolute numbers work because the ceiling can be moved closer or
> farther away from the absolute values.
>
> Best,
> Jake

Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Jacob Joaquin]

I've learned more about Csound by hacking and abusing it than I ever
would have if I stayed within the confines of what is considered
accepted or intended practices. I would prefer a better alternative to
hacking 0dbfs, such as a final output scaler that did its scaling
inside Csound's native internal resolution of 32 or 64 bit float.
Until an alternative exists, I'm happy to have this hack available to
me, whether I'm producing a master sound file, or I'm in a time pinch
and need to overcome some clipping issues without doing major revision
work.

Best,
Jake
--
The Csound Blog - http://csound.noisepages.com/


On Tue, Nov 3, 2009 at 10:03 AM, Richard Dobson
<richarddobson@...> wrote:

> At the risk of asking the obvious - there can't be many calls to "outs" etc
> in "trapped". Would it not be both simpler and clearer simply to scale the
> arguments to outs by an appropriate amount?
>
> The reason for having 0dBFS is not as a hack to overcome arbitrary overrange
> or normalisation tasks, but to formalize levels to a reasonable convention;
> of which really the only reasonable one these days is 1.0.
>
> Sure you can set 0dBFS to any value, including 44855.whatever; but such a
> value has no meaning or significance. I am unable to see it as something one
> could possibly recommend as any form of good practice. If you need to reduce
> amplitudes, reduce amplitudes!
>
> 0dBFS was/is supposed to contribute to the self-documenting of the code (not
> least, to demonstrate the Csound language's independence from sample type).
>  The best suggestion I have, following your line of argument, is to use it
> to define a formal amount of ~headroom~ for real-time streaming purposes.
> Given that nominal 0dBFS is 1.0, so that all amplitudes are defined relative
> to that level, you can then redefine 0dBFS to say 2.0, which would establish
> 6dB of headroom. If you are rendering to a hi-res size (24bit or floats),
> headroom of 18dB is common in professional studios; I have seen 20dB
> mentioned. See the various descriptions on the net about Bob Katz's
> "K-meter" system. But I would regard even this as dangerous; not least for
> the reasons you describe regarding local use of 0dBFS. At best and worst, I
> suggest 0dBFS should be some comprehensible round number. If it is still in
> the documentation, I remember suggesting that you might want to use 1000 as
> the value, as an easy number to work with.
>
>
> And my opinion still is that (at least where the task actually is to create
> a soundfile) the task of post-normalising a file (to whatever standard
> reference level) should be a separate and external procedure.
>
> When I defined 0dBFS I gave a lot of thought to the idea of defining a
> "headroom" global opcode along with it, given the increasing use of Csound
> for real-time work. It would act as an additional scalar on all amplitude
> values. Perhaps it is time to revisit that idea?
>
> Richard Dobson

Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Michael Gogins-2]

There is a scale utility which I use all the time, and have integrated
into my composition scripts. It is part of Csound and it's in the
manual. Basically I use it to rescale everything to -3 dBFS relative
to 1.0 amplitude after rendering.

In fact, every piece I do is a variation on this one script.

It renders to 88200 Hz float stereo.
It then rescales to -3 dBFS relative to 1.0 amplitude.
It then makes a CD-Audio version of the file.
It then makes an MP3 version of the file.
All of these have ID tags in them so they are ready for distribution.



On 11/3/09, Jacob Joaquin <jacobjoaquin@...> wrote:

> I've learned more about Csound by hacking and abusing it than I ever
> would have if I stayed within the confines of what is considered
> accepted or intended practices. I would prefer a better alternative to
> hacking 0dbfs, such as a final output scaler that did its scaling
> inside Csound's native internal resolution of 32 or 64 bit float.
> Until an alternative exists, I'm happy to have this hack available to
> me, whether I'm producing a master sound file, or I'm in a time pinch
> and need to overcome some clipping issues without doing major revision
> work.
>
> Best,
> Jake
> --
> The Csound Blog - http://csound.noisepages.com/
>
>
> On Tue, Nov 3, 2009 at 10:03 AM, Richard Dobson
> <richarddobson@...> wrote:
>> At the risk of asking the obvious - there can't be many calls to "outs"
>> etc
>> in "trapped". Would it not be both simpler and clearer simply to scale the
>> arguments to outs by an appropriate amount?
>>
>> The reason for having 0dBFS is not as a hack to overcome arbitrary
>> overrange
>> or normalisation tasks, but to formalize levels to a reasonable
>> convention;
>> of which really the only reasonable one these days is 1.0.
>>
>> Sure you can set 0dBFS to any value, including 44855.whatever; but such a
>> value has no meaning or significance. I am unable to see it as something
>> one
>> could possibly recommend as any form of good practice. If you need to
>> reduce
>> amplitudes, reduce amplitudes!
>>
>> 0dBFS was/is supposed to contribute to the self-documenting of the code
>> (not
>> least, to demonstrate the Csound language's independence from sample
>> type).
>>  The best suggestion I have, following your line of argument, is to use it
>> to define a formal amount of ~headroom~ for real-time streaming purposes.
>> Given that nominal 0dBFS is 1.0, so that all amplitudes are defined
>> relative
>> to that level, you can then redefine 0dBFS to say 2.0, which would
>> establish
>> 6dB of headroom. If you are rendering to a hi-res size (24bit or floats),
>> headroom of 18dB is common in professional studios; I have seen 20dB
>> mentioned. See the various descriptions on the net about Bob Katz's
>> "K-meter" system. But I would regard even this as dangerous; not least for
>> the reasons you describe regarding local use of 0dBFS. At best and worst,
>> I
>> suggest 0dBFS should be some comprehensible round number. If it is still
>> in
>> the documentation, I remember suggesting that you might want to use 1000
>> as
>> the value, as an easy number to work with.
>>
>>
>> And my opinion still is that (at least where the task actually is to
>> create
>> a soundfile) the task of post-normalising a file (to whatever standard
>> reference level) should be a separate and external procedure.
>>
>> When I defined 0dBFS I gave a lot of thought to the idea of defining a
>> "headroom" global opcode along with it, given the increasing use of Csound
>> for real-time work. It would act as an additional scalar on all amplitude
>> values. Perhaps it is time to revisit that idea?
>>
>> Richard Dobson
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@... with body "unsubscribe
> csound"

--
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com


Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Jacob Joaquin]

I certainly have other programs that scale as well. My point is to
scale while the signal is still inside Csound's native 32 or 64 bit
floats, without having to rewrite code, or implement scalers at each
output.

Best,
Jake
--
The Csound Blog - http://csound.noisepages.com/


On Tue, Nov 3, 2009 at 11:47 AM, Michael Gogins
<michael.gogins@...> wrote:

> There is a scale utility which I use all the time, and have integrated
> into my composition scripts. It is part of Csound and it's in the
> manual. Basically I use it to rescale everything to -3 dBFS relative
> to 1.0 amplitude after rendering.
>
> In fact, every piece I do is a variation on this one script.
>
> It renders to 88200 Hz float stereo.
> It then rescales to -3 dBFS relative to 1.0 amplitude.
> It then makes a CD-Audio version of the file.
> It then makes an MP3 version of the file.
> All of these have ID tags in them so they are ready for distribution.

Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Michael Gogins-2]

Do you specify loudness in your scores in decibels, if so relative to
what, MIDI velocity, amplitude, gain, or what?

Regards,
Mike

On 11/3/09, Jacob Joaquin <jacobjoaquin@...> wrote:

> I certainly have other programs that scale as well. My point is to
> scale while the signal is still inside Csound's native 32 or 64 bit
> floats, without having to rewrite code, or implement scalers at each
> output.
>
> Best,
> Jake
> --
> The Csound Blog - http://csound.noisepages.com/
>
>
> On Tue, Nov 3, 2009 at 11:47 AM, Michael Gogins
> <michael.gogins@...> wrote:
>> There is a scale utility which I use all the time, and have integrated
>> into my composition scripts. It is part of Csound and it's in the
>> manual. Basically I use it to rescale everything to -3 dBFS relative
>> to 1.0 amplitude after rendering.
>>
>> In fact, every piece I do is a variation on this one script.
>>
>> It renders to 88200 Hz float stereo.
>> It then rescales to -3 dBFS relative to 1.0 amplitude.
>> It then makes a CD-Audio version of the file.
>> It then makes an MP3 version of the file.
>> All of these have ID tags in them so they are ready for distribution.
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@... with body "unsubscribe
> csound"
>

--
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com


Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Jacob Joaquin]

Scaling based on the overall amps value at the end of Csound's render
output message.

Best,
Jake
--
The Csound Blog - http://csound.noisepages.com/


On Tue, Nov 3, 2009 at 11:59 AM, Michael Gogins
<michael.gogins@...> wrote:
> Do you specify loudness in your scores in decibels, if so relative to
> what, MIDI velocity, amplitude, gain, or what?
>
> Regards,
> Mike


Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[richarddobson]

..

>
> On 11/3/09, Jacob Joaquin <jacobjoaquin@...> wrote:
>> I certainly have other programs that scale as well. My point is to
>> scale while the signal is still inside Csound's native 32 or 64 bit
>> floats, without having to rewrite code, or implement scalers at each
>> output.
>>
>> Best,
>> Jake
>> --

My solution to the issue would certainly be some variation on the theme
of a "headroom" argument. One approach would be to have it as a command
line flag; and all it would do would be to report output amplitudes
relative to the headroom level. So that (to take the example of
"trapped", peak at 0.969) if you set "--headroom=3"  (meaning 3dB below
0dBFS), the Csound output would report dB levels relative to that; in
this case +2.737 dB. A host could easily retain such a value and on the
second performance run adjust the data to the nominated headroom level.
This is also one of the purposes of the PEAK chunk; to enable
single-pass normalisation (or other rescaling e.g. if overrange) when
Csound loads a soundfile.

Richard Dobson




Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Michael Gogins-2]

This does not answer my question. How do you specify loudness as a
composer, loudness for each note, in the score?

Regards,
Mike

On 11/3/09, Richard Dobson <richarddobson@...> wrote:

> ..
>>
>> On 11/3/09, Jacob Joaquin <jacobjoaquin@...> wrote:
>>> I certainly have other programs that scale as well. My point is to
>>> scale while the signal is still inside Csound's native 32 or 64 bit
>>> floats, without having to rewrite code, or implement scalers at each
>>> output.
>>>
>>> Best,
>>> Jake
>>> --
>
>
> My solution to the issue would certainly be some variation on the theme
> of a "headroom" argument. One approach would be to have it as a command
> line flag; and all it would do would be to report output amplitudes
> relative to the headroom level. So that (to take the example of
> "trapped", peak at 0.969) if you set "--headroom=3"  (meaning 3dB below
> 0dBFS), the Csound output would report dB levels relative to that; in
> this case +2.737 dB. A host could easily retain such a value and on the
> second performance run adjust the data to the nominated headroom level.
> This is also one of the purposes of the PEAK chunk; to enable
> single-pass normalisation (or other rescaling e.g. if overrange) when
> Csound loads a soundfile.
>
> Richard Dobson
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@... with body "unsubscribe
> csound"
>

--
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com


Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[richarddobson]

I guess you will have to ask Jacob that; I was responding to his post.

Sadly I have not done much by way of composing, whether in Csound or
otherwise, for a while. But all my own instincts are towards dB, and
those  ampdbfs opcodes I wrote. For my usual brand of test signal, I am
doing little or no enveloping, and will then usually just use raw amp
values in the orch.

But if I were to compose something substantial, I would probably try to
rig a look up table or something so i could write "mf", "pp" etc and
have them translated into dB somehow. The Csound string limits might be
a problem though...



Richard Dobson



Michael Gogins wrote:

> This does not answer my question. How do you specify loudness as a
> composer, loudness for each note, in the score?
>
> Regards,
> Mike
>
> On 11/3/09, Richard Dobson <richarddobson@...> wrote:
>> ..
>>> On 11/3/09, Jacob Joaquin <jacobjoaquin@...> wrote:
>>>> I certainly have other programs that scale as well. My point is to
>>>> scale while the signal is still inside Csound's native 32 or 64 bit
>>>> floats, without having to rewrite code, or implement scalers at each
>>>> output.
>>>>
>>>> Best,
>>>> Jake
>>>> --
>>
>> My solution to the issue ...

Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Jacob Joaquin]

Usually in amps, though I do occasionally flirt with dBs from time to time.

Best,
Jake
--
The Csound Blog - http://csound.noisepages.com/

On Tue, Nov 3, 2009 at 12:51 PM, Michael Gogins
<michael.gogins@...> wrote:

> This does not answer my question. How do you specify loudness as a
> composer, loudness for each note, in the score?
>
> Regards,
> Mike
>
> On 11/3/09, Richard Dobson <richarddobson@...> wrote:
>> ..
>>>
>>> On 11/3/09, Jacob Joaquin <jacobjoaquin@...> wrote:
>>>> I certainly have other programs that scale as well. My point is to
>>>> scale while the signal is still inside Csound's native 32 or 64 bit
>>>> floats, without having to rewrite code, or implement scalers at each
>>>> output.
>>>>
>>>> Best,
>>>> Jake
>>>> --
>>
>>
>> My solution to the issue would certainly be some variation on the theme
>> of a "headroom" argument. One approach would be to have it as a command
>> line flag; and all it would do would be to report output amplitudes
>> relative to the headroom level. So that (to take the example of
>> "trapped", peak at 0.969) if you set "--headroom=3"  (meaning 3dB below
>> 0dBFS), the Csound output would report dB levels relative to that; in
>> this case +2.737 dB. A host could easily retain such a value and on the
>> second performance run adjust the data to the nominated headroom level.
>> This is also one of the purposes of the PEAK chunk; to enable
>> single-pass normalisation (or other rescaling e.g. if overrange) when
>> Csound loads a soundfile.
>>
>> Richard Dobson
>>
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@... with body "unsubscribe
>> csound"
>>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@... with body "unsubscribe csound"
>

Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Andres Cabrera]

You could also use the monitor opcode to get the output and scale that.

Cheers,
Andrés

On Tue, Nov 3, 2009 at 10:14 PM, Jacob Joaquin <jacobjoaquin@...> wrote:

> Usually in amps, though I do occasionally flirt with dBs from time to time.
>
> Best,
> Jake
> --
> The Csound Blog - http://csound.noisepages.com/
>
> On Tue, Nov 3, 2009 at 12:51 PM, Michael Gogins
> <michael.gogins@...> wrote:
>> This does not answer my question. How do you specify loudness as a
>> composer, loudness for each note, in the score?
>>
>> Regards,
>> Mike
>>
>> On 11/3/09, Richard Dobson <richarddobson@...> wrote:
>>> ..
>>>>
>>>> On 11/3/09, Jacob Joaquin <jacobjoaquin@...> wrote:
>>>>> I certainly have other programs that scale as well. My point is to
>>>>> scale while the signal is still inside Csound's native 32 or 64 bit
>>>>> floats, without having to rewrite code, or implement scalers at each
>>>>> output.
>>>>>
>>>>> Best,
>>>>> Jake
>>>>> --
>>>
>>>
>>> My solution to the issue would certainly be some variation on the theme
>>> of a "headroom" argument. One approach would be to have it as a command
>>> line flag; and all it would do would be to report output amplitudes
>>> relative to the headroom level. So that (to take the example of
>>> "trapped", peak at 0.969) if you set "--headroom=3"  (meaning 3dB below
>>> 0dBFS), the Csound output would report dB levels relative to that; in
>>> this case +2.737 dB. A host could easily retain such a value and on the
>>> second performance run adjust the data to the nominated headroom level.
>>> This is also one of the purposes of the PEAK chunk; to enable
>>> single-pass normalisation (or other rescaling e.g. if overrange) when
>>> Csound loads a soundfile.
>>>
>>> Richard Dobson
>>>
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@... with body "unsubscribe
>>> csound"
>>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@... with body "unsubscribe csound"
>>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@... with body "unsubscribe csound"

--


Andrés


Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Michael Gogins-2]

In that case I think just adjusting 0dbfs=something till it works out
right is fine. That is what I used to do until I switched to my
normalizing script.

Regards,
Mike

On 11/3/09, Jacob Joaquin <jacobjoaquin@...> wrote:

> Usually in amps, though I do occasionally flirt with dBs from time to time.
>
> Best,
> Jake
> --
> The Csound Blog - http://csound.noisepages.com/
>
> On Tue, Nov 3, 2009 at 12:51 PM, Michael Gogins
> <michael.gogins@...> wrote:
>> This does not answer my question. How do you specify loudness as a
>> composer, loudness for each note, in the score?
>>
>> Regards,
>> Mike
>>
>> On 11/3/09, Richard Dobson <richarddobson@...> wrote:
>>> ..
>>>>
>>>> On 11/3/09, Jacob Joaquin <jacobjoaquin@...> wrote:
>>>>> I certainly have other programs that scale as well. My point is to
>>>>> scale while the signal is still inside Csound's native 32 or 64 bit
>>>>> floats, without having to rewrite code, or implement scalers at each
>>>>> output.
>>>>>
>>>>> Best,
>>>>> Jake
>>>>> --
>>>
>>>
>>> My solution to the issue would certainly be some variation on the theme
>>> of a "headroom" argument. One approach would be to have it as a command
>>> line flag; and all it would do would be to report output amplitudes
>>> relative to the headroom level. So that (to take the example of
>>> "trapped", peak at 0.969) if you set "--headroom=3"  (meaning 3dB below
>>> 0dBFS), the Csound output would report dB levels relative to that; in
>>> this case +2.737 dB. A host could easily retain such a value and on the
>>> second performance run adjust the data to the nominated headroom level.
>>> This is also one of the purposes of the PEAK chunk; to enable
>>> single-pass normalisation (or other rescaling e.g. if overrange) when
>>> Csound loads a soundfile.
>>>
>>> Richard Dobson
>>>
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@... with body "unsubscribe
>>> csound"
>>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@... with body "unsubscribe
>> csound"
>>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@... with body "unsubscribe
> csound"

--
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com


Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Felipe Sateler]

On Mon, 2009-11-02 at 21:00 +0000, Richard Dobson wrote:

> Jacob Joaquin wrote:
> > At the risk of sounding like I don't know what I'm talking about
> > (which happens to be the case, but at least I'll learn something)...
> >
> > Let's say I set 0dbfs to 1.0.  All my amplitudes are explicit values
> > (1.0, 0.5, 0.333, etc.)  After I render the file, the overall amps is
> > 0.677.  Can I set 0dbfs to 0.677 to do a normalized render? Or does
> > this alter the relative amplitudes between notes?
> >
> > Best,
> > Jake
>
> Well, I admit that idea  had not occurred to me! But those amplitudes
> are still absolute until scaled relative to 0dBFS at the point of
> writing the samples

Does this make csound slower than if no scaling is done? Phrased
differently, does this 0dbfs flexibility make csound a bit slower than
forcing a certain value of 0dbfs (like PD or Max do)?


--
Saludos,
Felipe Sateler

[Michael Gogins-2]

Once Csound is rendering the scaling is accomplished by one
multiplication per audio sample... in the context of everything else
that is happening this is additional overhead only in the theoretical
sense, there is no additional overhead in any practical sense.

Regards,
Mike

On 11/4/09, Felipe Sateler <fsateler@...> wrote:

> On Mon, 2009-11-02 at 21:00 +0000, Richard Dobson wrote:
>> Jacob Joaquin wrote:
>> > At the risk of sounding like I don't know what I'm talking about
>> > (which happens to be the case, but at least I'll learn something)...
>> >
>> > Let's say I set 0dbfs to 1.0.  All my amplitudes are explicit values
>> > (1.0, 0.5, 0.333, etc.)  After I render the file, the overall amps is
>> > 0.677.  Can I set 0dbfs to 0.677 to do a normalized render? Or does
>> > this alter the relative amplitudes between notes?
>> >
>> > Best,
>> > Jake
>>
>> Well, I admit that idea  had not occurred to me! But those amplitudes
>> are still absolute until scaled relative to 0dBFS at the point of
>> writing the samples
>
> Does this make csound slower than if no scaling is done? Phrased
> differently, does this 0dbfs flexibility make csound a bit slower than
> forcing a certain value of 0dbfs (like PD or Max do)?
>
>
> --
> Saludos,
> Felipe Sateler
>

--
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com


Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"