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

Thanks,
Jake

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@lists.bath.ac.uk with body "unsubscribe csound"

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

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@lists.bath.ac.uk with body "unsubscribe csound"

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@lists.bath.ac.uk with body "unsubscribe csound"

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@lists.bath.ac.uk with body "unsubscribe csound"

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@lists.bath.ac.uk with body "unsubscribe csound"

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
 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@lists.bath.ac.uk with body "unsubscribe csound"

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  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
>  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@lists.bath.ac.uk 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@lists.bath.ac.uk with body "unsubscribe csound"

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

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  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
>  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@lists.bath.ac.uk with body "unsubscribe
> csound"
>

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

Best,
Jake

..
> 
> On 11/3/09, Jacob Joaquin  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@lists.bath.ac.uk with body "unsubscribe csound"

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  wrote:
> ..
>>
>> On 11/3/09, Jacob Joaquin  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@lists.bath.ac.uk with body "unsubscribe
> csound"
>

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  wrote:
>> ..
>>> On 11/3/09, Jacob Joaquin  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@lists.bath.ac.uk with body "unsubscribe csound"

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
 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  wrote:
>> ..
>>>
>>> On 11/3/09, Jacob Joaquin  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@lists.bath.ac.uk 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@lists.bath.ac.uk with body "unsubscribe csound"
>


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

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  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
>  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  wrote:
>>> ..
>>>>
>>>> On 11/3/09, Jacob Joaquin  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@lists.bath.ac.uk 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@lists.bath.ac.uk with body "unsubscribe csound"
>>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



-- 


Andrés


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

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  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
>  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  wrote:
>>> ..
>>>>
>>>> On 11/3/09, Jacob Joaquin  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@lists.bath.ac.uk 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@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"

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

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

Hmm; I have just this minute discovered (csound 11.1 floats Intel OS X) 
  that writing to a floats WAVE outfile is wrong - the samples should be 
scaled to the proper +-1.0 range, but are not, they are just the 
explicit values from the orch (i.e 0dbfs ignored altogether), which of 
course is totally wrong for both WAVE and AIFF-C (at least). So there is 
in fact not quite as much overhead as there should be when writing a 
floats file. Has nobody been writing floats files at all? This can't 
possibly have gone unnoticed!

Richard Dobson




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

I only work on Windows XP and Eeebuntu Linux....

Regards,
Mike

On 11/4/09, Richard Dobson  wrote:
> Michael Gogins wrote:
>> 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.
>>
>
> Hmm; I have just this minute discovered (csound 11.1 floats Intel OS X)
>   that writing to a floats WAVE outfile is wrong - the samples should be
> scaled to the proper +-1.0 range, but are not, they are just the
> explicit values from the orch (i.e 0dbfs ignored altogether), which of
> course is totally wrong for both WAVE and AIFF-C (at least). So there is
> in fact not quite as much overhead as there should be when writing a
> floats file. Has nobody been writing floats files at all? This can't
> possibly have gone unnoticed!
>
> Richard Dobson
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>

I am sure this is not a specific OSX problem. There is nothing  
specific to OSX in the code.
It just uses libsndfile. So this is possibly just a bug in the file  
output.

I never used floats output files, so I guess I never checked this.

Victor
On 4 Nov 2009, at 21:37, Richard Dobson wrote:

> Michael Gogins wrote:
>> 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.
>
> Hmm; I have just this minute discovered (csound 11.1 floats Intel OS  
> X)  that writing to a floats WAVE outfile is wrong - the samples  
> should be scaled to the proper +-1.0 range, but are not, they are  
> just the explicit values from the orch (i.e 0dbfs ignored  
> altogether), which of course is totally wrong for both WAVE and AIFF- 
> C (at least). So there is in fact not quite as much overhead as  
> there should be when writing a floats file. Has nobody been writing  
> floats files at all? This can't possibly have gone unnoticed!
>
> Richard Dobson
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"



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

Well, it definitely works on Windows and I'm pretty sure it works on Linux.

I was just looking at libsnd_u.c. That's where it is. Line 265.

Regards,
Mike

On 11/4/09, Victor Lazzarini  wrote:
> I am sure this is not a specific OSX problem. There is nothing
> specific to OSX in the code.
> It just uses libsndfile. So this is possibly just a bug in the file
> output.
>
> I never used floats output files, so I guess I never checked this.
>
> Victor
> On 4 Nov 2009, at 21:37, Richard Dobson wrote:
>
>> Michael Gogins wrote:
>>> 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.
>>
>> Hmm; I have just this minute discovered (csound 11.1 floats Intel OS
>> X)  that writing to a floats WAVE outfile is wrong - the samples
>> should be scaled to the proper +-1.0 range, but are not, they are
>> just the explicit values from the orch (i.e 0dbfs ignored
>> altogether), which of course is totally wrong for both WAVE and AIFF-
>> C (at least). So there is in fact not quite as much overhead as
>> there should be when writing a floats file. Has nobody been writing
>> floats files at all? This can't possibly have gone unnoticed!
>>
>> Richard Dobson
>>
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> "unsubscribe csound"
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>

Michael Gogins wrote:
> Well, it definitely works on Windows and I'm pretty sure it works on Linux.
> 
> I was just looking at libsnd_u.c. That's where it is. Line 265.
> 

I have 5.10 floats on Suse 64bit; same problem.

Richard Dobson



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

And it seems to work here on OSX . I just rendered trapped  using -f   
to an RIFF-wave file and
opened in Audacity, perfectly. Just to be sure, I opened it again as  
Raw data, 32-bit floats and
Audacity read it perfectly.

So I am not sure what we are talking about here.

Victor


On 4 Nov 2009, at 22:00, Michael Gogins wrote:

> Well, it definitely works on Windows and I'm pretty sure it works on  
> Linux.
>
> I was just looking at libsnd_u.c. That's where it is. Line 265.
>
> Regards,
> Mike
>
> On 11/4/09, Victor Lazzarini  wrote:
>> I am sure this is not a specific OSX problem. There is nothing
>> specific to OSX in the code.
>> It just uses libsndfile. So this is possibly just a bug in the file
>> output.
>>
>> I never used floats output files, so I guess I never checked this.
>>
>> Victor
>> On 4 Nov 2009, at 21:37, Richard Dobson wrote:
>>
>>> Michael Gogins wrote:
>>>> 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.
>>>
>>> Hmm; I have just this minute discovered (csound 11.1 floats Intel OS
>>> X)  that writing to a floats WAVE outfile is wrong - the samples
>>> should be scaled to the proper +-1.0 range, but are not, they are
>>> just the explicit values from the orch (i.e 0dbfs ignored
>>> altogether), which of course is totally wrong for both WAVE and  
>>> AIFF-
>>> C (at least). So there is in fact not quite as much overhead as
>>> there should be when writing a floats file. Has nobody been writing
>>> floats files at all? This can't possibly have gone unnoticed!
>>>
>>> Richard Dobson
>>>
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>> "unsubscribe csound"
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk 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@lists.bath.ac.uk with body  
> "unsubscribe csound"



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

But if I write a headerless float file (-fh), Csound does not write it  
in the correct normalised range (-1.0 to 1.0) but uses the set 0dbfs  
(=32767), so that bit is wrong.

Victor

On 4 Nov 2009, at 22:09, Victor Lazzarini wrote:

> And it seems to work here on OSX . I just rendered trapped  using - 
> f  to an RIFF-wave file and
> opened in Audacity, perfectly. Just to be sure, I opened it again as  
> Raw data, 32-bit floats and
> Audacity read it perfectly.
>
> So I am not sure what we are talking about here.
>
> Victor
>
>
> On 4 Nov 2009, at 22:00, Michael Gogins wrote:
>
>> Well, it definitely works on Windows and I'm pretty sure it works  
>> on Linux.
>>
>> I was just looking at libsnd_u.c. That's where it is. Line 265.
>>
>> Regards,
>> Mike
>>
>> On 11/4/09, Victor Lazzarini  wrote:
>>> I am sure this is not a specific OSX problem. There is nothing
>>> specific to OSX in the code.
>>> It just uses libsndfile. So this is possibly just a bug in the file
>>> output.
>>>
>>> I never used floats output files, so I guess I never checked this.
>>>
>>> Victor
>>> On 4 Nov 2009, at 21:37, Richard Dobson wrote:
>>>
>>>> Michael Gogins wrote:
>>>>> 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.
>>>>
>>>> Hmm; I have just this minute discovered (csound 11.1 floats Intel  
>>>> OS
>>>> X)  that writing to a floats WAVE outfile is wrong - the samples
>>>> should be scaled to the proper +-1.0 range, but are not, they are
>>>> just the explicit values from the orch (i.e 0dbfs ignored
>>>> altogether), which of course is totally wrong for both WAVE and  
>>>> AIFF-
>>>> C (at least). So there is in fact not quite as much overhead as
>>>> there should be when writing a floats file. Has nobody been writing
>>>> floats files at all? This can't possibly have gone unnoticed!
>>>>
>>>> Richard Dobson
>>>>
>>>>
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>> "unsubscribe csound"
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk 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@lists.bath.ac.uk with body  
>> "unsubscribe csound"
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"



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

Victor Lazzarini wrote:
> And it seems to work here on OSX . I just rendered trapped  using -f  to 
> an RIFF-wave file and
> opened in Audacity, perfectly. Just to be sure, I opened it again as Raw 
> data, 32-bit floats and
> Audacity read it perfectly.
> 
> So I am not sure what we are talking about here.
> 

OK, have narrowed it down:  seems it is (for some reason) using the 
--format=wavex that presents the problem. I am writing B-Format files 
(and other multi-channel) so of course need WAVE_EX format.

Richard Dobson





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

Victor Lazzarini wrote:
> But if I write a headerless float file (-fh), Csound does not write it 
> in the correct normalised range (-1.0 to 1.0) but uses the set 0dbfs 
> (=32767), so that bit is wrong.
> 


Thats would depend entirely on what the rules are for headerless (raw?) 
files. I remember Istvan being especially insistent that raw floats 
files should receive exactly the unmodified output values -no scaling of 
any kind, presumably not even 0dbfs. I have no opinion on the proper 
writing of raw files (other than it should be known and documented so 
people know what to expect).  My concern with 0dbfs etc is entirely with 
regard to the standard headered formats that do mandate ranges.

Richard Dobson





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

This could be for the same reason that raw data is not written  
correctly.
Victor

On 4 Nov 2009, at 22:22, Richard Dobson wrote:

> Victor Lazzarini wrote:
>> And it seems to work here on OSX . I just rendered trapped  using - 
>> f  to an RIFF-wave file and
>> opened in Audacity, perfectly. Just to be sure, I opened it again  
>> as Raw data, 32-bit floats and
>> Audacity read it perfectly.
>> So I am not sure what we are talking about here.
>
> OK, have narrowed it down:  seems it is (for some reason) using the  
> --format=wavex that presents the problem. I am writing B-Format  
> files (and other multi-channel) so of course need WAVE_EX format.
>
> Richard Dobson
>
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"



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

I think at least 0dbfs should be applied, but still I think floating- 
point raw data should always be normalised, despite what Istvan might  
think, this is an established practice in computer music since a long  
time.
On 4 Nov 2009, at 22:26, Richard Dobson wrote:

> Victor Lazzarini wrote:
>> But if I write a headerless float file (-fh), Csound does not write  
>> it in the correct normalised range (-1.0 to 1.0) but uses the set  
>> 0dbfs (=32767), so that bit is wrong.
>
>
> Thats would depend entirely on what the rules are for headerless  
> (raw?) files. I remember Istvan being especially insistent that raw  
> floats files should receive exactly the unmodified output values -no  
> scaling of any kind, presumably not even 0dbfs. I have no opinion on  
> the proper writing of raw files (other than it should be known and  
> documented so people know what to expect).  My concern with 0dbfs  
> etc is entirely with regard to the standard headered formats that do  
> mandate ranges.
>
> Richard Dobson
>
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"



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

Victor Lazzarini wrote:
> I think at least 0dbfs should be applied, but still I think 
> floating-point raw data should always be normalised, despite what Istvan 
> might think, this is an established practice in computer music since a 
> long time.

No argument from me!

the only other currently presenting issue I have with the current setup 
is that libsndfile only writes a PEAK chunk for floating-point files 
(need that for WAVE_EX too of course); there was no such restriction 
when we defined PEAK, and I find plenty of uses for it with all sample 
formats. But that is not so much a Csound-specific question.

Richard Dobson



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

This bit of code might be responsible for it:

     if (!(O->outformat == AE_FLOAT || O->outformat == AE_DOUBLE) ||
         (O->filetyp == TYP_WAV || O->filetyp == TYP_AIFF ||
          O->filetyp == TYP_W64))
       csound->spoutran = spoutsf;       /* accumulate output */
     else
       csound->spoutran = spoutsf_noscale;

I wonder if adding O->filetyp == TYP_WAVEX to the check would fix it.  
The question really is: do we need this code or could we just use  
spoutsf() always?

That would make more sense to me. Perhaps we should move this  
discussion to the developers' list. I would like John's opinion on this.

Victor


On 4 Nov 2009, at 22:26, Richard Dobson wrote:

> Victor Lazzarini wrote:
>> But if I write a headerless float file (-fh), Csound does not write  
>> it in the correct normalised range (-1.0 to 1.0) but uses the set  
>> 0dbfs (=32767), so that bit is wrong.
>
>
> Thats would depend entirely on what the rules are for headerless  
> (raw?) files. I remember Istvan being especially insistent that raw  
> floats files should receive exactly the unmodified output values -no  
> scaling of any kind, presumably not even 0dbfs. I have no opinion on  
> the proper writing of raw files (other than it should be known and  
> documented so people know what to expect).  My concern with 0dbfs  
> etc is entirely with regard to the standard headered formats that do  
> mandate ranges.
>
> Richard Dobson
>
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"



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